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