Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Community Member

TCP Traffic is delayed through tunnel - we think...

We are trying to work out a delay issue related to VoIP control traffic to a remote site... When someone pressing a button on a remote phone the response is delayed.

One thing I noticed today at the head end, trace routes to the remote side look weird.

Has anyone seen this before on a VPN?

Site A Site B

Site A is a 2811 IP

Site B is a 2651XM IP

Device on far side being traced is

traceroute to (, 64 hops max, 40 byte packets

1 ( 1.418 ms 0.794 ms 0.772 ms

2 * * *

3 ( 52.994 ms 52.466 ms 52.409 ms

Ping works fine..

PING ( 56 data bytes

64 bytes from icmp_seq=0 ttl=126 time=53.184 ms

64 bytes from icmp_seq=1 ttl=126 time=53.090 ms

64 bytes from icmp_seq=2 ttl=126 time=54.501 ms

64 bytes from icmp_seq=3 ttl=126 time=52.957 ms

64 bytes from icmp_seq=4 ttl=126 time=52.424 ms


--- ping statistics ---

5 packets transmitted, 5 packets received, 0% packet loss

round-trip min/avg/max/stddev = 52.424/53.231/54.501/0.687 ms

Community Member

Re: TCP Traffic is delayed through tunnel - we think...

That all looks fine to me. The "missing" traceroute reply is from the far end router. Since it is terminating the VPN it will not "see" the traffic in decrypted form.

Look elsewhere for your issue.

In general networks cannot store packets for very long, so if you are seeing delays in response they will be caused by either the end stations or by packet losses and retransmission timeouts before retransmitions.

54ms RTT indicates either that you are using DSL technology, have the end stations 2000 miles apart or that the link is busy such that the packet queues are full on the router.

Community Member

Re: TCP Traffic is delayed through tunnel - we think...

Both sides are DSL based.

Thanks for the reply (rated) that let's me know that missing reply is normal.

CreatePlease to create content