[sfc-dev] [opnfv-tech-discuss] [SFC] Slides to show OpenStack NSH Issues

Edward Warnicke hagbard at gmail.com
Sat Aug 29 15:54:48 UTC 2015


Sam,

I had thought this would be the IP address assigned to the VM, did you plan
on assigning it some other way?

Ed

On Sat, Aug 29, 2015 at 4:02 AM, Sam Hague <shague at redhat.com> wrote:

> Ed,
>
> if the IP address is dummy IP just for looping back to the bridge there
> shouldn't be a collision. That just moves the problem to the dummy IP, but
> that should be easier to manage.
>
> We could also use another match for the descriminator instead of or in
> combination with the udp port. Overloading some other field is an option.
>
> This *should* only be something used via this loopback. So it really isn't
> exposed much and shouldn't conflict with hardly anything.
>
> Sam
>
> On Fri, Aug 28, 2015 at 5:37 PM, Edward Warnicke <hagbard at gmail.com>
> wrote:
>
>> Sam,
>>
>> How do we avoid port collisions?  Meaning, how do we ensure we are the
>> unique users of a port that is not a well known port for the port
>> discriminator?
>>
>> Ed
>>
>> On Fri, Aug 28, 2015 at 2:11 PM, Sam Hague <shague at redhat.com> wrote:
>>
>>> Tim,
>>>
>>> yeah, my current setup is using the udp port to disciminate the SF. Then
>>> just flows to add the headers to make it go to the right VM. And we can do
>>> all that because we know the tenant mapping.
>>>
>>> If you use br-int's dst mac you end up hitting the issue where OVS adds
>>> drop flows, so you have to use a different dst mac. Which then means adding
>>> an arp response flow. I have that working now. It's possible using a
>>> different internal port other than br-int might behave differently so we
>>> can check that also. The key though, is once we have that VxLAN encapped
>>> packet into the bridge we can add any flows we want to change the dst mac
>>> and dst ip since we know all the mappings.
>>>
>>> Sam
>>>
>>> On Fri, Aug 28, 2015 at 4:52 PM, Tim Rozet <trozet at redhat.com> wrote:
>>>
>>>> Hi Ed,
>>>> I think a VXLAN GPE packet leaving the br-int to would have the
>>>> destination ip address as 10.0.0.1 + unique UDP port.  The ethernet dest
>>>> would be written as br-int's since there is a an ip route directing the
>>>> packet to br-int as the next hop.  That packet gets into the bridge, and
>>>> OpenFlow takes over.  Due to the fact that it went out a unqiue VTEP (UDP
>>>> port), we can have a rule that matches the return UDP port (that we know
>>>> maps to a particular VNID).  Since the VNID separates the tenant networks,
>>>> we know which 10.0.0.1 VM the packet refers to and can set the output port.
>>>>
>>>> Tim Rozet
>>>> Red Hat SDN Team
>>>>
>>>> ----- Original Message -----
>>>> From: "Edward Warnicke" <hagbard at gmail.com>
>>>> To: "Tim Rozet" <trozet at redhat.com>
>>>> Cc: "Sam Hague" <shague at redhat.com>, sfc-dev at lists.opendaylight.org,
>>>> opnfv-tech-discuss at lists.opnfv.org
>>>> Sent: Friday, August 28, 2015 4:43:54 PM
>>>> Subject: Re: [opnfv-tech-discuss] [sfc-dev] [SFC] Slides to show
>>>> OpenStack NSH Issues
>>>>
>>>> Tim,
>>>>
>>>> From your example, say I have two VMs (VM1, and VM2) both having ip
>>>> 10.0.0.1 (because they are in different tenants).
>>>> How does the local IP stack determine the correct MAC address to put on
>>>> the
>>>> packet?
>>>>
>>>> Ed
>>>>
>>>> On Fri, Aug 28, 2015 at 1:10 PM, Tim Rozet <trozet at redhat.com> wrote:
>>>>
>>>> > Hey Ed,
>>>> > For the idea where you route back to the the bridge to preserve the
>>>> vxlan
>>>> > header (first idea), you mentioned the overlapping IP space problem.
>>>> Sam
>>>> > came up with a solution where you can identify tenants by assigning
>>>> them a
>>>> > unique VXLAN tunnel UDP port to differentiate.  I kind of drew up a
>>>> working
>>>> > diagram to how this would work here:
>>>> >
>>>> > https://gist.github.com/trozet/2d892bfb11a4f66371a7
>>>> >
>>>> > I'm not saying this is the only solution, but it is one that I think
>>>> will
>>>> > work.  I agree that it doesn't solve the root problem, but it allows
>>>> us to
>>>> > make progress in OPNFV SFC in the meantime.  The other nice thing
>>>> about
>>>> > this solution is that it preserves the previously created neutron
>>>> > networks.  So SFs will still be reachable as it normally would in it's
>>>> > neutron network.
>>>> >
>>>> > The downside to this solution include modfying routing tables on a
>>>> host,
>>>> > along with creating an extra VTEP interface on every OVS bridge for
>>>> every
>>>> > SFC tenant.
>>>> >
>>>> > Tim Rozet
>>>> > Red Hat SDN Team
>>>> >
>>>> > ----- Original Message -----
>>>> > From: "Edward Warnicke" <hagbard at gmail.com>
>>>> > To: "Sam Hague" <shague at redhat.com>
>>>> > Cc: sfc-dev at lists.opendaylight.org,
>>>> opnfv-tech-discuss at lists.opnfv.org
>>>> > Sent: Friday, August 28, 2015 3:20:31 PM
>>>> > Subject: Re: [opnfv-tech-discuss] [sfc-dev] [SFC] Slides to show
>>>> > OpenStack      NSH Issues
>>>> >
>>>> > Sam,
>>>> >
>>>> > I had a long talk on IRC with Tim about this, and I believe we have
>>>> > misidentified the root issue.
>>>> >
>>>> > The problem is not that the VXLAN (or other) encap is being stripped
>>>> off
>>>> > by the bridge. The proper tunnel dest for the frame being delivered
>>>> to the
>>>> > SF
>>>> > is the IP of the SF, not the bridge. The problem is that we can only
>>>> encap
>>>> > by sending the packet to a tunnel port on OVS, and
>>>> > that tunnel port then dumps to the hosts local IP stack. It should be
>>>> > noted, that this is an issue for tunnels in general for OVS, not just
>>>> > VXLAN, or NSH.
>>>> >
>>>> > The root problem is that when you use a port to encap, you have
>>>> committed
>>>> > to having the local IP stack deliver it, and loose control over the
>>>> OUTPUT
>>>> > port for the encapped packet.
>>>> >
>>>> > Looking at the proposed solutions, the "Hybrid VxLAN Tunnel" solution
>>>> > proposed doesn't work because it relies on us manipulating the local
>>>> hosts
>>>> > IP routing tables, and if you get overlapping IP spaces (which you
>>>> will)
>>>> > that will fail (among other issues).
>>>> >
>>>> > This same issue is going to break the other proposed solutions:
>>>> >
>>>> > "Change Port Type from tap to VxLAN", "NSH Proxy", and "Add Linux
>>>> Bridge"
>>>> >
>>>> > If we had a proper push/pop vxlan header OpenFlow Action, we could
>>>> simply
>>>> > use that to encap and output to the port of our choosing, including
>>>> > the tap port.
>>>> >
>>>> > I think this is what you mean with the solution "Modify OVS to pass
>>>> > VxLAN/NSH over Tap Ports". As far as I can see, this is really the
>>>> only
>>>> > viable option.
>>>> >
>>>> > I would suggest we look into getting such a proper solution to the
>>>> root
>>>> > issue, rather than hacking around in ways that are likely to produce
>>>> even
>>>> > more technical debt.
>>>> >
>>>> > Ed
>>>> >
>>>> >
>>>> > On Thu, Aug 27, 2015 at 10:32 AM, Sam Hague < shague at redhat.com >
>>>> wrote:
>>>> >
>>>> >
>>>> >
>>>> > Ed,
>>>> >
>>>> > they do - but at that point the VxLAN/NSH has already been stripped on
>>>> > ingress to the bridge. The headers are stored in metadata but that
>>>> doesn't
>>>> > get added back unless the packets egresses a vlxan port.
>>>> >
>>>> > So some of the solutions revolve around sending the packets out a
>>>> VxLAN
>>>> > port so the headers are added and try to get that packet into the SF -
>>>> > without the headers stripped or packets dropped. But you need to
>>>> bypass the
>>>> > OVS desire to expect vtep ports when it received VxLAN encapped
>>>> packets. We
>>>> > are in the middle of testing variations on how to do that.
>>>> >
>>>> > Tim mentioned you had a variation of using the IP of the SF to do that
>>>> > bypass mentioned above to get the encapped packets sneaking through
>>>> the
>>>> > bridge to the SF. That is on the list of things to try since it is a
>>>> slight
>>>> > variation.
>>>> >
>>>> > Sam
>>>> >
>>>> > On Thu, Aug 27, 2015 at 12:13 PM, Edward Warnicke < hagbard at gmail.com
>>>> >
>>>> > wrote:
>>>> >
>>>> >
>>>> >
>>>> > Sam,
>>>> >
>>>> > Question... don't tap ports simply carry ethernet frames up to the
>>>> guest?
>>>> >
>>>> > Ed
>>>> >
>>>> > On Thu, Aug 27, 2015 at 8:57 AM, Sam Hague < shague at redhat.com >
>>>> wrote:
>>>> >
>>>> >
>>>> >
>>>> > Hi all,
>>>> >
>>>> > I had the acttion items to create slides showing the issues when using
>>>> > OpenStack instantiated VMs that cannot terminate VxLAN/NSH tunnels.
>>>> Those
>>>> > are at [slides]. W can use this as a basis for working out the
>>>> solutions.
>>>> >
>>>> > Thanks, Sam
>>>> >
>>>> >
>>>> > [slides]
>>>> >
>>>> https://docs.google.com/presentation/d/1y0A1DNA1bB6y-1hR-ZfvtW8cKL4psMvj8BdaEMC4n2I/edit?usp=sharing
>>>> >
>>>> > _______________________________________________
>>>> > sfc-dev mailing list
>>>> > sfc-dev at lists.opendaylight.org
>>>> > https://lists.opendaylight.org/mailman/listinfo/sfc-dev
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > opnfv-tech-discuss mailing list
>>>> > opnfv-tech-discuss at lists.opnfv.org
>>>> > https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>>>> >
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/sfc-dev/attachments/20150829/80949876/attachment.html>


More information about the sfc-dev mailing list