fwha_pivot_forward_mac

[fdamstra]

On a new install of R65/ClusterXL on Splat Pro, the pivot enforcement node is spamming /var/log/messages with the following warning/error:

Oct 4 08:45:02 FW4 kernel: FW-1: fwha_pivot_forward_packet: can not forward since fwha_ether_addrs[dst=1][ifn=0] is NULL (4506368)
Oct 4 08:45:02 FW4 kernel: FW-1: fwha_pivot_forward_packet: can not forward since fwha_ether_addrs[dst=1][ifn=1] is NULL (4506368)
Oct 4 08:45:03 FW4 kernel:
Oct 4 08:45:03 FW4 kernel: FW-1: stopping debug messages for the next 51 seconds

These are resulting in /var/log/messages being rotated about every 15 minutes.

The firewall has 10 interfaces, yet this message is only ever [ifn=0] or [ifn=1]. Both enforcement nodes are handling traffic, so it clearly is able to 'pivot' successfully sometimes. Everything appears to be working normally, though we do also get a lot of 'TCP out of sync' errors.

The firewalls are running in load sharing unicast mode. Changing between 'set_ccp broadcast' and 'set_ccp unicast' makes no difference. The non-pivot node does not have any error messages in the log.

I've had a ticket open with Checkpoint for about 6 weeks now, but they clearly have no idea.

If anybody has thoughts on what's causing this, I'd appreciate any input.

[luisrocha]

Last time i had that problem it was the port on the switch that belongs to 2 vlans at same time.


LR

[fdamstra]

Originally Posted by luisrocha

Last time i had that problem it was the port on the switch that belongs to 2 vlans at same time.

I think I can clarify this. I can't guarantee that my problem is solved, as we haven't implemented the changes yet, but after many weeks, checkpoint finally came back with a reply that makes sense.

They say our problem is that we have an IP on the physical interface, as well as a tagged VLAN with an IP on a subinterface. Official response is that we should remove the IP from the physical interface and only use vlan subinterfaces (if the interface is vlan'd at all).

This requires a network interruption and quite a bit of reconfiguration, so it might be a few more weeks before I'm able to verify that this solves the problem.