No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Time delay jump during traceroute in vpn instance becase of theory of vpn

Publication Date:  2012-07-27 Views:  51 Downloads:  0
Issue Description
  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
   
      
Alarm Information
  Time delay jump on P1. 
Handling Process
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.
            
Root Cause
1, Link problem;
2, Others;
      
Suggestions
Null 
      

END