All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
IPv6 Ping Latency
I've noticed when pinging an IPv6 host the first ping response will be several hundred ms higher then subsequent responses. It seems to happen more often when pinging via hostname which I figured was just the time it took for a DNS resolve, yet it does happen sometimes on just pinging an IPv6 address.
Any clues to what might be causing this?
IPv4 works fine, most systems are running KVM/XEN but it happens on my OpenVZ as well. It happens on different boxes with different networks, only thing in common is they all run Debian.
ping6 2a00:dcc0:eda:88:245:71:2da2:12d5 PING 2a00:dcc0:eda:88:245:71:2da2:12d5(2a00:dcc0:eda:88:245:71:2da2:12d5) 56 data bytes 64 bytes from 2a00:dcc0:eda:88:245:71:2da2:12d5: icmp_seq=1 ttl=49 time=707 ms 64 bytes from 2a00:dcc0:eda:88:245:71:2da2:12d5: icmp_seq=2 ttl=49 time=168 ms 64 bytes from 2a00:dcc0:eda:88:245:71:2da2:12d5: icmp_seq=3 ttl=49 time=168 ms ping6 italy.sonicboxes.net PING italy.sonicboxes.net(italy.sonicboxes.net) 56 data bytes 64 bytes from italy.sonicboxes.net: icmp_seq=1 ttl=53 time=552 ms 64 bytes from italy.sonicboxes.net: icmp_seq=2 ttl=53 time=154 ms 64 bytes from italy.sonicboxes.net: icmp_seq=3 ttl=53 time=154 ms
Try any of my looking glass severs (aside from buffalo) if you want to see for yourself.
Germany: PING google.com(muc03s02-in-x05.1e100.net) 56 data bytes 64 bytes from muc03s02-in-x05.1e100.net: icmp_seq=1 ttl=56 time=73.4 ms 64 bytes from muc03s02-in-x05.1e100.net: icmp_seq=2 ttl=56 time=7.68 ms 64 bytes from muc03s02-in-x05.1e100.net: icmp_seq=3 ttl=56 time=7.88 ms
I'm hoping one of our networking guru's has an answer.
Comments
More than likely it's the time to setup CEF style entries, the first packet might be CPU switched, and the rest are ASIC switched.
If I repeat the ping to the same host, the ping time is correct, that's why I figured it was DNS related. I'm not that familiar with Cisco equipment, so I don't know if I understand this correctly, do they expire after X period?
Also, pretty much all of my hosts have this problem, is it possible they're all using similar gear?
CPU Switching packets is slow, ASIC switching packets is fast. Even a firewall will do a CPU lookup in it's tables to allow traffic before pushing it down to ASIC's for processing.
The most generic term we have for it is FastPath or in cisco land CEF.
And if your upstream has the wrong switch it might all be CPU bound, but it would crap itself pretty quickly.
If you barely use IPv6 except than for those pings, most likely the ND entry (a record of which IPv6 address corresponds to which MAC address) gets expired in the router's cache, so on the first ping6 packet the router (or your VPS, to reach the router) has to do multicast on their LAN to resolve IPv6->MAC again. Not sure if it should take this long, though.
I could understand that if it was just the first packet of IPv6 sent in awhile, but if I send a ping to an address, then ping a different address, I still have the delay in the first response from ping.
@nunim maybe nobody pinged that address for a long time, so there is the same neighbor discovery learning process happening but on the other end.
He probably used a 6to4 tunnel or teredo. That can also account to first time ping beeing high while tunnel is beeing established. Quite normal actually. You can read the appropriate documentation for it.
Just a question. I've never used ipv6 before, can i set ipv6 to use eth0, the same as my ipv4 or do ipv6 and ipv4 have to be on different device/interface?
Normal for Teredo, but not for 6to4. It is not being reestablished, 6to4 in general is not being "established" in any sense of the word at all. And anyways, I don't think @nunim is on a tunnel.
I have just tried pinging the same hostname from different servers and the first response display is still present.
I don't have any tunnels setup (except on my Buffalo server), all my hosts have told me that it's native IPv6.