Etherchannel Configuration

[traqglow]

Hi, I'm new at configuring Etherchannel, I'm a bit puzzled at a few things and have a few questions:

1. After applying the commands below within the lab, the gigabit interfaces on switch (CORE A) remain amber color and not green, I don't know what this means, doing a "show interface g0/1 & 2" shows the g0/1 & 2 interfaces in the up/up state and everything seems ok. Does anyone know why the g0/1&2 interfaces remain amber?

2. Second is, for some strange reason, everyone on the 6th floor is reachable from the 7th floor only via the Etherchannel from CORE B Gi0/1 & 2 to IDF SW 2. I think this has something to do with the amber color state of the CORE A gigabit interfaces.

3. If one link from the Etherchannel going from SW 2 to CORE B goes down, the entire 6th Floor is unreachable for around 40 seconds. I don't know why this happens, but the amber links from CORE A to SW1 then turn green, allowing everyone from the 6th floor to be rechable only via CORE A to SW1. Why does this happen, and why does it take 40 seconds for the two floors to become reachable again? If there are two links in the Etherchannel isn't this supposed to help in the redundancy?

Switchport Configuration Per Switch

base commands used on each switch and interfaces. config t interface range g0/1 - g0/2 switchport trunk encapsulation dot1q switchport mode trunk channel-group 1 mode desirable core b interface FastEthernet0/23 channel-group 2 mode desirable switchport trunk encapsulation dot1q switchport mode trunk ! interface FastEthernet0/24 channel-group 2 mode desirable switchport trunk encapsulation dot1q switchport mode trunk ! interface GigabitEthernet0/1 channel-group 1 mode desirable switchport trunk encapsulation dot1q switchport mode trunk ! interface GigabitEthernet0/2 channel-group 1 mode desirable switchport trunk encapsulation dot1q switchport mode trunk ! interface Port-channel 1 switchport mode trunk ! interface Port-channel 2 switchport mode trunk core a interface FastEthernet0/23 channel-group 2 mode desirable switchport trunk encapsulation dot1q switchport mode trunk ! interface FastEthernet0/24 channel-group 2 mode desirable switchport trunk encapsulation dot1q switchport mode trunk ! interface GigabitEthernet0/1 channel-group 1 mode desirable switchport trunk encapsulation dot1q switchport mode trunk ! interface GigabitEthernet0/2 channel-group 1 mode desirable switchport trunk encapsulation dot1q switchport mode trunk ! interface Port-channel 1 switchport mode trunk ! interface Port-channel 2 switchport mode trunk 6idf1 = sw1 interface FastEthernet0/23 channel-group 2 mode desirable switchport trunk encapsulation dot1q switchport mode trunk ! interface FastEthernet0/24 channel-group 2 mode desirable switchport trunk encapsulation dot1q switchport mode trunk ! interface GigabitEthernet0/1 channel-group 1 mode desirable switchport trunk encapsulation dot1q switchport mode trunk ! interface GigabitEthernet0/2 channel-group 1 mode desirable switchport trunk encapsulation dot1q switchport mode trunk ! interface Port-channel 1 switchport mode trunk ! interface Port-channel 2 switchport mode trunk 6idf2 = sw2 interface FastEthernet0/23 channel-group 2 mode desirable switchport trunk encapsulation dot1q switchport mode trunk ! interface FastEthernet0/24 channel-group 2 mode desirable switchport trunk encapsulation dot1q switchport mode trunk ! interface GigabitEthernet0/1 channel-group 1 mode desirable switchport trunk encapsulation dot1q switchport mode trunk ! interface GigabitEthernet0/2 channel-group 1 mode desirable switchport trunk encapsulation dot1q switchport mode trunk ! interface Port-channel 1 switchport mode trunk ! interface Port-channel 2 switchport mode trunk

Any help with this would be greatly appreciate, thank you!

[Jeff Van Houten]

put switchport trunk encap dot1q on the port channel interfaces. Change the ports to channel-group mode on instead of desirable.

Sent from Cisco Technical Support iPad App

[Jerry Ye]

First, it has nothing to do with you channel-group config. You description makes lot of sense if you think about spanning-tree.

The ports are amber because it is in STP blocking state, you can verify it by using the show spanning-tree command.

Second, when an interface goes down on the active port-channel at CORE B, your switch is going into STP state (BLK, LIS, LRN), and the cost of the link will change to less prefer. Hence, the port-channel at your CORE A will come out from amber (green) right now. To speed up STP, you can use RSTP through out your L2 domain. It should be able to lower the calculation to about 3 second.

Third, port-channel will help on redundancy, but like I said in the first 2 points, your problem has to do with spanning-tree instead of port-channel.

