I have seen similar situation where a host had 2 interfaces on the same subnet, each with different IP on that subnet. Host was preferring to send traffic(sourced from both of its IPs) out of only one of the interfaces. Hence source mac of the second interface was never learned and was unicast flooded.
On 8/22/2011 8:15 AM, Chuck Church wrote:
-----Original Message----- From: Lee [mailto:[email protected]] Sent: Friday, August 19, 2011 11:05 PM To: Chuck Church Cc: NSP - Cisco Subject: Re: [c-nsp] ARP oddness Unicast flooding? You didn't say if the destination MAC address was known on the switch or no.. Lee I'm starting to think this is unicast flooding now. Noticed this just now:VLAN0001 is executing the ieee compatible Spanning Tree protocol Bridge Identifier has priority 24576, sysid 1, address 001d.453d.f300 Configured hello time 2, max age 20, forward delay 15 We are the root of the spanning tree Topology change flag set, detected flag set Number of topology changes 913 last change occurred 15:02:50 ago from GigabitEthernet3/38 Times: hold 1, topology change 35, notification 2 hello 2, max age 20, forward delay 15 Timers: hello 0, topology change 22, notification 0, aging 15 That 'topology change flag set' never seems to go away, despite the last change timer getting up into the hours timeframe now. I'm not sure why this STP doesn't seem to want to iron itself out. I'm going to have our vendor move this to RSTP, which is our standard. Still, not sure why it's doing this, unless a device is constantly sending out TCNs? Chuck _______________________________________________ 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/
