Uplink Fast

-


in normal STP operation, SW1 is the root. SW3 e0/0 is in block status.
SW3#sh spanning-tree
VLAN0001
  Spanning tree enabled protocol ieee
  Root ID    Priority    32769
             Address     aabb.cc00.0100
             Cost        100
             Port        2 (Ethernet0/1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     aabb.cc00.0300
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/0               Altn BLK 100       128.1    Shr
Et0/1               Root FWD 100       128.2    Shr

Enable debug on SW3 and shut down e0/1 port on SW1.
SW3#debug spanning-tree events
SW3#
*Dec 29 15:52:13.815: STP: VLAN0001 new root port Et0/0, cost 200
*Dec 29 15:52:13.815: STP: VLAN0001 Et0/0 -> listening
*Dec 29 15:52:13.815: STP[1]: Generating TC trap for port Ethernet0/1
SW3#sh spanning-tree
*Dec 29 15:52:15.815: %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to down
SW3#sh spanning-tree
*Dec 29 15:52:15.815: STP: VLAN0001 sent Topology Change Notice on Et0/0
*Dec 29 15:52:16.815: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to down
SW3#sh spanning-tree
*Dec 29 15:52:28.815: STP: VLAN0001 Et0/0 -> learning
SW3#
*Dec 29 15:52:43.815: STP[1]: Generating TC trap for port Ethernet0/0
*Dec 29 15:52:43.815: STP: VLAN0001 Et0/0 -> forwarding

We can see SW e0/0 went through listening and learning state, it took 30 exact 30 seconds (2x fw_delay) to transferred to forwarding state


Then let's enable SW1 port e0/1.
SW3>
*Dec 29 16:05:05.879: %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
*Dec 29 16:05:06.883: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
*Dec 29 16:05:06.883: set portid: VLAN0001 Et0/1: new port id 8002
*Dec 29 16:05:06.883: STP: VLAN0001 Et0/1 -> listening
SW3>
*Dec 29 16:05:07.839: STP: VLAN0001 new root port Et0/1, cost 100
*Dec 29 16:05:07.839: STP: VLAN0001 sent Topology Change Notice on Et0/1
*Dec 29 16:05:07.839: STP[1]: Generating TC trap for port Ethernet0/0
*Dec 29 16:05:07.839: STP: VLAN0001 Et0/0 -> blocking
SW3>
*Dec 29 16:05:21.887: STP: VLAN0001 Et0/1 -> learning
SW3>
*Dec 29 16:05:36.891: STP[1]: Generating TC trap for port Ethernet0/1
*Dec 29 16:05:36.891: STP: VLAN0001 Et0/1 -> forwarding
SW3>
we can see e0/1 went to listening state and SW3 received better BPDU on e0/1 so e0/1 became the new root port, this caused the old root port e0/0 went into blocking state, then after e0/1 went through listening and learning state, it took 30 seconds, finally e0/1 went to forwarding state, so within this 30 seconds, no traffic can be forwarded from SW3 to anywhere, because both e0/0 and e0/1 are not in forwarding state.


Let's shut down SW e0/1 to simulate there is only one uplink on SW3, then we enable the port to simulate there is a new redundant link added to SW3:
SW3>
*Dec 29 16:17:13.231: %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
*Dec 29 16:17:14.231: set portid: VLAN0001 Et0/0: new port id 8001
*Dec 29 16:17:14.231: STP: VLAN0001 Et0/0 -> listening
*Dec 29 16:17:14.235: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
SW3>
*Dec 29 16:17:15.907: STP: VLAN0001 Et0/0 -> blocking
SW3>
We can see the new link is added, it went to listening state then immediately jumped into blocking state as SW3 knows it doesn't have a better BPDU on this new link. So traffic forwarding on SW is not interrupted.

To Summarize:
1. When  a new link is added but doesn't have a better path, SPT has no change.
2. When a new link is added and has a better path, new root port is chosen, SPT is recalculated, it takes 30 seconds for the convergence, and no traffic can be forwarded to uplink switch during this 30 second.
3. When redundant link exists, and the root link is down, it took 30 second for the redundant link transferring to forwarding state. During this 30 second. no traffic can be forwarded to uplink switches.


Now let's enable uplinkfast on sw3, note this caused priority on SW3 to be changed to a high number.
SW3(config)#spanning-tree uplinkfast
SW3(config)#
*Dec 29 16:32:44.083: setting bridge id (which=1) prio 49153 prio cfg 49152 sysid 1 (on) id C001.aabb.cc00.0300
SW3(config)#
Then we shutdown e0/1 on SW1:
SW1(config)#int e0/1
SW1(config-if)#shut
SW1(config-if)#
*Dec 29 16:33:13.471: %LINK-5-CHANGED: Interface Ethernet0/1, changed state to administratively down
*Dec 29 16:33:14.471: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to down
SW1(config-if)#
SW3(config)#
*Dec 29 16:33:22.003: STP: VLAN0001 new root port Et0/0, cost 3200
*Dec 29 16:33:22.003: %SPANTREE_FAST-7-PORT_FWD_UPLINK: VLAN0001 Ethernet0/0 moved to Forwarding (UplinkFast).
*Dec 29 16:33:22.003: STP[1]: Generating TC trap for port Ethernet0/0
*Dec 29 16:33:22.003: STP[1]: Generating TC trap for port Ethernet0/1
*Dec 29 16:33:22.007: stp_state_change_completed: Et0/0. new state = FWD
SW3(config)#
*Dec 29 16:33:24.003: STP: VLAN0001 sent Topology Change Notice on Et0/0
SW3(config)#
*Dec 29 16:33:24.003: %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to down
*Dec 29 16:33:25.003: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to down
SW3(config)#
We can see as soon as SW3 notice the link on e0/1 is down, its e0/0 port immediately went to forwarding state due to Uplinkfast is configured.

Then we re-enable e0/1 on sw3 to simulate the primary link is back:
SW1(config)#int e0/1
SW1(config-if)#no shut
SW1(config-if)#
*Dec 29 16:48:02.807: %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
*Dec 29 16:48:03.807: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
SW3(config)#
*Dec 29 16:48:04.091: %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
*Dec 29 16:48:05.091: set portid: VLAN0001 Et0/1: new port id 8002
*Dec 29 16:48:05.091: STP: VLAN0001 Et0/1 -> listening
*Dec 29 16:48:05.091: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
SW3(config)#
*Dec 29 16:48:05.391: STP: VLAN0001 Et0/1: root port delay timer active
*Dec 29 16:48:05.391: STP: VLAN0001 Et0/1 -> blocking
SW3(config)#
*Dec 29 16:48:40.391: STP: VLAN0001 new root port Et0/1, cost 3100
*Dec 29 16:48:40.391: STP: VLAN0001 Et0/0 -> blocking (uplinkfast)
*Dec 29 16:48:40.391: STP[1]: Generating TC trap for port Ethernet0/0
*Dec 29 16:48:40.391: %SPANTREE_FAST-7-PORT_FWD_UPLINK: VLAN0001 Ethernet0/1 moved to Forwarding (UplinkFast).*Dec 29 16:48:40.391: STP[1]: Generating TC trap for port Ethernet0/1
*Dec 29 16:48:40.391: STP: VLAN0001 sent Topology Change Notice on Et0/1
*Dec 29 16:48:40.391: stp_state_change_completed: Et0/1. new state = FWD
SW3(config)#
We can see when the new primary link came up, a delay timer started which let SW3 wait 35 seconds to transfer root port from e0/0 to e0/1.

 --------------------------

Now we remove uplinkfast on sw3 and enable RSPT on all three switches:
SW1(config)#spanning-tree mode rapid-pvst
SW2(config)#spanning-tree mode rapid-pvst
SW3(config)#spanning-tree mode rapid-pvst
Then we disable e0/1 on SW1 to simulate the primary link failure
SW1(config)#int e0/1
SW1(config-if)#shut
SW1(config-if)#
*Dec 29 17:02:08.871: %LINK-5-CHANGED: Interface Ethernet0/1, changed state to administratively down
*Dec 29 17:02:09.871: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to down
SW1(config-if)#
SW3(config)#
*Dec 29 17:02:13.403: RSTP(1): Et0/1 rcvd info expired
*Dec 29 17:02:13.403: RSTP(1): updt roles, information on root port Et0/1 expired
*Dec 29 17:02:13.403: RSTP(1): Et0/0 is now root port
*Dec 29 17:02:13.403: RSTP(1): Et0/1 blocked by re-root
*Dec 29 17:02:13.403: RSTP(1): Et0/1 is now designated
*Dec 29 17:02:13.403: RSTP[1]: Et0/1 state change completed. New state is [blocking]
*Dec 29 17:02:13.403: RSTP[1]: Et0/0 state change completed. New state is [forwarding]
*Dec 29 17:02:13.403: RSTP(1): starting topology change timer for 35 seconds
*Dec 29 17:02:13.403: STP[1]: Generating TC trap for port Ethernet0/0
SW3(config)#
*Dec 29 17:02:13.411: RSTP(1): transmitting a proposal on Et0/1
*Dec 29 17:02:13.735: RSTP(1): transmitting a proposal on Et0/1
SW3(config)#
*Dec 29 17:02:14.735: RSTP(1): transmitting a proposal on Et0/1
SW3(config)#
*Dec 29 17:02:16.735: RSTP(1): transmitting a proposal on Et0/1
SW3(config)#
*Dec 29 17:02:19.155: %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to down
*Dec 29 17:02:20.155: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to down
SW3(config)#
*Dec 29 17:02:48.403: RSTP(1): stopping topology change timer
SW3(config)#
We can see port e0/0 went to forwarding state as soon as the switch detected the link failure. So uplinkfast is a buildin feature of RSPT.

Then let's enable e0/1 on sw1 to simulate the primary link recovery:
SW1(config-if)#no shut
SW1(config-if)#
*Dec 29 17:06:53.979: %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
*Dec 29 17:06:54.979: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
SW1(config-if)#
SW3(config)#
*Dec 29 17:06:55.151: %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
*Dec 29 17:06:56.151: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
*Dec 29 17:06:56.151: RSTP(1): initializing port Et0/1
*Dec 29 17:06:56.151: RSTP(1): Et0/1 is now designated
*Dec 29 17:06:56.159: RSTP[1]: Et0/1 state change completed. New state is [blocking]
*Dec 29 17:06:56.159: RSTP(1): transmitting a proposal on Et0/1
SW3(config)#
*Dec 29 17:06:56.791: RSTP(1): transmitting a proposal on Et0/1
*Dec 29 17:06:57.431: RSTP(1): updt roles, received superior bpdu on Et0/1
*Dec 29 17:06:57.431: RSTP(1): Et0/1 is now root port
*Dec 29 17:06:57.431: RSTP(1): Et0/0 blocked by re-root
*Dec 29 17:06:57.431: RSTP(1): Et0/0 is now alternate
*Dec 29 17:06:57.431: RSTP[1]: Et0/0 state change completed. New state is [blocking]
*Dec 29 17:06:57.431: RSTP[1]: Et0/1 state change completed. New state is [forwarding]
*Dec 29 17:06:57.431: RSTP(1): starting topology change timer for 35 seconds
*Dec 29 17:06:57.431: STP[1]: Generating TC trap for port Ethernet0/1
SW3(config)#
*Dec 29 17:07:32.431: RSTP(1): stopping topology change timer
*Dec 29 17:07:33.431: RSTP(1): starting topology change timer for 35 seconds
SW3(config)#
*Dec 29 17:08:08.431: RSTP(1): stopping topology change timer
SW3(config)#
We can see there is no Delay timer like the one in SPT, root port switch over started as soon as the link recovery is detected.
However we notice there is another type of timer which is 35 seconds does the same protection for link flaps. but this timer starts when the topology change is completed. The Delay timer in SPT starts when the root link recovery is detected.

Comments

Post a Comment

Popular posts from this blog

Firepower FMC and FTD troubleshooting

-
 1. Display real time log on FMC or FTD: pigtail for example: pigtail | grep 192.168.2.20                      pigtail | grep sftunnel 2. Restart communication channel manage_procs.pl run it from  the sensor only, run it from FMC will reset all sensors' channel. This scripts are nice to be used when the FMC and FTD have communication problems like heartbeats are not received, policy deployment is failing or events are not received > expert ************************************************************** NOTICE - Shell access will be deprecated in future releases          and will be replaced with a separate expert mode CLI. ************************************************************** admin@FTD:~$ sudo su Password: root@FTD:/home/admin# manage_procs.pl ****************  Configuration Utility  **************  1   Reconfigure Correlator  2   Reconfigure and flush Correlator  3    Restart Comm. channel  4   Update routes  5   Reset all routes  6   Validate Network  0   Exit *****
Read more

ASA IKEv1 VPN troubleshooting Steps and Tips

-
  1. Phase I proposal mismatch  Run show crypto isakmp sa  Initiator: MM_WAIT_MSG2 Responder: No info  Most likely this is phase1 proposal mismatch, verify IKEv1 policy, other symptoms:   Initiator log: Information Exchange processing failed All configured IKE versions failed to establish the tunnel Initiator debug: Received an un-encrypted NO_PROPOSAL_CHOSEN notify message, dropping Responder log: Error processing payload: Payload ID Responder debug:  All SA proposals found unacceptable 2. IKE version mismatch:  Run  show crypto isakmp sa  no info at both initiator and responder Initiator log: Removing peer from correlator table failed, no match! Reason: User Requested  All configured IKE versions failed to establish the tunnel Initiator debug: Oakley begin quick mode PHASE 1 COMPLETED IKE Initiator sending 1st QM pkt Removing peer from correlator table failed, no match! Session is being torn down. Reason: User Requested Responder log: Tunnel Rejected: Conflicting protocols specified
Read more

Firepower 2100/1100 FTD/ASA initial setup, reimage, upgrade.

-
  Chassis FXOS and FTD share same management IP (default 192.168.45.45) Chassis FXOS (192.168.45.45) and ASA ()use different management IP although on same physical interface. SSH to FXOS/FTD are on FTD CLI prompt, go to FXOS using the  connect fxos  command Console to Chassis is on FXOS CLI prompt, go to FTD using the  connect ftd  command The Firepower 1100 does not support the FXOS Firepower Chassis Manager; only a limited CLI is supported for troubleshooting purposes. The Firepower 2100 runs an underlying operating system called the Firepower eXtensible Operating System (FXOS).  If you run ASA on Firepower 2100, ASA can be in the following modes: Appliance mode (the default after ASA 9.13)—Appliance mode lets you configure all settings in the ASA. Only advanced troubleshooting commands are available from the FXOS CLI. See the  FXOS troubleshooting guide  for more information. Firepower Chassis Manager is not supported . ciscoasa# connect fxos [admin] Connecting to fxos. Connected
Read more