11-23-2011 10:20 AM - edited 03-07-2019 03:34 AM
I have a 7609 with two LAG groups (Etherchannel not LACP) going to two separate devices that DO NOT participate in spanning-tree (Occam gear if you must know). I'm running 802.1w across the LAG groups but the convergence time is terrible! In essence, the 7609 is running spanning tree against itself (between the two blades). What can I do to fix my configuration?
Topology:
7609 Blade 1 ----1G----> Occam 6450 VPT1
/\
| 10G
\/
7609 Blade 2 ----1G----> Occam 6450 VPT2
Testing:
If I disable the ports on the equipment connected to g1/17 & g1/18, it takes ~30 seconds for spanning tree to start forwarding on g2/17 & g2/18.
When I bring the ports back up on the other side of g1/17 & g1/18 which are in a lag group, g2/17 & g2/18 immediately go into block mode while g1/17 & g1/18 start learning for another ~30 seconds!!
Cisco IOS Software Version 12.2(33)SRD5, RELEASE SOFTWARE (fc2)
7609#sho span int g1/17
Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0081 Desg LRN 3 128.3329 P2p
7609#sho span int g1/18
Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0081 Desg LRN 3 128.3329 P2p
7609#sho span int g2/17
Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0081 Back BLK 3 128.3330 P2p
7609#sho span int g2/18
Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0081 Back BLK 3 128.3330 P2p
sho spanning-tree vlan 81 detail
VLAN0081 is executing the rstp compatible Spanning Tree protocol
Bridge Identifier has priority 32768, sysid 81, address 0027.0dfd.b600
Configured hello time 2, max age 20, forward delay 15, tranmsit hold-count 6
We are the root of the spanning tree
Topology change flag not set, detected flag not set
Number of topology changes 16 last change occurred 19:28:34 ago
from Port-channel81
Times: hold 1, topology change 35, notification 2
hello 2, max age 20, forward delay 15
Timers: hello 0, topology change 0, notification 0, aging 300
Port 3329 (Port-channel81) of VLAN0081 is designated forwarding
Port path cost 3, Port priority 128, Port Identifier 128.3329.
Designated root has priority 32849, address 0027.0dfd.b600
Designated bridge has priority 32849, address 0027.0dfd.b600
Designated port id is 128.3329, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
BPDU: sent 34958, received 1
Port 3330 (Port-channel82) of VLAN0081 is backup blocking
Port path cost 3, Port priority 128, Port Identifier 128.3330.
Designated root has priority 32849, address 0027.0dfd.b600
Designated bridge has priority 32849, address 0027.0dfd.b600
Designated port id is 128.3329, designated path cost 0
Timers: message age 16, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
BPDU: sent 92, received 35337
Configuration:
interface Port-channel81
description Network-8-VPTs
switchport
switchport access vlan 81
switchport trunk encapsulation dot1q
switchport trunk native vlan 80
switchport trunk allowed vlan 81
switchport mode trunk
load-interval 30
!
interface GigabitEthernet1/17
description Occam-VPT1-2
switchport
switchport access vlan 81
switchport trunk encapsulation dot1q
switchport trunk native vlan 80
switchport trunk allowed vlan 81
switchport mode trunk
logging event link-status
load-interval 30
channel-group 81 mode on
!
interface GigabitEthernet1/18
description Occam-VPT2-1
switchport
switchport access vlan 81
switchport trunk encapsulation dot1q
switchport trunk native vlan 80
switchport trunk allowed vlan 81
switchport mode trunk
logging event link-status
load-interval 30
channel-group 81 mode on
!
interface Port-channel82
description Network-8-VPTs
switchport
switchport access vlan 81
switchport trunk encapsulation dot1q
switchport trunk native vlan 80
switchport trunk allowed vlan 81
switchport mode trunk
!
interface GigabitEthernet2/17
description Occam-VPT2-2
switchport
switchport access vlan 81
switchport trunk encapsulation dot1q
switchport trunk native vlan 80
switchport trunk allowed vlan 81
switchport mode trunk
logging event link-status
load-interval 30
channel-group 82 mode on
!
interface GigabitEthernet2/18
description Occam-VPT2
switchport
switchport access vlan 81
switchport trunk encapsulation dot1q
switchport trunk native vlan 80
switchport trunk allowed vlan 81
switchport mode trunk
logging event link-status
load-interval 30
channel-group 82 mode on
end
Thanks for any help you can offer!
-=JGR
Solved! Go to Solution.
11-23-2011 12:27 PM
Hello,
The behavior you are seeing may appear confusing but it is actually expectable.
What you have done is, exactly as you have noted yourself, essentially connected your 7609 back to itself. On this link, one of the ports is elected as Designated Forwarding, the other as Backup Discarding. The Backup port is defined as a port that provides a backup of Designated port - both these ports have to be located on the same switch and connected to the same segment. This is clearly the case with your link, as also evidenced by some of your attached output:
7609#sho span int g2/17
Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0081 Back BLK 3 128.3330 P2p
7609#sho span int g2/18
Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0081 Back BLK 3 128.3330 P2p
Now, Cisco switches do not put the Backup port rapidly into Designated Forwarding role/state. If the Designated port fails, the Backup ports has to go over the RSTP sequence of Discard -> Learning -> Forwarding states driven by timers, hence the 30s delay you are experiencing. I am not sure if this is mandated by the RSTP standard (I do believe it is but I am not 100% sure here) or if this is just a peculiarity of Cisco RSTP implementation but the bottom line is - RSTP will not rapidly unblock a Backup Discarding port.
What I suggest using here is the Flex Link feature, i.e. defining a pair of ports that actually do not use STP but that provide a mutual backup for each other - if one works, the other is automatically put to a blocking state, and if the primary port fails, the other is automatically and immediately put to forwarding state. Read more about the feature here:
http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/flexlink.html
Also, this documentation seems to be very limited on the additional features related to the Flex Links (preemption of the ports), so I suggest extending the knowledge about the feature using this documentation for a different Catalyst product line (3560):
In your case, the configuration should look as follows:
interface Po81
switchport backup interface Po82
switchport backup interface Po82 preemption mode forced
Please test this in a maintenance window and let us know if it worked!
Best regards,
Peter
11-23-2011 12:27 PM
Hello,
The behavior you are seeing may appear confusing but it is actually expectable.
What you have done is, exactly as you have noted yourself, essentially connected your 7609 back to itself. On this link, one of the ports is elected as Designated Forwarding, the other as Backup Discarding. The Backup port is defined as a port that provides a backup of Designated port - both these ports have to be located on the same switch and connected to the same segment. This is clearly the case with your link, as also evidenced by some of your attached output:
7609#sho span int g2/17
Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0081 Back BLK 3 128.3330 P2p
7609#sho span int g2/18
Vlan Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
VLAN0081 Back BLK 3 128.3330 P2p
Now, Cisco switches do not put the Backup port rapidly into Designated Forwarding role/state. If the Designated port fails, the Backup ports has to go over the RSTP sequence of Discard -> Learning -> Forwarding states driven by timers, hence the 30s delay you are experiencing. I am not sure if this is mandated by the RSTP standard (I do believe it is but I am not 100% sure here) or if this is just a peculiarity of Cisco RSTP implementation but the bottom line is - RSTP will not rapidly unblock a Backup Discarding port.
What I suggest using here is the Flex Link feature, i.e. defining a pair of ports that actually do not use STP but that provide a mutual backup for each other - if one works, the other is automatically put to a blocking state, and if the primary port fails, the other is automatically and immediately put to forwarding state. Read more about the feature here:
http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/flexlink.html
Also, this documentation seems to be very limited on the additional features related to the Flex Links (preemption of the ports), so I suggest extending the knowledge about the feature using this documentation for a different Catalyst product line (3560):
In your case, the configuration should look as follows:
interface Po81
switchport backup interface Po82
switchport backup interface Po82 preemption mode forced
Please test this in a maintenance window and let us know if it worked!
Best regards,
Peter
11-23-2011 02:58 PM
Thanks Peter for the quick (and accurate) response!
I've tested this and it works well. My best results are 15-200ms and my worse 3-5 seconds all depending on where I shutdown or pull a link. This was tested across port-channels with details below.
Configuration:
interface Port-channel81
description Network-8-VPTs
switchport
switchport access vlan 81
switchport trunk encapsulation dot1q
switchport trunk native vlan 80
switchport trunk allowed vlan 81
switchport mode trunk
switchport backup interface Port-channel82
load-interval 30
!
interface Port-channel82
description Network-8-VPTs
switchport
switchport access vlan 81
switchport trunk encapsulation dot1q
switchport trunk native vlan 80
switchport trunk allowed vlan 81
switchport mode trunk
end
Traffic Test:
7609#sho int port-channel 81 | i second
30 second input rate 337000 bits/sec, 539 packets/sec
30 second output rate 18110000 bits/sec, 1501 packets/sec
7609#sho int port-channel 82 | i second
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
7609#sho int switchport backup
Switch Backup Interface Pairs:
Active Interface Backup Interface State
------------------------------------------------------------------------
Port-channel81 Port-channel82 Active Up/Backup Standby
7609(config)#int port-channel 81
7609(config-if)#shut
7609#sho int port-channel 81 | i second
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
7609#sho int port-channel 82 | i second
30 second input rate 109000 bits/sec, 173 packets/sec
30 second output rate 6573000 bits/sec, 545 packets/sec
7609#sho int switchport backup
Switch Backup Interface Pairs:
Active Interface Backup Interface State
------------------------------------------------------------------------
Port-channel81 Port-channel82 Active Down/Backup Up
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide