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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