Regards,

jerry

[traqglow]

Hi jeye, thank you for your response, I though it could've been spanning-tree, however I'm not too good with spanning-tree, going to research that furture.

It's strange, after changing the channel-group mode to on, everything is now working accross all ethernchannels. I don't understand, does spanning-tree no longer take affect, will this cause loops in the long run?

Even with RSTP, if 1 link of the 2 within an Etherchannel fails will RSTP recalculate the costs causing a 3 second down time?

[Jerry Ye]

WIthout looking at the full config and some show output I cannot comment why channel-group on will change its behavior or is there a loop in your network right now (I kind of doubted).

However, we do recommend customer to use channel-protocol to avoid config issue that causes traffic black hole. Using channel negotiation protocol is strongly recommended.

Yes, with RSTP, it will still cause about 3 second outage.

Regards,

jerry

[traqglow]

Hi guys, doing a "show spanning-tree" on each switch gave the following output (below). This output was taken after changing the channel-group mode from "desirable" to "on". What are your throughts on this output, is STP running ok?

STP after channel-group mode change from "desirable" to "on"

core a VLAN0001   Spanning tree enabled protocol ieee   Root ID    Priority    32769              Address     000A.F379.69C9              Cost        9              Port        27(Port-channel 2)              Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec   Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)              Address     0090.21A0.5A08              Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec              Aging Time  20 Interface        Role Sts Cost      Prio.Nbr Type ---------------- ---- --- --------- -------- -------------------------------- Fa0/2            Desg FWD 19        128.2    P2p Po2              Root FWD 9         128.27   Shr Gi0/1            Desg FWD 4         128.25   P2p Gi0/2            Desg FWD 4         128.26   P2p core b VLAN0001   Spanning tree enabled protocol ieee   Root ID    Priority    32769              Address     000D.BD58.18B3              This bridge is the root              Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec   Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)              Address     000D.BD58.18B3              Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec              Aging Time  20 Interface        Role Sts Cost      Prio.Nbr Type ---------------- ---- --- --------- -------- -------------------------------- Po2              Desg FWD 9         128.27   Shr Fa0/1            Desg FWD 19        128.1    P2p Gi0/1            Desg FWD 4         128.25   P2p Gi0/2            Desg FWD 4         128.26   P2p SW1 VLAN0001   Spanning tree enabled protocol ieee   Root ID    Priority    32769              Address     000A.F379.69C9              Cost        9              Port        27(Port-channel 2)              Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec   Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)              Address     0010.112E.1DBA              Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec              Aging Time  20 Interface        Role Sts Cost      Prio.Nbr Type ---------------- ---- --- --------- -------- -------------------------------- Fa0/1            Desg FWD 19        128.1    P2p Po2              Root FWD 9         128.27   Shr Po1              Desg FWD 0         128.28   Shr SW2 VLAN0001   Spanning tree enabled protocol ieee   Root ID    Priority    32769              Address     000A.F379.69C9              This bridge is the root              Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec   Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)              Address     000A.F379.69C9              Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec              Aging Time  20 Interface        Role Sts Cost      Prio.Nbr Type ---------------- ---- --- --------- -------- -------------------------------- Fa0/1            Desg FWD 19        128.1    P2p Po2              Desg FWD 9         128.27   Shr Po1              Desg FWD 0         128.28   Shr

[Jerry Ye]

You STP looks fine but I see some design issues:

1. Your STP root bridge is at SW2 not your CORE.

2. You did not define a STP root priority at your CORE, this is cause SW2 to become the root (based on system lowest system MAC).

3. The above can cause STP issue since the lowest system MAC can mean it is an older switch.

4. You are not running RSTP.

Below is the Campus Network SRND, it should provide a good reference how various design option and tunning:

http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/HA_campus_DG/hacampusdg.html

Regards,

jerry

[traqglow]

Hi Jeff Van Houten, thank you, by changing all the "channel-group interface modes to "on" instead of desirable allowed all the interfaces to go green instead of 1 remaining amber. Most important of all, a single link from any etherchannel can go down without bringing down the entire 6th floor.

1. What caused the amber ports between CORE A and SW1, and why did they suddenly both go green after changing from desirable to on?

2. Below are the available modes, which one is preferred?

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

2. Why can a single link be disconnected from an Etherchannel where it is transparent and no longer requires waiting 40 seconds for the links to be reestablished?

Thank you again!

[Jeff Van Houten]

1. You shouldn't leave switch to switch communication to a protocol that "tries" to do something. Channel group mode on simply turns ether channel on without negotiation.

Sent from Cisco Technical Support iPad App