Hello Alexey,
But i found out that it is possible - fast convergence on shared link, in case when all ports threated as full duplex by default
This is rather untypical scenario. A shared link that works on a full duplex is usually caused by a non-STP switch interconnecting a bunch of other switches together. This will cause the other switches to have their link operating in full duplex and leading the STP implementation to a mistaken conclusion that the link is of the point-to-point type.
Please note that the derivation of the link type (p2p/shared) depending on the duplex setting is only a simple heuristic implemented by Cisco. It is absolutely not supported by the STP standard. What Cisco switches do is a simple educated but still naive guess - if the link operates in half duplex then it must be connected to a hub, because a hub is never able to operate in full duplex, and hence the link is shared. Otherwise, if the link operates in full duplex, it is probably directly connected to other switch and that switch is expected to run STP, hence the p2p mode. But the situation when a number of switches is interconnected by a non-STP switch is a non-standard scenario and can not be handled automatically.
There is no guaranteed way of detecting the link type (p2p/shared), and there is no guaranteed way of detecting the port type (edge/non-edge). That is why you have to be very careful about the real physical topology, and configure the ports appropriately.
new to RSTP flags - describing portrole has bits pointed to Alternate/Backup state of port. Question is - in what circumstances its possible to receive BPDU with such flag?
A very good question that has caught me quite unprepared! Clearly, we know that usually ports in Alternate/Backup role do not send BPDUs.
One thing coming to my mind is a feature introduced by Cisco called the Bridge Assurance where all ports send BPDUs, regardless of their role/state, and the BPDUs therefore become a fully fledged Hello mechanism. In this case, it would make sense.
Another use may arise in MSTP when a port may be in a different role/state in different instances. As MSTP uses a single large BPDU to describe all instances, there can be situations in MSTP where opposite ports on the same link both send MSTP BPDUs.
In general, however, I have a feeling that the role flags were added to the RSTP BPDUs primarily for debugging purposes, not necessarily to perform any explicit action. They are being used in recent implementations as a means to prevent unidirectional links (the so-called Dispute mechanism) but as far as the standard goes, there is no much usage described.
And other question - why is Discarding state ommited in the flag?
Perhaps it is because the Learning/Forwarding bits have to be interpreted slightly differently. If you capture RSTP BPDUs, you will see that these BPDUs sent from a Designated Forwarding port carry both Learning and Forwarding flags set. That would implicate the following interpretation:
- If a port forwards frames, the Forwarding bit will be set. Otherwise, it will be cleared, signifying either Discarding or Learning states.
- If a port learns MAC addresses, the Learning bit will be set. Otherwise, it will be cleared. So, having both Learning and Forwarding bits cleared, we have the Discarding state. Having Learning set to 1 and Forwarding clear, we have the Learning state. Having both Learning and Forwarding bits set to 1, we have the Forwarding state. There is no meaning for Learning=0, Forwarding=1.
Proposal bit can appear only on port in Designated Discarding state - so to describe this state flag bit for Discarding state required
Not true - Proposals are set on BPDUs sent from Designated/Discarding and Designated/Learning ports.
If Alternate/Backup role of port is presented, its seems to be logical that this port role most of time corresponds to Discarding
All the time - not most of the time. An Alternate/Backup port can never be on a way to Forwarding state and hence be in the transitory Learning state.
Best regards,
Peter
