As a followup to this problem I posted about earlier - I've observed some very strange behaviour that might explain why this GEC went stupid on me for no apparent reason:
I setup a brand new GEC link, with 1 physical interface in the group. This was brand new, to a new empty switch, so of course there was no traffic on the link as show here: metro2.tor-Front[7609]#sh int gi1/13 GigabitEthernet1/13 is up, line protocol is up (connected) Hardware is C6k 1000Mb 802.3, address is 0015.f91d.5c86 (bia 0015.f91d.5c86) Description: Facing TOR2-04-4-2GE.915.1oe2 [Gi0/16] (GEC2) MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Full-duplex, 1000Mb/s, media type is LH input flow-control is off, output flow-control is desired Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 But when I look at the port-channel, holy hanna! What the heck?! The traffic load is huge.... metro2.tor-Front[7609]#sh int po115 Port-channel115 is up, line protocol is up (connected) Hardware is EtherChannel, address is 0015.f91d.5c86 (bia 0015.f91d.5c86) Description: Facing TOR2-04-4-2GE.915.1oe2 [Po1] MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 196/255, rxload 180/255 Encapsulation ARPA, loopback not set Full-duplex, 1000Mb/s input flow-control is off, output flow-control is unsupported Members in this channel: Gi1/13 ARP type: ARPA, ARP Timeout 04:00:0 Has anybody ever seen this before? This smells like a bug for sure... I tried it with LACP, PAgP, and without either, just "on".. same behaviour... interface GigabitEthernet1/13 description Facing TOR2-04-4-2GE.915.1oe2 [Gi0/16] (GEC2) no ip address switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 100 switchport mode trunk channel-group 115 mode on ! interface Port-channel115 description Facing TOR2-04-4-2GE.915.1oe2 [Po1] no ip address switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 100 switchport mode trunk Dan Armstrong wrote: >These were just 2 ports on the same blade of a WS-X6724 blade at both >sides... nothing at all strange. > >I never thought of not using PAgP or LACP - perhaps I should try it. > >I am too nervous to bring the GEC back up - both links out of the >Etherchannel have been testing fine for days... maybe I should just suck >it up and try it to see if it fails again. > > > >Mike Lydick wrote: > > > >>I had a similar issue when trying to turn up port channels that span >>across stack 3750. TAC recommends not using PAGP or LACP. Have not >>gotten it work since. Is this similar to your scenerio? Any resolution? >> >>----- Original Message ---- >>From: Dan Armstrong <[EMAIL PROTECTED]> >>To: "Collins, Richard (SNL US)" <[EMAIL PROTECTED]> >>Cc: cisco-nsp@puck.nether.net >>Sent: Tuesday, May 8, 2007 7:31:17 PM >>Subject: Re: [c-nsp] Port-Channel Problem >> >>I did exactly that, and managed to get it to go into LACP mode. >> >>The Etherchannel ran for about 3 hours without a problem, then all of a >>sudden started losing pings all over the place. I took one channel out >>of service, and it was fine. >> >>I tested both physical links separately, and they're both perfect. I'm >>scared to put them back into the Etherchannel now for fear that they'll >>fail again. >> >>I am using the single fibre SFPs (the GLC-BX-Us and GLC-BX-Ds) for both >>of these links. >> >>Anybody seen an Etherchannel lose it when the two underlying physical >>links are seemingly perfect on their own? >> >> >> >> >>Collins, Richard (SNL US) wrote: >> >> >>>So I suppose the opposite side was set at the same time to either >>>channel-group 10 mode [active or passive] for LACP? >>> >>>What about additionally setting.. >>>metro2.tor-Front[760(config-if)#channel-protocol lacp >>>I can't test this myself but saw the configuration option. >>> >>>-Rich >>> >>> >>> >>> >>> >>>>Date: Sat, 05 May 2007 02:39:04 -0400 >>>>From: Dan Armstrong <[EMAIL PROTECTED]> >>>>Subject: [c-nsp] Port-Channel Problem >>>>To: cisco-nsp@puck.nether.net >>>>Message-ID: <[EMAIL PROTECTED]> >>>>Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>>> >>>>Riddle me this. >>>> >>>>I have 1 physical link, and a port-channel interface operating in PAgP >>>> >>>> >>>> >>>mode. >>> >>> >>> >>>>interface GigabitEthernet1/21 >>>>no ip address >>>>switchport >>>>switchport trunk encapsulation dot1q >>>>switchport trunk allowed vlan >>>> >>>> >>>> >>>50,80,119,300-304,349,412,420,440,444,446,447 >>> >>> >>> >>>>switchport trunk allowed vlan add 449,500,503,616,620,900 >>>>switchport mode trunk >>>>channel-group 10 mode desirable >>>>end >>>> >>>>interface Port-channel10 >>>>no ip address >>>>switchport >>>>switchport trunk encapsulation dot1q >>>>switchport trunk allowed vlan >>>> >>>> >>>> >>>50,80,119,300-304,349,412,420,440,444,446,447 >>> >>> >>> >>>>switchport trunk allowed vlan add 449,500,503,616,620,900 >>>>switchport mode trunk >>>> >>>> >>>>metro2.tor-Front[7609]#sh int po10 >>>>Port-channel10 is up, line protocol is up (connected) >>>> Hardware is EtherChannel, address is 0015.f91d.5c8e (bia >>>> >>>> >>>> >>>0015.f91d.5c8e) >>> >>> >>> >>>> Description: GEC to metro1.tor-Mowat [Port-channel10] >>>> MTU 9216 bytes, BW 1000000 Kbit, DLY 10 usec, >>>> reliability 255/255, txload 104/255, rxload 202/255 >>>> >>>> >>>>Life was good, then: >>>> >>>> >>>>2 problems. I first tried to change to LACP: >>>> >>>>metro2.tor-Front[760(config-if)#channel-group 10 mode ? >>>> active Enable LACP unconditionally >>>> auto Enable PAgP only if a PAgP device is detected >>>> desirable Enable PAgP unconditionally >>>> on Enable Etherchannel only >>>> passive Enable LACP only if a LACP device is detected >>>> >>>>metro2.tor-Front[760(config-if)#channel-group 10 mode active >>>> >>>> >>>>The interface bounced, and went straight back into PAgP mode..... >>>> >>>>I tried it several times. [EMAIL PROTECTED], always back to PAgP..... >>>>"channel-group 10 mode desirable" >>>> >>>> >>>>Second problem: >>>> >>>>I tried a second link anyway, and when I added a second link into the >>>>PAgP group, the rely on the port-channel interface started dropping >>>> >>>> >>>> >>>like >>> >>> >>> >>>>a stone, packets were dropping all over the place and even though >>>>everything seemed to be up, speed, duplex, vlans, configuration >>>>perfectly matched between the underlying physical interfaces & the >>>>port-channel interface.... the po interface was a mess. The new >>>>physical link on it's own is clean as a whistle when I setup a test >>>>vlan, or set both sides up as routed interfaces.... >>>> >>>>Anybody have any light to shed? >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>cisco-nsp mailing list cisco-nsp@puck.nether.net >>>https://puck.nether.net/mailman/listinfo/cisco-nsp >>>archive at http://puck.nether.net/pipermail/cisco-nsp/ >>> >>> >>> >>_______________________________________________ >>cisco-nsp mailing list cisco-nsp@puck.nether.net >>https://puck.nether.net/mailman/listinfo/cisco-nsp >>archive at http://puck.nether.net/pipermail/cisco-nsp/ >> >> >> > >_______________________________________________ >cisco-nsp mailing list cisco-nsp@puck.nether.net >https://puck.nether.net/mailman/listinfo/cisco-nsp >archive at http://puck.nether.net/pipermail/cisco-nsp/ > > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/