Troubleshoot Interface Flapping

[dstern@bn.com]

Platform:
Linux, NG, 4 interfaces.

If you look at the following, you see that the secondary keeps going up and down. A reboot didnt fix it. Any ideas on troubleshooting?


# cphaprob state

Cluster Mode: New High Availability (Active Up)

Number Unique Address Assigned Load State

1 192.168.75.1 100% active
2 (local) 192.168.75.2 0% standby

# cphaprob state

Cluster Mode: New High Availability (Active Up)

Number Unique Address Assigned Load State

1 192.168.75.1 100% active
2 (local) 192.168.75.2 0% down

# cphaprob state

Cluster Mode: New High Availability (Active Up)

Number Unique Address Assigned Load State

1 192.168.75.1 100% active
2 (local) 192.168.75.2 0% standby

[Claer]

Try to find why the second member keep going down.

From my experience, I had a similar case with an unused interface configured in DHCP mode. As there was no link on this interface, this particular cluster member was going up and down as yours. My solution was to remove IP configuration from that interface.

Hope this help :)

[kva.kva]

Check Smartview Tracker and Status and use "cphaprob list". Last command shows you cluster devices and there status.

[dstern@bn.com]

Right - I know how to find it, Im more curious as to what creates the condition of regular up/down activity.

[varera]

1. Please check your cluster is working in multicast mode. It most probably is.
2. To avoid the problem you have two options:

2.1 switch to broadcast mode (not really a good solution)
2.2 switch off igmp snooping on your switch. it will fix is once and for all. this solution is recommended by clusterxl user guide.

[dstern@bn.com]

IGMP Snooping is not running on the switch. There are a number of Cisco CSS Load Balancers on that segment that some of my people feel are causing a bad interaction. When I know more Ill post it.

Thanks for all the help.

[dstern@bn.com]

it looks like a funky clusterXL issue. Usually, if CCP isnt being transmitted, then its on all of the interfaces. In my case, its only happening on 1 interface, which means the cluster needs to be slapped.

[FERappel]

This occurs here due to the trunk not forwarding multicast traffic between the virtual trunk ports in the 6500 w/ the Native IOS, the ones connecting inside, though no problems w/ the (real) ones connecting the firewalls, inside or outside - the multicast macs appears in the ports -, neither w/ trunk in the 6500 w/ the CatOS + IOS, the ones connecting outside. The solution was to configure the multicast addresses in the ports, both the virtual and the ones connecting firewalls, but not the real ones of the trunk, besides disabling IGMP snooping. There are links in the CP and the Cisco sites. Note: the parameters are slight different for the Native IOS between SUP2 and SUP1A.

[pop_alex]

Hi,

Can you provide me the link for the solution? :)

Regards,

Al

[kva.kva]

In CP knowledge base there is next link
http://www.cisco.com/en/US/products/...5.html#1035778

[maurox]

Did you solve the problem ( I'm having the same problem ) with the Cisco solution ?
thanks,
Maurox

[Blueknight]

Guys I have come across a similar problem many moons ago. The issue then was to do with the Ethernet interface being in auto and continually hunting between 10 and 100 Mb settings. Was ok once we hard configed the interface on the firewall and the switch to operate at a specific speed.

Hope this helps

Blueknight

[FERappel]

Originally Posted by maurox

Did you solve the problem ( I'm having the same problem ) with the Cisco solution ?
thanks,
Maurox

Yes, I did!

[pop_alex]

Originally Posted by FERappel

This occurs here due to the trunk not forwarding multicast traffic between the virtual trunk ports in the 6500 w/ the Native IOS, the ones connecting inside, though no problems w/ the (real) ones connecting the firewalls, inside or outside - the multicast macs appears in the ports -, neither w/ trunk in the 6500 w/ the CatOS + IOS, the ones connecting outside. The solution was to configure the multicast addresses in the ports, both the virtual and the ones connecting firewalls, but not the real ones of the trunk, besides disabling IGMP snooping. There are links in the CP and the Cisco sites. Note: the parameters are slight different for the Native IOS between SUP2 and SUP1A.

Hi,

Am still confuse about multicast IPs. How do I determine the multicast IP?

Thanks.

Regards,

Al

[FERappel]

Originally Posted by pop_alex

Hi,

Am still confuse about multicast IPs. How do I determine the multicast IP?

Thanks.

Regards,

Al

Not you, FW-1! sk 25977 30197 11551 31325, which I've sent 2 e-mails w/ comments to CP, 1 implemented, 1 pending.

[pop_alex]

Hi, JFYI...

I had done a synchronization between two test machine (installed with the latest version of Check Point NG AI R55) across two Cisco 6509 Switch Series recently and it works perfectly. These machines are installed using Red Hat 7.3. By enabling the "no igmp snooping" on VLAN, it works fine. Below are two test result conducted recently:

a) By connecting both test machine (firewall) on each Cisco 6509 Switch series, which will be on same VLAN across trunked fiber, also configured both switches using a command called "no igmp snooping". It works perfectly.

b) We put IPs on VLAN on both side (Cisco 6509 switches) and test the state sync. Result, it working fine.

It seems it works fine using a test machine with Red Hat Linux 7.3 (installed with Check Point NG AI R55) but I couldn't make it sync using three SUN V280R (O.S. Solaris 9) with 1GBic Quadcard on each, across two Cisco 6509 switches.

I wonder why,

a) when using two test machine (firewall) on Linux are able to synchronize over two Cisco 6509 switches without any problem instead using two or more firewall on Solaris?

b) do I need to configure "mac-address-table static" for multicast address on Cisco 6509 switches just to make firewall talk to each other?

One last question, I noticed when I reboot all three firewall server (SUN) after activate the state synchronization, these messages appeared on primary and third firewall (but none in secondary firewall) during startup;

Apr 14 15:57:33 xxx.xxxx.xx ip: [ID 856290 kern.notice] ip: joining multicasts failed (3) on ce1 - will use link layer broadcasts for multicast

What does this mean?

Thanks very much

Regards,

Al