Sporratic ping times over pppoe

Hi everyone,

I am running linux in several locations and use IPSec to VPN them.
However recently we have swapped to PPPoE accounts (instead of
bridged). The problem is that that the packets are getting arbitrarily
delayed between one of the sites and the rest of the world.

For example, consider 2 locations, pc1 and pc2. PC1 is the PPPoE with
the problem.

If I ping PC2 from PC1 with normal size packets I get normal response:
64 bytes from X: icmp_seq=4 ttl=59 time=19.938 msec
64 bytes from X: icmp_seq=5 ttl=59 time=19.943 msec
64 bytes from X: icmp_seq=6 ttl=59 time=19.937 msec
64 bytes from X: icmp_seq=7 ttl=59 time=19.930 msec

If I do the same, but with 1300 bytes packets, every second packet (or
so) takes 10 times as long:
1308 bytes from X: icmp_seq=0 ttl=59 time=1.130 sec
1308 bytes from X: icmp_seq=1 ttl=59 time=129.944 msec
1308 bytes from X: icmp_seq=2 ttl=59 time=1.129 sec
1308 bytes from X: icmp_seq=3 ttl=59 time=129.947 msec

BUT if at any point PC2 is pinging PC1 at the same time, the ping times
are normal for both! Now how does that work?

I should note that I am using an older version of RedHat, but we have
the identical boxes at other locations that do not appear to have a
problem.

Help

Amer

- Amer

"amer" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...

> I am running linux in several locations and use IPSec to VPN them.
> However recently we have swapped to PPPoE accounts (instead of
> bridged). The problem is that that the packets are getting arbitrarily
> delayed between one of the sites and the rest of the world.

Is your VPN layered over TCP or any other technology than PPPoE at any
point? You would not expect this kind of behavior with PPPoE.

DS

Quick reply!

No; actually I have the same problem even when the VPN is down, ie
pinging outside the tunnel.

I have also discovered the following:

Pinging PC1 from PC2 (PC1 is the problem) yields similar results with
1300 byte packets:
# ping PC1 -s 1300
1308 bytes from PC1: icmp_seq=783 ttl=252 time=129.963 msec
1308 bytes from PC1: icmp_seq=784 ttl=252 time=129.966 msec
1308 bytes from PC1: icmp_seq=785 ttl=252 time=1.119 sec
1308 bytes from PC1: icmp_seq=786 ttl=252 time=1.119 sec
1308 bytes from PC1: icmp_seq=787 ttl=252 time=1.169 sec
1308 bytes from PC1: icmp_seq=788 ttl=252 time=259.956 msec
1308 bytes from PC1: icmp_seq=789 ttl=252 time=129.962 msec

But the tcpdump at the PC1 shows the following
# tcpdump -i ppp0 -tttt ip proto 1
2006-01-10 11:08:41.764977 IP PC2 > PC1: ICMP echo request, id 22786,
seq 45314, length 1308
2006-01-10 11:08:41.764977 IP PC1 > PC2: ICMP echo reply, id 22786, seq
45314, length 1308
2006-01-10 11:08:42.754977 IP PC2 > PC1: ICMP echo request, id 22786,
seq 45570, length 1308
2006-01-10 11:08:42.754977 IP PC1 > PC2: ICMP echo reply, id 22786, seq
45570, length 1308
2006-01-10 11:08:44.754977 IP PC2 > PC1: ICMP echo request, id 22786,
seq 45826, length 1308
2006-01-10 11:08:44.754977 IP PC1 > PC2: ICMP echo reply, id 22786, seq
45826, length 1308
2006-01-10 11:08:44.764977 IP PC2 > PC1: ICMP echo request, id 22786,
seq 46082, length 1308
2006-01-10 11:08:44.764977 IP PC1 > PC2: ICMP echo reply, id 22786, seq
46082, length 1308

Notice that the echo request was delayed altogether by a second
(explaining the delays). Note that the echo request and replies in the
two listings are not synchronised (ie ping listing packets do not
exactly correspond to tcpdump listing packets, but you get the idea).

I have also plugged my laptop into the modem that PC1 connects to and
ran PPPoE that way without problems. This rules out cabling + modem on
the PC1 site. I have swapped the network card out of PC1 and put a new
one in, but the problem repeats itself. So I don't think it's the
network card either.

What else could it be?

- Amer

Also,

At PC1
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:EE:B1:02:F8:89
inet addr:192.168.3.127 Bcast:192.168.3.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:68426 errors:143 dropped:0 overruns:0 frame:0
TX packets:47814 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:8497389 (8.1 Mb) TX bytes:29367975 (28.0 Mb)
Interrupt:9 Base address:0xb000

eth1 Link encap:Ethernet HWaddr 00:00:E8:4E:34:2C
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:69383 errors:0 dropped:0 overruns:0 frame:0
TX packets:74167 errors:0 dropped:0 overruns:0 carrier:0
collisions:43 txqueuelen:100
RX bytes:35861805 (34.2 Mb) TX bytes:13620570 (12.9 Mb)
Interrupt:10 Base address:0x7000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2404 errors:0 dropped:0 overruns:0 frame:0
TX packets:2404 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:254416 (248.4 Kb) TX bytes:254416 (248.4 Kb)

ppp0 Link encap:Point-to-Point Protocol
inet addr:PC1 P-t-P:XXX Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:63196 errors:0 dropped:0 overruns:0 frame:0
TX packets:67982 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:34100160 (32.5 Mb) TX bytes:11753797 (11.2 Mb)

I have also found the following post with what seem to be identical
problems. However, none of the suggested workarounds (bar pinging to
keep the traffic moving) work:

http://groups.google.com.au/group/fa...b8d81f2a21301c

On 01/10/06 04:05, amer wrote:
> Also,
>
> At PC1
> # ifconfig
> eth0 Link encap:Ethernet HWaddr 00:EE:B1:02:F8:89
> inet addr:192.168.3.127 Bcast:192.168.3.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

> eth1 Link encap:Ethernet HWaddr 00:00:E8:4E:34:2C
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

> ppp0 Link encap:Point-to-Point Protocol
> inet addr:PC1 P-t-P:XXX Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1

Try using the same MTU (1492) on all interfaces.

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
Registered Linux user #337974 <http://counter.li.org/>

Thanks Giovanni,

But the ping packet size is 1300 bytes which is already less than the
1492, so it would not make a difference.

Tried it anyway - no luck,

- Amer