IPNET

MACsec (802.1AE) Fundamentals

Layer 2 link encryption with IEEE 802.1AE: CAK and CKN, MKA key agreement, key-server election, SAK rotation, and IOS-XR configuration.

3 min read Security

Key Takeaways

  • MACsec (IEEE 802.1AE) encrypts traffic at Layer 2, hop-by-hop on a single link — every frame crossing that physical or logical link is encrypted and integrity-checked, regardless of what's inside it (IP, MPLS, whatever). This is a different scope than IPsec, which encrypts at Layer 3 and typically protects an end-to-end path across multiple hops rather than one link.
  • Two devices agree on encryption keys using MKA (MACsec Key Agreement), which runs on top of a pre-shared secret — the CAK (Connectivity Association Key), identified by a CKN (Connectivity Association Key Name) — configured identically on both ends.
  • MKA elects one side as the key server (lower priority value wins) and that device is responsible for generating and distributing the actual per-session encryption key, the SAK (Secure Association Key), and rotating it periodically.
  • Every frame gets an ICV (Integrity Check Value) — if it doesn't check out on the receiving end, the frame is silently dropped. This protects against both eavesdropping and tampering/injection on the link.
  • Because it operates purely at Layer 2, MACsec is transparent to everything above it — routing protocols, MPLS labels, EVPN control-plane traffic, all of it rides inside the encrypted link without any awareness that MACsec is there.

Prerequisites

Basic familiarity with Ethernet framing and the distinction between Layer 2 and Layer 3 security scope.

Why MACsec, and How It Differs From IPsec

IPsec protects an end-to-end path — the encrypted tunnel can cross many routers, and only the two tunnel endpoints need to understand it. That's the right tool when you need to protect traffic across a network you don't fully control (the public internet, a third-party WAN).

MACsec protects one link — the physical connection (or logical, e.g. a bundle member) between two directly adjacent devices. Every device along a multi-hop path would need its own MACsec session with its neighbor for end-to-end link-level encryption. This is the right tool when the concern is physical access to the wire itself: a fiber tap between your router and the next hop, an untrusted cross-connect in a shared facility, or compliance requirements that mandate encryption on specific physical links (common on provider backbone links and cross-datacenter interconnects).

Because MACsec sits below the network layer, it has no visibility into and no effect on what's actually being carried — an EVPN/SR-MPLS core, as covered in the SR-MPLS Fundamentals article, can run entirely unmodified over MACsec-protected links; the encryption is invisible to it.

Key Concepts

CAK (Connectivity Association Key): the primary shared secret, configured identically on both ends of the link — this is the pre-shared key everything else derives from.

CKN (Connectivity Association Key Name): an identifier paired with the CAK, so both sides agree they're using the same keying material.

MKA (MACsec Key Agreement): the protocol that runs continuously between the two link partners once they've authenticated with each other using the CAK/CKN. MKA handles electing the key server, generating and distributing the SAK, and rekeying on a schedule.

Key server election: whichever peer is configured with the lower key-server priority value wins and becomes responsible for generating the SAK.

SAK (Secure Association Key): the actual key used to encrypt frames on the wire for a given session. This is what MKA rotates periodically (the rekey interval) to limit how much traffic is ever encrypted under one key.

ICV (Integrity Check Value): appended to every MACsec frame; the receiving side recomputes and compares it, dropping any frame that fails the check.

Configuration (Cisco IOS-XR)

Define the pre-shared key material in a key chain:

key chain mac_chain
 macsec
  key 1234abcd5678
   key-string 12345678123456781234567812345678 cryptographic-algorithm AES-128-CMAC
   lifetime 05:00:00 01 January 2026 infinite

Define a MACsec policy — cipher suite, whether the link must be encrypted or may fall back to cleartext, and key-server priority:

macsec-policy mac_policy
 cipher-suite GCM-AES-XPN-256
 key-server-priority 0
 security-policy must-secure
 window-size 64

Apply the keychain and policy to an interface:

interface HundredGigE 0/5/0/16
 macsec psk-keychain mac_chain policy mac_policy

security-policy must-secure means the interface will not pass traffic at all until a MACsec session is successfully established — appropriate once you've confirmed both ends are configured correctly, but worth testing with a more permissive setting first on a link you can't afford to take down.

Verification

show macsec mka summary

Confirms whether MKA has successfully established a session on each MACsec-enabled interface.

show macsec mka session

Shows session-level detail: which side is the key server, current SAK status, and peer identity.

show macsec mka interface detail

Per-interface detail, useful when one specific link isn't coming up.

Troubleshooting

  • MKA session never establishes: almost always a CAK/CKN mismatch between the two ends — they must be configured identically. Double-check both the key string and the key ID.
  • Session establishes but traffic doesn't pass: check the security-policy setting — must-secure blocks all traffic until MACsec is fully up, so if there's a transient MKA issue the link will appear completely down rather than degraded.
  • Interface flaps after a rekey: confirm both sides are running compatible cipher suites and that the rekey interval isn't set aggressively low for the platform's capabilities.

Segment Routing (SR-MPLS) Fundamentals and EVPN Multi-Homing over SR-MPLS — both describe control- and data-plane behavior that can run, unmodified, over MACsec-encrypted links.