CE1-----PE1-----P1--(Long distance transmission)---P2-----PE2----CE2
During customer tracert from CE1 to CE2, customer find there is a big jump of timedelay on P1. However, there is no time delay jump on P1 if tracert from PE1 to PE2 with public ip address.
Linux# traceroute 10.134.0.yy
traceroute to 10.134.0.yy (10.134.0.yy), 30 hops max, 40 byte packets
1 10.239.96.xx (10.239.96.253) 0.386 ms 0.271 ms 0.242 ms
2 10.0.216.90 (10.0.216.90) 10.129 ms 10.027 ms 9.996 ms
5 10.134.0.yy (10.134.0.yy) 10.485 ms 10.033 ms 9.965 ms
1, There is no crc error on links between PE1 and P.
2, After analyse of the theory of traceroute in vpn, we understand. The reason is as following:
If a P device on the public network receives a tracert packet with an expired TTL, the P device that has no VPN routes cannot make any response, as the tracert packet carries the VPN address. In this situation, devices on an MPLS tunnel of the public network process the packet and then forward it. This process lasts until the packet is sent to the remote PE2, which then processes the VPN packet. At this time, if a delay occurs at any hop in the tunnel, it is considered in the total delay of the entire tunnel. That is, when you run the tracert ip address of CE2 command, the delay at P1 is considered as the delay of the entire tunnel. For the 10 ms delay between two P(P1 and P2) stations on a public tunnel, however, this is normal.
1, Link problem;