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

Sam Hague shague at redhat.com
Fri Aug 28 20:56:15 UTC 2015


agreed. I think the best solution is to modify the OVS code to make it
easier to add these headers. That will take time so the slides were really
a way to communicate the current problem and start the conversation.

As you and Tim talked yesterday, we have the start of one workaround to get
the VxLAN/NSH into the tap attached VM's. I say the start because you have
have some issues:
- some way to discriminate the SF: use the udp dst port, use more IPs
- rewrite macs
- routing table modifications

Thanks, Sam

On Fri, Aug 28, 2015 at 3:20 PM, Edward Warnicke <hagbard at gmail.com> wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/sfc-dev/attachments/20150828/fddb32a3/attachment-0001.html>

More information about the sfc-dev mailing list