
how-to block ads
|
|
Uniqs: 471 |
Share Topic  |
 |
|
|
|
 RFPAerie Gang of Eagles join:2003-12-29 Hollis, NY | [HELP] Etherchannel Configuration - A bit Confused 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. | |  | 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 | |  RFPAerie 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
| |  RFPAerie 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. | |  | 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 . | |  | reply to RFP see other post | |
|