02-11-2023 08:11 AM
Hi,
below topology sw1 to sw2 connected interface sw1 end interface showing errr disable. both end port access port.
Sw1 info
Switch#sh int status
Port Name Status Vlan Duplex Speed Type
Fa0/1 connected 111 auto auto 10/100BaseTX
Fa1/1 err-disabled 111 auto auto 10/100BaseTX
Global configuration
spanning-tree mode pvst
spanning-tree portfast default
spanning-tree portfast bpduguard default
spanning-tree extend system-id
spanning-tree vlan 111 priority 8192
In switch 2
spanning-tree mode pvst
spanning-tree extend system-id
Kindly suggest.
Solved! Go to Solution.
02-11-2023 03:48 PM
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:
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
02-11-2023 08:41 AM
Never config portfast and bpduguard in global mode.
Always config it under interface connect to host.
02-11-2023 08:49 AM - edited 02-11-2023 09:06 AM
- Do not use overall spanning-tree portfast default , for interfaces with devices connected use switchport host (that includes portfast), now fa0/1 and fa1/1 can do spanning tree negotiation ,
M.
02-11-2023 10:30 AM
If you lock in the console or show log output you will see the reason for the err-disable. It's probably because of bpdu-guard. Also the command show errdisable recovery could be helpfull
02-11-2023 03:48 PM
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:
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
02-12-2023 07:22 AM
Thanks a lot .... Make sense information
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide