MPLS with Traceroute and Ping / How tracert traceroute works
The first part of this document will show how the traceroute or tracert command works, while the second part of the show how traceroutes can show misleading values on MPLS networks.
How the Traceroute Command Works:
IP packets have a field in their header called TTL (time to live) which is a value set when the packet is first sent, and decreases by one for each router it passes through. This helps prevent routing loops, when a packet has reached a TTL of 0 it will send a packet back to the sender stating it never reached its destination.
Say for example we have 3 locations, location1, location2, and location3 – to reach location3 from location 1, we must go through location2. Traceroute takes advantage of TTLs by setting them low. For exaple if you did a traceroute from location1 to location3, traceroute would set the TTL to 1 to start with, and once the packet reached location2 its TTL would be decreased to 0 and would be returned back to the origin (location1) with a TTL expired error. Traceroute can continue finding the path by incrementing the TTL, until it finally reaches its destination.
MPLS and Traceroute:
Taking the same scenario where completing a traceroute from location1 to location3, via location 2 we will take a look how this would effect the results. MPLS calculates the path before the packet is transmitted, it is designed to help take load of intermediate routers. location2 router would first forward the packet to location3 before realising that its TTL was 0, so you would have a false increase in latency for that hop.
Tracing route to [188.8.131.52]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms office.syd.crucialx.net [192.168.1.254]
2 16 ms 15 ms 15 ms loop0.lns4.syd7.internode.on.net
3 15 ms 15 ms 15 ms gi0-204.cor1.syd7.internode.on.net
4 173 ms 173 ms 173 ms gi0-0.bdr1.syd7.internode.on.net
5 205 ms 205 ms 205 ms pos2-0.bdr1.sjc2.internode.on.net
6 174 ms 174 ms 174 ms ge-7-20.car1.SanJose1.Level3.net
7 217 ms 216 ms 216 ms ae-31-53.ebr1.SanJose1.Level3.net
Taking a look at the 3rd and 4th hops, it can be seen that the latency increased to 173ms eventhough the hop is in the same city.