The Scenario:
Two 6500's. Three of the gig links between them configured as a port =E2=80=A8channel. =C2=A0All three are trunks. =C2=A0CatOS (grrrr...)
The issue:
Users start complaining. =C2=A0I isolate the problem to this pair of cats =E2=80=A8and take a look. =C2=A0CPU at 100... =C2=A0interfaces dropping mil= lions of =E2=80=A8packets...I look at the logs... =C2=A0HSRP is reporting dup addres= ses on a =E2=80=A8gob of segments.... =C2=A0lots of them... =C2=A0as many as you m= ight find, say, =E2=80=A8on a trunk. =C2=A0Says I to myself: "I've got a loop between = those cats." =E2=80=A8Upon investigation I find that *all three* of the links in the port =E2=80=A8channel are unidirectional. =C2=A0There we go. =C2=A0I mo= ve the channel to three =E2=80=A8different ports, different gbics, different fiber, blah blah... =C2=A0happy =E2=80=A8network, happy users,
The question:
huh?
I may be as thick as Randy Bushs' wallet, and I've been away from the =E2=80=A8catOS for some time, and I've never seen the like on a native, but= I =E2=80=A8don't quite get this. =C2=A0It's highly improbable that all three = of these =E2=80=A8interfaces (on three different line cards) went into this state. =C2=A0Could =E2=80=A8one single interface in UD mode cause the entire channel to do that? =E2=80=A8Bear in mind that I didn't just assume each of these links was UD, I =E2=80=A8saw all three in that state from the cons.
Anyone have a clue for me?
ps: I know, I know, udld.... =C2=A0only been on the job two months and I =E2=80=A8began my criticisms in the core. =C2=A0:)
p=2Ep.s: by the way... =C2=A0hi everybody. =C2=A0:)