I'm currently testing the 'spanning-tree bpduguard enable' feature on switch ports, and
have some doubts about it and the BPDU sending mechanism.
I have one switch (switchA) that is connected at the edge of the network, this switch as
one port Gi0/1 as Root Port. This switch has a free port, Fa0/35 that has the following
switchport access vlan 500
switchport mode access
spanning-tree bpduguard enable
I come with another switch (switchB with no more ports connected) and connect it to the
Fa0/35 of switchA.
SwitchA should put Fa0/35 in err-disabled mode. That doesn't happen, because switchB
(non-root bridge) is not sending BPDUs due to the fact that it received a better
configuration BPDU on his root port from switchA and updated his own configuration BPDU.
---> I would like to know wich switch send the first BPDU(!) <---
Case 1: switch A sends BPDU first
Expected result: SwitchB updates his configuration BPDU since his own is inferior and
doesnt send any BPDU towards root bridge; (this happens in 99,9% of the tests)
Case 2: switch B sends BPDU first
Expected result: switchA put his Fa0/35 in err-disabled mode; (this is what i would like
What is the correct behaviour and why? How can i achieve case2?
I would test BPDU guard in the following mode:
on second switch have a port in same vlan that is not configured for portfast.
connect a PC to this port, switchB should send out a topology change BPDU to signal the change of state on that port.
SwitchA should detect the BPDU and should put the port in errrordisable.
or configure on switchB a spanning-tree priority lower then that used by switchA so that it claims to be the new root bridge.
Hope to help
I know that what you talked about it works! thanks...but..., what i'm testing is the use of bpduguard connecting a switch that has no more ports connected.
Since the switch always send a first bpdu (right?) shouldn't switchA use bpduguard and put the port in err-disable?
Thanks for your help,
thanks for your kind remarks.
I think that we need to take in account the following:
if no port is active the STP instance is probably not created initialized.
when the first port is connected on switchB to switchA, switchA is always the first to send its own BPDU because its STP instance is already running.
SwitchB starts STP instance and receives BPDU from SwitchA, so now the question becomes does switchB sends out one BPDU to advertise its existence of it suppresses even this first BPDU because it knows it cannot become designated port on segment?
For this reason to avoid a race condition it is better to test as I suggested in first post.
Hope to help
The correct case is that Switch A is the first sender of the BPDU since its connected to the root bridge out its designated port, Switch B recieves BPDU of the root bridge information.
Switch B wont send any BPDUs out unless a topology change occurs out its root port.
In order to have port f0/35 into err-disabled state, Either Switch B must be the root bridge, Or STP topology changes so that BPDUs recieved on switch A designated port an immediately put f0/35 into err-disable state.
Yes, the port is portfast enabled. (but it works too if not portfast enabled).
The hundred million dollar question is what switch will send the first bpdu and why (?!)
I'm confused about this, because i would like the switch to go into err-disabled immediately if i connect some BPDU-sender device...understand my doubt?
Thanks for your help!
I have the feeling that who will send the first BPDU is primarily a matter of concidence. You can easily imagine that if your BPDU Guard-enabled port happens to send the first BPDU and if the neighboring port on the next switch recognizes this BPDU as superior, it will simply cease sending BPDUs altogether. I am not sure if it is possible to delay sending the BPDUs for a couple of seconds on a port.
if the second switch has not active port in the vlan it has to start the STP instance first, and then it could send out its own BPDU.
For this reason I think Met sees switchA sending the BPDU first and switchB doesn't send its own and bpdu guard action is not triggered.
Hope to help
I am not sure about your statement. The BPDU Guard feature can be activated on any port, be it an PortFast-enabled port or not, and it will always behave the same way. As a matter of fact, that is the reason why you have both the spanning-tree portfast bpduguard default command that activates the BPDU Guard automatically on all PortFast ports, and at the same time, the spanning-tree bpduguard enable interface-level command to activate the BPDU Guard on the port unconditionally.