Charlie Allom wrote:
On Thu, Dec 18, 2008 at 06:43:46AM -0800, Teller, Robert wrote:
This appears to be related to hsrp. What is the exact problem your
having, do your users report loss of connectivity momentarily or are you
just looking in your log file and see this entry. It's hard to say
without see your config what the problem is.
I get this often on ISR routers with high CPU (2821's)
Depending on how long it lasts it can knock out streaming but that's
about all that notices.
C.
Hi Jack,
There is a Cisco doc about troubleshooting HSRP problems which mentions
that high CPU can cause HSRP flaps.
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094afd.shtml
Case Study 7 describes a scenario where two routers are connected to a
shared stub LAN, with both supporting multicast and running HSRP. Each
has a route to a multicast source via another interface. The DR is
sending multicast onto the shared LAN, and these are reaching the non-DR
on a non-RPF interface. The non-DR may
not have created any state for the group (I guess since the DR is
handling joins), and so the non-RPF packets are punted to the CPU for
processing. The increased CPU causes HSRP state changes on the non
designated router. The suggested solution is to use an ACL on the
standby router to prevent these multicasts being received via the
multicast DR.
Paul.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
