Does designated port have to be in forwarding state?
johnifanx98
Member Posts: 329
in CCNA & CCENT
Let's say a scenario like
A is the root bridge. B has lower MAC than C. Then B's port in BC segment becomes a designated port, and will be forwarding. However, since C's port in BC segment is blocking, B's designated port virtually can forward/receive nothing, right? Then what's the point for B's designated port to be in forwarding state?
A / \ B--C
A is the root bridge. B has lower MAC than C. Then B's port in BC segment becomes a designated port, and will be forwarding. However, since C's port in BC segment is blocking, B's designated port virtually can forward/receive nothing, right? Then what's the point for B's designated port to be in forwarding state?
Comments
-
Zartanasaurus
Member Posts: 2,008 ■■■■■■■■■□
C's port is blocking, but it still receives certain frames.
Thought experiment: What would C do if B didn't send any frames whatsoever on that link?Currently reading:
IPSec VPN Design 44%
Mastering VMWare vSphere 5 42.8% -
jsb515
Member Posts: 253
B stays in forwarding as a backup if a link fails. B and C send frames upstream to A. So if B wants to send to C, B will send it upstream from its root port to A and A will forward it to C. If a link fails, say like the link between A and B fails STP will open the blocking port frames can be sent again until the link failure is fixed and STP will change the port back to blocking. So I would imagine it would need to stay designated for those reasons. If you didn't have a triangle link setup like that no ports would be in a blocking state, but you lose fail over. -
johnifanx98
Member Posts: 329
Zartanasaurus wrote: »C's port is blocking, but it still receives certain frames.
Thought experiment: What would C do if B didn't send any frames whatsoever on that link?
I came up a more interesting experiment. What if AB link is broken? How the re-convergence take place? -
johnifanx98
Member Posts: 329
A / \ B--C
A is the root bridge. B has lower MAC than C. Then B's port in BC segment is designated.
Say, at a point the link AB is broken, and the re-converging is triggered.A \ B--C
I use PT to simulate the whole process, and have observed at a point C's port in BC segment changes from blocking to learning state. But how this happens? I thought C's port will be stuck in blocking. -
networker050184
Mod Posts: 11,962 Mod
So what happens when a bridge stops hearing BPDUs from the root? What does the root bridge do when it notices a topoplogy change?An expert is a man who has made all the mistakes which can be made. -
fiftyo
Member Posts: 71 ■■□□□□□□□□
To add on to that, what's the purpose of STP?networker050184 wrote: »So what happens when a bridge stops hearing BPDUs from the root? What does the root bridge do when it notices a topoplogy change? -
networker050184
Mod Posts: 11,962 Mod
Another question to spur thought, why is that port from C blocking in the first place? What is B sending on that link to make C block?An expert is a man who has made all the mistakes which can be made.
-
johnifanx98
Member Posts: 329
networker050184 wrote: »So what happens when a bridge stops hearing BPDUs from the root? What does the root bridge do when it notices a topoplogy change?
After the link AB is broken, B thinks itself to be the root. Is this the reason C woke up from the blocking? I noticed C woke after 3 or 4 BPDUs from B. Is this a timer thing? Why not the first BPDU from B woke C up? -
fiftyo
Member Posts: 71 ■■□□□□□□□□
B still receives A's superior BPDU's from switch C, so it will not assume itself in this case as the root. When link AB fails, to still allow forwarding in the layer 2 domain, what must switch B do?johnifanx98 wrote: »After the link AB is broken, B thinks itself to be the root. Is this the reason C woke up from the blocking? I noticed C woke after 3 or 4 BPDUs from B. Is this a timer thing? Why not the first BPDU from B woke C up?
Another little hint is, every switch except for the root bridge has 1 root port. -
networker050184
Mod Posts: 11,962 Mod
That may not the case fiftyo. Blocking ports do not send BPDUs, only recieve in STP. RSTP on the other hand all bridges exchange BDPUs which helps the faster convergence.
Wait, I take that back, all Bridges generate BDPUs in RSTP, still blocking ports do not send BPDUs I believe. Need to refresh my STP now that I think about it...An expert is a man who has made all the mistakes which can be made. -
fiftyo
Member Posts: 71 ■■□□□□□□□□
It still listens to BPDU's indeed, thus, still receiving superior BPDU's from switch C.
-
networker050184
Mod Posts: 11,962 Mod
But there are no BPDUs to listen to since C is blocking. So it will first claim it's self as root as it is no longer hearing any BPDUs. Once C starts receiving these/stops receiving inferior path BPDUs it will then transition to forward the correct root BPDUs.
Again this is the case for 802.1D. I can't remember exactly for RSTP at the moment but I'm sure a google can straighten it out.An expert is a man who has made all the mistakes which can be made. -
johnifanx98
Member Posts: 329
It still listens to BPDU's indeed, thus, still receiving superior BPDU's from switch C.
As PT shows B has not received any BPDU until C flips to listening state. Actually as of now all my curiosity is what brought C out of blocking state. Is it A or B or some timer? -
fiftyo
Member Posts: 71 ■■□□□□□□□□
Actually I'm pretty sure blocking ports in old stp still listens and processes BPDU's. Let me hit up the actual standard and I'll get back with my findings. However, this does not imply that's the way cisco implements it..networker050184 wrote: »That may not the case fiftyo. Blocking ports do not send BPDUs, only recieve in STP. RSTP on the other hand all bridges exchange BDPUs which helps the faster convergence.
Wait, I take that back, all Bridges generate BDPUs in RSTP, still blocking ports do not send BPDUs I believe. Need to refresh my STP now that I think about it... -
networker050184
Mod Posts: 11,962 Mod
Yes the blocking port listen on C, but it doesn't transmit so B can't go to this path imeaditely. It will have to time out, declare it'self as root etc.An expert is a man who has made all the mistakes which can be made.
-
fiftyo
Member Posts: 71 ■■□□□□□□□□
Ah right, slight misread there, beg you pardon.networker050184 wrote: »Yes the blocking port listen on C, but it doesn't transmit so B can't go to this path imeaditely. It will have to time out, declare it'self as root etc.
Brain fried after a good day of maths.
Was thinking A connected to B which would still be up then B to C, where C would be blocking. -
Zartanasaurus
Member Posts: 2,008 ■■■■■■■■■□
You're having issues because you don't understand the basics of spanning-tree.johnifanx98 wrote: »As PT shows B has not received any BPDU until C flips to listening state. Actually as of now all my curiosity is what brought C out of blocking state. Is it A or B or some timer?
How are the BPDUs propagated through the network (what mechanism tells a switch to send a BPDU)?
What is the purpose of ports going into a blocking state?
How does spanning-tree know when to recalculate the topology?
If you find out the answer to those 3 questions, your confusion will be cleared up.Currently reading:
IPSec VPN Design 44%
Mastering VMWare vSphere 5 42.8% -
johnifanx98
Member Posts: 329
Zartanasaurus wrote: »You're having issues because you don't understand the basics of spanning-tree.
How are the BPDUs propagated through the network (what mechanism tells a switch to send a BPDU)?
What is the purpose of ports going into a blocking state?
How does spanning-tree know when to recalculate the topology?
If you find out the answer to those 3 questions, your confusion will be cleared up.
Hi Z, your third question is brilliant. I got it now. C received B's BPDU, and realized the topology change happened, and then flipped state to listening, right? I was reading a state transition diagram, but did not see this condition...
One more basic question. I knew all ports are booted to be blocking. Then who breaks the tie? -
networker050184
Mod Posts: 11,962 Mod
The one forwarding the lowest cost BPDU to the root. If the same cost then they go through the tie breaking algorithm.An expert is a man who has made all the mistakes which can be made.
-
johnifanx98
Member Posts: 329
Hi Networker,
If all ports are initialized to be blocking state, who will send the BPDU? Do you mean during initialization, ports will automatically transit to listening after blocking without any condition? -
networker050184
Mod Posts: 11,962 Mod
They come online at listening if I'm not mistaken.An expert is a man who has made all the mistakes which can be made.
-
Zartanasaurus
Member Posts: 2,008 ■■■■■■■■■□
No.johnifanx98 wrote: »Hi Z, your third question is brilliant. I got it now. C received B's BPDU, and realized the topology change happened, and then flipped state to listening, right? I was reading a state transition diagram, but did not see this condition...
The spanning-tree timers are hello: 2s, forward delay: 15s, max age: 20s. For the purpose of this discussion, we only care about hello and max age.
The root switch sends out a BPDU every 2s. Inferior switches wait for the hello from the root before they will propagate it to other switches. This is easily proven:Interface Role Sts Cost Prio.Nbr Type ------------------- ---- --- --------- -------- -------------------------------- Fa0/13 Root FWD 19 128.15 P2p Fa0/16 Altn BLK 19 128.18 P2p SW3#show spanning-tree interface fastEthernet 0/16 det | i received BPDU: sent 0, received 4268 SW3#show spanning-tree interface fastEthernet 0/16 det | i received BPDU: sent 0, received 4269 SW3#show spanning-tree interface fastEthernet 0/16 det | i received BPDU: sent 0, received 4270 SW3#show spanning-tree interface fastEthernet 0/16 det | i received BPDU: sent 0, received 4271
SW3 is still RECEIVING BPDUs on his BLOCKED port. Remember the purpose to create a loop-free topology. After the initial convergence, SW3 blocked port 0/16. But he has to know to keep it blocked. That's the purpose of the designated port of the upstream switch; to notify other switches that he's still alive and superior. Inferior switches transition the port to blocked (or root).
A non-root switch WILL NOT SEND BPDUs until he hears the BPDU that is announce from his upstream peer. If I were to magically take the root switch out of the topology, no BPDus would be sent on the network.SW1(config-if)#int fa 0/13 SW1(config-if)#spanning-tree bpdufilter enable SW3#show spanning-tree interface fastEthernet 0/16 det | i received BPDU: sent 0, received 4362 SW3#show spanning-tree interface fastEthernet 0/16 det | i received BPDU: sent 0, received 4362 SW3#show spanning-tree interface fastEthernet 0/16 det | i received BPDU: sent 0, received 4362 SW3#show spanning-tree interface fastEthernet 0/16 det | i received BPDU: sent 0, received 4362
Now the received counter has stopped incrementing. The switch that port is attached to stopped receiving BPDUs from the root, so he stopped propagating them. That's why you saw what you did in packet tracer.
And there's where the maxage timer comes in. After 20s of not receiving a BPDU, the switch declares the root down and an election process happens again.
C didn't recalculate the topology because he heard B's BPDU, he recalculated because he DIDN'T hear B's BPDU.
Note:
Now technically, C could realize there was a topology change based on suddenly receiving an inferior BPDU from B, which is the purpose of backbonefast. Out of scope for this discussion though.Currently reading:
IPSec VPN Design 44%
Mastering VMWare vSphere 5 42.8% -
johnifanx98
Member Posts: 329
Note:
Now technically, C could realize there was a topology change based on suddenly receiving an inferior BPDU from B, which is the purpose of backbonefast. Out of scope for this discussion though.
In my PT test, after removing (simulating broken AB) the AB cable, I saw A/B sent BPDUs to C every two seconds. However, BPDU sent from B assumes B is root bridge, which indicates a topology change. Just paste the topology after the change in case we're not on the same page.A \ B--C -
johnifanx98
Member Posts: 329
networker050184 wrote: »They come online at listening if I'm not mistaken.
Just read this from an CCIE book,After initialization, ports start in the Blocking state where they listen for BPDUs.
A variety of events (such as a bridge thinking it is the Root Bridge immediately after booting or an absence of BPDUs for certain period of time)
This explains... -
Zartanasaurus
Member Posts: 2,008 ■■■■■■■■■□
It's the same topology. B started sending BPDUs immediately because you deleted the port. In mine, I just had A stop sending BPDUs. B still had to listen for them because the link was still active.johnifanx98 wrote: »In my PT test, after removing (simulating broken AB) the AB cable, I saw A/B sent BPDUs to C every two seconds. However, BPDU sent from B assumes B is root bridge, which indicates a topology change. Just paste the topology after the change in case we're not on the same page.A \ B--CCurrently reading:
IPSec VPN Design 44%
Mastering VMWare vSphere 5 42.8% -
altdrugz
Member Posts: 69 ■■□□□□□□□□
When the A-B link goes down, SwitchB notices and sends a TCN (Topology Change Notification) to SwitchC. (actually it is sent to any Switch in order to reach the Root Bridge). Switch C Acknowledges the TCN and forwards it out towards (uplinks) the root SwitchA. Then A does the same and sends a broadcast for all switches informing them that guys things changed and we have to reconverge.
Now in your example i think Zartanasaurus gave you ALL the informations. DPs are forwarding traffic and the other end in Blocking mode they discard the traffic except the incoming BPDUs (and this is happening in order to get noticed the TCN thing I just described)
-
Zartanasaurus
Member Posts: 2,008 ■■■■■■■■■□
This is not true. TCNs are not sent to any switch, they are only sent on the root port.When the A-B link goes down, SwitchB notices and sends a TCN (Topology Change Notification) to SwitchC. (actually it is sent to any Switch in order to reach the Root Bridge).Then A does the same and sends a broadcast for all switches informing them that guys things changed and we have to reconverge.
This is not true at least the part about "sending a broadcast for all switches". When the root receives a TCN, it sets the TC flag on its BPDUs for maxage + forward delay seconds.
Not super easy to see with a debug, but it's possible.
A
| \
B - C
A is root
I brought up another port on B.
C#deb spanning-tree bpdu receiveBefore port goes into forwarding: C *Mar 1 23:33:09.639: STP: Data 00000000008001001B0DBD9100000000008001001B0DBD9100800F0000140002000500 Port goes into forwarding and sends a TCN to A: B *Mar 1 23:33:06.770: STP: VLAN0001 sent Topology Change Notice on Fa0/13 (only the root port) B *Mar 1 23:33:06.770: STP: VLAN0001 Fa0/3 -> forwarding C *Mar 1 23:33:11.644: STP: Data 000000000[U][B]1[/B][/U]8001001B0DBD9100000000008001001B0DBD9100800F0000140002000500
The root is setting the TC bit in its BPDUs. Switches that receive a BPDU with the TC bit set change their CAM aging timer to equal the forward delay timer.Currently reading:
IPSec VPN Design 44%
Mastering VMWare vSphere 5 42.8% -
altdrugz
Member Posts: 69 ■■□□□□□□□□
If the link between A and B goes down then the RP of B "goes down" as well and it shouldnt be able to send a TCN from its root port (except if this is done from the root bridge's perspective and switch B does nothing (?)). Well the example that I remember was just like that, and B then was sending the TCN to C in order to reach his root bridge and then the follow up is what you said about the cam flushing.
