MACsec Explained: Encrypting the Cable Between Two Switches

A padlock on one cable, not a tunnel across the internet

Picture the cable between two switches in a data hall. Anyone who can touch that cable — a compromised patch panel, a shared meet-me room, a carrier's handoff — can in principle read or tamper with every frame on it. MACsec (Media Access Control Security, the IEEE 802.1AE standard) is the fix built for exactly that one cable: the two devices on its ends agree on keys, and every single frame crossing the link is encrypted and integrity-checked before it leaves and verified the moment it arrives.

The analogy is a sealed, tamper-evident envelope for every letter, but only for one leg of the journey. At the next switch, the envelope is opened, checked, and — if the next cable also runs MACsec — the frame is sealed again in a fresh envelope for that leg. MACsec never travels end to end. That is the first thing to get straight, because it decides everything else in this article: what MACsec protects (one link), what it costs (bytes on every MACsec link), and what it is not (a replacement for IPsec across a routed network).

What MACsec adds to every frame

A MACsec frame is easy to spot: it carries EtherType 0x88E5, the registered "this is a MACsec frame" marker, right where an ordinary frame would name IPv4 or IPv6. After that marker comes the SecTAG, then your original frame's payload — encrypted — then the ICV seal at the tail.

Keys come from MKA. The two devices start from a shared connectivity association key agreed in configuration, prove they both hold it, and derive short-lived session keys that actually encrypt the traffic — rotating them as packet numbers grow. You configure the shared secret and the policy; the per-frame keys look after themselves. And because the standard cipher suites are AES-GCM (an encryption method that produces the integrity check as part of encrypting), modern hardware does the work in the forwarding path: MACsec is a configuration and MTU problem far more often than a performance problem.

The 24-vs-32-byte argument, settled

Search for MACsec overhead and you will find confident sources saying 32 bytes and other confident sources saying 24. Both are right. They are counting different options:

The SecTAG is 8 or 16 bytes. Its base form is 8 bytes. If the sender includes the optional SCI — the explicit label naming the sending device and port — the SecTAG is 16. Cisco's Catalyst 9000 MACsec troubleshooting guide documents the SecTAG as 8 to 16 bytes for exactly this reason.

The ICV is 16 or 8 bytes. For the standard GCM-AES-128 and GCM-AES-256 cipher suites the integrity check value is 16 bytes. Suites with a truncated ICV use 8.

Add the parts and there are four real totals:

That is the whole mystery. When Cisco's IOS XR documentation says enabling MACsec adds 32 bytes, it is describing the default combination: SCI included, full 16-byte ICV. When Arista's MACsec white paper says MACsec adds 24 bytes (SecTAG + ICV), it is describing the no-explicit-SCI combination with the same full ICV. Cisco's own guide gives the full range in one line: maximum overhead 32 bytes, minimum 16. Nobody made an arithmetic error — they shipped different defaults.

What those bytes do to your MTU (the part that actually breaks things)

Overhead bytes are not free. They come out of the same fixed-size frame. On an ordinary 1500-byte link with the 32-byte default, the payload your network can actually carry drops to 1468 bytes — the exact figure Cisco's guides work from. For TCP, the MSS (maximum segment size: the largest chunk of data in one packet) to clamp is 1468 minus the 40 bytes of IPv4 + TCP headers: 1428.

It compounds when MACsec shares the link with other overhead. Put MACsec on a fabric link that also carries VXLAN (50 bytes of tunnel overhead — see our EVPN-VXLAN guide) and the stack is 82 bytes total: inner MTU 1418, MSS 1378. That is why vendor guidance strongly recommends jumbo frames when MACsec links carry overlay traffic — raising the link MTU gives the overhead somewhere to go instead of squeezing the payload.

Two rules keep you out of trouble. First, model the tightest link, do not add links together: if a path crosses two MACsec links, the end-to-end MTU is set by the worst single link, because MACsec is stripped and re-applied at each hop — you do not pay 32 bytes twice on one frame. Second, remember what happens when you ignore this entirely: large packets that no longer fit get fragmented or, worse, silently dropped when path MTU discovery is blocked — the classic "small pings work, real traffic hangs" blackhole. Our TCP internals guide covers why those hangs look the way they do.

The auto-MTU trap: did your platform already subtract it?

Here is the part that bites experienced engineers. Platforms disagree about who does the subtraction:

Cisco Catalyst 8500 does it for you: per Cisco's WAN MACsec guide, the interface MTU is automatically reduced by 32 bytes when MACsec is applied. Cisco IOS XR does not: its MACsec guide tells you to set the LSP MTU 32 bytes lower by hand. Juniper added an automatic adjustment in Junos OS 25.4 — a setting named enable-auto-mtu-update — but it is off by default, and Juniper's own release note says that without it, the interface and protocol MTU must be adjusted manually.

A vendor shipping an opt-in automatic fix for this exact arithmetic, in 2026 software, tells you how often operators still get it wrong. Get it wrong one way and traffic blackholes. Get it wrong the other way — subtracting 32 yourself on a platform that already subtracted it — and you waste capacity and confuse the next engineer. Check your platform's behaviour first; then subtract once, in exactly one place.

MACsec or IPsec? They protect different journeys

Newcomers often ask why both exist. IPsec protects traffic across a routed network: it wraps packets at Layer 3 and the protection survives every hop between the two tunnel endpoints. MACsec protects the physical link itself at Layer 2 — including traffic that never gets routed, like switch-to-switch control frames on that cable — and it ends at the next device. Use MACsec when the threat is the cable: shared facilities, carrier handoffs, links between buildings. Use IPsec when the threat is the path between sites. Serious designs often run both, each doing the job it is shaped for.

Five MACsec mistakes that cause real outages

1. Turning it on without touching MTU. The link comes up, handshakes pass, small packets flow — and full-size traffic blackholes. The 32 bytes have to come from somewhere.

2. Subtracting twice. You clamp MSS by 32 on a platform that already auto-reduced the interface MTU. Nothing breaks loudly; you just ship smaller packets forever.

3. Assuming end-to-end protection. MACsec on one link says nothing about the next link. Audit every cable you actually care about.

4. Quoting "24 bytes" from a white paper against a 32-byte default. Now you know why both numbers exist: check whether your SecTAG carries the SCI and which ICV your cipher suite uses, then budget that total in the MTU/MSS calculator — it now includes a MACsec layer, so add MACsec to your stack there and pick the SCI and ICV options that match your link instead of subtracting by hand.

5. Forgetting stacked overhead. MACsec plus VXLAN is 82 bytes, not 32. Jumbo frames on fabric and DCI links are not a luxury once encryption moves to the link layer.