arping responses not showing on newer appliances

[Paul_Hagyard]

We have noticed with newer appliances (standard cluster members, not VSX or Maestro) that we do not get a response to "arping" requests as we do with older appliances, open servers, and CG IaaS on VMware. The issue is present for both standard and bond interfaces. We are definitely getting a response as running a tcpdump in another window for ARP traffic for the address in the arping command shows the reply.

We use arping extensively for simple connectivity testing (ping is often blocked by firewalls), has anyone else seen this or have any workarounds? The tcpdump approach is a pretty ugly workaround  as it needs another command (in another window or as a background task) for each arping.

Cheers

[the_rock]

Interesting... any specific model?

Andy

[Paul_Hagyard]

I've only noticed it on 9100 Plus appliances so far.

[Timothy_Hall]

Code version?  The Gaia kernel has been updated numerous times in recent releases, and arping may have been touched by those updates as it is a Linux utility.

[the_rock]

That could be, for sure. I had not seen this on new 3920 models though.

Andy

[Paul_Hagyard]

R81.20 JHF 105

[Bob_Zimmerman]

When you say you don't get a response, what exactly do you mean? As you said, you must be getting ARP replies, otherwise traffic wouldn't work. Is the arping command telling you it got no responses?

[Expert@DallasSC]# arping -I eth1 -c 1 10.0.1.252
ARPING 10.0.1.252 from 10.0.1.251 eth1
Unicast reply from 10.0.1.252 [00:12:C1:10:01:FC]  0.802ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)

[Expert@DallasSC]# cpinfo -y all 2>&1 | grep JUMBO_HF_MAIN | uniq
	HOTFIX_R82_JUMBO_HF_MAIN	Take:  41
	BUNDLE_R82_JUMBO_HF_MAIN	Take:  41

[the_rock]

I just did tcpdump -enni any arp in my lab and gave results. Not sure what was exact command ran by @Paul_Hagyard , but even any arp command I did was fine too.

Andy

[Paul_Hagyard]

Correct, arping shows no responses but tcpdump shows the reply is seen.

Seen on 9100 Plus appliances.

[the_rock]

What about just arp or arp -a?

Andy

[Paul_Hagyard]

Those are both passive, so you need to ping first (or something) to generate an ARP request then check the arp table (arp -an). arping is a quick way to confirm that all the devices you could see before (e.g. platform migration) are still visible after.

[Paul_Hagyard]

Couple of screenshots attached, one showing arping with no responses when ping is working (allowed by the policy in this case), the second showing arping with no responses when tcpdump confirms that the ARP replies were received.

[the_rock]

Odd...just tried in the lab, even R82 has same issue.

Andy

[Bob_Zimmerman]

That's bizarre. I would open a TAC case at this point. arping definitely works in general on Check Point's software.

Might be a quirk with the 9100. I don't have one to test to be sure, but I doubt that's it. Check Point's branded hardware is pretty vanilla amd64 gear, just with weird, proprietary card slots. It's normal enough you can run Windows on it.

[the_rock]

Just tried on customer's 6200, same issue.

Andy

[Paul_Hagyard]

Same behaviour on 9300 Plus with R82 JHF 39

[the_rock]

I would open TAC case for this.

Andy

[_Val_]

Please open a TAC case for this

[Paul_Hagyard]

I've raised a SR and the latest response included:
"The R&D team is actively working on it under case ID TM-89261."

[the_rock]

Thanks for letting us know, Paul.

Andy

[Timothy_Hall]

Known issue between UPPAK mode (used on Quantum Force 3900/9XXX/19XXX/29XXX) and arping, a fix is available: sk184292: ARPING Utility Fails in SecureXL UPPAK Mode

[the_rock]

Thanks for that, Tim.

[PhoneBoy]

Noticed that one this morning 🙂