My friends,
Please allow me to join.
It has already been correctly pointed out that the fa1/1 port on Switch01 becomes err-disabled because it is protected by the BPDU Guard and obviously it receives a BPDU from Switch02. In this topology and with this configuration, it is expected that the fa1/1 on Switch01 becomes err-disabled.
Let's, however, dig deeper into whether the configuration in this topology is correct.
Switches that support VLANs - such as the ones in this topology - are usually interconnected by trunks, not by access ports. It is not wrong to use access ports to interconnect the switches but at the same time, it is hugely limiting - it makes it impossible to span multiple VLANs over the single interconnection between the switches. Converting a former access link between two switches to a trunk link is disruptive, so as a matter of best practice, switch interconnections are commonly configured as trunks right from the start.
If we accept this concept and configure the switch interconnections as trunks then there is no need to discourage the use of spanning-tree portfast default and spanning-tree portfast bpduguard default. Let's review what they do:
- spanning-tree portfast default causes all access ports on the switch to immediately become STP Forwarding when they come up (and also activate other features of edge ports which I'm not going to dive into here). This command does not affect trunk ports because it apriori assumes that a trunk goes to another switch that speaks STP so the port role and state will be negotiated by STP.
- spanning-tree portfast bpduguard default causes all PortFast-enabled ports to become err-disabled if they receive a BPDU. Why is that? That is because a PortFast-enabled port is a port that is supposed to connect to a Layer3 or higher device, not to another switch, and so receiving a BPDU means this assumption has been violated and there is a risk of a switching loop if the port immediately becomes Forwarding.
Note how the two commands nicely complement each other: The spanning-tree portfast default makes all access ports to be PortFast ports, and spanning-tree portfast bpduguard default makes all PortFast ports (which includes all access ports that became PortFast ports thanks to spanning-tree portfast default) to be protected by the BPDU Guard - which is exactly what we want because access ports should not connect to other switches.
Therefore, I am not opposed at all to the use of spanning-tree portfast default and spanning-tree portfast bpduguard default commands as long as the interconnections to other switches are diligently configured as trunks - which they should.
In the above topology, it would be more proper to configure the link between Switch01 and Switch02 as a trunk. Then the configuration automatically won't result into err-disabling the port. If the link has to remain operating in access mode for whatever reason, however, then it is required to either remove the global spanning-tree portfast default and spanning-tree portfast bpduguard default commands from Switch01, or keep those commands present but configure spanning-tree portfast disable directly on its fa1/1 interface. This will prevent the port - despite being an access port - from becoming a PortFast port, and in turn, automatically becoming BPDU Guard-protected.
Best regards,
Peter
