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

[justincohen]

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 192.168.2.0/24 Site B 10.5.1.0/24

Site A is a 2811 IP 192.168.2.1

Site B is a 2651XM IP 10.5.1.1

Device on far side being traced is 10.5.1.15

traceroute to 10.5.1.15 (10.5.1.15), 64 hops max, 40 byte packets

1 192.168.2.1 (192.168.2.1) 1.418 ms 0.794 ms 0.772 ms

2 * * *

3 10.5.1.15 (10.5.1.15) 52.994 ms 52.466 ms 52.409 ms

Ping works fine..

PING 10.5.1.15 (10.5.1.15): 56 data bytes

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

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

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

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

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

^C

--- 10.5.1.15 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

[DouglasScott99]

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.

[justincohen]

Both sides are DSL based.

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