MPLS and traceroute timed-outs

RouterOS Forwarding Protocols
1

Hey guys.

I have a rather strange problem with MPLS and traceroute.

/tool> traceroute 10.0.0.1
 # ADDRESS                                 RT1   RT2   RT3   STATUS
 1 0.0.0.0                                 0ms   0ms   0ms
 2 0.0.0.0                                 0ms   0ms   0ms
 3 0.0.0.0                                 0ms   0ms   0ms
 4 10.0.0.1                                3ms   3ms   2ms

/tool> traceroute 10.0.0.1
 # ADDRESS                                 RT1   RT2   RT3   STATUS
 1 10.1.23.1                               3ms   2ms   2ms   <MPLS:L=19,E=0>
 2 10.1.22.1                               3ms   2ms   2ms   <MPLS:L=114,E=0>
 3 10.1.21.1                               3ms   4ms   3ms   <MPLS:L=28,E=0>
 4 10.0.0.1                                3ms   2ms   2ms

These traces were done right after each other. As you can see, in the first one, the hops are not responding, but in the traceroute done right after, they all respond correctly.
After the first traceroute, I can traceroute as much as I want and it all works. Only the first traceroute is timed-out.

However, if I wait about 1 minute, the situation repeats.
Again, for the first traceroute the hops dont respond, but for next traceroutes, all works.

Any idea what may be causing this?
OSPF is used as IGP and MPLS config on all LSR is:

/mpls interface
set [ find default=yes ] mpls-mtu=1512
/mpls ldp
set distribute-for-default-route=yes enabled=yes lsr-id=$LoopbackIP transport-address=$LoopbackIP
/mpls ldp interface
add interface="eth1 - b1.wlan1.local"
add interface="eth2 - b2.wlan1.local"

Thanks!

2

I’m having the same issue on one routerboard. MPLS is working. Labels are exchanged. Traffic is going through the VPLS tunnels without any problems. I can ping the routers (loopback adddresses). So, how to interpret this “problem”? :smiley:

3

Actually, its a firewall problem.

Due to ICMP behaviour with MPLS (ICMP errors switched to the destination), the firewall on the LER considers the initial ICMP packets as invalid, and blocks them. When the final ICMP packet comes in, the ICMP “session” is properly entered into the connection tracking table, and subsequent ICMP traces are not considered as “invalid” traffic.

Short answer: the “block invalid” firewall rule is causing it.

4

Thank you for the quick response!