Backbond fast

-





Backbone fast is a Cisco proprietary feature that, once enabled on all switches of a bridge network, can save a switch up to 20 seconds (max_age) when it recovers from an indirect link failure.

Let's shut down SW1 e0/0 to simulate the link failure.
SW1(config)#int e0/0
SW1(config-if)#shut
SW1(config-if)#
*Dec 29 18:26:01.487: %LINK-5-CHANGED: Interface Ethernet0/0, changed state to administratively down
*Dec 29 18:26:02.487: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to down
SW1(config-if)#
SW3(config)#
*Dec 29 18:26:10.327: STP: VLAN0001 heard root 32769-aabb.cc00.0200 on Et0/0
SW3(config)#
*Dec 29 18:26:12.323: STP: VLAN0001 heard root 32769-aabb.cc00.0200 on Et0/0
SW3(config)#
*Dec 29 18:26:14.327: STP: VLAN0001 heard root 32769-aabb.cc00.0200 on Et0/0
SW3(config)#
*Dec 29 18:26:16.327: STP: VLAN0001 heard root 32769-aabb.cc00.0200 on Et0/0
SW3(config)#
*Dec 29 18:26:18.327: STP: VLAN0001 heard root 32769-aabb.cc00.0200 on Et0/0
*Dec 29 18:26:18.967: STP: VLAN0001 Et0/0 -> listening
SW3(config)#
*Dec 29 18:26:19.979: STP: VLAN0001 Topology Change rcvd on Et0/0
*Dec 29 18:26:19.979: STP: VLAN0001 sent Topology Change Notice on Et0/1
SW3(config)#
*Dec 29 18:26:33.971: STP: VLAN0001 Et0/0 -> learning
SW3(config)#
*Dec 29 18:26:48.971: STP[1]: Generating TC trap for port Ethernet0/0
*Dec 29 18:26:48.971: STP: VLAN0001 sent Topology Change Notice on Et0/1
*Dec 29 18:26:48.971: STP: VLAN0001 Et0/0 -> forwarding
SW3(config)#
Once sw2 detect the link failure and realized that it lost the root bridge, it sent BPDU towards sw3 to claim it is the root switch, when sw3 received this inferior BPDU, sw3 ignored it until max-age (20 seconds) timeout, then sw3 e0/0 went to listening and learning state (30 seconds) eventually change e0/0 to forwarding state.

Now we enabled backbone fast on all three switches, then shut down e0/0 on sw1:
SW1(config)#spanning-tree backbonefast
SW2(config)#spanning-tree backbonefast
SW3(config)#spanning-tree backbonefast
SW1(config)#int e0/0
SW1(config-if)#shut
SW1(config-if)#
*Dec 29 18:39:02.807: %LINK-5-CHANGED: Interface Ethernet0/0, changed state to administratively down
*Dec 29 18:39:03.807: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to down
SW1(config-if)#
SW3(config)#
*Dec 29 18:39:11.519: STP: VLAN0001 heard root 32769-aabb.cc00.0200 on Et0/0
*Dec 29 18:39:11.519: STP: VLAN0001 Et0/0 -> listening
*Dec 29 18:39:12.039: STP: VLAN0001 Topology Change rcvd on Et0/0
*Dec 29 18:39:12.039: STP: VLAN0001 sent Topology Change Notice on Et0/1
SW3(config)#
*Dec 29 18:39:26.519: STP: VLAN0001 Et0/0 -> learning
SW3(config)#
*Dec 29 18:39:41.519: STP[1]: Generating TC trap for port Ethernet0/0
*Dec 29 18:39:41.519: STP: VLAN0001 sent Topology Change Notice on Et0/1
*Dec 29 18:39:41.519: STP: VLAN0001 Et0/0 -> forwarding
SW3(config)#
We can see this time sw3 no longer ignore the inferior BPDU from sw2, as soon as sw3 received it, it immediately move e0/0 to listening state.


Let's see what happens if we turn on RSTP.
SW1(config)#spanning-tree mode rapid-pvst
SW2(config)#spanning-tree mode rapid-pvst
SW3(config)#spanning-tree mode rapid-pvst

SW1(config)#int e0/0
SW1(config-if)#shut
SW1(config-if)#
*Dec 29 18:46:03.883: %LINK-5-CHANGED: Interface Ethernet0/0, changed state to administratively down
*Dec 29 18:46:04.883: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to down
SW1(config-if)#
SW3(config)#
*Dec 29 18:46:06.879: RSTP(1): updt roles, received superior bpdu on Et0/0
*Dec 29 18:46:06.879: RSTP(1): Et0/0 is now designated
*Dec 29 18:46:06.883: RSTP(1): transmitting a proposal on Et0/0
*Dec 29 18:46:06.887: RSTP(1): starting topology change timer for 35 seconds
*Dec 29 18:46:07.483: RSTP(1): transmitting a proposal on Et0/0
SW3(config)#
*Dec 29 18:46:09.483: RSTP(1): transmitting a proposal on Et0/0
SW3(config)#
*Dec 29 18:46:11.483: RSTP(1): transmitting a proposal on Et0/0
SW3(config)#
*Dec 29 18:46:13.483: RSTP(1): transmitting a proposal on Et0/0
SW3(config)#
*Dec 29 18:46:15.483: RSTP(1): transmitting a proposal on Et0/0
SW3(config)#
*Dec 29 18:46:17.483: RSTP(1): transmitting a proposal on Et0/0
SW3(config)#
*Dec 29 18:46:19.483: RSTP(1): transmitting a proposal on Et0/0
SW3(config)#
*Dec 29 18:46:21.483: RSTP(1): transmitting a proposal on Et0/0
*Dec 29 18:46:21.883: RSTP(1): Et0/0 fdwhile ExpiredSW3(config)#
*Dec 29 18:46:23.483: RSTP(1): transmitting a proposal on Et0/0
SW3(config)#
*Dec 29 18:46:25.483: RSTP(1): transmitting a proposal on Et0/0
SW3(config)#
*Dec 29 18:46:27.483: RSTP(1): transmitting a proposal on Et0/0
SW3(config)#
*Dec 29 18:46:29.483: RSTP(1): transmitting a proposal on Et0/0
SW3(config)#
*Dec 29 18:46:31.483: RSTP(1): transmitting a proposal on Et0/0
SW3(config)#
*Dec 29 18:46:33.483: RSTP(1): transmitting a proposal on Et0/0
SW3(config)#
*Dec 29 18:46:35.483: RSTP(1): transmitting a proposal on Et0/0
SW3(config)#
*Dec 29 18:46:36.883: RSTP(1): Et0/0 fdwhile Expired
*Dec 29 18:46:36.883: RSTP[1]: Et0/0 state change completed. New state is [forwarding]
*Dec 29 18:46:36.883: RSTP(1): starting topology change timer for 35 seconds
*Dec 29 18:46:36.883: STP[1]: Generating TC trap for port Ethernet0/0
SW3(config)#
We can see after sw3 received the inferior BPDU, it starts a timer, somehow it didn't say that the port is moved to listening state, but the timer is exactly 15 seconds; then another 15 seconds timers before the port is changed to forwarding state.
So backbone is RSTP build-in feature.











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