Re: [c-nsp] Port-Channel Problem
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 100 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 100 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
Re: [c-nsp] Port-Channel Problem
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 100 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 100 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
Re: [c-nsp] Port-Channel Problem
For the records - we use 3750 cross- stack even with 12.2.25SEC (yeah, dusty by now, but the first version that supported that) and they just work, and they absolutely work fine. -ako On Wed, 9 May 2007 16:52:00 -0700, 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 100 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 passiveEnable 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/
Re: [c-nsp] Port-Channel Problem
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 100 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 passiveEnable 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/
Re: [c-nsp] Port-Channel Problem
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 100 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 passiveEnable 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/
Re: [c-nsp] Port-Channel Problem
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 100 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 passiveEnable 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/
