Loss of traffic when pushing policy

[dfoulser]

I have a pair of R60 HFA04 on SPLAT running in ClusterXL mode. Each firewall's external interface is attached to a separate Baystack 450 switch, and the two switches have a multi-link trunk between them.

When I push policy on the CheckPoints, I lose all traffic from outside. Power cycling the switches restores traffic. I did not have this problem with old Nokia IP330's and FP3 (just two firewalls, not a clustered solution). I have not waited for the 5 minute ARP cache timeout on the switches, but expected gratuitous ARPs to fix up the switch ARP table immediately.

I have disabled IGMP snooping on the Baystacks, to no avail. I'm allowing various multicast traffic out the external interface.

Any suggestions on a configuration change to the CP or Baystack that will allow me to push policy without power-cycling equipment?

Regards,

Dave

[chillyjim]

Try switching to pivot mode for the cluster. If that works then you know its a multicast problem with the switches.

[dfoulser]

Ah, I should have mentioned this, the ClusterXL is not doing load sharing. It is just in active/standby mode.

Also, the management interfaces are connected via a different device, not through the Baystack switches.

Any other suggestions?

[chillyjim]

Under HA, are you using new mode or traditional mode? New mode is multicast, traditional is basically VRRP.

[dfoulser]

Yes, HA in new mode. No load sharing. Use state sync.

I have seen the multicast traffic and set up rules to allow it.
I read through a bunch of HFA release notes and concluded I did not need to make any multicast ARP definitions on my switches, but I did turn off IGMP snooping even though that advice appeared only to apply to load sharing.

[wujido]

This behavior "should" be controlled by switches, as there is no change in IP address or MAC from pushing policy.

There is a property in the dashbaord within a gateway which dictates if connections are kept during a policy install. You should look it over.

[dfoulser]

Hmm, I think it is not related to maintaining connection state, but somehow to a bad interaction with the Baystacks. perhaps not sending gratuitous ARPs, or perhaps some problem with how multicast is used. There seemed to be plenty of warnings about multicast traffic for load sharing.

Ideally I'd find someone who already had this problem and has a solution or has seen something like it with other switches and has a suggestion for this clustered situation.

Thanks.

Dave

[_d3nx]

you may face many problem with switches when you have used multicast for CCP. In order to find the problem is related with multicast, try to switch CCP to broadcast from multicast using command below. Actually disabling IGMP snooping causes to flood multicast packets to all switch ports like broadcast.

cphaconf set_ccp broadcast

In order to see what you are using for CCP you can use cphaprob -a if command.

[Acidio]

The 450's are quite old hardware now. Have you got the latest software loaded on these?

[Acidio]

Also, I've seen some odd things happen when spanning tree is enabled on MLT ports. Might be worth checking this too. Nortel's recommendation is to have STP disabled on these ports.

[dfoulser]

Thanks for the posts, Acidio. I'm using recent software on the Baystacks, v4.5.2.4 which I updated in the last year or so. The MLT has spanning tree disabled for just the reasons you mention.

_d3nx, I'm inclined to try the 'cphaconf set_ccp broadcast' change. Is this the same as changing HA from new mode to traditional?

Also, would enabling IGMP snooping solve the problem? I'm not using load sharing, so perhaps the CheckPoint recommendation to disable IGMP snooping does not apply here?

Any other suggestions? Thanks.