republican-creole
site Search:


 
    All Forums Hot Topics Gallery






how-to block ads


 
Search Topic:
Uniqs:
471
Share Topic
Posting?
Post a:
Post a:
Links: ·Submit a new forum topic ·Forum FAQ ·Submit a FAQ ·Docs Guidelines and Advisories ·EOS/EOL thread
AuthorAll Replies


RFP
Aerie Gang of Eagles

join:2003-12-29
Hollis, NY

[HELP] Etherchannel Configuration - A bit Confused

Click for full size
1
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?


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!

nosx

join:2004-12-27
00000
kudos:5

spanning tree.
spanning tree.
spanning tree.

First change your port-channel mode to active on the member links. Also do a show etherchan sum and make sure the port chan is all up and happy. Double check the show cdp neighbor ports are also configured for mode active.

Then locate the spanning tree root bridge for all vlans, make sure its on the desired switch (primary HSRP gateway).

Do a show span and see what kind of spanning tree is running. Per-vlan rapid spanning tree or multiple spanning tree will be your best bet. Single instance rapid spanning tree will also work for a lab, but is somewhat less desirable in TRW.


DocLarge
Premium
join:2004-09-08
kudos:1

reply to RFP
Tagging along with NOSX on this one:

Question #1: , Keep in mind "all ports" of your etherchannel "must" have identical settings (i.e., speed, etherchannel group assignment, etc...).

Question #2: Do a "sh int Po1 trunk" (if Po1 is te number designator) to see if the vlan your users are having issues with is allowed through the trunk.

Question #3:As stated by NOSX, check spanning-tree. It sounds like one of your ports is in "blocking" mode, then going to "forwarding" mode. As mentioned in "question #2," make sure the settings for your ports are identical (i.e, speed, duplex, etc...).

Here's a couple of resources that might help:

1) Keith Barker, CCIE #6783 - Spanning Tree

»www.youtube.com/watch?v=8CZiVd2K···ture=pyv


2) Chris Bryant, CCIE #12933 - Etherchannel Configuration

»www.youtube.com/watch?v=UCL3LbsgrqI


Jay


RFP
Aerie Gang of Eagles

join:2003-12-29
Hollis, NY

reply to nosx

said by nosx:

First change your port-channel mode to active on the member links. Also do a show etherchan sum and make sure the port chan is all up and happy. Double check the show cdp neighbor ports are also configured for mode active.

What are "member links" and how do I find them? I've read "active" is not very good, all links should be set to mode "on" as switches should not be negotiating anything, is this true? What do you think of the outputs below, I think "show etherchannel summary" is showing the defined etherchannel groups correctly. Show cdp neighbor is a bit confusing, is "por 2" and "por 1" the actual etherchannel groups?

CORE_A#show etherchannel summary 
Flags:  D - down        P - in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      f - failed to allocate aggregator
        u - unsuitable for bundling
        w - waiting to be aggregated
        d - default port
 
Number of channel-groups in use: 2
Number of aggregators:           2
 
Group  Port-channel  Protocol    Ports
------+-------------+-----------+----------------------------------------------
 
1      Po1(SU)           -      Gig0/1(P) Gig0/2(P) 
2      Po2(SU)           -      Fa0/23(P) Fa0/24(P) 
 

CORE_A#show cdp neighbors (only from CORE_A#)
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID    Local Intrfce   Holdtme    Capability   Platform    Port ID
CORE_B       Por 2            152                    3560        Fas 0/23
CORE_B       Por 2            152                    3560        Fas 0/24
CORE_B       Por 2            152                    3560        Por 2
6idf1        Por 1            147                    3560        Gig 0/1
6idf1        Por 1            147                    3560        Gig 0/2
6idf1        Por 1            147                    3560        Por 1
CORE_A#
 

said by nosx:

spanning tree.
Then locate the spanning tree root bridge for all vlans, make sure its on the desired switch (primary HSRP gateway).

I'm not using HSRP at the moment, will it help me provide redundancy across the switches since the two cables making up the Etherchannel seem to provide no redundancy; just bandwidth?

said by nosx:

Do a show span and see what kind of spanning tree is running. Per-vlan rapid spanning tree or multiple spanning tree will be your best bet. Single instance rapid spanning tree will also work for a lab, but is somewhat less desirable in TRW.

I'm new to spanning tree and will try to learn much as I can about it.
What is "single instance rapid spanning tree"? Below are outputs for the the command show spanning-tree from each switch. Please let me know if it's a good or bad setup, I think most of the spanning-tree in my lab is automatically created, is it best to design a STP or RSTP manually in TRW?

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
 


