MACsec encryption over 800G trunks on OXP2-K9 line card | MACsec Encryption on NCS1K14-OXP2-K9 Line Card | Configuration Guide for Cisco NCS 1014, IOS XR Releases 26.x.x

Describes the Media Access Control Security (MACsec) encryption feature for 800G trunk interfaces on the NCS1K14-OXP2-K9 line card, including release information, protection behavior, and configuration scope.

This chapter explains how to configure and verify MACsec encryption on Cisco NCS 1014 systems that use the NCS1K14-OXP2-K9 line card for 800G trunk interfaces.

Table 1. Feature history
Feature name	Release information	Feature description
MACsec encryption on the OXP2-K9 line card	Cisco IOS XR Release 26.3.1	You can now configure MACsec on the NCS1K14-OXP2-K9 line card, enabling robust Layer 2 encryption directly on 800G trunk interfaces. Based on the IEEE 802.1AE standard, this feature secures your data through AES-GCM encryption, frame integrity checks, and strict replay protection. This capability allows you to deploy high-performance, hop-by-hop security that protects your 800G DWDM links from interception and tampering without sacrificing throughput. It ensures your critical data remains secure across physical topologies, providing a seamless balance of high-capacity transport and enterprise-grade security.

MACsec encryption over 800G trunks

MACsec encryption on the OXP2-K9 line card is a Layer 2 security feature that protects 800G Ethernet traffic on trunk interfaces. MACsec secures each hop between directly connected MACsec peers and helps protect traffic from unauthorized access, frame modification, and replay attacks.

The MACsec Key Agreement (MKA) control plane authenticates the connected peers and negotiates the Secure Association Keys (SAKs). After the MKA session is secured, the data plane uses the active SAK to encrypt outbound frames and to validate and decrypt inbound frames in hardware on the line card.

On the OXP2-K9 line card, MACsec is configured on EightHundredGigECtrlr controllers after the 800G client service, AppSel code, optical frequency, MACsec key material, and MACsec policy are provisioned.

Protection model

MACsec provides the following protection functions for 800G trunk traffic:

Data confidentiality: Encrypts the Ethernet payload by using Advanced Encryption Standard-Galois/Counter Mode (AES-GCM).
Data integrity and authenticity: Adds an Integrity Check Value (ICV) to protected frames so that modified frames are discarded by the receiving controller.
Replay protection: Uses packet numbers to detect frames that arrive outside the configured replay-protection window.

Configuration scope

A complete OXP2-K9 MACsec configuration includes the 800G controller readiness configuration, MKA authentication method, MACsec policy, controller MACsec enablement, and verification steps.

Table 2. MACsec configuration scope
Configuration area	Purpose
800G controller readiness	Configures the muxponder slice, AppSel code, frequency, and controller state required before MACsec is enabled on the trunk.
MKA authentication	Authenticates MACsec peers by using preshared keys or EAP-TLS with local certificate validation or remote RADIUS/AAA validation.
MACsec policy	Defines cipher suite, confidentiality offset, replay protection, window size, and key-server behavior.
Controller enablement	Applies the MACsec policy and authentication profile to the EightHundredGigECtrlr controller.
Verification and statistics	Confirms that the MKA session is secured, the Secure Channel Identifier (SCI) is installed, encrypted and decrypted counters increase, and MACsec error counters remain stable.

MACsec key concepts

Use these concepts to understand the MACsec configuration elements before you configure keychains, policies, and controllers.

Certificate enrollment and authentication scope

For EAP-TLS, the SCEP enrollment server location is separate from the EAP-TLS authentication method. A router can enroll its CA certificate and identity certificate from a local SCEP server or from a remote SCEP server. After enrollment, the authentication method determines where the peer certificate is validated and where the Master Session Key (MSK) is generated.

