Does designated port have to be in forwarding state?

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?

jsb515

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.

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?

   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.

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 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?

To add on to that, what's the purpose of STP?

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?

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?

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?

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?

Another little hint is, every switch except for the root bridge has 1 root port.

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...

It still listens to BPDU's indeed, thus, still receiving superior BPDU's from switch C.

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.

fiftyo wrote: »

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?

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...

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..

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.

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.

Ah right, slight misread there, beg you pardon.

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.

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?

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.

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?

The one forwarding the lowest cost BPDU to the root. If the same cost then they go through the tie breaking algorithm.

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?

They come online at listening if I'm not mistaken.

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...

No.

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.

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

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...

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--C

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.

altdrugz

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)