Switching, VLANs, and Layer 2 Segmentation Questions

Direct answer

Create VLANs by trust zone and by physical failure domain, never by org chart. Cap each user broadcast domain at a /23 (510 usable addresses) and plan it to about 60 percent occupancy at peak, so a /23 carries roughly 306 devices. Keep every VLAN inside one building, put the layer 3 boundary (the SVI, the switch virtual interface that acts as the VLAN's default gateway) on the building distribution pair, and run DHCP centrally with relays on each SVI. Give each campus one summarisable internal address block, and keep guests in a separate range outside it. Choose NAC-driven dynamic VLAN assignment for users and guests so the VLAN follows the person, not the wall jack. NAC (network access control) is a server that checks who or what has plugged in and tells the switch which VLAN to use, and it speaks to switches over RADIUS, a standard authentication protocol.

How many VLANs and how big each broadcast domain is

A VLAN is one broadcast domain: every broadcast (ARP requests, DHCP discovers) reaches every host in it, and every host's MAC address lands in the table of every switch that carries it. So two inputs set the count: trust zones (which traffic needs a firewall or ACL between it) and a size ceiling (how much broadcast noise and failure blast radius you accept).

Trust zones, each its own VLAN (and subnet) in every building. Users, servers and management are drawn from one internal address block per campus; guests come from a separate range outside it:

1. Users (employees and managed laptops/phones).
2. Servers (local file/print/application servers; the big server estate lives in the data center).
3. Management (switch, access point and controller management addresses; reachable only from an admin jump host).
4. Guests (internet only, client isolation meaning guest devices cannot talk to each other on the Wi-Fi, own address range).
   Restricted classes such as contractors and quarantined devices are extra NAC roles in the same scheme.

Size ceiling. There is no standard for "maximum hosts per VLAN"; this is an engineering rule of thumb. I use /23 for user VLANs: 2^(32-23) - 2 = 510 usable addresses, planned to 60 percent peak occupancy (0.6 x 510 = 306 devices) so growth and DHCP lease churn do not exhaust the scope. A /24 gives 254 usable addresses; a /22 doubles the broadcast domain to 1,022.

Worked example, 10,000 users over three campuses. Assume two network devices per user (a laptop and a phone on Wi-Fi). Campus A has 4,000 users, B 3,500, C 2,500.

The 67 is the minimum that the capacity ceiling allows, because it assumes every VLAN is filled to 306. The physical layout can only raise it: a floor with 150 devices gets its own VLAN sized /24 rather than sharing a /23 with another building. For example, if campus A's 8,000 devices sit on 60 floors, that is 60 VLANs of about 133 devices each (8,000 / 60), roughly 52 percent of a /24's 254 usable addresses, rather than the 27 minimum. A /18 holds 64 /24 blocks, so the address plan below still fits. Use the table to size the floor and the layout to set the real count. Add roughly three more VLANs per building, one each for local servers, management and guests; the point-to-point links between switches are routed ports and need no VLAN.

Where the layer 3 boundary and DHCP go

Layer 3 boundary. Terminate user VLANs on the building distribution pair, with the VLAN confined to that building (access switches trunk to the distribution pair only; no VLAN spans buildings, and none spans campuses). Why: a spanning tree loop or broadcast storm stays inside one building, and inter-building and inter-campus links carry routed traffic only. Each building's local-server VLAN terminates on that building's distribution pair like the others, and the data-center server estate terminates on the data-center pair, both behind firewall policy. Management VLANs terminate on the distribution pair but are only routable from the admin jump host range. Guests terminate in a separate routing context (a VRF, virtual routing and forwarding instance, or directly on the firewall) whose only route leads to the internet, so a guest has no path to 10.0.0.0/8 even if an ACL is mistyped. Guests still need DHCP and DNS, so the guest SVIs relay to a guest DHCP service, and point guests at a resolver, that live inside that guest context (on the firewall or in a small DMZ server), not to the internal data-center servers; otherwise the only-route-to-the-internet rule would be broken.

DHCP. Run two DHCP servers in the data center configured for failover for all the internal VLANs, not one DHCP server per VLAN (guest scopes are served inside the guest context, described above). A client that has no address yet can only broadcast, and broadcasts do not cross subnets, so each SVI acts as a relay: it forwards the client's broadcast to the server as a unicast. On Cisco IOS this is the ip helper-address command in SVI configuration (the Cisco guide example is interface vlan 1, ip address ..., ip helper-address 172.16.1.2). The relay stamps the SVI's address into the request (the giaddr field, the relay agent IP address in the DHCP message), which is how the server knows which scope to answer from: per RFC 2131 it allocates from the subnet that contains giaddr. Example with the excerpt below: the request arrives with giaddr 10.8.64.1, the server finds the scope 10.8.64.0/23 that contains that address, and leases the client an address from it, such as 10.8.64.57 (illustrative). Excerpt for one user VLAN (Cisco IOS; the vlan, name, interface vlan, ip address and ip helper-address forms are the ones in Cisco's configuration guides):

vlan 101
 name USERS-A-BLDG1-F1
interface vlan 101
 ip address 10.8.64.1 255.255.254.0
 ip helper-address 10.200.10.10

For redundancy of the relay itself, check your platform's documentation for listing a second server; the scope design below does not depend on it. Make guest scopes use short leases (the right value is a site choice, for example one hour) because guest devices come and go and a /23 fills with stale leases otherwise.

Addressing that summarises per campus

Using Python's ipaddress module to check the plan:

Checks: a /18 holds 32 /23 blocks, which covers A's 27, B's 23 and C's 17 user VLANs. The three campus blocks sit inside 10.8.0.0/14 (10.11.0.0/16 stays reserved for a fourth site). Route summarisation means advertising one route that stands for many: 10.8.0.0/16 covers every internal campus A subnet, meaning users, local servers and management (65,536 addresses), so the WAN and data center hold one route per site, or the single 10.8.0.0/14 for the company, instead of one route per VLAN. The guest ranges sit inside 172.20.0.0/21 (private space under RFC 1918's 172.16.0.0/12) and deliberately outside 10.0.0.0/8, so "deny 10.0.0.0/8" on the guest edge is one line, and the guest ranges are summarised and filtered on their own, apart from the campus blocks. Users that need a /24 instead of a /23 take half a block and the rest stays free. The per-campus management, server and guest blocks are carved per building: for example, a four-building campus could split its guest /23 into four /25s (126 usable addresses each) and its management /24 into four /26s (illustrative sizes), so no VLAN spans buildings and the campus still summarises as one block.

NAC-driven dynamic VLAN assignment for users and guests

Network access control (NAC) authenticates each device with IEEE 802.1X (the port-based authentication standard: the switch port stays closed to everything except authentication until the device proves its identity) and the RADIUS server answers with the VLAN to place it in. When authentication succeeds, the RADIUS server's Access-Accept reply carries the VLAN, for example (VLAN ID illustrative):

Access-Accept
  Tunnel-Type             = VLAN (13)
  Tunnel-Medium-Type      = 802 (6)
  Tunnel-Private-Group-ID = "101"

The switch then puts that port into VLAN 101. RFC 3580 defines the three attributes: Tunnel-Type = VLAN (13), Tunnel-Medium-Type = 802 (value 6 in RFC 2868's list), and Tunnel-Private-Group-ID = the VLAN ID as a string (12 bits, 1 to 4094). So the same access port puts an employee laptop in USERS-A-BLDG1-F1, a contractor in a restricted VLAN and an unmanaged device in a quarantine or guest VLAN. Guests normally arrive through a guest SSID (wireless network name) or a captive portal (a web page that intercepts a new device and asks it to sign in or accept terms) that lands them in the guest VLAN. The consequences for the design:

• The VLAN number returned must exist on the access switch and be trunked to the distribution pair, so the role VLANs are defined per building and the NAC policy returns the building's own VLAN ID.
• Decide what the port does when RADIUS is unreachable or rejects the device (fail open to guest, fail closed, or keep the last VLAN). That choice is a business decision recorded before rollout.
• Role-based VLANs multiply the VLAN count by roles per building, which is another reason to cap roles at a handful and use ACLs or group-based policy for finer separation instead of more VLANs.

Many small VLANs versus fewer large ones, day to day

Recommendation: small-to-medium VLANs (/24 to /23) per building with the ceiling above, because incident size is the cost that hurts and object count is cheap once VLANs, SVIs and DHCP scopes come from templates. What would flip it: a Wi-Fi design that needs one subnet across a whole building (keep the large VLAN there and cap it at /22 with controller-based roaming), or an overlay fabric (such as VXLAN, a tunnelling scheme that carries layer 2 over layer 3) where stretching a segment no longer means a spanning tree domain.

Pitfalls

• Letting a VLAN span campuses "for convenience": one loop then takes down three sites.
• Numbering VLANs inconsistently so the ID tells nobody the building or role (the ID scheme is documented and automated).
• Leaving unused ports in the default VLAN 1 (the default VLAN created at system initialization) or using it for management.
• Sizing the DHCP scope to the headcount instead of the device count: the 10,000 users in this example are 20,000 devices.

Direct answer

Create the VLAN, then configure the port as a static access port in that VLAN, enable PortFast (so it skips the spanning-tree listening and learning delay) and BPDU guard (so a switch plugged in later shuts the port), and turn off trunk negotiation. Verify with show vlan, show interfaces switchport and the MAC table. Platform: Cisco IOS XE (Catalyst 9300 documentation); the vendor-agnostic order is the same everywhere: VLAN exists, port mode access, port assigned, port edge-protected, verify.

Configuration

configure terminal
vlan 40
 name SALES
interface GigabitEthernet1/0/12
 description Sales user port
 switchport mode access
 switchport access vlan 40
 switchport nonegotiate
 spanning-tree portfast
 spanning-tree bpduguard enable
 no shutdown
end

Command roles:

• vlan 40 / name SALES: create the VLAN (Cisco's documented creation sequence). Cisco documents that assigning an interface to a VLAN that does not exist creates it, but an implicitly created VLAN has no name and a typo in the number silently creates a wrong one, so create it deliberately first.
• switchport mode access and switchport access vlan 40: the documented access-port sequence. A port in static access mode does not carry tagged frames for other VLANs.
• switchport nonegotiate: stops the port generating DTP (Dynamic Trunking Protocol) frames. Cisco documents that it must pair with a static access or trunk mode, which is why switchport mode access precedes it.
• spanning-tree portfast: the port moves straight to forwarding when the link comes up, so DHCP does not time out waiting for spanning tree. Cisco documents this form for access ports and warns to use it only on ports to end stations. Some other releases and platforms use the form spanning-tree portfast edge instead; the Catalyst 9300 guide cited here documents only the plain form, so confirm the exact keyword in the platform's command reference. Rapid PVST (rapid per-VLAN spanning tree) is the faster modern spanning-tree mode.
• spanning-tree bpduguard enable: if a BPDU (Bridge Protocol Data Unit, the spanning-tree message) arrives, the port goes error-disabled. Cisco documents this as the interface-level form; the global form is spanning-tree portfast bpduguard default, which applies to ports that have PortFast on.

Checks that confirm it works

Then test from the end: the PC gets a DHCP lease in the Sales subnet, pings its gateway, and the gateway interface for VLAN 40 exists upstream.

Worked example of what each protection stops

• Someone plugs a small unmanaged switch with a loop cable into the port. Without BPDU guard, the switch treats the new device as part of the spanning-tree topology: the port can start forwarding and the extra switch can send BPDUs that change which switch is root or create a loop that floods the VLAN. With BPDU guard, the port goes error-disabled (the switch shuts the port down and shows it as disabled) on the first BPDU and the problem is contained to that one port. List such ports with show interfaces status err-disabled. Recover with shutdown then no shutdown after removing the device.
• A laptop sends DTP trunk-desirable frames. With switchport mode access plus nonegotiate the port never becomes a trunk, so the laptop cannot see tagged traffic for VLANs it was not given.

Trade-offs and pitfalls

• Default switchport mode on Cisco Ethernet interfaces is dynamic auto (Cisco documents it), so a port left at its default can become a trunk if the neighbour asks. Always set the mode explicitly.
• Do not enable PortFast on ports that connect to other switches.
• Create the VLAN deliberately first and make sure it exists on, and is allowed on, the uplink trunk, or the user is isolated on the access switch.
• Describe the port (description) and document the VLAN assignment so the next engineer does not guess.

Direct answer

Do it as a series of small, reversible waves, each moving one group of related hosts into a new VLAN, with the router interface for the new VLAN built and tested BEFORE any host moves, and a written, timed back-out for every wave. A VLAN is a separate broadcast domain carved out of the same physical switches; a trunk is a switch-to-switch link that carries several VLANs; an SVI (switch virtual interface) is the switch's layer 3 interface for one VLAN, which is the gateway address the hosts in that VLAN use to reach other subnets. The risks are not the VLAN commands: they are addressing (hosts keep their IPs only if you keep the subnet), ARP caches that can hold old MACs (a Cisco router interface keeps an entry for 4 hours by default), and DHCP scopes that no longer match. Commands below are Cisco IOS XE.

Pick the addressing strategy first

Hosts in a flat VLAN share one subnet, so each new VLAN needs its own subnet and its own gateway address. Recommend re-addressing each tier into a NEW subnet taken from address space that is currently unused, rather than shrinking masks on live hosts and rather than carving the tiers out of the old subnet, because that is what lets the old and new subnets exist side by side through the whole migration.
Why not carve them out of the old subnet: suppose the flat network is VLAN 1 with 10.20.0.0/16. A host there with mask /16 treats every address from 10.20.0.1 to 10.20.255.254 as directly reachable on its own wire. If a web host were moved to 10.20.10.5, an old host would not send to it through the gateway; it would ARP for it locally and fail because the two now sit in different VLANs. Worse, 10.20.10.5 may already belong to an existing flat-network host, so a rolled-back host could collide with it.
Example, with 10.30.0.0/16 as an illustrative free block (confirm in your IP address management records that nothing else uses it): web 10.30.10.0/24 (254 usable hosts), app 10.30.20.0/24 (254), database 10.30.30.0/25 (126) and management 10.30.99.0/26 (62). Computed with Python's ipaddress: none of the four overlaps another or the old 10.20.0.0/16, and each gateway is the first address (.1). Size each subnet from the host count plus growth. If no free block exists, the only options are an in-place renumber, which cannot run side by side and carries more risk, so finding free space is the first task. Hosts that get addresses from DHCP (Dynamic Host Configuration Protocol) only re-address when they next renew or re-request a lease. Changing the port's VLAN does not by itself drop the link, so a client keeps its old, now-wrong address until its next renewal, which can be hours or days away depending on the lease length. Force it in every wave by bouncing the port or renewing the lease on the host, and consider shortening the lease time ahead of the work (at least one old lease length before the first wave). Hosts with static addresses need a configuration change, so list them first.

Sequence

1. Inventory and dependencies (before the window): list every host, its MAC, IP, role, and who talks to whom (flow records or show mac address-table). Group by tier and by dependency so a wave moves hosts that talk to each other together.
2. Prepare the network without touching hosts: create the VLANs on every switch (vlan 20, name APP), allow them on the trunks with switchport trunk allowed vlan add 20 (without add, the command replaces the whole list), create the gateway SVI (interface vlan 20, ip address 10.30.20.1 255.255.255.0) and leave it up. If VTP is in use, check show vtp status first.
3. DHCP: for each new VLAN create the scope and point the SVI at the server with ip helper-address. DHCP clients find a server by broadcast, and a broadcast does not cross a router, so the SVI relays it: by default it forwards DHCP (UDP ports 67 and 68) among other broadcast services, rewriting the destination to the server address. Exclude static addresses (gateway, printers, servers) from each scope.
4. ARP and the gateway: the old subnet's gateway stays on the old SVI until the last wave ends. ARP (Address Resolution Protocol) caches map an IP address to a MAC address; on a Cisco router interface the default lifetime is 14400 s (4 hours) per interface, and hosts keep their own caches with timers set by their operating system. Two cases matter. A re-addressed host gets a new IP, so the old SVI's entry for its old IP just goes unused, but if that old IP is later handed to a different device, the old SVI can keep sending that IP's frames to the previous MAC until the entry expires, so keep vacated addresses reserved until the wave closes. A host that keeps its IP while its MAC changes (a replaced server or NIC, a moved gateway address) is where neighbours can hold the wrong MAC for up to 4 hours. Lower arp timeout (in seconds, interface mode) on the old SVI a day ahead of the work, for example arp timeout 300, and restore it afterwards.
5. Wave 0 (canary, one low-risk host moved first so a failure shows up cheaply): move one non-critical host, change its port with switchport access vlan 20, renew DHCP or set the static address, and run the validation list below.
6. Waves 1..N: one tier per window, least critical first, database last, each with the same validation and back-out.
7. Clean up: remove old SVI addresses, tighten ACLs (access control lists, the permit and deny rules that filter traffic) between the new VLANs, update documentation, restore ARP timeout.

Validate each wave (pass or roll back)

• Port in the right VLAN: show vlan brief lists VLAN 20 with the host's port in its Ports column.
• Trunks carry it: show interfaces trunk lists 20 under allowed VLANs and under VLANs in the forwarding state.
• Host: gets address (DHCP lease from the right scope), pings the new gateway, resolves DNS, and reaches the dependency in another tier through routing and the firewall.
• Switch: show mac address-table shows the host's MAC on one port in VLAN 20.
• Application owners confirm a real transaction. Metric: error rate and latency at the load balancer compared to the previous hour.

Roll back

Because the old subnet and old SVI stay intact until the end, and the new subnets do not overlap them, rollback is: switchport access vlan 1 (the original flat VLAN), renew the old lease or restore the old static address (which is still unused by anyone else, because vacated addresses stay reserved), and flush the ARP entry on the gateway. Set a back-out trigger beforehand, for example "if any validation line fails 15 minutes after the move, roll back that wave", so no one decides under pressure. A wave is only started if the window leaves time for its own rollback.

Pitfalls

• Moving a host before its trunk and SVI exist: no gateway, outage.
• Forgetting static-IP hosts that DHCP never touches.
• Stale ARP: the 4-hour default turns a minute of work into hours of intermittent failure.
• Moving dependent hosts in different waves: both SVIs live on the same router, so the old and new subnets can reach each other by routing, but the ACLs and firewall rules must permit that traffic until the pair is together.

Direct answer

A VLAN (virtual local area network) is a way to split one physical switch network into several separate logical networks. Each VLAN is its own broadcast domain: a broadcast sent by one machine (a frame addressed to every device, such as an ARP or DHCP request) is delivered only to ports in the same VLAN. Think of one open-plan office floor that gets partitioned into rooms: same building and same wiring, but a shout stays inside its room, and getting from one room to another requires walking through a door (a router or layer 3 switch).

What changes once the network is split

Broadcasts. On a flat network every ARP (Address Resolution Protocol: "who has this IP address, tell me your MAC address") and every DHCP (Dynamic Host Configuration Protocol: automatic IP address assignment) discover reaches every host. With VLANs those broadcasts stop at the VLAN edge. Each VLAN is normally one IP subnet, so ARP only ever resolves addresses inside the sender's own subnet, and traffic to anything else is sent to the default gateway's MAC address. (A subnet is a block of IP addresses that share a prefix, such as 10.10.10.0/24; the default gateway is the router address a host sends to when the destination is outside its own subnet.)

Security boundaries. A VLAN gives you separation at layer 2: a server in VLAN 10 cannot be reached by a direct frame from a laptop in VLAN 20. Traffic between VLANs has to be routed, and the routing point (a firewall, a router, or the switch's layer 3 interface) is where you apply access control lists (ACLs: permit/deny rules). The boundary is only as strong as that routing point: if the gateway routes everything between VLANs with no ACL, the VLANs separate broadcasts but not risk. A VLAN is a segmentation tool, not a firewall.

Day-to-day operations.

• Moving a person or server to another network is a port configuration change, not a recabling job.
• Every VLAN needs its own subnet, its own default gateway, and its own DHCP scope (the pool of addresses the DHCP server may hand out for that subnet). A DHCP server in another subnet is reached through a DHCP relay agent on the gateway, which forwards the broadcast as unicast to the server.
• Switches are joined by trunk links that carry many VLANs over one cable, each frame labelled with its VLAN number. A VLAN missing from a trunk is the classic "works on this switch, dead on that one" fault.
• Shared environments with several tenants (customers or business units on the same switches) usually start with one VLAN per tenant, paired with separate routing instances (VRFs, virtual routing and forwarding tables: each tenant gets its own private routing table on the same router) or separate firewall policy per tenant. For example, tenants A and B may both use 192.168.1.0/24, which is an overlapping address plan. Each tenant's VLAN lands in its own VRF, so 192.168.1.10 in tenant A and 192.168.1.10 in tenant B never collide, because the router looks up each in a different table, and any traffic between tenants is allowed only where you deliberately permit it.

Worked example

A site has 600 devices: 200 servers, 200 user devices (199 PCs plus the shared printer) and 200 IP phones. Flat, they all share one subnet. A subnet of 2^h addresses has 2^h - 2 usable addresses (minus the network and broadcast addresses), where h is the number of host bits, so it must satisfy 2^h - 2 >= 600. With h = 9, 2^9 - 2 = 510, which is too small; with h = 10, 2^10 - 2 = 1022, which fits. Host bits are 32 minus the prefix length, so h = 10 means a /22. Every broadcast then reaches the other 599 devices. Split into three VLANs of 200 devices each, each subnet needs 2^h - 2 >= 200: h = 7 gives 126 (too small), h = 8 gives 254, so a /24 per VLAN:

A broadcast now reaches 199 other devices instead of 599, and the printer in VLAN 20 no longer sees server chatter. (Addresses and counts here are illustrative.) The users-to-servers path crosses the gateway, where an ACL can permit only the application ports the users need.

Trade-offs and pitfalls

• More VLANs means more gateways, DHCP scopes and trunk allowed-lists to keep consistent. Name and document them.
• Do not treat a VLAN as a security control by itself. Leaving unused ports in a default VLAN, or trunking user VLANs carelessly, weakens the separation.
• Keep VLAN size sensible: a VLAN stretched across the whole campus enlarges the failure domain (a layer 2 loop affects every switch it touches).

Direct answer

Spanning tree is the protocol that stops loops in a switched network by electing one switch as the root bridge (the reference point, the one with the lowest bridge ID: the priority number first, with the MAC address as the tie-break) and blocking every redundant port so each switch keeps a single forwarding path toward the root. A pod is a group of racks built and managed as one unit, and a ToR (top-of-rack) switch is the switch at the top of each rack that the servers plug into. Spanning tree hurts at pod scale because it makes redundancy cost bandwidth: it blocks every redundant link so each switch has one forwarding path to the root bridge, which means half of dual-homed uplink capacity sits idle, and a topology change can disturb forwarding while it reconverges. For the access layer I would put a multi-chassis link aggregation (MLAG, called vPC, virtual PortChannel, on Cisco Nexus) pair at the top of each rack, with servers dual-homed using LACP (Link Aggregation Control Protocol, which bundles several cables into one logical link) and ToR uplinks routed (each uplink is a layer 3 point-to-point link with its own IP address, and the routing protocol spreads traffic over all equal-cost uplinks, so there is no layer 2 loop to block) or aggregated into a port-channel, so every link forwards and failure is handled by link aggregation, not by a spanning-tree recalculation. I would still keep spanning tree running as a safety net on edge ports to stop a mistaken cable from causing a loop, and keep it as the main mechanism where a legacy switch or a device without LACP support must attach with redundant links.

Where spanning tree hurts (computed example)

Spanning tree (Cisco defaults to Rapid PVST+ on Catalyst 9000, with bridge priority 32768 and port priority 128) forces redundant paths into a blocked state. Example: a pod where each of 20 access switches has two 40G uplinks to two aggregation switches. Under a single spanning tree shared by all VLANs (or per-VLAN trees that all have the same root), one uplink per switch forwards: usable = 20 x 40G = 800G of 1,600G installed, 50%. Per-VLAN trees (PVST+, one tree per VLAN) or multiple spanning tree (MST, one tree per group of VLANs) can alternate the blocked link per VLAN. Concretely, with 20 VLANs, make aggregation switch 1 the root for VLANs 1 to 10 and aggregation switch 2 the root for VLANs 11 to 20: on each access switch the uplink to switch 1 forwards VLANs 1 to 10 and blocks 11 to 20, and the uplink to switch 2 does the opposite. Each 40G uplink carries 10 VLANs, so both are used and, if the VLANs carry equal load, the pod uses its full 1,600G on average. It recovers capacity on average, but any one VLAN (and so any single large flow in it) still has only one 40G path, and the load balance is a manual VLAN-to-root assignment that drifts as workloads move.
Other costs at scale:

• Blocked links are not tested by traffic until failure, so a bad standby link surfaces during an outage.
• Root election is fragile: a switch added with a lower bridge priority value than the intended root wins the election and reshapes the whole tree.
• Large single broadcast domains and many VLANs on shared trees amplify any mistake into a pod-wide event.

What to use instead, at layer 2

When I would still keep spanning tree

1. Always on edge ports as a protection: PortFast (moves the port straight to forwarding) plus BPDU guard (error-disables the port if it receives spanning-tree messages), configured with spanning-tree portfast and spanning-tree bpduguard enable on Cisco, or globally with spanning-tree portfast default (PortFast on all non-trunking access ports) plus spanning-tree portfast bpduguard default (BPDU guard on PortFast ports; the second command alone does not turn PortFast on). A server NIC bridge or a stray switch then cannot create a loop.
2. As the main protocol where it is the only safe option: attaching a legacy switch with redundant links to the pod, a small branch or lab pod where two cables are the entire redundancy need, or a device that cannot run LACP.
3. Root guard (spanning-tree guard root) and a deliberately set root where access switches connect to a shared layer.

Pitfalls

• Disabling spanning tree entirely "because MLAG is loop-free": a miscabled port-channel or a bridged server then floods the pod.
• Treating MLAG as free: it couples two switches' software versions and makes the peer link critical.
• Mixing MST and PVST+ domains without checking the root placement.
• Believing the hashing balances evenly: the hash (a fixed recipe that turns address bits into a link number) sends every frame of one flow down the same link so frames stay in order, which is why a few large flows can still fill one member link.