The environment is running with Nexus 9K in NXOS mode. Both are in vPC mode and running hsrp with N9K1 active and N9K2 standby. Due to vPC both nodes are running Active/Active for HSRP.

Now the devices in the same vlan are having arp issue. For example Device-A can not ping Device-B. However, when we ping Device-A from Device-B both bi-directional ping works.

Any suggestions would be helpful. I want to avoid giving static arp entries in the nodes.

  • The ping failure message will give you the best clue as to what went wrong. It sounds like you have a closed firewall rule that is being opened from one end, then the firewall times out, and you must again open it from inside.
    – Ron Maupin
    Sep 4 '19 at 9:45
  • Also, the problem is that questions about the hosts are off-topic here. A host firewall or ARP table is off-topic. We could help with the network devices, but not your hosts. You could ask about host problems on Server Fault for a business network.
    – Ron Maupin
    Sep 4 '19 at 9:47
  • Hmmm the actual issue is with ARP. I can redirect the question to server vault. However ARP is related to network that's why I posted here. There is no firewall placed in the middle of network. Just layer2 connectivity with Layer3 interfaces acting as Gateways or the host machines.
    – Muneeb Ali
    Sep 4 '19 at 9:50
  • I hope server fault don't redirect this question to networkengineering.stackexchange.com
    – Muneeb Ali
    Sep 4 '19 at 9:52
  • A host implementation of a protocol is off-topic here. We could help with the protocol theory, but not fixing the way a host does something. Obviously, the network works, so we are left with malfunctioning hosts, and that is off-topic.
    – Ron Maupin
    Sep 4 '19 at 9:53

A ping test result (failed) is a only hint at, but never a proof of failed ARP resolution.

Suspected ARP problems must be diagnosed on both end systems (usually it takes something like arp -a or arp -na to display the ARP cache's content). If both end systems have the respective peer's IP to MAC mapping in their ARP caches, then it's not an ARP problem.

Classically the problem of asymmetric ping results is a local firewall policy on one of the end systems that allows outgoing ICMP Echo requests and incoming ICMP Echo responses (--> Ping successful), but drops incoming ICMP Echo requests (--> ping fails).

Then you may also want to cross-check that the Nexus have the given end system's MAC addresses in their CAM tables on the expected ports and VLANs show mac address-table interface ...

  • Let's assume Device-A is windows 2008 and Device-B is esxi server. I checked in arp -a in windows machine. There wasn't an entry for device-b. I ssh into the device-b and ping the device-a. Then there is arp entry for device-b in device-a. In nexus, the arp entry stays intact even before doing any ping or else.
    – Muneeb Ali
    Sep 4 '19 at 8:50
  • Yes of course. ARP Cache entries have a lifetime - usually 5min for end hosts, 4hrs for routers. If the end systems haven't been talking to each other for <cache lifetime>, then the entries are flushed from the caches, and ARP resolution will happen at the start of the next communication attempt. To be sure you do not have an ARP problem, you must look at the ARP cache on both end systems. Sep 4 '19 at 8:55
  • This is the output: Client Machine ( C:\Windows\system32>ping Pinging with 32 bytes of data: Reply from Destination host unreachable. Reply from Destination host unreachable. Ping statistics for Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
    – Muneeb Ali
    Sep 4 '19 at 9:02
  • @MuneebAli how are your clients and your layer 3 interface configured.
    – user56700
    Sep 4 '19 at 9:13
  • @MuneebAli please edit and add the command outputs to the original question, using the "{ }" formatting tags, and also include the ouput of arp -a and esxcli network ip neighbor list (as shown in buildvirtual.net/viewing-the-arp-table-on-an-esxi-host) Sep 4 '19 at 9:21

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