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

Edward Warnicke hagbard at gmail.com
Fri Aug 28 20:43:54 UTC 2015


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/20150828/63f23f0e/attachment.html>


More information about the sfc-dev mailing list