Refer to the exhibit.
All switches have default bridge priorities, and originate BPDUs with MAC addresses as indicated.
The numbers shown are STP link metrics. Which two ports are in blocking state after STP
converges? (Choose two.)
A.
the port on switch SWD that connects to switch SWE
B.
the port on switch SWF that connects to switch SWG
C.
the port on switch SWD that connects to switch SWC
D.
the port on switch SWB that connects to switch SWD
This is wrong,
IF D. is the right answer, the wording for it should be ‘the port on switch SWD that connects to switch SWB’.
Switch SWD has the higher MAC address, therefore it loses the local election, and must place its port in the blocking state.
i read this one a hundred times thinking i was missing something. C is the only choice that is correct on here.
C and D are the correct answers. I setup this exact topology on real gear. This scenario is truly perplexing, and am still not 100% on why the topology behaves as it does. The only difference between B and D, in terms of tie breakers is the bridge-id, which according to documentation says that the winners port would assume the desg role, and the far side to blocking. Which makes it even more difficult to understand the behavior.
I’ve searched far and wide for an answer, but found nothing close to this topology. All I can think of is that Switch-B hears the root from a lower bridge-id switch-C, and transitions its port connecting to switch-D to blocking. Further more, I am not sure if a switch can have more than 1 port in a blocking state with respect to a topology using only a single vlan w/o explicitly configuring it on another switchport.
Having said that, there can only be 2 outcomes between a pair of switches in this scenario.
1) switch-x (desg) switch-y (root)
2) switch-x (desg) switch-y (blk)
Which switch assumes the (desg) (root) (blk) role isn’t important here, however I don’t believe you will ever see something like.
switch-x (desg) switch-y (desg).
!-Spanning-Tree debug on switch-B while rebooting switches C and D
!
*Mar 1 00:10:07.335: STP: VLAN0002 new root port Gi0/2, cost 8
*Mar 1 00:10:07.335: STP: VLAN0002 Gi0/2 -> listening
*Mar 1 00:10:07.335: STP[2]: Generating TC trap for port GigabitEthernet0/1
*Mar 1 00:10:09.340: STP: VLAN0002 sent Topology Change Notice on Gi0/2
*Mar 1 00:10:22.342: STP: VLAN0002 Gi0/2 -> learning
*Mar 1 00:13:06.700: setting bridge id (which=3) prio 32770 prio cfg 32768 sysid 2 (on) id 8002.0019.06e8.6300
*Mar 1 00:13:06.700: set portid: VLAN0002 Gi0/1: new port id 8001
*Mar 1 00:13:06.700: STP: VLAN0002 Gi0/1 -> listening
*Mar 1 00:13:07.128: STP: VLAN0002 heard root 32770-001d.a247.d900 on Gi0/1
*Mar 1 00:13:07.136: STP: VLAN0002 Topology Change rcvd on Gi0/1
*Mar 1 00:13:08.143: STP: VLAN0002 heard root 32770-0019.0687.0b80 on Gi0/1
*Mar 1 00:13:08.143: supersedes 32770-0019.06e8.6300
*Mar 1 00:13:08.143: STP: VLAN0002 new root is 32770, 0019.0687.0b80 on port Gi0/1, cost 8
*Mar 1 00:13:08.143: STP: VLAN0002 sent Topology Change Notice on Gi0/1
*Mar 1 00:13:21.707: STP: VLAN0002 Gi0/1 -> learning
*Mar 1 00:13:30.859: set portid: VLAN0002 Gi0/2: new port id 8002
*Mar 1 00:13:30.859: STP: VLAN0002 Gi0/2 -> listening
*Mar 1 00:13:32.763: STP: VLAN0002 Gi0/2 -> blocking
*Mar 1 00:13:36.714: STP[2]: Generating TC trap for port GigabitEthernet0/1
*Mar 1 00:13:36.714: STP: VLAN0002 Gi0/1 -> forwarding
Also, I had rebooted D, C, and B in this order and it did not change the behavior of the link status between D and B.
Switch-B determines it’s root port to be towards switch-C. It then negotiates with it’s neighbor on the non-root port (towards D). When trying to determine whose port will assume the designated role, the switches compare their root path costs. Switch-B’s root path cost for the link connected to switch-d would be 8 (4+4) because my topology is using gigabit towards the root from B/C/D. Switch-d root path cost would be 4. This is the only reason I can see for switch-d’s port of that link to be designated. Adding to the fact that each switch in this topology by default will only have a single blocking port. Why this defies the bridge-id check I cannot answer.