Is it correct to advertises proxy arp as garp on failover?

[ChoiYunSoo]

Hi

Does anyone know of any logic that advertises the proxy ARP that the firewall has on failover?

As far as I know, Checkpoint advertises Proxy ARP as GARP.

However, when it is confirmed through tcpdump, it is confirmed that the firewall's VIP is advertised as GARP, but Proxy ARP is not.

I would like to know if the packet dump is wrong or if the checkpoint logic is not advertising it.

There is a problem that about 20 ping losses occur during failover in the customer's firewall.

I suspect that perhaps the upper switch is not updating the path properly.

So I did TCPDUMP to check if the firewall is sending GARP normally.

When viewed from tcpdump, GARP advertising the firewall's VIP was checked normally, but the proxy ARP advertising of the lower server as GARP was not confirmed.

The firewall is a VRRP configuration and the version is R80.40, Hotfix Take 156.

[Timothy_Hall]

The GARP/proxy ARP is updating the IP to MAC mapping table on an adjacent Layer 3 routing device; L2 switches do not directly pay attention to GARPs other than what MAC addresses are present in the Layer 2 frame when populating their forwarding table.  So you are intermingling two separate things here.

The behavior you are seeing is what I call a "slow" failover in my book, and is most probably caused by an STP issue that can be mitigated by setting portfast on the involved switchports (NOT disabling STP completely - don't do that).  Here is some content from my book about how to deal with a slow failover:

 

[ChoiYunSoo]

thank you for the reply.

But one thing I didn't mark in the text is that the customer's switch is an L3 switch.

Therefore, ARP Request and ARP Reply are considered necessary processes.

What I am curious about is, when a failover occurs in the VRRP configuration of the checkpoint firewall, Should checkpoint firewalls advertise proxy arp tables over GARP?

I want to know the intended logic of the checkpoint.

From what I've checked, about 15-20 seconds after failover, the ARP Request comes as a broadcast, and the firewall responds right away.
And communication works normally.

I wonder if the firewall should advertise the NAT IP's route through GARP before the broadcast request comes in.

[Timothy_Hall]

OK thanks for clarifying that it is the Layer 3 IP-MAC mapping table we are talking about here.

With VRRP there is a virtual MAC address so there is no need for gratuitous ARP upon failover, the Layer 3 IP-MAC mapping remains the same and it is up to the L2 switches to update their forwarding table for the VMAC which has moved to another switchport.

Still sounds to me like a L2 STP issue either at the switchports directly attached to the firewall or further upstream.  When the VMAC suddenly moves to another switchport STP is detecting a possible bridging loop and blocking the port for 10-15 seconds.  Check your switch logs for STP events, pretty sure you are going to find some that correlate with your failovers.  As my book says try setting portfast on the involved switchports.

[ChoiYunSoo]

Thanks for your reply.

Let me ask you one more thing.

The customer's L3 switch is a non-Cisco HP device.

In the opinion of HP L3 switch engineers, Cisco equipment and packet forwarding logic are different.

As far as I know, the cisco L3 switch first looks at the VLAN information in the ARP table.

And I know that the packet is forwarded after referring to the MAC table for the VLAN path.

However, the HP switch says that the physical interface path appears in the interface information of the ARP table, and the path does not refer to the MAC table.

Because it does not refer to the MAC table, it is said that the HP switch does not update the physical interface routes in the ARP table unless the firewall informs the NAT IP information via GARP at the moment of failover.

Can there be any issues with compatibility between the HP L3 switch and the checkpoint firewall?

HP L3 switch is hp5940 model

[Vladimir]

Not sure about VRRP cluster and HP switches, but I had no issues with HP (the ProVision OS) and Check Point clusterXL with VMAC.

[Timothy_Hall]

I guess it is possible, but I have seen HP switches in use at multiple customer sites in both L2 and L3 modes and have not run into anything like this.  It sounds like HP is blurring the lines a bit between the first 3 OSI layers for efficiency or whatever, but there is a good reason that they are supposed to be three completely separate layers...

[ChoiYunSoo]

I found something peculiar.

When failover to FW_B --> FW_A, ARP Request does not come from the switch to the firewall.

I think this means that the path update was done normally on the switch.

However, when failover to FW_A --> FW_B, an ARP request is confirmed.

This means that the path has not been updated on the switch.

I'm not sure, but there seems to be something wrong with the switch updating the path.

We are inquiring after passing the situation to the switch engineer.

Thanks for your help.