| Slow first ping to any VE IP? It's driving me crazy! [message #21682] |
Sun, 14 October 2007 11:27  |
tomfra
Messages: 28
Registered: September 2007
|
Junior Member |
|
|
This is really a strange problem.
When I ping any of the IP addresses assigned to VEs on my Hardware Node (OpenVZ), the first ping is very often (but not always) extremely slow but the consecutive pings are OK.
I have tested this from my home PC as well as from one different server located in a different data center.
This is an example of such a ping:
PING 195.242.153.137 (195.242.153.137) 56(84) bytes of data.
64 bytes from 195.242.153.137: icmp_seq=0 ttl=55 time=401 ms
64 bytes from 195.242.153.137: icmp_seq=1 ttl=55 time=13.2 ms
64 bytes from 195.242.153.137: icmp_seq=2 ttl=55 time=10.9 ms
64 bytes from 195.242.153.137: icmp_seq=3 ttl=55 time=10.7 ms
64 bytes from 195.242.153.137: icmp_seq=4 ttl=55 time=10.6 ms
When you repeat the same ping after a short while, everything is OK. When you wait a few more minutes, it happens again. It looks like some caching mechanism is in place but I am not a "network guru".
You can try it yourself - ping 195.242.153.135, 195.242.153.137, 195.242.153.140, 195.242.153.142.
I thought it could have been caused by firewall but I disabled CSF/iptables on both the HN and VEs and the problem persisted.
Pinging the main hardware node IP always works great so it is something that has to be related to the VE network setup.
Any ideas are very welcome, it's driving me crazy!
Tomas
Do you really believe the Internet is a safe place?
IdentityCloaker.com - Take Back Your Privacy!
[Updated on: Mon, 15 October 2007 03:16] Report message to a moderator |
|
|
|
|
|
|
|
| Re: [SOLVED] Slow first ping to any VE IP? It's driving me crazy! [message #21702 is a reply to message #21692] |
Mon, 15 October 2007 08:14  |
khorenko
Messages: 533
Registered: January 2006
Location: Moscow, Russia
|
Senior Member |
|
|
Hello Tomas,
most probably you should blame ARP caching.
When you ping the host for the first time (or after some timeout) the node doesn't have a corresponding ARP entry (the destination ARP entry or default gateway ARP entry). So the node issues an ARP request for destination IP or default gateway IP or IP of the next gateway. This takes time, and the same algorithm is true for each gateway the packet goes through.
--
Konstantin.
If your problem is solved - please, report it!
It's even more important than reporting the problem itself...
|
|
|
|
| Re: Slow first ping to any VE IP? It's driving me crazy! [message #21721 is a reply to message #21682] |
Mon, 15 October 2007 11:34 |
tomfra
Messages: 28
Registered: September 2007
|
Junior Member |
|
|
I have asked the same question at Experts Exchange and just today got a similar answer there. I was told to do:
c:\>arp -s <ip.add.res.s> <ma-ca-dd-re-ss>
I tried it from my home PC (Win XP) and it worked but the question is how do I make the cache record permament for every computer without needing each of them to run this command?
I thought I should do this on the hardware node itself and that this would perhaps do the trick but the linux command "arp" has apparently different syntax so I will have to take a look at that.
But shouldn't this all be done automatically?
There is one thing I should mention. I compiled the openvz kernel myself and there is a chance I could have done a mistake when doing so. For example I just found that I didn't compile it with "CONFIG_BRIDGE_EBT_ARP" and all the other EBT related options. Do you think this could be a part of the problem? I've just checked the kernel config for the default openvz kernel and it is included in there...
Tomas
Do you really believe the Internet is a safe place?
IdentityCloaker.com - Take Back Your Privacy!
|
|
|
|
|
|
| Re: Slow first ping to any VE IP? It's driving me crazy! [message #21725 is a reply to message #21723] |
Mon, 15 October 2007 12:44 |
tomfra
Messages: 28
Registered: September 2007
|
Junior Member |
|
|
| finist wrote on Mon, 15 October 2007 14:16 |
But why this first time access delay disturbs you so much?
If you plan to deal with that IP address often - you won't get this delay but if not - well, is it a horrow thing to wait for half a second once?
|
I was asked the same question at the experts exchange... Yes, it is a problem for me because there will be some VPN stuff running on it and because of the way the custom created VPN client software measures connection "health".
Anyway, since it works great for others I do not see a reason I should be getting that delay. The delay is sometimes up to 800ms and that's very noticeable IMHO. It's very noticeable even when you browse web pages on the VPSes.
Tomas
Do you really believe the Internet is a safe place?
IdentityCloaker.com - Take Back Your Privacy!
|
|
|
|
|
|
| Re: Slow first ping to any VE IP? It's driving me crazy! [message #21984 is a reply to message #21682] |
Thu, 18 October 2007 11:19 |
tomfra
Messages: 28
Registered: September 2007
|
Junior Member |
|
|
This question is still open. It's apparently so mysterious that nobody knows what the problem is exactly...
Some facts:
-----------
*) Response to ping from the main hardware node IP and from the gateway is always perfect without the initial delay. Only pinging the VPS IPs from the "outside" shows a delay of roughly 200-800ms on the first ping. The consequent pings are OK.
*) It's possibly caused by ARP cache expiration. One idea is that the hardware node does not store the VPS IPs in the ARP table as permanent. However, the "arp -a" command does show the record *is* indeed permanent, unless I am misinterpreting it.
*) The VPS network settings is the default as set by HyperVM.
As always, any ideas are very welcome!
Tomas
Do you really believe the Internet is a safe place?
IdentityCloaker.com - Take Back Your Privacy!
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Slow first ping to any VE IP? It's driving me crazy! [message #42258 is a reply to message #42257] |
Sun, 27 March 2011 03:55 |
ajc1
Messages: 1
Registered: March 2011
Location: SLC, UT, USA
|
Junior Member |
|
|
I used to have this problem and it was an ARP/routiing issue as I recall. I ended up installing Quagga on my firewall pair and all host nodes and using OSPF to resolve it. This has the added benefit of making live migrations very easy, as well as when you run out of IP space and obtain additional subnets.
In other words, when a request hits one of my firewalls for an IP of a VE, the firewalls know right off the bat via OSPF the IP of the host node that VE lives on and thus where the packets should be routed to.
This does require that the firewalls and host nodes live in a separate subnet from the VE's.
This solved the first packet delay for me... YMMV.
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
but IMHO - it's unlikely.
