Hi guys,
Calling in the experts because I need some help on a topology I'm working on. First, let me share the lab.
Allright, so the fa1/0 connection between SW01 and SW02 is a VLAN trunk. fa1/1 on both switches is configured as an access port in VLAN 10. SW02 is configured as the STP root bridge for VLAN 10 (spanning-tree vlan 10 root primary) and SW01 is the secondary (that doesn't really matter here). Here comes the magic.
R1 on the bottom is configured as a bridge, basically bridging fa0/0 and fa0/1. So, to prevent a switching loop, STP puts the path towards SW01 in BLK mode. So far, so good. However, an issue occurs when I shutdown fa0/1 (the current FWD / Root port) on R1, to do a failover towards fa0/0. The connectivity is restored after a 20 seconds by tweaking the STP timers (max-age and forward delay to 6 and 4 seconds respectively).
However, I'd like to see that those 20 seconds could be brought down even further. In doing so, I thought of 2 options:
Enabling RSTP on the bridge router (R1)
R1(config)#bridge 1 protocol ?
dec DEC protocol
ibm IBM protocol
ieee IEEE 802.1 protocol
vlan-bridge vlan-bridge protocol
Very little to find about RSTP here. ieee refers to 802.1D (classic spanning-tree), which is what is running now.
Enabling UplinkFast
Well, if RSTP can't do the job, perhaps uplinkfast can.
R1#sh spanning-tree uplinkfast
UplinkFast is enabled
Station update rate set to 150 packets/sec.
UplinkFast statistics
-----------------------
Number of transitions via uplinkFast (all VLANs) : 0
Number of proxy multicast addresses transmitted (all VLANs) : 0
Name Interface List
-------------------- ------------------------------------
Bridge group 1 Fa0/1(fwd), Fa0/0
So far so good you'd say. When I disable fa0/1 on R1, the router seems to go through the normal STP states and does not go directly into FWD'ing mode:
*Mar 1 02:36:41.091: STP: Bridge group 1 Fa0/1 -> blocking
*Mar 1 02:36:41.091: STP: Bridge group 1 new root port Fa0/0, cost 119
*Mar 1 02:36:41.091: STP: Bridge group 1 Fa0/0 -> listening
*Mar 1 02:36:43.083: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down
*Mar 1 02:36:43.087: %LINK-3-UPDOWN: Interface BVI1, changed state to down
*Mar 1 02:36:43.091: STP: Bridge group 1 sent Topology Change Notice on Fa0/0
*Mar 1 02:36:44.083: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
*Mar 1 02:36:44.087: %LINEPROTO-5-UPDOWN: Line protocol on Interface BVI1, changed state to down
*Mar 1 02:36:45.091: STP: Bridge group 1 Fa0/0 -> learning
*Mar 1 02:36:48.835: %LINK-3-UPDOWN: Interface BVI1, changed state to up
*Mar 1 02:36:49.091: STP: Bridge group 1 sent Topology Change Notice on Fa0/0
*Mar 1 02:36:49.091: STP: Bridge group 1 Fa0/0 -> forwarding
*Mar 1 02:36:49.835: %LINEPROTO-5-UPDOWN: Line protocol on Interface BVI1, changed state to up
Very little UplinkFast to see here. Is it some kind of unwritten rule that bridge-groups and uplinkfast do not play well together?
Calling on you guys, experts
Tell me what I'm missing here.
R1 config
R1#sh run
Building configuration...
Current configuration : 1128 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
no ip icmp rate-limit unreachable
ip cef
!
!
no ip domain lookup
!
multilink bundle-name authenticated
!
spanning-tree uplinkfast
archive
log config
hidekeys
!
bridge irb
!
interface FastEthernet0/0
no ip address
duplex auto
speed auto
bridge-group 1
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
bridge-group 1
!
interface BVI1
ip address 192.168.1.1 255.255.255.248
no ip redirects
no ip unreachables
no ip proxy-arp
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 192.168.1.254
!
!
control-plane
!
bridge 1 protocol ieee
bridge 1 route ip
!
