traceroute with mpls question

[c.walsh]

Hi,

     We have a customer, who is getting intermittant poor response issues over their MPLS network.

When they experience these issues & do a traceroute between the 2 sites, they get the following output...

traceroute to  10.0.0.2 (10.0.0.2), 30 hops max, 60 byte packets

  1  cs-c65core1  (192.0.0.250)  0.748 ms  1.036 ms  1.024 ms

  2  192.0.0.15  (192.0.0.15)  1.613 ms  1.613 ms  1.606 ms

  3  192.168.50.5  (192.168.50.5)  2.092 ms  2.910 ms  2.905 ms

4  * * *

  5  * * *

  6   bristol-mpls-router (192.168.50.22)  15.663 ms * *

What is the reason for replies 4 & 5?

Thanks

Colin

[royalblues]

Devices in the path may be configured with " no ip unreachables" command and hence will not send an icmp unreachable message back to the source.

Narayan

[c.walsh]

I would have thought the routers in the MPLS core would be configured the same.

We only see this reply when there are performance issues & packets are being lost in the core!

[lacirasella]

Did you have CoPP enable on these router or rate-limiter?

maybe also increase the hod-queue on the related interfaces...

[c.walsh]

This is an intermittant issue in the service providers core, we have no access to the routers.

Problem is they won't admit to any issues, just wanted to understand what is happening when we see what appears to be timeouts in the traceroute output

[Giuseppe Larosa]

Hello Colin,

if I have understood  your issue, you see the '*' only in some cases during time periods of low performance on the MPLS service.

As suggested by Narayan routers within an MPLS cloud need a specific configuration to be able to answer to traceroute probe packets.

A possible interpretation is that when you face issues the provider has has troubles on the normal path they use and your traffic is rerouted via another path where:

two routers can have different settings regarding ICMP unreachables or they are too busy with links saturated and other cpu intensive tasks and they don't answer.

Also service provider routers can have the control plane policing (CoPP) configured as suggested by the other colleague and one possible effect is that they skip to answer with an ICMP unreachable to your traceroute probe.

You should compare traceroute results in good conditions and during issues to see if the number of hops change of if any of the IP address changes this would mean your traffic is taking an alternate path.

If the path doesn't change CoPP on SP routers can explain this and it can be seen a sign of great activity in the signalling plane that may lead also to performance issues.

Hope to help

Giuseppe

[bernatellez]

I have seen that some times when on the SP routers has the no mpls ip propagate forward command enable, that command basically hides the SP MPLS infrastructure from custumers, but you have to enable it on all routers to work as should. Maybe when you have issues on your net it's because the SP is using a backup link(with less resources or bandwidth) on some routers that has the no mpls ip propagate forward command.

Check this Link for more info: Disabling MPLS TTL Propagation