Table 3. SCEP and EAP-TLS distinction
Term	What it means	What it does not mean
Local SCEP server	The SCEP enrollment endpoint is hosted in the local lab, site, or management network.	It does not determine whether EAP-TLS authentication is local or remote.
Remote SCEP server	The SCEP enrollment endpoint is hosted in a remote or centralized PKI network and is reachable from the router.	It does not require remote RADIUS/AAA authentication. The router can still use local EAP-TLS authentication after enrolling from a remote SCEP server.
Local EAP-TLS authentication	The router validates the peer certificate locally by using the CA certificate installed in the local trustpoint and generates the MSK locally.	It does not mean that the SCEP server must be local.
Remote EAP-TLS authentication	The router forwards EAP-TLS authentication to a RADIUS/AAA server, and the RADIUS/AAA server validates the peer certificate and returns the MSK.	It is not the same concept as remote SCEP enrollment.

Table 4. MACsec authentication methods
Method	What it uses	Operational notes
Pre-shared key	A MACsec keychain that contains the CKN, CAK, MKA cryptographic algorithm, and key lifetime.	Use matching keychain values on both peers. This chapter provides PSK configuration tasks because the source MOP includes complete PSK command sequences.
Local Extensible Authentication Protocol-Transport Layer Security (EAP-TLS)	802.1X, certificates, a CA trustpoint, an EAP profile, and MKA. The router validates the peer certificate locally and generates the Master Session Key (MSK).	In local EAP-TLS authentication, the router acts as both authenticator and authentication server. The router verifies the peer certificate against the local CA trustpoint and does not require AAA server authentication configuration. The SCEP enrollment server used by the trustpoint can be local or remote.
Remote EAP-TLS authentication with RADIUS/AAA	802.1X, certificates, an EAP profile, RADIUS server configuration, AAA dot1x authentication, and MKA. The RADIUS server validates the peer certificate and returns the MSK to the router.	In remote EAP-TLS authentication, the router acts as a pass-through authenticator. The router forwards EAP messages to the RADIUS server, receives the MSK in the RADIUS Access-Accept response, and passes the MSK to MKA so that MKA can derive SAKs for MACsec data protection. This authentication method is independent of whether the certificate was enrolled from a local SCEP server or remote SCEP server.

Remote EAP-TLS key flow

Remote EAP-TLS centralizes certificate validation and key authorization on a RADIUS/AAA server. The OXP2-K9 controller still runs 802.1X and MKA locally, but the authentication decision and MSK generation come from the remote AAA infrastructure.

Table 5. Remote EAP-TLS key flow
Stage	Component	Key concept
Peer authentication	802.1X authenticator on the router and remote RADIUS server.	The router forwards the EAP-TLS certificate exchange to the RADIUS server for validation.
MSK generation	RADIUS/AAA server.	The RADIUS server generates the Master Session Key after successful EAP-TLS authentication and returns it to the router.
MKA key derivation	MKA process on the OXP2-K9 controller.	MKA uses the MSK to derive SAKs and install them for MACsec encryption and decryption.
Data protection	MACsec hardware on the line card.	The active SAK protects traffic on the 800G trunk by encrypting outbound frames and validating inbound frames.

Use Remote EAP-TLS authentication with RADIUS/AAA for the complete remote authentication flow and operational behavior.

Table 6. MACsec keychain elements
Element	What it is	Used for
Connectivity Association Key Name (CKN)	A public key identifier configured with the key command. The value must contain an even number of hexadecimal characters.	Identifying the key that both connected ports use for MKA negotiation.
Connectivity Association Key (CAK)	A secret key configured with the key-string clear command.	Deriving SAKs that the MACsec hardware uses to encrypt and decrypt data.
Cryptographic algorithm	The MKA control-plane protection algorithm. The aes-256-cmac option uses a 64-character hexadecimal key string. The aes-128-cmac option uses a 32-character hexadecimal key string.	Generating the Integrity Check Key (ICK) and the Key Encrypting Key (KEK). The ICK is responsible for verifying the integrity of MKA control packets, ensuring they have not been tampered with. The KEK, on the other hand, encrypts the SAK during its distribution between peers. It is essential that both peers utilize the same algorithm for these processes.
Lifetime	A validity timer that defines when the key starts and when it expires.	Controlling when a key becomes active for MACsec negotiation.
Secure Association Key (SAK)	A hardware data encryption key derived after MKA authenticates the peer.	Encrypting transmitted frames and decrypting received frames on a secure channel.