RFP
Aerie Gang of Eagles

join:2003-12-29
Hollis, NY

reply to DocLarge

said by DocLarge:

Tagging along with NOSX on this one:
Question #1: , Keep in mind "all ports" of your etherchannel "must" have identical settings (i.e., speed, etherchannel group assignment, etc...).

I was wondering what the significance of the "channel-group #" was. Why do they have to be the same across the switches, is this information shared? Does making separate "channel-group" number's make a difference?

said by DocLarge:

Question #2: Do a "sh int Po1 trunk" (if Po1 is te number designator) to see if the vlan your users are having issues with is allowed through the trunk.

Looks like all the vlans are allowed on the trunk.

CORE_A#show interfaces trunk 
Port        Mode         Encapsulation  Status        Native vlan
Fa0/23      on           802.1q         trunking      1
Fa0/24      on           802.1q         trunking      1
Gig0/1      on           802.1q         trunking      1
Gig0/2      on           802.1q         trunking      1
Po1         on           802.1q         trunking      1
Po2         on           802.1q         trunking      1
 
Port        Vlans allowed on trunk
Fa0/23      1-1005
Fa0/24      1-1005
Gig0/1      1-1005
Gig0/2      1-1005
Po1         1-1005
Po2         1-1005
 
Port        Vlans allowed and active in management domain
Fa0/23      1
Fa0/24      1
Gig0/1      1
Gig0/2      1
Po1         1
Po2         1
 
Port        Vlans in spanning tree forwarding state and not pruned
Fa0/23      1
Fa0/24      1
Gig0/1      none
Gig0/2      none
Po1         none
Po2         1
 

said by DocLarge:

Question #3:As stated by NOSX, check spanning-tree. It sounds like one of your ports is in "blocking" mode, then going to "forwarding" mode. As mentioned in "question #2," make sure the settings for your ports are identical (i.e, speed, duplex, etc...).

I'm going to learn spanning-tree. My biggest concern right now is what solution will provide transparent redundancy while utilizing the great features of Ethernchannel to provide more bandwidth. Waiting for a link to come back is not really an option for something I would design as some networks today rely on 100% up time through out the day with very low latency.

nosx

join:2004-12-27
00000
kudos:5

The reason your switches are performing so poorly at failover and recovery is this:

VLAN0001
   Spanning tree enabled protocol ieee
 
It should look more like this:
VLAN0001
  Spanning tree enabled protocol rstp
 
do this:
conf t
  spanning-tree mode rapid-pvst
 end
wr
 

Always autonegotiate wherever possible, especially things like link aggregation. Too many massive outages over the years have been caused by forcing port-channels into "mode on". By allowing LACP to operate normally and negotiate link aggregation, you are saved from accidential misconfiguration or cabling induced problems.

In your case, "core B" is the root bridge and it should probablly be the secondary backup root, not the primary.

I would draw a picture with every switch, what its bridge ID is, and make sure that on the primary device it is the root for all VLANs. You can do this quickly and automatically with this command:
conf t
  spanning-tree vlan 1-4094 root primary
 exit
wr
 
The secondary switch (when you DO have HSRP setup for the default gateway) make sure that it is the secondary bridge similarly:
conf t
  spanning-tree vlan 1-4094 root secondary
 exit
wr
 

Along the lines of other best practices these days, make sure VTP is disabled (mode transparent) so that you can use vlans >1000. Configure HSRP on upstream default gateway interface "int vlan xyz" for each respective vlan, etc.

Channel group numbers are only locally significant. You can have Po1 on switch A going to Po7 on switch B. It DOES tend to help with the sanity when you keep them in sync however, unless you have a very specific well planned and executed port-channel numbering plan in mind.


vipergg22

@frontiernet.net

reply to RFP
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?

Answer -- They remain amber because spanning tree is blocking that link . Your design has a built in loop and spanning tree has to block somewhere and that is the link it has chosen .

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.

Answer. Because the gig link is blocked it has to go all the way around the horn so to speak , its the only way to the gateway .

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?

Answer -- Your etherchannel is not working , what you have is 2 individual trunk ports so one side is blocked . When one link goes down spanning tree runs (about 40 seconds) before the other link goes active. If the etherchannel was working properly it would not have this issue because spanning tree sees that as a single logical link so losing a single link would not cause spanning tree to run .


vipergg

join:2010-03-14

reply to RFP
see other post


Friday, 01-Jun 18:55:50 Terms of Use & Privacy | feedback | contact | Hosting by nac.net - DSL,Hosting & Co-lo
over 12.5 years online © 1999-2012 dslreports.com.
Most commented news this week
Hot Topics