[ovs-dev] adding an option for GRE tunneling without an Ethernet header

Lori Jakab lojakab at cisco.com
Mon Apr 14 12:06:15 UTC 2014


On 4/14/14, 3:00 PM, thomas.morin at orange.com wrote:
> Hi Lori,
>
> 2014-04-14, Lori Jakab:
>> On 4/14/14, 11:01 AM, thomas.morin at orange.com wrote:
>>> 2014-04-11, Lori Jakab:
>>>> On 4/11/14, 4:24 PM, thomas.morin at orange.com wrote:
>>>>> The result is the following:
>>>>> - an option is added to GRE tunnel port, to allow making them OVS
>>>>> l3ports
>>>> My first impression is that starting with my patches and now yours there
>>>> are a lot of different places with is_layer3 or l3port type of bool
>>>> members, but I don't really have a more elegant proposal either.
>>> Well, there is a specific need for GRE: since the protocol can traffic
>>> both with an Ethernet header and without, it is useful to be able to
>>> specify which behavior we want at port creation time.
>> I agree that it should be possible to specify the operating layer of a
>> GRE port at creation time.
> Good.
>
>>>>> - the vport-gre.c code is adapted to treat GRE ethertype consistently
>>>>> with the type of the port (i.e. on emission the GRE ethertype is chosen
>>>>> based on whether or not the skb is layer3; symmetrically on reception)
>>>>>
>>>>> I also adapted pop_eth code, so that it strips the Ethernet and VLAN
>>>>> headers, but not the MPLS headers if there is any (I only modified the
>>>>> linux kernel datapath actions, the userland datapath I left untouched
>>>>> for now).
>>>> This is an issue for LISP, since it cannot have MPLS headers in the
>>>> encapsulated packets.I see two solutions: 1) add an option to the
>>>> pop_eth action to specify if MPLS header(s) should stay there; or 2) or
>>>> just use pop_eth() as is and add push_mpls() actions to push the MPLS
>>>> headers back (they should be saved somehow).
>>>>
>>>> Or maybe there's a better solution, I'll let the core developers to
>>>> voice their opinions.
>>> Popping the MPLS header before sending the packet on the LISP tunnel is
>>> actually the right solution IMO. The flow that forwards the packet on
>>> the LISP tunnel would have a "pop_mpls" action before "output".
>> I would like to be able to create flows to encap LISP packets by
>> matching on the L3 destination address of the packet, and wildcarding
>> everything else.
> Well, as you suggest below, if the Ethernet payload is MPLS, then, until
> you have popped an MPLS label and recirculated the packet, you will not
> have access to the L3 destination address anyway (assuming there is an
> IP packet somewhere inside).
>
> And you need to keep in mind that, typically, in the general case, with
> an MPLS dataplane, you cannot derive anything (including a tunnel
> destination) from an MPLS-encapsulated IP packet IP addresses without
> also checking which was the value of the MPLS label.
>
>> The flow now have actions
>> (pop_eth,set_tunnel,output).  If I add pop_mpls after pop_eth, the flow
>> may be rejected, since there is no MPLS match. At least this is what I
>> understood from Jesse Gross how it should work in the datapath, but I
>> didn't review the patches proposed for MPLS in the datapath.
> Well, you could just match on dl_type=0x0800 (IPv4) or dl_type=0x86dd
> (IPv6), in that case, you know you don't have an MPLS label and you can
> forward the IP packet in a LISP tunnel.
>
> The day you have a valid case (which is not entirely obvious) for
> forwarding an MPLS IP payload over LISP without checking the value of
> the MPLS label, you can test that traffic is mpls in your flow in a
> similar manner before doing a pop_mpls,outout:<lisptunnelport>.
>
>
>> I think your approach would work if pop_mpls can be a no-op for flows
>> with no MPLS headers.
> See above, if you apply your LISP tunnel output action to a flow which
> only matches IP packets, you're good.
>
>
>>> Implicitly popping the mpls header along with the ethernet header does
>>> not help a lot I think; in all practical cases, assuming you need to
>>> combine MPLS and LISP, you will need to check the MPLS header anyways
>>> (in particular the label value).  Among the reasons is that, in the
>>> general case, you cannot assume that what is beyond the MPLS header
>>> would be IP.
>> True, flows with an mpls match can't even see what's after the mpls
>> headers (maybe with recirculation?).
> You are correct that only recirculation would provide that.
> And recirculation won't happen until you explicitly change (typically
> pop) the label stack.
>
>> Either way, since the LISP spec
>> only allows IPv4 or IPv6 payloads, I would only LISP encapsulate flows
>> matching on those L3 protocols, so that avoids the issue for me.
> It seems that we agree, right ?

I think so, let me mull over it for a few days :)

-Lori



More information about the dev mailing list