On Fri, 24 Apr 2009, Kevin Loch wrote:
all the interfaces on this router running VRRP started having their states
change from backup to master to backup every few seconds. After about 40
seconds of this, it settled down and all the VRRP states went back to their
original state. While this was going on, the other 6500 participating in
the VRRPs (which was the master) logged nothing and thought it was the
master the whole time.
This is likely a side effect of the cpu being maxed out, or encountering
control plane rate limiting. Was there something that spiked the cpu
or exeeded your control plane limits that caused both the BGP session to
drop and the vrrp flaps? Loops on the switch that include cpu affecting
packets (like vrrp for example) can easily do this.
It's not control plane rate limiting. Because the BGP peer that went down
was a transit peer (~280k routes), the CPU would likely have been quite
busy dealing with the routing changes.
Do I need to tune process-max-time to keep VRRP from failing during
periods of high CPU usage? I don't think I've messed with that since
AS5200s.
----------------------------------------------------------------------
Jon Lewis | I route
Senior Network Engineer | therefore you are
Atlantic Net |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
