css11503 vrrp frequent flapping

[ray_juarez]

Hi,

We are having problems with our css11503 failover arrangement. We see  vrrp-mac flapping in the switch where the two css11503 are connected (master and backup). This behavior causes that some Cointainers stop responding requests from users. We need to suspend and then reactive these containers to start responding user requests.

Here are some shows from the switch:

Mar 19 10:10:06: %SW_MATM-4-MACFLAP_NOTIF: Host 0000.5e00.0120 in vlan 40 is flapping between port Gi0/52 and port Gi0/50

Mar 19 10:10:06: %SW_MATM-4-MACFLAP_NOTIF: Host 0000.5e00.0183 in vlan 40 is flapping between port Gi0/52 and port Gi0/50

And these are from the css11503:

MAR 23 12:58:15 1/1 2662 FP_DRV-4: PrismImmFastPath::Send: Could not allocate an MCID.  Remote message send aborted.

MAR 23 12:58:26 1/1 2823 VRRP-4: Virtual router 56: master on interface 10.0.40.229

MAR 23 12:58:26 1/1 2824 VRRP-4: Virtual router 58: master on interface 10.0.40.229

MAR 23 13:08:36 1/1 2825 SYSSOFT-4: Communications-QUEUE FULL-Ipv4ReceivePkt: Internal Messages Dropped.

We upgraded from 8.10 to 8.20, but the problem is still there

bal-cc-ct-int# sh ver

Version:               sg0820601 (08.20.6.01)

Flash (Locked):        08.10.0.02

Flash (Operational):   08.20.6.01

Type:                  PRIMARY

Licensed Cmd Set(s):   Standard Feature Set

Any idea what the problem is ?

Thanks in advance.

[rodrguti_2]

Hi Ray,

VRRP works using multicast 224.0.0.18, and on the CSS VRRP works like this, once the CSS's decide which one is going to be the Master based on the config, just the Master CSS will send the VRRP advertisements, those packets are like "keepalives" this happen every second +, there is a formula actually to calculate this, we need to use the VRid and you get the exact time, but to make it simple, lets say one second.

So, the Master will send the multicast packet on each vlan configured with the Virtual Router parameters configured, at some point the multicast packet will end up into the backup, so the Backup CSS will know that the Master is alive.

If for some reason, the multicast packet is getting blocked or dropped 3 times, which means +3 seconds, the Backup will assume that the Master is gone, and will take mastership.

So when the issue is happening it would be good to have some captures to confirm above.

Now, assuming that you have a critical service configured, is it down when the issue is happening?, are you having connectivity problems at that time?

What changed that might trigger the problem?