Classroom Loop, Rogue DHCP and a Flat VLAN 1
A K-12 school has a single 48-port closet switch. Every access port is switchport mode access in VLAN 1, port security is not enabled, trunks between switches run native VLAN 1, and DTP is left at its default. During a lesson a student plugs a low-cost unmanaged 5-port switch into a classroom wall port and then, trying to 'make it faster', connects two of its ports to two wall jacks in the same room. The building goes down: the switch CPU sits at 99 %, and every device loses connectivity until staff unplug the cables. Later the same week, IT finds a laptop offering DHCP with gateway 192.168.1.1 on the student network, and a member of staff reports opening the switch management interface from a classroom PC. Nothing is logged on the switch beyond a burst of MAC flaps, and the school wants a repeatable fix before the next term.
1. Give the order in which you would act, and explain which control would have caught the loop and which would not.
Read the worked answer
First restore service: find and shut one of the two looped ports, or pull the patch leads. Nothing can be diagnosed while the CPU is saturated.
Then prevent recurrence, in this order:
spanning-tree portfastplusspanning-tree bpduguard enableon every access port. The unmanaged switch returns the school switch's own BPDUs to a second port, so that port err-disables instead of looping. PortFast without BPDU guard is the dangerous combination.- Storm control (broadcast/multicast around 1–5 % of link rate) as a backstop for loops that emit no BPDUs, and because it limits blast radius.
spanning-tree guard rooton ports facing downstream switches, loop guard on trunks.- Errdisable recovery on a sensible interval so a legitimate device is not locked out permanently.
Port security alone would not help: the loop is created by one device behaviour, not by many MAC addresses.
2. Explain why port security would not have stopped the rogue DHCP server, and what would.
Read the worked answer
Port security counts and limits MAC addresses; the rogue laptop presents a single MAC and passes inspection cleanly. It is the wrong control for this threat.
The right control is DHCP snooping: trust only the uplinks toward the legitimate DHCP server or router, leave access ports untrusted, and set a rate limit (for example 15 pps) on untrusted ports so a DHCP flood is dropped and the port err-disables. Legitimate DHCP then flows server→client only on trusted ports, and offers arriving from a wall port are discarded.
Follow with Dynamic ARP Inspection using the snooping binding table, and IP Source Guard, because a rogue offer with gateway 192.168.1.1 is the setup for gateway impersonation - the attacks come as a package. Locate the offender with show ip dhcp snooping binding and correlate the MAC in the address table to a port.
3. A classroom PC could reach the switch management interface. Explain the design faults and the correct configuration.
Read the worked answer
Two faults: management shares VLAN 1, and VLAN 1 is the native VLAN on every trunk.
Correct design:
- Move management to a dedicated VLAN (for example 99) with an SVI, no access ports in it, pruned from all access-facing trunks, and an ACL permitting only the admin subnet; SSH only, Telnet off.
- Set the native VLAN on every trunk to an unused ID (999) excluded from the allowed list, so untagged frames have nowhere useful to land.
switchport mode accessandswitchport nonegotiateon user ports;switchport mode trunkandswitchport nonegotiateon real trunks, so DTP cannot be talked into forming a trunk.- Shut or park unused wall ports in an unused VLAN.
This combination also blocks double-tagged frames: an attacker on the native VLAN can otherwise send a frame whose outer tag is stripped by the first switch and whose inner tag delivers it into another VLAN.