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

Edward Warnicke hagbard at gmail.com
Fri Aug 28 19:20:31 UTC 2015


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/0483506c/attachment.html>


More information about the sfc-dev mailing list