Open Stack

Hi Banszel,

Please see inline. 

Thanks,
Cathy 

-----Original Message-----
From: Banszel, MartinX [mailto:martinx.banszel at intel.com] 
Sent: Tuesday, June 14, 2016 9:07 AM
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] networking-sfc: unable to use SFC (ovs driver) with multiple networks

Hello,

I'd need some help with using the SFC implementation in openstack.

I use liberty version of devstack + liberty branch of networking-sfc.

It's not clear to me if the SFC instance and it's networks should be separated from the remaining virtual network topology or if it should be connected to it.

E.g. consider the following topology, where SFC and its networks net2 and net3 (one for ingress port, one for egress port) are connected to the tenants networks. I know that all three instances can share one network but a use case I am trying to implement requires that every instance has it's separated network and there is a different network for ingress and egress port of the SF.

 +-------+                     +---------+                 +-------+
 | VMSRC |                     |  VMSFC  |                 | VMDST |
 +---+---+                     +--+---+--+                 +---+---+
     | p1 (1.1.1.1)             p2|   |p3                      |p4 (4.4.4.4)
     |                            |   |                        |
-----+--------+------- net1       |   |                  --+---+--------- net4
              |                   |   |                    |
              |          ---+-----+---)---- net2           |
              |          ---)--+------+---- net3           |
              |             |  |                           |
              |          +--+--+--+                        |
              +----------+ ROUTER +------------------------+
                         +--------+


All networks are connected to a single router ROUTER. I created a flow classifier that matches all traffic going from VMSRC to VMDST (--logical-source-port p1 --source-ip-prefix=1.1.1.1/32 --destination-ip-prefix=4.4.4.4/32), port pair p2,p3, a port pair group containing this port pair and a port chain containing this port pair group and flow classifier.

If I try to ping from VMSRC the 5.4.4.4 address, it is correctly steered through the VMSFC (where just the ip_forwarding is set to 1) and forwarded back through the p3 port to the ROUTER.  The router finds out that there are packets with source address 1.1.1.1 coming from port where is should not (the router expects those packets from the net1 interface), they don't pass the reverse path filter and the router drops them.

It works when I set the rp_filter off via sysctl command in the router namespace on the controller. But I don't want to do this -- I expect the sfc to work without such changes.

Is such topology supported? What should the topology look like?

Cathy> No, current networking-sfc does not support this topology. 

I have noticed, that when I disconnect the net2 and net3 from the ROUTER, and add new routers ROUTER2 and ROUTER3 to the net2 and net3 networks respectivelly and don't connect them anyhow to the ROUTER nor the rest of the topology, the OVS is able to send the traffic to the p2 port on the ingress side. However, on the egress side the packet is routed to the ROUTER3 which drops it as it doesn't have any route for it.
Cathy> Router3 will not have any rule to forward the packet since networking-sfc does not install any new forwarding rules into a Router, that is why it is dropped. Anyway the current implementation does not have proper support for chain across multiple subnets. If you put VMSRC and VMSFC in the same subnet and VMDST in another subnet, it should work. 

Thanks for any hints!

Best regards
Martin Banszel
--------------------------------------------------------------
Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev