Hi Banszel,

Please see inline. 

Thanks,
Cathy 

-----Original Message-----
From: Banszel, MartinX [mailto:martinx.bans...@intel.com] 
Sent: Tuesday, June 14, 2016 9:07 AM
To: openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Reply via email to