Are you using first-hop redundancy like hsrp, glbp, vrrp? This can cause asymmetrical MAC based FIB timeouts which leads to unicast flooding. I didn't think these were RP switched, but it could be.
If so, what is your setting for "mac-address-table aging-time" ? We have ours set > fib timeout...so: mac-address-table aging-time 14400 ---- Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Drew Weaver Sent: Tuesday, November 24, 2009 1:21 PM To: 'Lee' Cc: Cisco-nsp Subject: Re: [c-nsp] 6500 - What determines whether certain traffic is punted or not? Hi Lee, I believe you're referring to show 'platform hardware capacity' and nothing looks extremely out of the ordinary. -Drew From: Lee [mailto:[email protected]] Sent: Tuesday, November 24, 2009 1:14 PM To: Drew Weaver Cc: Cisco-nsp Subject: Re: [c-nsp] 6500 - What determines whether certain traffic is punted or not? On Tue, Nov 24, 2009 at 1:03 PM, Drew Weaver <[email protected]<mailto:[email protected]>> wrote: Hi, Yeah I followed the exact same instructions you posted when creating the RP span session. Well.. it was worth a shot :) Have you seen any syslog messages about a fib or tcam table overflow? Someone else will have to chime in with the show commands to see hardware resource utilization - I'm not at work & don't remember what they are. Sorry.. Lee _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
