[ovs-discuss] [openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC andOVN

Ryan Moats rmoats at us.ibm.com
Tue Jun 21 20:09:53 UTC 2016



"discuss" <discuss-bounces at openvswitch.org> wrote on 06/17/2016 05:24:19
PM:

> From: Cathy Zhang <Cathy.H.Zhang at huawei.com>
> To: Na Zhu <nazhu at cn.ibm.com>
> Cc: Srilatha Tangirala/San Francisco/IBM at IBMUS, "OpenStack
> Development Mailing List \(not for usage questions\)" <openstack-
> dev at lists.openstack.org>, John McDowall
> <jmcdowall at paloaltonetworks.com>, discuss <discuss at openvswitch.org>
> Date: 06/17/2016 05:25 PM
> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn]
> [networking-sfc] SFC andOVN
> Sent by: "discuss" <discuss-bounces at openvswitch.org>
>
> Hi Juno,
>
> Here is an example.
>
> Src            SF           DST
> |             |  |           |
> 1             2  3           4
> OVS1==========OVS2==========OVS3
>
> For bump-in-the-wire SF type, since what it does is just to pass the
> packet from its ingress port to egress port, broadcast and multicast
> packets will form  a loop on port 2 and 3.
> This problem is not specific to SFC though. A simple way to solve
> this is to put a bump-in-the-wire SF’s port 2 and port 3 in
> different subnets. For L3 SF, this is not an issue.

The above is a good reason for following OVN's pipeline logic
and not punting a packet to an output port in the ingress pipeline
(as I first expressed concerns about in [1]).

There is a loopback check in table 34 (between the ingress and egress
pipelines) that we can look at using to break the loops - program it
to drop broadcast/multicast traffic going between ports 2 and 3 and
the loop is broken.

Ryan

[1] http://openvswitch.org/pipermail/discuss/2016-May/021419.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20160621/8468481f/attachment-0002.html>


More information about the discuss mailing list