1

I have a weird issue on Debian 8 on a provisioning workflow,
the steps are :

  • The debian is DHCP configured (from the PXEBoot)
  • VLAN Change on ESX
  • ifdown on eth0
  • reconfigure /etc/network/interfaces with static address
  • ifup on eth0
  • ping -c 1 gateway

The gateway ping fails, but if you retry the ping it always succeed. do you have any idea on why those first ping fail ?
No issue met on Debian 7 or RHEL 6 (maybe linked with systemd ?)
(I've tried added a 5 seconds -or 10 seconds- sleep before ping)
Thanks

  • How long does it take for ping -c 1 gateway to fail, and what's the full output? Which package is ping from (some versions of Debian include several slightly different implementations)? – Gilles Sep 30 '15 at 22:45
  • @Gilles The ping output is simple : 1 paket transmitted, 0 received, 100% packet loss, time 0ms, the version is : iputils-s20121221 (jessie) – doctori Oct 1 '15 at 8:51
  • Are you absolutely positively sure that the IP address isn't in use anywhere? What happens if you pick a different (also unused) IP address? – Gilles Oct 1 '15 at 9:12
  • I'm absolutely positive, since I just need to retry for it to work perfectly (just launching ping a second time !) – doctori Oct 1 '15 at 9:20
  • That proves nothing: your machine could have grabbed the IP address in the router's ARP cache in the meantime. There may well be other reasons why it can't be an IP address conflict, but the information you've given so far is not conclusive. – Gilles Oct 1 '15 at 11:47
1

Before ping can send ICMP packets to the target host, it first decides whether it's a local or remote host. Either way, it will need to retrieve the MAC address of the next hop, which could be the host itself on a local subnet or the router for a remote host.

It gets this using the Address Resolution Protocol (ARP) which in essence broadcasts "Who has IP address a.b.c.d? Tell e.f.g.h" and waits for a reply of "IP address a.b.c.d is at MAC address ab-cd-ef-gh-ij-kl". Once it has the MAC address it can send the ICMP packet.

The delay you're experiencing is due to this ARP process. You can tell ping to wait longer with the -W option.

ping -W 10 gatway

will cause it to wait 10 seconds for a response.

ARP data is cached, therefore subsequent pings do not have to follow this process and the response is near instantaneous.

  • Sorry but it doesn't solve it, even if we try a ping -c 4 -W 10 -I eth0 -n gateway, still failure... the weird part is that if we clean the arp cache it doesn't fail again ... – doctori Oct 1 '15 at 10:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.