The switch in depth
L2 mechanics and security: MAC table and flooding, the 802.1Q frame, port security, VLAN hopping, DHCP snooping and DAI, Spanning Tree protection.
Lesson 1: How a switch really forwards
MAC learning
A visitor in the meeting room plugs their laptop into a wall socket – and within minutes they can sniff other people’s traffic, or the whole company network is down. How that is possible and how to prevent it is what this entire course is about. And it starts with how a switch really works inside. How does a switch know where to send a frame? It learns by itself. For each incoming frame it reads the source MAC address and remembers which port it saw it on – into the MAC table (CAM). Next time it has something to deliver for that MAC, it sends it only to that one port, not everywhere. A switch never reads IP (that’s the router’s job) – it works purely with MAC addresses at Layer 2. This table is the heart of the switch.
Step by step
- PC-A sends a frame. The switch reads its source MAC and the port it arrived on.
- It writes to the MAC table: "AA:..:A1 is on port P1". It learned where PC-A is.
- When it has something for AA:..:A1, it sends it only to P1 – not to all ports. The table saves the network.
Flooding an unknown MAC
What if the switch doesn’t yet know the destination MAC (not in the table)? It doesn’t drop the frame – it does flooding: sends it out all ports except the one it came in on (unknown unicast flooding). The right recipient replies, the switch learns its port from that reply, and next time sends it directly. A broadcast (destination "everyone") is handled the same – it’s always sent everywhere within the VLAN. Flooding is normal and brief; trouble only arises when the table breaks (next lesson).
Step by step
- SRV wants to send to PC-B, but the switch doesn’t know PC-B’s MAC (not in the table).
- The switch floods the frame out all other ports. It reaches everyone, but only PC-B replies.
- From PC-B’s reply the switch learns its port. Next time no flood – it sends directly.
Aging and table capacity
The MAC table is neither infinite nor permanent. Each entry has an aging timer, typically around 5 minutes: if a given MAC goes quiet for a while, the switch evicts it (the device may have moved or powered off). The table also has a limited size (CAM capacity). When it fills up, the switch has nowhere to learn new MACs and starts flooding – which is exactly what the attack in lesson 3 abuses (CAM overflow). So aging and capacity aren’t just technical detail, they’re a security topic too.
Step by step
- The table is full of active entries. But PC-B has gone quiet for a while…
- …so after the aging timer the switch evicts its entry. The table keeps only what’s active.
- And beware: if the table fills up entirely, the switch starts flooding everything. That is exactly what the attack we will show in lesson 3 (CAM overflow) abuses.
Lesson 2: Inside the frame and 802.1Q
The Ethernet frame
Let’s go inside the frame – the Layer-2 unit. The important fields are two addresses: the destination MAC (to whom) and the source MAC (from whom), then type/length and the data itself, and at the end a checksum (FCS). The switch decides only by these MAC addresses – it doesn’t care about the IP inside. It uses the source MAC to learn and the destination MAC to deliver. This is the whole "language" the switch speaks.
Step by step
- The destination MAC = who the frame is for. By it the switch decides which port to deliver to.
- The source MAC = from whom. By it the switch learns (records it for the ingress port).
- Inside is the data (with the IP packet) and at the end the FCS. But the switch doesn’t read the IP – it goes purely by MAC. That’s L2.
The 802.1Q tag
When one link (a trunk) must carry several VLANs (what a VLAN is, you know from the Switching and VLANs course), how does the switch know which VLAN a frame belongs to? It inserts an 802.1Q tag into the frame – a short 4-byte field right after the source MAC, carrying mainly the VLAN ID (a number 1–4094). The second switch reads the tag, places the frame in the right VLAN and removes the tag again before handing it to the end device (which knows nothing about VLANs). So tagging happens only between switches on a trunk; the access port to an end device is always untagged. And one more connection: a switch can have its own IP address inside a VLAN – that’s called an SVI (Switch Virtual Interface), the VLAN’s virtual interface. On a plain L2 switch there is usually one SVI for management (you log in to that IP); and it is exactly thanks to SVIs that the L3 switch from the Switching and VLANs course can route between VLANs – each VLAN has its own SVI there, which is its default gateway.
Step by step
- PC-A sends a plain untagged frame (it knows nothing about VLANs). It arrives on an access port in VLAN 20.
- Before sending the frame over the trunk to the other switch, it inserts an 802.1Q tag with "VLAN 20". Now it’s clear where it belongs.
- The second switch reads the tag, places it in VLAN 20 and removes it again before giving it to the end PC. Tagging is only between switches.
The native VLAN
One exception: a trunk has a native VLAN – the single VLAN whose frames go untagged. Historically for devices that couldn’t do 802.1Q. But it’s a security risk: if two connected switches have a different native VLAN, frames can "jump" into the wrong VLAN (native VLAN mismatch). And the VLAN hopping attack via double-tagging abuses the native VLAN directly (lesson 4). Practical rules: same native VLAN on both ends, and ideally a dedicated unused VLAN with no data in it.
Step by step
- On a trunk one VLAN goes untagged – the native VLAN. All others are tagged.
- If the switches have a different native VLAN, an untagged frame lands in the wrong VLAN (mismatch). A security hole.
- Rule: native VLAN the same on both ends and ideally unused (no data). That also closes VLAN hopping (lesson 4).
Lesson 3: Port security in depth
CAM overflow (MAC flooding)
Now the first L2 attack – and it ties straight to the MAC table. In MAC flooding the attacker spews a flood of frames with bogus source MACs into the switch. The switch dutifully tries to learn them until its CAM table overflows. A full switch can’t learn legitimate MACs – it has nowhere to store new/unknown destinations and floods them to all ports: it behaves more and more like a hub. The attacker thus sniffs traffic that would otherwise never reach them. The defense? Limit how many MACs are allowed on a port – port security (next modules).
Step by step
- The attacker on PC-B spews frames with thousands of fake MACs. The switch tries to learn them…
- …until the CAM overflows. A full switch floods unknown destinations to all ports – behaving more and more like a hub.
- SRV → PC-A traffic now also reaches the attacker (PC-B). Eavesdropping! The defense = port security.
Port security and sticky MAC
Port security is a defense right on the switch port. You tell it: "this access port may have at most N MAC addresses" (typically 1 – one computer). When more appear, it’s a violation. You can also lock a MAC (sticky): the switch remembers the first learned MAC and then only allows that one – nobody else gets through. That kills MAC flooding (the attacker can’t fill the table via one port) and plain "I’ll plug a foreign PC into the socket". You’ll try it in this simulator: on the managed switch’s Ports tab you set max MAC and an allowed MAC. (The "Allowed MAC" field only shows in Advanced mode.)
Step by step
- On PC-B’s port you set max 1 MAC. One computer = fine.
- Sticky: the switch locks PC-B’s MAC. Only it passes on the port.
- The attacker tries to flood fake MACs or swap in a foreign PC → violation, the port acts. MAC flooding falls.
Violation actions
What happens on a port-security violation? There are three response modes. Protect: it silently drops the disallowed frames, reports nothing. Restrict: it drops them and also logs (a log/counter) – you know something’s happening. Shutdown (the default and strictest): it fully disables the port (err-disabled) until an admin manually restores it. The choice is a trade-off between security and uptime: shutdown is safest but one mistake downs a port; protect/restrict don’t interrupt traffic but only slow the attacker. So what is protect good for, if restrict does almost the same and logs on top? It fits where the records would needlessly flood the log – say a port where several MACs show up routinely and predictably (a shared meeting room, a printer with a built-in mini-switch, a phone with a PC behind it). There restrict would spew messages that drown out the important ones, so you drop silently instead. In practice access ports still most often use restrict or shutdown.
Step by step
- Protect: disallowed frames silently vanish. The mildest – but you don’t even know it happened.
- Restrict: drops and logs. Traffic keeps flowing, but you have a trace to investigate.
- Shutdown (default): the port is fully disabled until you restore it by hand. Safest, but harshest.
Lesson 4: VLAN hopping
Double tagging
VLAN hopping = an attack that reaches a foreign VLAN it shouldn’t. You glimpsed it briefly in the redundancy course – here we take it apart properly and add the second variant (switch spoofing via DTP) and the full defense. The first variant: double tagging. The attacker (in the native VLAN) sends a frame with two 802.1Q tags. The first switch strips the outer tag (it’s its native VLAN, goes untagged) and forwards the frame – but underneath remains the second tag, aimed at the victim’s target VLAN. The second switch reads it and delivers it to that VLAN. Why doesn’t the first switch strip both? Because a switch always removes only the outer tag – whatever is underneath it treats as the frame’s data and never looks inside. So it never "sees" the second tag and passes it on untouched. And how does the attacker even build such a frame? An ordinary computer doesn’t tag – tagging is the switch’s job. So the attacker needs a network card and software that can insert 802.1Q tags themselves (standard equipment on Linux); only then can they send a frame that already carries two tags. It’s one-way – the victim’s reply travels back the normal way (with a single tag), so it never reaches the attacker; it works only from the native VLAN – but that’s enough to inject an attack. The defense is in the next module.
Step by step
- The attacker (in the native VLAN) sends a frame with two tags: outer = native, inner = the victim’s VLAN.
- The first switch strips only the outer tag (it’s its native → untagged) and forwards. It never looks underneath – the second tag passes untouched.
- The second switch reads the remaining tag and delivers the attack into the victim’s VLAN. Hopping! One-way, but effective.
DTP and switch spoofing
The second VLAN-hopping variant: switch spoofing via DTP (Dynamic Trunking Protocol – the protocol two switches use to agree on their own that a trunk should form between them). Many switches have ports in a default mode where they auto-negotiate a trunk – for convenience (plug two switches together and the trunk comes up on its own), but that is also a hole. The attacker connects and pretends to be a switch wanting a trunk. When the port accepts DTP, a trunk forms – and the attacker suddenly sees all VLANs at once (a trunk carries everything). A one-computer access port becomes a gateway into the whole network. The cause: automatic trunk negotiation where it has no business being. The defense is obvious – next module.
Step by step
- The port is willing to negotiate a trunk by default (DTP). It waits for a switch to speak up.
- The attacker pretends to be a switch and asks for a trunk. The port agrees → a trunk forms.
- A trunk carries all VLANs – the attacker sees them all at once. A one-PC port became a hole into the whole network.
Defending against hopping
The defense against VLAN hopping is luckily straightforward – it’s port hygiene: (1) On ports to end devices disable DTP and hard-set them as access (no automatic trunk negotiation). (2) Set the native VLAN to a dedicated unused VLAN with no data in it – that kills double tagging. (3) On a trunk allow only the needed VLANs (pruning), not all. (4) Administratively shut unused ports. A few rules, and both hopping variants are gone.
Step by step
- You hard-set the PC port as access and disable DTP. Switch spoofing has no chance.
- You give the native VLAN a dedicated unused one. Double tagging has nothing to start from.
- On the trunk only needed VLANs and shut unused ports. Done – hopping closed.
Lesson 5: DHCP and ARP defense
Rogue DHCP (MITM)
Another L2 threat targets DHCP (automatic IP assignment). The attacker plugs a rogue DHCP server into the network. When a client asks for an IP, the rogue can answer before the real one – and hand it its own IP as the default gateway. From then on all the client’s traffic flows through the attacker (man-in-the-middle): they can sniff or alter it. The client knows nothing – it got "an IP and a gateway", as always. This is dangerous precisely because DHCP isn’t normally verified by anyone. The defense? DHCP snooping – next module.
Step by step
- PC-A asks for an IP via DHCP (a broadcast "who can help me?").
- The attacker’s rogue DHCP answers first: "here’s an IP and a gateway = me". PC-A has no idea.
- Now all of PC-A’s traffic flows through the attacker (MITM). They can sniff and alter it. The defense = DHCP snooping.
DHCP snooping
DHCP snooping is a defense right on the switch. The principle: ports are split into trusted and untrusted. The switch accepts DHCP replies (IP/gateway offers) only from trusted ports – typically the uplink toward the real DHCP server. If a DHCP offer arrives from an untrusted port (where an end PC or attacker is connected), the switch drops it. That kills rogue DHCP. The switch also builds a binding table "MAC + IP + port", useful for a further defense (DAI – next module).
Step by step
- You split the ports: the uplink to the real DHCP = trusted, end-PC ports = untrusted.
- The attacker tries a DHCP offer from an untrusted port → the switch drops it. Rogue DHCP falls.
- For legitimate clients the switch records MAC + IP + port in the binding table. It’ll be handy for DAI.
Dynamic ARP Inspection
The last of the trio is Dynamic ARP Inspection (DAI) – a defense against ARP spoofing. Recall from the How networks work course: ARP maps IP to MAC. An attacker can broadcast forged ARP ("the gateway IP = my MAC"), pulling the victim’s traffic to themselves (MITM again). DAI prevents this: on untrusted ports it checks every ARP against the binding table from DHCP snooping. Does "MAC + IP" match an entry? The ARP passes. Doesn’t match (a forgery)? It drops it. So DHCP snooping and DAI form a pair: snooping knows who has which IP, and DAI enforces it for ARP too.
Step by step
- The attacker broadcasts forged ARP: "the gateway IP = my MAC". They want to pull the victim’s traffic.
- DAI compares that ARP with the binding table (from DHCP snooping): does that MAC really own that IP?
- No match (a forgery) → the ARP is dropped. ARP spoofing falls. Snooping + DAI = a strong pair against MITM.
Lesson 6: Protecting Spanning Tree
Rogue root and BPDU attack
You can also attack Spanning Tree (from the Redundancy and Spanning Tree course). STP elects the root bridge by the lowest bridge ID. (This simulator computes the tree per VLAN – like Cisco PVST+.) When an attacker connects a switch (or software) with an artificially low priority, it declares itself root and STP recomputes the tree so that traffic starts flowing through it – eavesdropping, or at least destabilizing the network. All it takes is sending forged BPDUs (the messages switches compute STP with). The cause: a switch trusts any BPDU on any port – even where only an end PC should be. The defense is in the next modules (BPDU Guard, Root Guard).
Step by step
- Normally the root is the central backbone switch. The tree is built sensibly around it.
- The attacker sends forged BPDUs with an extra-low priority: "I am root". STP believes it.
- The tree recomputes and traffic starts flowing through the attacker. Eavesdropping / destabilization. Defense → BPDU/Root Guard.
PortFast and BPDU Guard
The first STP protection: PortFast + BPDU Guard on access ports (where end PCs belong). PortFast lets such a port go straight to forwarding (a PC needn’t wait for STP). But that would make it vulnerable – so BPDU Guard is added: on a PortFast port no BPDUs are expected, it’s just a computer after all. If any BPDU arrives on such a port (someone connected a switch or attacker), BPDU Guard instantly disables the port (err-disabled). An STP attack thus ends before it begins. (You know PortFast and BPDU Guard from the Redundancy and Spanning Tree course – here you see them as a defense against a rogue-root attack.)
Step by step
- On the access port to a PC you enable PortFast – the port forwards immediately, the PC doesn’t wait for STP.
- You add BPDU Guard: on this port no BPDUs are expected – there’s a computer here.
- If someone connects a switch and a BPDU arrives, the port is instantly disabled. A rogue root can’t even get going.
Root Guard
And what about ports where a switch belongs (a legitimate switch link) but you don’t want the other side to become the root? That’s what Root Guard is for. It watches: a BPDU may arrive on a protected port, but NOT a "superior" BPDU that would make the neighbor the new root. If such a one arrives, Root Guard puts the port in the root-inconsistent state (temporarily blocking) until it stops. This pins the direction the root may come from (toward the backbone) and prevents someone outside from taking over the tree’s root. BPDU Guard protects access ports, Root Guard protects ports toward other switches from which the root must not come.
Step by step
- You want the root in the backbone. On the trunk to another switch you enable Root Guard.
- The neighbor sends a superior BPDU ("I’d be a better root"). Root Guard won’t allow it.
- The port goes root-inconsistent (blocks) until the superior BPDUs stop. The root stays where it belongs.
Lesson 7: Operations and synthesis
SPAN and monitoring
A slightly different but practical topic: how do you see traffic on a switch without being in its path? That’s what SPAN (port mirroring) is for: the switch sends a copy of traffic from one or more ports to a chosen monitor port. There you attach an analyzer or an IDS (recall the Advanced security course – an IDS sits "off-path" precisely thanks to SPAN/TAP). Traffic keeps flowing normally; SPAN only mirrors. It’s a basic tool for diagnostics (why isn’t it working) and security (what packets are flying around).
Step by step
- Normal traffic flows between PC-A and the server. You want to see it, but not be in the path.
- You enable SPAN: the switch sends a copy of the traffic to the monitor port (PC-B with an analyzer/IDS).
- The original traffic flows on untouched; you have a copy for diagnostics and security. That’s how an IDS sits "off-path".
The port’s physical layer
A colleague reports that "the internet is slow" – yet the link is up, the ping goes through and the switch reports nothing. The culprit is often the port’s physical layer. It starts with duplex: full duplex means the port sends and receives at the same time (the norm today), half duplex can only do one at a time and has to watch for collisions (a legacy of hubs and collisions – you saw both in the ISO/OSI and TCP/IP: the network map course). Both ends of the cable usually negotiate speed and duplex themselves – that is autonegotiation. But if you hard-set one end and leave the other on auto, the fixed side stops sending the negotiation signal – the auto side has nothing to read, it can still derive the speed from the signal on the wire, but not the duplex, so it safely falls back to half duplex. That is why a mismatch is almost always in duplex, not in speed. You get a duplex mismatch. That is the treacherous fault: the link "works", the ping goes through, but any real transfer is desperately slow and collisions and errors pile up on the port. The rule is simple: either both ends on auto, or both hard-set the same – never half and half. The same family includes port speed (100M / 1G / 2.5G / 10G) and SFP uplinks: an SFP is a small pluggable module in a switch slot that takes a copper or fiber cable – that is how fast switch-to-switch links and longer-distance links are built. Both are in this simulator too: you set speed and duplex by right-clicking a link (or in the port detail) and the number of SFP slots is in the switch’s port settings. Note though: duplex here is a property of the whole link, not of each end separately – so you cannot build the mismatch itself (one end hard-set, the other on auto) in the simulator; that one is knowledge for the real world. And thirdly PoE (Power over Ethernet): the switch sends power over the data cable as well, so a Wi-Fi AP, camera or IP phone runs without its own socket – one ethernet cable is enough. How much power a device gets is set by classes: 802.3af about 15.4 W, 802.3at (PoE+) 30 W and 802.3bt up to 90 W – that tells you whether the switch can power just a phone or also a pan-tilt camera. An honest note: this simulator does not model PoE – there is nowhere here to configure power, take it as knowledge for the real world.
Step by step
- Full duplex: the port sends and receives at the same time. Both ends negotiate speed and duplex themselves – autonegotiation.
- Duplex mismatch: one end hard-set, the other on auto → the auto side falls back to half. The link "works" but is desperately slow.
- The rule: both ends on auto, or both hard-set the same. Never half and half – that makes the mismatch go away.
- Port speed and the SFP uplink: a pluggable module (copper/fiber) for fast links. In the simulator: right-click a link, and the port settings.
- PoE: one cable carries data and power (af 15.4 W / at 30 W / bt 90 W). Note – the simulator does not model PoE.
Link aggregation
One gigabit cable between switches is no longer enough – and replacing both switches with ten-gigabit ones is expensive. Link aggregation (EtherChannel/LACP – from the Redundancy and Spanning Tree course) offers a cheaper way: you bundle several physical cables into one logical link. This grows the bundle’s total capacity (two gigabits instead of one) – but not the speed of a single transfer. The switch does not spread individual frames; it spreads whole flows: from the sender/receiver pair it computes a "fingerprint" (a hash) and permanently pins that flow to one particular cable, so frames don’t arrive out of order. One download therefore still rides a single cable at a gigabit at most; the bundle helps where there are many connections – they spread across all the cables and together saturate them. The second benefit is redundancy: if a digger cuts one cable or someone yanks a connector, the bundle keeps going, just with less capacity. And the loop? There are several cables, so a physical loop is there – but the bundle acts as one logical port, which is how STP sees it, so there is nothing to block. The condition: both ends must be bundled into the same group and configured the same – otherwise you get exactly the loop you wanted to avoid instead of a bundle. In the simulator you build a bundle by right-clicking a link (Bundle parallel links into a LAG). The physical side of a port – duplex, speed, SFP and PoE – is covered by the previous module.
Step by step
- Aggregation: you bundle two cables into one logical link. The capacity adds up and traffic is spread across them.
- One cable fails? The bundle keeps going, just with less capacity. That’s the free redundancy.
- The physical loop is there, but STP sees one logical port – nothing to block. The condition: both ends configured the same.
A secured L2 and what’s next
Let’s sum up the switch in depth. We taught the switch to forward (MAC table, flooding, aging), dissected the frame and 802.1Q, and above all went through L2 security: port security against MAC flooding, defense against VLAN hopping (disable DTP, mind the native VLAN), DHCP snooping + DAI against MITM, and BPDU/Root Guard against STP attacks. The access layer is the first place an attacker reaches – and now you know how to harden it. The next stop in the course rhythm: the router in depth.
Step by step
- The switch forwards by the MAC table and tags VLANs via 802.1Q. That’s the L2 core.
- And you can harden it: port security, hopping defense, DHCP snooping + DAI, BPDU/Root Guard.
- The access layer is secured. Next device in depth: the router (you already covered the firewall in the security courses).