Hands-On Lab: Configuring MACsec Layer 2 Encryption

This hands-on lab configures MACsec on a switch-to-switch link to encrypt all Layer 2 traffic crossing it, verifying frames are genuinely encrypted in transit and that a mismatched key prevents the link from passing traffic at all.

MACsec Link EncryptionCAK Pre-Shared Key802.1AE Frame Protection

~4 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

Lab Objective

Configure MACsec on the link between two switches using a manually configured pre-shared key, verify frames traversing the link are encrypted, and confirm a key mismatch prevents the link from establishing a MACsec session at all.

Lab Purpose

IPsec, covered extensively earlier in this series, encrypts Layer 3 traffic between routers. MACsec instead operates at Layer 2, encrypting every frame on a specific link (including frames from higher-layer protocols like ARP that IPsec would never see), making it suited to protecting traffic on a physical link itself — a data center interconnect or a campus backbone link, for instance — regardless of what Layer 3 traffic rides on top of it.

Lab Topology

Switch1 ---- Gi1/0/24 (link to be MACsec-protected) ---- Gi1/0/24 ---- Switch2

Task 1: Verify Normal Unencrypted Connectivity

Confirm the link passes traffic normally before MACsec is configured.

Task 2: Configure a MACsec Key Chain

Configure a key chain containing the Connectivity Association Key (CAK) on both switches.

Task 3: Enable MACsec on the Interface

Apply MACsec protection to the link interface on both switches, referencing the key chain.

Task 4: Verify the MACsec Session Establishes and Frames Are Encrypted

Confirm the MACsec session is active and examine interface statistics confirming encryption is occurring.

Task 5: Introduce a Key Mismatch and Verify the Link Fails

Change Switch2's key to a different value and confirm the link can no longer pass traffic.

Solution and Verification

Switch1# ping [Switch2's management address]

!!!!!
Success rate is 100 percent (5/5)
-- Normal connectivity confirmed before
-- MACsec is applied

Switch1(config)# key chain MACSEC-KEYS macsec
Switch1(config-keychain-macsec)# key 01
Switch1(config-keychain-macsec-key)# cryptographic-algorithm aes-128-cmac
Switch1(config-keychain-macsec-key)# key-string 0123456789ABCDEF0123456789ABCDEF

Switch2(config)# key chain MACSEC-KEYS macsec
Switch2(config-keychain-macsec)# key 01
Switch2(config-keychain-macsec-key)# cryptographic-algorithm aes-128-cmac
Switch2(config-keychain-macsec-key)# key-string 0123456789ABCDEF0123456789ABCDEF

Switch1(config)# interface gigabitethernet1/0/24
Switch1(config-if)# mka policy default
Switch1(config-if)# mka pre-shared-key key-chain MACSEC-KEYS
Switch1(config-if)# macsec

Switch2(config)# interface gigabitethernet1/0/24
Switch2(config-if)# mka policy default
Switch2(config-if)# mka pre-shared-key key-chain MACSEC-KEYS
Switch2(config-if)# macsec

-- MKA (MACsec Key Agreement) is the
-- protocol that establishes and maintains
-- the actual encryption session using the
-- shared CAK from the key chain

Switch1# show macsec interface gigabitethernet1/0/24

MACsec Status: Secured
Capabilities:
  Cipher: GCM-AES-128
Transmit Secure Channels
  Cipher: GCM-AES-128
  Encrypt: Enabled
-- "Secured" confirms an active MACsec
-- session, with encryption explicitly
-- enabled on the transmit channel

Switch1# show mka sessions

Interface  Local-TxSCI       Status    Key-Server
Gi1/0/24   [Switch1-MAC]/1   Secured   YES
-- MKA session confirmed secured --
-- underlying frames on this link are now
-- genuinely encrypted, not just passed as
-- plaintext with a policy label attached

Switch2(config)# key chain MACSEC-KEYS macsec
Switch2(config-keychain-macsec)# key 01
Switch2(config-keychain-macsec-key)# key-string FEDCBA9876543210FEDCBA9876543210

Switch1# show macsec interface gigabitethernet1/0/24

MACsec Status: Not Secured
-- The MACsec session failed to establish
-- once the keys diverged -- unlike a
-- simple authentication failure that might
-- still pass unencrypted traffic, MACsec
-- with a failed key exchange blocks the
-- link from passing traffic entirely

Switch1# ping [Switch2's management address]

.....
Success rate is 0 percent (0/5)
-- Complete connectivity loss, confirming
-- the link genuinely will not pass traffic
-- without a successfully negotiated
-- MACsec session

Key Takeaway

MACsec's default behavior when the MKA key exchange fails is to block the link entirely rather than fail open into unencrypted communication — this fail-secure design ensures a misconfigured or compromised key never silently degrades into passing unprotected traffic, but it also means a MACsec key mismatch produces total link failure rather than the more gradual symptoms typically seen with routing protocol authentication mismatches covered earlier in this series.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه