6

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?

Ron Maupin
  • 98,218
  • 26
  • 115
  • 191
Maurício Mota
  • 63
  • 1
  • 1
  • 4

2 Answers2

12

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.

Ron Maupin
  • 98,218
  • 26
  • 115
  • 191
  • 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? – Maurício Mota Jan 23 '17 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 '17 at 15:50
  • I thought of it too, but im afraid that I get too many addresses to count. Will try both ways. Thanks. – Maurício Mota Jan 23 '17 at 15:54
1

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.

Peter Green
  • 12,935
  • 2
  • 20
  • 46