cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1220
Views
3
Helpful
5
Replies

6509s not learning VRRP MAC address

p.p.lewis
Level 1
Level 1

Our setup is 2 x 6513s (Native mode) with 2 x Nokia Firewalls running Checkpoint FW-1 NG with Cluster XL in HA (active/standby mode),one interface on each of the FWs is connected to a switchport on each of the 6513s, we then have 2 x 1Gb links back to 2 x 6509s (Hybrid mode) running HSRP.

The problem we have is when one of the 1Gb links goes down the 6509 does not learn the MAC address of the now active FW, if we clear the arp cache then ok, we have set the arp cache timeout to 4 minutes, and after 4 minutes we learn the new MAC, however surely this isn't how it should work, we can't afford to wait that long.

Does anybody have any ideas, maybe a bug with the code on the 6509s?

Code on 6509s is 6.3(5) and 12.1(3a)E7

Thanks in advance.

5 Replies 5

l600671
Level 1
Level 1

I'm not real familiar with the Checkpoing HA but it sounds like they are not using a shared (virtual) MAC address for failover. If they are not using a shared MAC then it is the responsibility of the Checkpoint to perform a graceful arp for its HA IP address when it becomes primary. When the Checkpoint performs this graceful arp the 6513 will correctly populate its arp cache with the new MAC. I believe the 6513 is operating as it should. A network trace will uncover if this arp is occurring.

You're right they do not share the same MAC, the virtual IP maps to two different MACs, one for each of the physical firewalls.

The FW sends out gratuitous arps, basically saying the way to get to the virtual IP is now this MAC address, seems that the 6509, the default gateway, doesn't know how to get to the virtual IP, I'm more of a Cisco person, so the FW people are blaming us!

Have you actually seen the gratuitous arps in a trace or are you basing this off the vendor documentation? I would get a trace, if you haven't already, to confirm if it is the FW not sending it at failover or the 6513 not seeing it. That trace alone should be enough to get the appropriate vendor to correct the problem.

I'm reliably informed by the FW group that the FW is sending the arps, we've since done some testing and if we wait for the arp cache timeout period on the MSFC then it recovers ok, we've set this to 4 minutes, however, if we ping the FW's virtual IP address we recover almost immediately.

gstaats
Level 1
Level 1

I have done the same setup with instant fail over successfully. Ensure that you can reach all three IP's ( Primary FW, Secondary FW and Cluster IP) from the 6509. If these are all accessible you have a possible route issue, ensure that your route is pointing to the Cluster IP on the FW. If these are your settings you need to ensure that the FW VRRP is not causing the problem which was the problem I had with the same results as you are having and the solution to this problem was forcing the Cisco port speed and duplex settings to max speed, full duplex and non-negotiate. I hope this helps -good luck