[dev] [frr] 2 MPLS Questions

[Renato Westphal]

On Sat, Mar 18, 2017 at 10:23 AM, Renato Westphal
<renato at opensourcerouting.org> wrote:
> On Sat, Mar 18, 2017 at 9:45 AM, Renato Westphal
> <renato at opensourcerouting.org> wrote:
>> On Sat, Mar 18, 2017 at 2:27 AM, Roopa Prabhu <roopa at cumulusnetworks.com> wrote:
>>> On 3/17/17, 10:19 PM, Vivek Venkatraman wrote:
>>>> This is correct. By definition, if a router is the penultimate hop, it
>>>> means the actual egress is downstream and has signaled (advertised) an
>>>> implicit-null label to this router. The router doing the PHP knows the next
>>>> hop to forward to (the egress) without doing any additional lookup.
>>>>
>>>> This behavior should already be supported.
>>>>
>>>> What is not supported (if I remember right) is the ability on the egress to
>>>> terminate a label and perform a (route) lookup.  That is needed to really
>>>> be able to support any L2/L3 VPN service properly.
>>>
>>> yes, correct. terminating a label and performing a route lookup is not supported
>>> today.
>>
>> The exception being the ipv4/ipv6 explicit null labels. Please take a
>> look: https://github.com/torvalds/linux/blob/master/net/mpls/af_mpls.c#L1872
>
> Correction.. the explicit-null labels don't seem to work on Linux.
>
> Using ldpd, if I configure the "label local advertise explicit-null"
> command in all nodes of a network, all LDP sessions flap every 3
> minutes (the default holdtime).
>
> I can't even ping a directly attached Linux LSR if I push an
> explicit-null label. It's like the kernel just drops all incoming
> packets that have an explicit-null label.
>
> I'm using an relatively old kernel (v4.4.0) so maybe this was fixed
> already, will check later.

Hi all,

Finally found some time to check this out and my conclusion is that
there's nothing wrong in the Linux kernel w.r.t to the handling of
explicit null labels. In other words, upon receipt of an explicit null
label the kernel is capable of popping it and performing a route
lookup.

I did some testing using several different kernel versions, ranging
from v4.4 to v4.11-rc4, and found no problems at all.

The only exception is when I'm using Ubuntu to perform the tests. On
Ubuntu, irrespective of the kernel version I'm using, incoming packets
labeled with the IPv4 null label are just dropped (the IPv6 null label
works fine though). I couldn't find out why this happens. The output
of "ip link afstats" indicates that the packets are not dropped in the
MPLS stack, but somehow fail in the route lookup. I believe that this
might be related to some obscure sysctl that is enabled on Ubuntu by
default. Using Debian I don't have the same problem.

Regarding the pop+route lookups that Olivier is interested in, I
discovered something interesting. I commented out the following two
lines and rebuilt the kernel:
https://github.com/torvalds/linux/blob/v4.11-rc4/net/mpls/af_mpls.c#L1778-L1779

Then I looked at the MPLS routing table:
# ip -M ro
0 via link 00:00:00:00:00:00 dev lo proto kernel
2 via link 00:00:00:00:00:00 dev lo proto kernel

Pretty interesting huh?

Then I discovered that adding LSPs like this is enough to perform pop
+ route lookup:
# ip -M route add 16 dev lo

I would like to hear from our kernel developers if we can consider
this as a solution to Olivier's 2nd problem or if it's just a
workaround.

Cheers.
-- 
Renato Westphal