On Sat, Mar 18, 2017 at 10:23 AM, Renato Westphal <renato@opensourcerouting.org> wrote:
On Sat, Mar 18, 2017 at 9:45 AM, Renato Westphal <renato@opensourcerouting.org> wrote:
On Sat, Mar 18, 2017 at 2:27 AM, Roopa Prabhu <roopa@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-L1... 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