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

Tim Rozet trozet at redhat.com
Sat Aug 29 23:35:07 UTC 2015


    
Yeah if you are discriminating every SF by udp port then you only need 1 dummy ip.  Problem is now you need a vtep created for every sf, and more udp ports used up.
-Tim


Sent via the Samsung GALAXY S®4 Active™, an AT&T 4G LTE smartphone

-------- Original message --------
From: Sam Hague <shague at redhat.com> 
Date: 08/29/2015  7:29 PM  (GMT-05:00) 
To: Edward Warnicke <hagbard at gmail.com> 
Cc: Tim Rozet <trozet at redhat.com>, sfc-dev at lists.opendaylight.org, opnfv-tech-discuss at lists.opnfv.org 
Subject: Re: [opnfv-tech-discuss] [sfc-dev] [SFC] Slides to show OpenStack NSH Issues 

Ed,

one idea was to use a single dummy IP + some other descriminator. This was
to avoid overlapping IPs and to not expose the tenant IPs. The idea was
this was something local only to this node so it was flexible. But if you
do have some other descriminator then I guess it doesn't matter what IP you
use and also avoid the overlaps.

Sam

On Sat, Aug 29, 2015 at 11:54 AM, Edward Warnicke <hagbard at gmail.com> wrote:

> 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/21c02719/attachment-0001.html>


More information about the sfc-dev mailing list