ENTERPRISE LINK SECURITY · 29 OCTOBER 2026

MACsec on campus uplinks: a commissioning worksheet

A fiber uplink can be physically separate from the public internet and still cross shared risers, outdoor pathways, provider handoffs or rooms controlled by different teams. MACsec protects Ethernet frames on supported links, but only when both peers, keys, cipher suite, MTU, fail behavior and recovery are commissioned together.

Visual reference photographs

Know what MACsec protects

IEEE 802.1AE defines media access control security for confidentiality, frame integrity and data-origin authenticity. MACsec operates at the Ethernet layer and is normally applied between directly connected MACsec peers or across a supported carrier service that transparently transports the required control traffic.

It does not replace endpoint security, network access control, firewalling, IPsec or application encryption. It also does not automatically protect an entire routed path. Map every hop and identify where frames enter and leave a secured channel.

Select the exact link and enforcement boundary

Common campus cases include building-to-building fiber, distribution-to-core uplinks, data-center interconnects and sensitive links through shared pathways. Cisco also documents host-to-switch and WAN use cases on supported platforms. Confirm that the exact switch model, line card, port type, optic, speed and software release support the required MACsec mode and cipher.

Some platforms encrypt only on specific hardware ports or speeds. Others have feature interactions with stacking, link aggregation, tunneling, quality of service or telemetry. Check both ends, not only the newer switch.

Choose MKA and key ownership deliberately

MACsec Key Agreement, or MKA, discovers authenticated peers, negotiates capabilities, elects a key server and distributes Secure Association Keys. A deployment may use pre-shared Connectivity Association Keys or keys derived from an 802.1X authentication workflow, depending on the platform and architecture.

With static pre-shared keys, the CAK and CKN must match on both peers. Juniper recommends using the full supported key length rather than leaving unspecified digits that default to zero. Store secrets in an approved system, restrict configuration access and never place live keys in drawings, screenshots or general handover documents.

Decide fail-closed or fallback behavior

A secured link needs an explicit behavior when MKA is not established. Aruba documents modes comparable to must-secure, which blocks data until protection exists, and should-secure, which can allow unprotected forwarding. The names and details vary by vendor.

For a confidentiality requirement, silent fallback can defeat the design. Prefer fail-closed where the business requirement and recovery plan support it. If availability demands controlled fallback, document exactly which traffic can pass, how operators are alerted and how long the exception may remain.

Account for frame overhead and MTU

Cisco documents up to 32 bytes of added MACsec overhead and warns that an undersized system or interface MTU can cause unexpected packet loss or delay for large packets. Determine how the selected platform counts MTU and whether every intermediate service can carry the protected frame size.

Do not assume that a successful ping proves MTU. Test the largest intended IP packet with fragmentation prohibited where applicable, then verify application traffic. Include VLAN tags, QinQ, overlays or provider encapsulation in the path calculation when used.

Set the cipher suite and replay policy

Both peers must support and negotiate the intended cipher suite. Record whether encryption and integrity are both enabled, key length, packet-number mode and any extended packet numbering support. Avoid copying a policy from a different platform without confirming hardware and release capability.

Replay protection checks packet numbers and can drop frames outside the accepted window. Juniper and Aruba document configurable replay behavior on supported devices. A window that is too strict can affect paths with legitimate reordering, while disabling protection weakens the design. Measure the real link and set a justified policy.

Commission one direction and both peers

Before enabling MACsec, verify ordinary link stability, optic levels, errors, VLANs, spanning-tree role, routing adjacency and application reachability. Save baseline counters. Stage matching peer configuration with rollback access available through an independent management path.

After activation, confirm both peers are live MKA participants, agree on the connectivity association and cipher, identify the elected key server and show active secured transmit and receive associations. Check encrypted and validated packet counters in both directions. An interface that is physically up is not proof of a secured channel.

Prove that clear traffic is not accepted

Under an approved maintenance test, remove or invalidate the peer policy on one side and observe the designed result. A must-secure link should stop protected data rather than continue in clear text. Confirm that the event produces a usable alarm with device, port, peer and reason.

Restore the matching policy and measure recovery time from MKA establishment through routing adjacency and application restoration. Do not perform uncontrolled key mismatch tests on links without out-of-band access.

Test rekey without an application outage

MKA periodically creates and distributes new Secure Association Keys. Cisco documents key-server election and rekey responsibilities, while Juniper describes key rollover and high-availability considerations. Observe at least one normal rekey or perform a vendor-supported rotation test.

Include redundant links and device failover

Each member of a port channel or redundant path may have its own secure-channel state. Verify the vendor's supported design before applying MACsec to aggregated links. Test member loss, port-channel failover, switch stack or chassis switchover and restoration.

Juniper documents special suspension behavior for some graceful Routing Engine switchovers. This shows why ordinary routing high availability does not automatically guarantee uninterrupted MACsec. Validate the exact platform pair and software release.

Monitor the secure channel through its lifecycle

Collect MKA participant state, key-server identity, active and pending associations, cipher, packet numbers, validated frames, encrypted frames, replay drops, integrity failures and policy violations. Alert on unsecured fallback, peer loss, repeated rekey failure and counters that increase unexpectedly.

Link the MACsec record to optic baselines, interface errors and route monitoring. Encryption does not hide a dirty connector, optical margin problem, congestion or loop. It adds another state that operations teams must diagnose without exposing keys.

Commissioning worksheet

1. The business reason and protection boundary are documented.
2. Every hop and clear-text transition point is mapped.
3. Both platforms, ports, optics, speeds and releases support the design.
4. The selected MKA and key method is approved.
5. CAK values remain in a controlled secret store, not the handover pack.
6. Connectivity association names and CKN references match.
7. The cipher suite and packet-number mode match.
8. Fail-closed or controlled fallback behavior is explicit.
9. MTU includes MACsec and other encapsulation overhead.
10. Replay protection and its window are justified.
11. Baseline link, optic, VLAN, routing and application state is saved.
12. Both MKA peers and the elected key server are verified.
13. Secured transmit and receive associations are active.
14. Encryption, validation and error counters are captured.
15. A controlled peer or key failure produces the intended forwarding result and alarm.
16. Normal rekey completes without unacceptable interruption.
17. Redundant-member and device failover are tested where included.
18. Recovery, monitoring, rotation and emergency rollback enter the handover pack.

Minimum handover pack

Provide the link and trust-boundary diagram, platform support evidence, port and optic schedule, MKA and cipher policy, secret-free key register, MTU calculation, replay policy, baseline counters, peer and secure-association evidence, large-frame results, controlled failure and rekey results, redundancy tests, monitoring thresholds, key-rotation procedure and rollback plan. Link this to the optical uplink worksheet, switch redundancy worksheet and wired NAC worksheet.

Primary technical references

• IEEE 802.1AE-2018: MAC Security
• IEEE P802.1AE project
• Cisco: Troubleshoot MACsec on Catalyst 9000
• Cisco: MACsec encryption configuration
• Juniper: Configuring MACsec
• Juniper: Advanced MACsec features
• HPE Aruba Networking: AOS-CX MACsec policy reference