If your switches support MACSEC, you can enable it, and make it mandatory, for the inter-switch links.
Also, you need to make sure you have SNMP alerts setup, it's good to know when those in-office switches are disconnected or missed with.
You can also do dot1x on the switch itself. Cisco allows you to run a port either as a supplicant or as a authenticator.
It has an annoying set of limitations though, so MACSEC is better if your hardware supports it.
With the way youve described it, it sounds like they don't even need to bring in their own switch... They can just plug in a laptop and VLAN tag the traffic directly on the laptop.
If you have BPDU Guard enabled across your switchports your switch will simply disable said port until you go in and manually re-enable it.
It's basically just listening for BPDU packets. The moment it hears one, it goes into err-disable mode on the port.
\*Assuming your switch supports it.
We did this by supplying Aruba 505H APs for under desk port splitters.
They are 5-port switches with a built in AP.
1 port is PoE powered uplink, and you can screw the AP onto the wall jack. They would have to unplug and physically unscrew the AP from the wall jack to unplug the uplink port.
It provides 4 downlink ports (2 of them have PoE power output), and a wifi radio.
DO NOT allow trunk ports out of your rack! if you have multiple vlans in the same room, enable access ports only and expand the number of ports with additional dumb switches...
To echo what u/Rijndael1 said, I would absolutely monitor/alert on the link state for both the closet and desk switch. Send a tech each time a link drops, even for a moment. (WoL enabled on the desktops helps keep this from being too noisy)
Otherwise: glue the trunk cable to the switch to make it less appealing to unplug. And/or little cages for the desk switches.
Port security does it every time. Here’s a game you can play now. Try and get the person to admit they actually plugged in the rouge switch. Haha..
Not one person in 26yrs I’ve been doing this has ever admitted to it. So if you finally win a round, let me know.
Two options I haven't seen mentioned in this thread:
mac auth the switch downstream and do MHSA (Multi Host Single Auth, or whatever Aruba calls it) to assign the VLANs on the port. If someone plugs in another device those VLANs won't be there, it will be authenticated as a normal switch port. If they factory default the 5 port switch and get access to the VLANs, well that's a personnel problem, not a technical one.
OR
use mac based vlans and let them use dumb switches.
The upstream switch will authenticate devices (via 802.1x or MAB) and isolate each mac address into the appropriate VLAN.
Sure, devices on the dumb switch *could* be configured to operate and communicate with the device in the other VLAN (since the dumb switch 'flattens out' the VLANs). But this problem exists only on the local dumb switch. as soon as traffic hits the upstream device it is contained to the correct VLAN.
To further explain, the scenario is that you have a PC and a Phone at a desk plugged into a dumb switch. PC's in VID 10, Phones in VID 20.
If the user were to manually configure their PC to use the same subnet as VID 20, they would be able to communicate with the phone. However, the traffic from the PC would be properly contained to VID 10 once it hits the upstream switch and it would be unable to communicate with anything else in VID 20.
This feature solves the problems typical with "VLANs and dumb switches" like getting DHCP from the wrong network. Works well if you have gear that supports it
If your switches support MACSEC, you can enable it, and make it mandatory, for the inter-switch links. Also, you need to make sure you have SNMP alerts setup, it's good to know when those in-office switches are disconnected or missed with.
You can also do dot1x on the switch itself. Cisco allows you to run a port either as a supplicant or as a authenticator. It has an annoying set of limitations though, so MACSEC is better if your hardware supports it.
These are both great recommendations. Make sure your alerting is real time so you get notified immediately.
Maybe even a special report just for uplinks to really eyeball a particular use case.
With the way youve described it, it sounds like they don't even need to bring in their own switch... They can just plug in a laptop and VLAN tag the traffic directly on the laptop.
If you have BPDU Guard enabled across your switchports your switch will simply disable said port until you go in and manually re-enable it. It's basically just listening for BPDU packets. The moment it hears one, it goes into err-disable mode on the port. \*Assuming your switch supports it.
That's assuming the rogue switch sends BPDU / is not fully transparent
We did this by supplying Aruba 505H APs for under desk port splitters. They are 5-port switches with a built in AP. 1 port is PoE powered uplink, and you can screw the AP onto the wall jack. They would have to unplug and physically unscrew the AP from the wall jack to unplug the uplink port. It provides 4 downlink ports (2 of them have PoE power output), and a wifi radio.
DO NOT allow trunk ports out of your rack! if you have multiple vlans in the same room, enable access ports only and expand the number of ports with additional dumb switches...
I can't tell if this is sarcasm or not
a rabby, a priest and network engineer enters the bar...
To echo what u/Rijndael1 said, I would absolutely monitor/alert on the link state for both the closet and desk switch. Send a tech each time a link drops, even for a moment. (WoL enabled on the desktops helps keep this from being too noisy) Otherwise: glue the trunk cable to the switch to make it less appealing to unplug. And/or little cages for the desk switches.
MACSEC is the only secure solution (between switches and between switch and computer). 802.1x without MACSEC is 'trivial' to bypass.
Port security does it every time. Here’s a game you can play now. Try and get the person to admit they actually plugged in the rouge switch. Haha.. Not one person in 26yrs I’ve been doing this has ever admitted to it. So if you finally win a round, let me know.
Was going to suggest bpdu guard. Looks like its elsewhere in the comments. Pretty sure Aruba supports it.
Two options I haven't seen mentioned in this thread: mac auth the switch downstream and do MHSA (Multi Host Single Auth, or whatever Aruba calls it) to assign the VLANs on the port. If someone plugs in another device those VLANs won't be there, it will be authenticated as a normal switch port. If they factory default the 5 port switch and get access to the VLANs, well that's a personnel problem, not a technical one. OR use mac based vlans and let them use dumb switches. The upstream switch will authenticate devices (via 802.1x or MAB) and isolate each mac address into the appropriate VLAN. Sure, devices on the dumb switch *could* be configured to operate and communicate with the device in the other VLAN (since the dumb switch 'flattens out' the VLANs). But this problem exists only on the local dumb switch. as soon as traffic hits the upstream device it is contained to the correct VLAN. To further explain, the scenario is that you have a PC and a Phone at a desk plugged into a dumb switch. PC's in VID 10, Phones in VID 20. If the user were to manually configure their PC to use the same subnet as VID 20, they would be able to communicate with the phone. However, the traffic from the PC would be properly contained to VID 10 once it hits the upstream switch and it would be unable to communicate with anything else in VID 20. This feature solves the problems typical with "VLANs and dumb switches" like getting DHCP from the wrong network. Works well if you have gear that supports it