RSTP Working ( How to use BPDU Agreement Flag )

[takashima557]

I recentry use catalyst 2950 and HP Procurve under Rapid STP mode.

RSTP converge and traffic has no problem.

But BPDU Flag is diffrent when catalyst 2950 is root and when Procurve is root .

Agreement Flag of BPDU which Procurve sent is always "ON" under convergent.

I red IEEE 802.1D-2004, but I can not resolve which　work is right.

BPDU Flag is below when catalyst 2950 is root,

----------------------------------------------------------------------------------

BPDU flags: 0x3c (Forwarding, Learning, Port Role: Designated)
0... .... = Topology Change Acknowledgment: No
.0.. .... = Agreement: No
..1. .... = Forwarding: Yes
...1 .... = Learning: Yes
.... 11.. = Port Role: Designated (3)
.... ..0. = Proposal: No
.... ...0 = Topology Change: No

----------------------------------------------------------------------------------

[takashima557]

below is, when root is procurve

--------------------------------------------------------------------------------------------------------------
BPDU flags: 0x7c (Agreement, Forwarding, Learning, Port Role: Designated)
0... .... = Topology Change Acknowledgment: No
.1.. .... = Agreement: Yes
..1. .... = Forwarding: Yes
...1 .... = Learning: Yes
.... 11.. = Port Role: Designated (3)
.... ..0. = Proposal: No
.... ...0 = Topology Change: No

Thanks a lot.

[Peter Paluch]

Hello,

You have made an interesting discovery. What you see here is basically the Designated Forwarding port on a root bridge sending BPDUs with the Agreement flag set which is not necessary neither logical, but at the same time, it is not harmful.

In my personal opinion, this behavior of the HP switch is not entirely correct. An Agreement should be sent by a port in the Root Discarding or Root Learning role/state. Other port roles (Designated, Alternate, Backup) have no reason to send Agreements because they do not seek to make the link rapidly go to the forwarding state. A Designated Discarding or Designated Learning port sends Proposals but no Agreements. Ports in the Forwarding state do not send Proposals neither Agreements because there is no need for them. Therefore, the HP sending Agreements on its Designated Forwarding port is, according to this logic, wrong.

Fortunately, it does not break things here - obviously, the Cisco silently ignores the Agreements arriving on its Root port.

I may try to reproduce this behavior with some of my HP switches if I have some time, and I may report this as a bug to HP. I guess you should do the same - having the same bug reported twice will increase the likelihood that it will get corrected.

Best regards,

Peter