[openstack-dev] networking-sfc: unable to use SFC (ovs driver) with multiple networks

Na Zhu nazhu at cn.ibm.com
Mon Jun 27 07:34:09 UTC 2016


Hi MartinX,

I think you can move p2 to net1 and p3 to net4, or you can put p1, p2, p3 
and p4 in the same network.



Regards,
Juno Zhu
IBM China Development Labs (CDL) Cloud IaaS Lab
Email: nazhu at cn.ibm.com
5F, Building 10, 399 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong New 
District, Shanghai, China (201203)



From:   Cathy Zhang <Cathy.H.Zhang at huawei.com>
To:     "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev at lists.openstack.org>, "martinx.banszel at intel.com" 
<martinx.banszel at intel.com>
Date:   2016/06/22 02:36
Subject:        Re: [openstack-dev] networking-sfc: unable to use SFC (ovs 
driver) with multiple networks



Hi MartinX,

I sent you a reply on 6/14. 

Cathy

-----Original Message-----
From: Banszel, MartinX [mailto:martinx.banszel at intel.com] 
Sent: Thursday, June 16, 2016 4:49 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?

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.

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

----- Message from Cathy Zhang <Cathy.H.Zhang at huawei.com> on Wed, 15 Jun 
2016 00:58:33 +0000 -----
To:
"OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev at lists.openstack.org>
cc:
Cathy Zhang <Cathy.H.Zhang at huawei.com>
Subject:
RE: networking-sfc: unable to use SFC (ovs driver) with multiple networks
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
__________________________________________________________________________
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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160627/ec93b3f1/attachment-0001.html>


More information about the OpenStack-dev mailing list