Deckert
Well-Known Member
Hi,
As of late., we're experiencing significant disruptions from the Xneelo datacenter to/from international destinations for packets larger than 1476 bytes. The default is 1500 bytes, but at the time of this writing, any packet larger than 1476 bytes is simply dropped.
Is anybody else experiencing this issue?
As a simple test, from your (Linux) Xneelo server, ping any international destination:
This works:
$ ping -n speedtest.london.linode.com -s 1448 -M do
PING speedtest-1.lon1.gb.prod.linode.com (176.58.107.39) 1448(1476) bytes of data.
1456 bytes from 176.58.107.39: icmp_seq=1 ttl=50 time=168 ms
1456 bytes from 176.58.107.39: icmp_seq=2 ttl=50 time=167 ms
This does not:
~$ ping -n speedtest.london.linode.com -s 1449 -M do
PING speedtest-1.lon1.gb.prod.linode.com (176.58.107.39) 1448(1477) bytes of data.
^C
--- speedtest-1.lon1.gb.prod.linode.com ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5145ms
Note, the increasing packets size from 1476 to 1477 in the above two examples.
Normally, with MTU path discovery, this does not cause an issue (although it still causes degradation due to packet fragmentation), but for customer-facing VPNs this is a disaster. Further more, we cannot control the maximum MTU size on the customer's end, so we need to contact every customer and convince them that they need to reduce their MTU or add MSS clamping.
This is not an issue we see with any of the other datacenters we host in. Frustrating to say the least.
--deckert
As of late., we're experiencing significant disruptions from the Xneelo datacenter to/from international destinations for packets larger than 1476 bytes. The default is 1500 bytes, but at the time of this writing, any packet larger than 1476 bytes is simply dropped.
Is anybody else experiencing this issue?
As a simple test, from your (Linux) Xneelo server, ping any international destination:
This works:
$ ping -n speedtest.london.linode.com -s 1448 -M do
PING speedtest-1.lon1.gb.prod.linode.com (176.58.107.39) 1448(1476) bytes of data.
1456 bytes from 176.58.107.39: icmp_seq=1 ttl=50 time=168 ms
1456 bytes from 176.58.107.39: icmp_seq=2 ttl=50 time=167 ms
This does not:
~$ ping -n speedtest.london.linode.com -s 1449 -M do
PING speedtest-1.lon1.gb.prod.linode.com (176.58.107.39) 1448(1477) bytes of data.
^C
--- speedtest-1.lon1.gb.prod.linode.com ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5145ms
Note, the increasing packets size from 1476 to 1477 in the above two examples.
Normally, with MTU path discovery, this does not cause an issue (although it still causes degradation due to packet fragmentation), but for customer-facing VPNs this is a disaster. Further more, we cannot control the maximum MTU size on the customer's end, so we need to contact every customer and convince them that they need to reduce their MTU or add MSS clamping.
This is not an issue we see with any of the other datacenters we host in. Frustrating to say the least.
--deckert