how do i know if an arp query is failing on checkpoint?

[kb1]

So im getting a complaint from a server owner saying that his newly deployed server is failing arps, the gateway for that server points to the ips of our firewalls in cluster both on R80.20, how do i see on the logs if arp is failing? when i log into the cli on expert mode and look for the arp entry for that server ip i do see the mac address for it:

[Expert@XXX-XXXX:0]# arp -a | grep 10.X.X.X
X.X.com (10.X.X.X) at XX:XX:XX:XX:XX:XX [ether] on ethX.X

Does this mean that arp works? 

I also logged into that server myself and pinged the gateway ip (which is the VIP of the firewall cluster) and pings work, i pinged the actual ips of both the gateways as well and it also worked.

My point is how do i make sure that arp is working/not working for that server?

Thank You.

[PhoneBoy]

If you see an arp entry for the server on your gateways, it means the gateway has a MAC address for that IP.
If you also see arp entries for the gateway on the server side, arp is working.
tcpdump would be how you'd troubleshoot this. 

[kb1]

So i replied and the server owner says that it works with multicast but not with unicast? how do i troubleshoot this? how do i i use tcpdump to troubleshoot this particular servers unicast ip?

[Bob_Zimmerman]

If you can ping from the new endpoint to the firewall's IP or cluster VIP, ARP is working. The end.

Unicast versus multicast has nothing to do with ARP. I have no idea what the server owner is reporting here.

[kb1]

---

@Bob_Zimmerman wrote:

If you can ping from the new endpoint to the firewall's IP or cluster VIP, ARP is working. The end.

Unicast versus multicast has nothing to do with ARP. I have no idea what the server owner is reporting here.

---

Thank you! I will let him know that this is not an arp issue on the firewall!

[Bob_Zimmerman]

The longer explanation is this. Let's say your new endpoint has the IP 10.20.30.40, and your firewalls own 10.20.30.1 (VIP), .2 (active member), and .3 (standby member).

When you tell the new endpoint to ping 10.20.30.1, it doesn't know what MAC address to use for the Ethernet frame. It sends an ARP request to ask who owns that IP. Everything on the network gets that ARP request. The active firewall member replies that it owns the address, the new endpoint caches this reply, and the new endpoint sends the ping request.

The active receives the Ethernet frame and extracts the packet. It sees that the destination IP in the packet is itself, so it hands the packet to its network stack to handle. The network stack sees it's a ping request and sends a ping response, but it doesn't know the destination MAC to use in the Ethernet frame, so it sends an ARP request asking who owns 10.20.30.40. The new endpoint replies, and the reply gets cached in the firewall's ARP table. The firewall then sends the reply.

Without ARP working in both directions, you could not get a response to a ping. If the server owner can describe the symptom they're seeing, we may be able to recommend further troubleshooting steps. Their reported symptom does not match your test results, though.

[kb1]

Thank you Sir for your detailed reply!