[c-nsp] ARP oddness

[Chuck Church]

Lee,

	You're close.  An admin had plugged a spare server into a
switchport, the server had no OS, just constantly trying to reboot, bring up
link (for PXE, I assume), and then reboot.  Portfasted it, problem solved...

Chuck

-----Original Message-----
From: Lee [mailto:ler762 at gmail.com] 
Sent: Tuesday, August 23, 2011 12:30 AM
To: Chuck Church
Cc: NSP - Cisco
Subject: Re: [c-nsp] ARP oddness

On 8/22/11, Chuck Church <chuckchurch at gmail.com> 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.

We had something similar happen between a pair of 6500s and lots of
IBM blade switches recently.  There was a constant stream of topology
change traps for vlan 1 (strange since we don't put anything on vlan 1
& stranger still because it was only vlan 1 having topology changes)
I didn't bother trying to figure it out once I noticed that people
hadn't been trimming vlan 1 off the trunks for all those blade
switches.  Removed vlan 1 on all the trunks going to the blade
switches and no more topology change traps :)

>  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?

Where I work, most probably it'd be users turning their PCs off/on &
us forgetting to enable portfast on the user switch ports :)    In
your case, could it be some interaction between RSTP and IEEE STP?

Regards,
Lee