Table 7. MACsec policy parameters
Parameter	Default or supported value	Purpose
Cipher suite	GCM-AES-XPN-256 by default. GCM-AES-XPN-128 is also supported.	Defines the data encryption strength and extended packet numbering behavior.
Confidentiality offset	CONF-OFFSET-0	Encrypts the complete payload without leaving cleartext bytes for bypass.
Security policy	must-secure	Drops traffic that is not protected by an established MACsec session.
SAK rekey interval	3600 seconds is recommended for production deployments.	Controls how often the key server generates a new SAK.
Key server priority	0 to 255. The lower value has higher preference. The default is 16.	Determines the MACsec peer that generates and distributes SAKs. If both peers use the default priority, the peer with the lowest Secure Channel Identifier (SCI) becomes the key server.

Fallback keychain

A fallback keychain is a backup MACsec keychain that the controller can use when the primary keychain cannot establish or maintain a session. Configure a fallback keychain when you need session recovery for primary key expiration, key mismatch, or planned key maintenance.

Guidelines for MACsec encryption on OXP2-K9 line card

800G service readiness

Provision the 800G client service, AppSel code, and optical frequency before you enable MACsec on the EightHundredGigECtrlr controller.

Verify that the OXP2-K9 line card and 800G pluggable optics are present in inventory.
Confirm that the FPD status for the line card and optics is current before you configure the service.
Configure only an AppSel ID that is advertised as supported and that matches the 800GE client service. AppSel IDs 39 and 40 are recommended in the source notes for Release 26.3.1 EFT use.

Use this guidance before configuring MACsec on an OXP2-K9 controller that carries 800G traffic.

The 800G traffic path must be provisioned before MACsec can secure traffic. If AppSel is missing, the system can report a mandatory configuration missing alarm and keep the trunk laser off.

The controller is ready for MACsec configuration and can establish the MKA session after both endpoints are configured.

If the session remains in the Init state, verify the 800G service, AppSel configuration, optical frequency, and peer MACsec configuration.

Keychain and policy selection

Use independent keychains for each controller and a consistent MACsec policy on both endpoints.

Use aes-256-cmac with a 64-character hexadecimal CAK for maximum security on 400G and 800G links.
Use must-secure when unencrypted traffic must be dropped until the MACsec session is secured.
Set an explicit key server priority when you need deterministic key server selection.

Use this guidance when you configure primary MACsec keychains and policies for production links.

Independent keychains limit the effect of key changes to a single controller. A consistent policy reduces unexpected negotiation differences between peers.

The MACsec peers negotiate a common MKA and data-plane encryption policy.

If the peer cannot negotiate a session, compare the CKN, CAK, cryptographic algorithm, lifetime, cipher suite, and security policy on both endpoints.

Fallback keychain lifetime

Configure a fallback keychain with a lifetime that starts at the same time as, or overlaps with, the primary keychain lifetime.

Use an infinite end lifetime for the fallback key when the operational policy allows it.
Verify both the primary and fallback sessions with show macsec mka summary after you apply the fallback keychain.

Use this guidance when traffic must remain secured during primary key maintenance or primary key failure.

Overlapping lifetimes allow the controller to use the fallback keychain when the primary keychain expires, is deleted, or does not match the peer.

The link can maintain secured MACsec traffic while operators correct the primary keychain.

If the MKA-NO-ACTIVE-PSK alarm is raised, verify that the active key lifetime has started and has not expired.