Verifying a VRRP cluster

[FDDIcent]

I have two Nokia boxes in a VRRP cluster, the cphad daemon on the primary mysteriously stopped and it failed over to the secondary. I performed a cpstop/start on the primary and then a cpstop on the second unit to fail it back to the correct device. This caused nothing but grief.

Now I'm in the position where what SHOULD be the primary (better hardware) is in secondary, and there's really nothing of note in /var/log/messages. Does anyone have any tips for trouble-shooting clustering? SmartCenter is completely green, cphaprob -i list looks good. Tcpdump of the int shows traffic flowing, I'm not sure what else I can do to verify.

Thanks,

-FDDI

[manrag]

What kind of VRRP are you using? IPSO versions? What is the output of
cphaprob list on both members?

[mcnallym]

There are some issues with cpha taking up large amounts of resource. I have had a particular problem with this. Apparently is fixed in the latest HFA's.

[FDDIcent]

IPSO 3.8 build 58 with HFA12

The primary came back up and thing seem to be running ok, I'm just not sure why stateful fail-over didnt work the first time. Multicast VRRP. Here's a cphaprob -i list:

Primary:


Built-in Devices:

Device Name: IPSO member status
Current state: OK

Registered Devices:

Device Name: Synchronization
Registration number: 0
Timeout: none
Current state: OK
Time since last report: 189608 sec

Device Name: Filter
Registration number: 1
Timeout: none
Current state: OK
Time since last report: 189608 sec

Device Name: cphad
Registration number: 2
Timeout: 5 sec
Current state: OK
Time since last report: 0.9 sec

Device Name: fwd
Registration number: 3
Timeout: 5 sec
Current state: OK
Time since last report: 0.2 sec

---
Secondary

Built-in Devices:

Device Name: IPSO member status
Current state: OK

Registered Devices:

Device Name: Synchronization
Registration number: 0
Timeout: none
Current state: OK
Time since last report: 247183 sec

Device Name: Filter
Registration number: 1
Timeout: none
Current state: OK
Time since last report: 247183 sec

Device Name: cphad
Registration number: 2
Timeout: 5 sec
Current state: OK
Time since last report: 1 sec

Device Name: fwd
Registration number: 3
Timeout: 5 sec
Current state: OK
Time since last report: 0.6 sec

Everything looks ok again at the moment, but it has me a bit concerned. The primary failed sync, secondary took over, primary was brought up with cpstop/start but then a cpstop on the secondary seemed to break fail-over. After a reboot of the primary everything recovered. CP has responded that we might want to increase our NAT cache which is usually full (10,000 entries) or reduce our connection limit which is far larger than our peak connections so as to not starve the kernel.

[Bob_Zimmerman]

Originally Posted by FDDIcent

IPSO 3.8 build 58 with HFA12

If you're running IPSO 3.8, I'm quite sure you can't be running HFA_12. "R55 for IPSO 3.8" (also called R55P) only goes up to HFA_09. When you run an 'fw ver', it should include the string "R55 for IPSO 3.8". If it doesn't, something is very wrong.