I'm going to replace some old "central" access switches to some Cisco Catalyst 2960X, and I'm not sure what to do on their STP configurations.

For this network, we have some "central" access switches, that connect some hosts and some unknown unmanaged or "smart" switches. For now, I have to maintain these unknown switches working, but I want to avoid getting my entire network down in case of a loop.

How should I configure these access ports regarding STP? At first, I thought it was better to turn off the STP using portfast in all ports (except my trunk), but i'm afraid that some of these connected switches might cause a loop in the entire network. If I turn on BPDU filter, as far as I know, any connected switch will put the port in err-disable, and I don't want that either.

Is there a way that I can have these unmanaged switches connected on the access ports and just disable their ports to the Cisco in case of a problem?

2 Answers 2


You really, really do not want to disable STP where you connect switches to other switches. That is the entire purpose of STP. If you disable STP, and there is a problem, it will really be too late because your entire network could crash when you notice it, and recovering from a broadcast storm is no fun at all.

By the way, portfast doesn't actually disable STP, it just skips the whole learning process, and it should only be enabled on a true access interface, not where you connect another switch.

A best practice is to not connect an access switch to another access switch, but if you do this, you can set the interface to trunk and set the native VLAN to what you had for the access VLAN. You can even restrict the VLANs allowed to only allow the native VLAN.

The use of globally enabled portfast and bpduguard is recommended. This will not be enabled on trunk interfaces unless you use the trunk keyword. This will give you the protection on access interfaces, but not anywhere you connect other switches with a trunk interface.

  • The problem is I don't know which ports connects those switches. Do you think enabling BPDU guard in all ports and doing the "trunking/native access VLAN" port to those who get err-disable is a good idea? Jan 23, 2017 at 15:42
  • That depends on how disrupted you can let your network get. That should find the switches. It may be better to check the MAC address table to see which interfaces have a bunch of MAC addresses associated.
    – Ron Maupin
    Jan 23, 2017 at 15:50
  • I thought of it too, but im afraid that I get too many addresses to count. Will try both ways. Thanks. Jan 23, 2017 at 15:54

So you are in a situation where for whatever reason people sometimes plug desktop switches into access ports.

In an ideal world you wouldn't have this but in practice it can be difficult. Sometimes rooms simply do not have enough outlets for the amount of equipment that is in them. Adding more wiring and/or cabinets so you can replace the desktop switches with properly secured and managed ones can cost a lot of money and time.

I would say the first thing to do is research. Write a script to figure out how many MAC addresses are behind each port.

That will let you get an idea of the scale of the problem.

It may also be an idea to run the script multiple times so you can figure out if the unknown switches are remaining static or are moving around.

Probablly a reasonable compromise is to limit ports by default to a small number of MAC addresses (maybe 7). This should quickly shut down any loops while not blocking small unmanaged switches on desktops.

If I turn on BPDU filter, as far as I know, any connected switch will put the port in err-disable, and I don't want that either.

Afiact only a switch that sends BDPUs will and your typical unmanaged desktop switch doesn't.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.