[c-nsp] HP Loop-protect on Cisco

[Peter Rathlev]

On Thu, 2011-12-08 at 17:16 +0100, Andrew Miehs wrote:
> Using an old switch I have in my lab :
>  
> Cisco IOS Software, C3550 Software (C3550-IPSERVICESK9-M), Version
> 12.2(44)SE6, RELEASE SOFTWARE (fc1)

I forgot to specify what I was using. :-) The specific messages was from
a 3550 running 12.2(52)SE:

 Cisco IOS Software, C3550 Software (C3550-IPBASEK9-M), Version
   12.2(52)SE, RELEASE SOFTWARE (fc3)

I'd have thought you would see the same messages. The specific loop on
my "test switch" was caused by Type-1 cable and some kind of defective
balun.

> If I connect an unmanged 8 port switch to cat3550-0/1 and once it is
> connected create a loop on the 8 port switch:
>  
> *Mar  1 02:15:32.811: %LINK-3-UPDOWN: Interface FastEthernet0/1,
> changed state to up
> *Mar  1 02:15:33.811: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> FastEthernet0/1, changed state to down
> *Mar  1 02:15:34.819: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> FastEthernet0/1, changed state to up
> *Mar  1 02:17:29.003: %SYS-2-MALLOCFAIL: Memory allocation of 1692
> bytes failed from 0x158568, alignment 0
> Pool: I/O  Free: 21284  Cause: Memory fragmentation
> Alternate Pool: None  Free: 0  Cause: No Alternate pool
>  -Process= "Pool Manager", ipl= 0, pid= 5

Hmm... I'd have thought that these swithes should never experience
malloc failures. Is this reproducible across reboots? It might relate to
an IOS bug.

The ethernet loopback test wouldn't work/activate if the neighbor is a
switch, since that isn't a direct physical loop.

> *Mar  1 02:17:35.515: %LINEPROTO-5-UPDOWN: Line protocol on Interface
> FastEthernet0/1, changed state to down
> *Mar  1 02:17:40.779: %PM-4-ERR_DISABLE: dtp-flap error detected on
> Fa0/1, putting Fa0/1 in err-disable state

Would this mean that the dumb switch sends the DTP frames back toward
the 3550 because of the loop?

You should be able to use BPDU Guard to prevent loops like this.

> So unfortunately on this old switch the port only goes down if the
> loop occurs after the interface comes up on the Cisco.
> I will try this with a newer switch which has the
> "ETHCNTR-3-LOOP_BACK_DETECTED" feature in the next few days.

I'm pretty sure that the loopback test was "always" there, and most
certainly in 12.2(44)SE, which isn't all that old. But the loopback-test
only works if the cable itself (or a dumb hub) creates a loop. A logical
loop through a switch (no matter how dumb) would never result in this
kind of loopback.

BPDU Guard is the answer here.

-- 
Peter