[c-nsp] ARP oddness

[Anton Yurchenko]

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:ler762 at gmail.com]
>> 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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>