Hello,
I have an issue with MPLS/LDP.
When label local advertise explicit-null (Ipv4 address-family) is active, the looback interface of my Linux box is unable to receive any kind of traffic. If I disable the feature and a label popping is made by the last "P" router (Cisco IOS XR) the traffic flows correctly.
I performed tcpdump and I see that the traffic is coming into the eth interface with a label identified by "0" that's correct for explicit-null. It seems that no label popping is perfomed by my Linux Box and traffic sent to the loopback interface.
I'm using FRR 7.2.1 on Ubuntu 18.04 with Kernel 5.5.1
Did you enable MPLS forwarding on the interfaces of your Linux box (loopback included)?
Reference: http://docs.frrouting.org/projects/dev-guide/en/latest/building-frr-for-ubuntu1804.html#enable-mpls-forwarding
Yes. Enabled on all interfaces:
root@rs01-pdgs36:~# sysctl -p
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.mpls.conf.ens4.input = 1
net.mpls.conf.ens5.input = 1
net.mpls.conf.lo.input = 1
net.mpls.platform_labels = 100000
Tcpdump shows:
14:24:42.048426 MPLS (label 0, exp 0, [S], ttl 254) IP 185.4.155.6 > 185.4.155.9: ICMP echo request, id 28965, seq 226, length 80
14:24:44.068046 MPLS (label 0, exp 0, [S], ttl 254) IP 185.4.155.6 > 185.4.155.9: ICMP echo request, id 28965, seq 227, length 80
185.4.155.9 is loopback address of Linux BOX
185.4.155.6 is the IOS XR device.
As you can see no ICMP echo answer is generated by the Linux OS. I'm expecting to see an MPLS packet with the ICMP answed
Interesting. What kernel version are you using? I have someone else reporting a similar problem with explicit-null labels on kernel 4.15.
Also, please ensure that your Linux box has a route to reply to 185.4.155.6.
I started with 4.15 but I upgraded to 5.5.1.
Linux rs01-pdgs36 5.5.1-050501-generic #202002011032 SMP Sat Feb 1 10:34:22 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
I confim I have a route to reply to 185.4.155.6. I'm using IS-IS that is working correcly.
I built FRR form source.
Hello,
As your are running FRR on Ubuntu, you felt into the same problem I discovered with OSPF Segment Routing a while ago. Ubuntu activate by default RP filter at the kernel level to protect the PC from incorrect formatted incoming packets. In particular, the RP filter removes packets that have for destination e.g. the loopback address but that come with a different IP address that the loopback address one. This occurs when you received an MPLS encapsulated packet with the IP address of the loopback interface and add a rule to forward the packet to the loopback interface. And, RP filter deletes packets at a very low level in the kernel in sort that you see nothing with tcpdump.
You could look at this document: https://github.com/FRRouting/frr/blob/master/doc/developer/ospf-sr.rst#configuration that gives indication to remove RP filter:
systcl -w net.ipv4.conf.all.rp_filter=0
sysctl -w net.ipv4.conf.lo.rp_filter=0
Can you try to disable RP filter and let us know if it solves your problem?
Hello.
thank you for your support. Disabling RP filter all works as expected!
Most helpful comment
Hello,
As your are running FRR on Ubuntu, you felt into the same problem I discovered with OSPF Segment Routing a while ago. Ubuntu activate by default RP filter at the kernel level to protect the PC from incorrect formatted incoming packets. In particular, the RP filter removes packets that have for destination e.g. the loopback address but that come with a different IP address that the loopback address one. This occurs when you received an MPLS encapsulated packet with the IP address of the loopback interface and add a rule to forward the packet to the loopback interface. And, RP filter deletes packets at a very low level in the kernel in sort that you see nothing with tcpdump.
You could look at this document: https://github.com/FRRouting/frr/blob/master/doc/developer/ospf-sr.rst#configuration that gives indication to remove RP filter:
Can you try to disable RP filter and let us know if it solves your problem?