Encrypting a link at Layer 2 sounds like the simplest possible security control: two switches, one cable, everything between them protected. It is simple when the cable is yours. It stops being simple the moment the two switches are in different buildings and the thing between them belongs to somebody else, because the mechanism depends on a frame type that carrier equipment is specifically built to intercept.
The protection itself is unremarkable in the best way. Frames are encrypted and authenticated at line rate in hardware, the addressing stays visible so switching still works, and the performance cost is essentially zero on equipment that supports it. What requires thought is the key agreement, the failure behaviour, and whether the path between the two ends will carry what the key agreement needs.
This article covers what is actually encrypted and what remains visible, how the two ends agree on a key and who decides, how a switch-to-switch link is configured and rotated, what happens when the link crosses infrastructure you do not own, and the failures that take a link down completely rather than degrading it. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.
The addressing remains visible so that switching still works, the payload is encrypted per link rather than end to end, and the key agreement frames use an address that carrier equipment is designed to consume rather than forward.What Is Actually Encrypted, and Where?
What does a protected frame look like?
The source and destination addresses stay in clear, because the switches along the way still need them to forward. A security tag is inserted after them, carrying the association identifier and a packet number, also in clear. Everything from there onward — the type field, any tags, and the entire payload — is encrypted, and an integrity value is appended. The protection is per link: each switch decrypts on receipt and re-encrypts on transmission, so every device in the path sees the traffic unprotected.
A Deeper Dive into the Protected Frame
Why the addressing stays visible
A switch that cannot read the destination address cannot forward the frame. Encrypting it would require every device to decrypt before making a forwarding decision, which is the opposite of what a Layer 2 protection is for. Leaving it visible is what allows the encryption to happen at line rate in hardware with no forwarding penalty.
The consequence is that an observer on the link learns which devices are communicating and how much, even though they learn nothing about what. That is a real limitation and it is inherent to protecting at this layer rather than a weakness of this particular mechanism.
What the added fields cost
The security tag and the integrity value together add a few dozen bytes to every frame. On most switching platforms this is handled internally and requires nothing from the operator, because the hardware accounts for it before the frame is placed on the wire.
Where it does matter is a path with a constrained maximum frame size — a carrier service that permits exactly a standard frame and no more. The added bytes push a full-size frame over that limit and it is discarded, which produces the familiar symptom of small packets passing and large ones vanishing. Confirming the path's frame size allowance before deployment avoids it entirely.
Hop by hop, and what that implies
Each link is protected independently with its own key. A switch in the middle of a path decrypts what arrives and re-encrypts what leaves, which means it holds the traffic in clear internally. Anyone who controls that switch sees everything.
So this is protection of the wire rather than protection of the conversation. It defends against someone tapping a fibre, a patch panel in a shared riser, or a carrier's infrastructure. It defends against nothing that happens inside a switch you own, and it is not a substitute for protecting the application traffic itself where that is what the threat model requires.
What it is genuinely good for
Links leaving a building. A fibre between two campus buildings crossing ground you do not control, a data centre interconnect over dark fibre, a connection between a cage and a carrier's handover point. In all of those the wire is the exposure and this addresses exactly it, at line rate, with no application changes.
Inside a single controlled room it adds little and costs configuration and operational complexity. Deploying it everywhere because it is available produces a large number of key associations to manage for protection nobody needed.
The cipher choices
Two key lengths, and for each a variant with extended packet numbering. The extended variant exists because the packet number is what guarantees each frame is encrypted uniquely, and on a very fast link the ordinary number space is exhausted quickly enough that rekeying becomes frequent. The extended form makes that a non-issue.
On links of forty gigabits and above the extended variant is the right default. Below that either works, and the choice should be consistent across the estate so that a mismatch is never the cause of a link failing to secure.
| Part of the frame | Visible on the wire | Protected | Why |
|---|---|---|---|
| Destination and source address | Yes | Integrity only | Switches must forward it |
| Security tag | Yes | Integrity only | Carries the packet number |
| Type field and tags | No | Encrypted | — |
| Payload | No | Encrypted | — |
| Integrity value | Yes | Is the protection | Appended |
How Do the Two Ends Agree on a Key?
What is the process?
A key agreement protocol runs between the two ends over the link itself. Both start from a shared root key — either configured identically at both ends, or derived from an authentication exchange with a central server. From that root they derive keys that protect the agreement itself, elect one end as the key server, and that end generates and distributes the key which actually encrypts frames. That distributed key is replaced periodically and whenever the membership of the association changes.
A Deeper Dive into Key Agreement
The two ways to establish the root key
Configured at both ends, which suits switch-to-switch links where both devices are yours and there is no user to authenticate. Or derived from an authentication exchange, which suits a link to a host or to a device whose identity should be established centrally before any key exists.
The first is simpler and puts the burden on key distribution and rotation. The second removes that burden and adds a dependency on the authentication infrastructure being reachable at the moment the link comes up, which on an uplink is a dependency worth thinking about carefully.
! Downlink variant: the root key comes from the 802.1X exchange
! rather than from a key chain. No key to distribute or rotate.
SwA(config)# aaa new-model
SwA(config)# aaa authentication dot1x default group radius
SwA(config)# aaa authorization network default group radius
SwA(config)# dot1x system-auth-control
!
SwA(config)# interface GigabitEthernet1/0/12
SwA(config-if)# switchport mode access
SwA(config-if)# macsec
SwA(config-if)# mka default-policy
SwA(config-if)# access-session port-control auto
SwA(config-if)# dot1x pae authenticator
!
! The session, and where its key came from
SwA# show mka sessions interface GigabitEthernet1/0/12 detail | include CKN|Status
The key server election
One end generates the key that encrypts frames, and which end that is comes from a configured priority with the lower value winning. Where both ends have the same priority the election falls back to an identifier comparison, which is deterministic and arbitrary.
Setting the priority explicitly is worth doing, not because the outcome matters functionally but because knowing which end is the server makes the output readable. A session that is not securing is diagnosed differently depending on whether you are looking at the server or the other end.
The frames the agreement uses
The agreement runs over a well-known frame type sent to a reserved multicast destination address. Those frames are not encrypted — they cannot be, because they exist to establish the encryption — and they are protected by their own integrity mechanism derived from the root key.
That reserved address is the source of the carrier problem covered later. Bridges are specified to consume frames sent to it rather than forward them, which is correct behaviour for a bridge and fatal for a deployment that needs those frames to cross one.
! The shared root key, in a key chain
SwA(config)# key chain MACSEC-KC macsec
SwA(config-keychain)# key 01
SwA(config-keychain-key)# cryptographic-algorithm aes-128-cmac
SwA(config-keychain-key)# key-string <64-hex-character-key>
SwA(config-keychain-key)# lifetime local 00:00:00 Jan 1 2026 infinite
!
! Policy: who is key server, which cipher
SwA(config)# mka policy MACSEC-POL
SwA(config-mka-policy)# key-server priority 10
SwA(config-mka-policy)# macsec-cipher-suite gcm-aes-256
SwA(config-mka-policy)# confidentiality-offset 0
Rekeying, and why it happens
The frame-encrypting key is replaced on a schedule and whenever the set of participants changes. Replacement is transparent: the new key is distributed while the old one is still in use and the switchover happens without interrupting traffic.
A link that is rekeying visibly — with loss at each rekey — indicates a platform or software problem rather than a configuration one, and it is worth checking after any software upgrade on a link where this is deployed, because it is exactly the kind of behaviour that regresses quietly.
Rotating the root key
The root key is configured and therefore has to be changed by somebody. A key chain supports several keys with lifetimes, so a rotation is performed by adding the new key at both ends with a start time, letting both ends hold both keys through an overlap, and removing the old one afterwards.
The overlap is what makes it non-disruptive, and it depends on the two ends agreeing about the time. A rotation configured with lifetimes on devices whose clocks differ produces a window in which one end has moved to the new key and the other has not, which takes the link down.
How Is a Switch-to-Switch Link Configured?
What is the minimum?
A key chain holding the shared key, a policy naming the cipher and the key server priority, and three lines on the interface: declare the link as a network link, attach the policy, and reference the key chain. Both ends need matching keys and compatible policies. The link then secures on its own, and the useful verification is the session state rather than the interface state, which is up either way.
A Deeper Dive into the Configuration
The interface configuration
Three lines, applied identically at both ends apart from the key server priority. The declaration that this is a link between infrastructure devices rather than to a host changes which key agreement mode is used and is the line most often omitted on a first attempt.
! Both ends, identical apart from the policy's priority
SwA(config)# interface TenGigabitEthernet1/0/1
SwA(config-if)# description To SwB - protected
SwA(config-if)# switchport mode trunk
SwA(config-if)# macsec network-link
SwA(config-if)# mka policy MACSEC-POL
SwA(config-if)# mka pre-shared-key key-chain MACSEC-KC
!
! Replay protection - see below before choosing a value
SwA(config-if)# macsec replay-protection window-size 0
Verifying, which is not the interface state
The interface is up whenever the physical link is up, regardless of whether anything is encrypted. The session view is what says whether the agreement succeeded, which cipher was negotiated, which end is the key server and how many times the key has been replaced.
The statistics view is the complementary check: frames protected and validated should both be increasing. One increasing without the other means traffic is being protected in one direction and not verified in the other, which is a specific and unusual failure worth catching.
! Did it actually secure? The interface state does not say.
SwA# show mka sessions
Total MKA Sessions....... 1
Secured Sessions... 1
Pending Sessions... 0
!
Interface Local-TxSCI Policy-Name Inherited Key-Server
Te1/0/1 0035.1a2b.3c01/0001 MACSEC-POL NO YES
!
SwA# show mka sessions detail | include Status|Cipher|Key Server|SAK
Status.......... Secured
Cipher Suite.... GCM-AES-256
Key Server...... Yes
Latest SAK AN... 1
! And the data plane counters, both directions
SwA# show macsec interface TenGigabitEthernet1/0/1 | include Secure|Protected|Validated
OutPktsProtected: 0
OutPktsEncrypted: 18405212
InPktsValidated: 0
InPktsDecrypted: 18399104
!
SwA# show mka statistics | include Failure|Invalid|Mismatch
Replay protection and the window
Each frame carries a packet number and the receiver can reject frames that arrive out of order beyond a configured tolerance. With the tolerance set to zero, frames must arrive in strict order, which is correct on a direct link and wrong on a path that reorders.
Paths reorder more often than expected: an aggregated link, a carrier service that load-balances internally, or equipment that queues differently per class. A window of a few dozen frames absorbs ordinary reordering with negligible security cost, and it is the right setting on anything other than a direct point-to-point fibre.
The failure behaviour, which is the real decision
Two options and they are not close in consequence. Requiring protection means that if the agreement fails, the link does not pass traffic at all. Preferring protection means that if it fails, traffic passes unencrypted and nothing obvious indicates it.
The first is correct for a link whose whole purpose is to be protected, and it converts any key problem into an outage. The second keeps the network running and delivers, at the worst moment, exactly the exposure the deployment existed to prevent, without telling anybody.
The defensible position is to require protection and to monitor the session state, so that a failure is an outage with an obvious cause rather than a silent loss of protection. That is a decision to take with the business rather than a default to accept.
! Require protection: the link is down if it cannot secure
SwA(config)# interface TenGigabitEthernet1/0/1
SwA(config-if)# macsec access-control must-secure
!
! Monitor the session, because now its failure is an outage
SwA# show mka sessions | include Secured Sessions
SwA# show mka summary
Bringing an existing link into the deployment
A live link cannot be converted without an interruption, because the two ends must both have the configuration before either can secure and the moment between them is a mismatch. The workable approach is to apply the configuration to both ends in the same maintenance window, with the console available, and to verify the session before the window closes.
On an aggregated link the interruption can be avoided by converting one member at a time, provided the platform supports protection on individual members. That is worth confirming for the specific platform and software before planning around it.
What to check before the window
Both platforms support the chosen cipher. Both run software versions where the feature is supported on the specific ports involved — support often differs between port groups on the same switch. The path permits the larger frame size. And the clocks are synchronised, because key lifetimes depend on them.
Each of those has taken a maintenance window from somebody, and all four are answerable in advance from documentation and from the devices themselves. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.
show mka sessions shows the session as pending rather than secured, or shows no session at all. Fix: compare the cipher and key on both ends and confirm both declare the interface as a network link; and stop treating interface state as evidence that a protected link is protected.What Happens When the Link Crosses Something You Do Not Own?
Why is that different?
The key agreement runs over frames sent to a reserved multicast address, and bridges are specified to consume frames sent to that address rather than forward them. A carrier's Ethernet service is built from bridges. So the agreement frames are absorbed somewhere in the middle, neither end hears the other, and no key is ever established — on a link that otherwise passes traffic perfectly. This is the single most common reason a deployment fails between sites.
A Deeper Dive into the Carrier Problem
Why the address is consumed
The reserved range exists for protocols that must not cross a bridge: spanning tree, authentication, link discovery. Consuming rather than forwarding is not a carrier being unhelpful, it is the specified behaviour of a bridge, and the carrier's equipment is doing exactly what it should.
That means the problem cannot be fixed by complaining about it. It is fixed either by the carrier configuring the service to tunnel that traffic transparently, or by both ends using a different destination address that the carrier's equipment will forward.
The first fix: ask the carrier
Carrier Ethernet services commonly offer transparent forwarding of reserved-address protocols as an option, sometimes as a chargeable feature and sometimes simply as a configuration the provisioning team can apply. It is worth asking for explicitly, by naming the protocol rather than describing the symptom, because the service desk will otherwise test reachability, find it works, and close the case.
Where they can do it, this is the better fix, because both ends keep the standard configuration and nothing unusual has to be maintained.
The second fix: change the address
Both ends can be configured to send the agreement frames to a different destination — the broadcast address, or another address the carrier is known to forward. This works without the carrier changing anything and it requires both ends to be configured identically, because an address mismatch means the frames are sent somewhere the other end is not listening.
It is a workaround rather than a correction, and it should be recorded prominently in the link's documentation. An engineer replacing one of the two switches from the standard template will restore the default address and the link will stop securing for no visible reason.
! Both ends, identically, when the carrier consumes the default
SwA(config)# interface TenGigabitEthernet1/0/1
SwA(config-if)# eapol destination-address broadcast-address
!
! Confirm the frames are now being exchanged
SwA# show mka statistics | include MKPDU|Transmitted|Received
MKPDUs Transmitted... 4821
MKPDUs Validated Rx.. 4819
The frame size question, again
A carrier service that permits exactly a standard frame does not have room for the added fields. Full-size frames are discarded and smaller ones pass, producing the classic selective failure.
The ask is straightforward and should be made at the same time as the protocol forwarding request: a frame size allowance that accommodates the additional bytes. Most services support this and it is usually a provisioning setting rather than a commercial change.
Reordering across the service
Carrier services frequently load-balance internally across multiple paths, which reorders frames in a way a direct fibre does not. With strict ordering required, reordered frames are discarded as replays and the link exhibits loss that correlates with traffic volume and with nothing else.
A reordering tolerance of a few dozen frames resolves it. This is the specific setting most worth changing from its default when the link crosses a service rather than a cable.
! Across a carrier: allow for internal reordering
SwA(config)# interface TenGigabitEthernet1/0/1
SwA(config-if)# macsec replay-protection window-size 64
!
! Frames discarded as out-of-order replays
SwA# show macsec interface TenGigabitEthernet1/0/1 | include Late|NotValid|Delayed
What to ask for, in one list
Three things, asked together, before the link is ordered rather than after it fails. Transparent forwarding of the authentication protocol frames. A frame size allowance above the standard maximum. And confirmation of whether the service reorders frames, which determines the tolerance setting.
Asking all three at ordering time costs nothing and removes the most common causes of a deployment that works on a bench and not in production.
| Symptom over a carrier | Cause | Ask for, or configure |
|---|---|---|
| Session never establishes | Agreement frames consumed | Transparent forwarding, or a different address |
| Large frames lost, small ones fine | No room for the added fields | A larger frame size allowance |
| Loss proportional to traffic | Internal reordering | A reordering tolerance |
| Works, then fails after a carrier change | The service was reprovisioned | Document the requirement on the circuit |
Which Failures Take the Link Down Entirely?
What should be anticipated?
Four. A key rotation where the two ends moved at different times because their clocks differ. A software upgrade after which the feature is not supported on that port group, or behaves differently. A configuration restored from a template that lost a non-default setting the link depended on. And the required-protection setting turning any of the above from a degradation into a complete outage. Every one of them is a link that was stable for months.
A Deeper Dive into the Failure Catalogue
Clock divergence during rotation
Covered earlier and worth repeating because it is the most likely scheduled outage this technology produces. Key lifetimes are evaluated against each device's own clock. Devices whose clocks differ by more than the overlap will, for a period, be offering and expecting different keys.
The prevention is an authenticated time source on both ends and an overlap generous enough to absorb anything reasonable. Rotations should also be scheduled during a window rather than at an arbitrary time, so that if it does go wrong somebody is watching.
Software upgrades
Support for this feature varies by platform, by port group within a platform, and by software version. An upgrade that changes any of those can leave a link that worked unable to secure, and with protection required that means the link is down at the end of the upgrade.
The check belongs in the upgrade plan: confirm the feature remains supported on the specific ports involved in the target version, and verify the session state as part of the post-upgrade validation rather than only checking that the interfaces came up.
Configuration restored from a template
Links crossing a carrier often carry non-default settings — a different agreement frame address, a reordering tolerance. A switch replaced or restored from the standard template loses them, and the link will not secure for a reason that is invisible in a comparison against the standard because the standard is what it now matches.
The defence is documentation attached to the link rather than to the device, and ideally a comment in the configuration itself explaining why the setting is non-default. A setting with no explanation will be normalised by somebody eventually.
The interaction with link aggregation
Protection is applied per physical member. An aggregated link where one member secures and another does not produces traffic that is protected or not depending on which member it hashed to, which is difficult to observe and worse than either outcome consistently.
Both members must be configured identically and both sessions verified separately. A summary check of the aggregate tells you nothing about individual members, and the member view is the one that matters.
! Aggregated links: check every member, not the bundle
SwA# show mka sessions | include Te1/0/
SwA# show macsec interface TenGigabitEthernet1/0/1 | include Secure Channel
SwA# show macsec interface TenGigabitEthernet1/0/2 | include Secure Channel
!
! A mismatch between members is the thing to look for
SwA# show etherchannel summary | include Po1
A diagnostic order that works
Session state first — secured, pending, or absent. If absent, the frames are not reaching the other end and the question is the path. If pending, they are reaching it and the parameters disagree, so compare the cipher, the key and the network-link declaration. If secured, the problem is not here and the investigation belongs elsewhere.
Three states, three different next steps, one command. That is a considerably better starting point than the interface view, which reports the same thing in all three cases.
! One command, three possible answers, three different paths
SwA# show mka sessions
!
! Absent: are the frames leaving and arriving?
SwA# show mka statistics | include MKPDU
!
! Pending: which parameter disagrees?
SwA# show mka sessions detail | include Cipher|CKN|Key Server|Status
SwA# show mka policy MACSEC-POL detail
!
! Secured: look somewhere else
SwA# show macsec interface TenGigabitEthernet1/0/1
What to monitor
The secured session count against the number of links expected to be protected, which is one number and catches every failure in this article. The key replacement counter, which should increase slowly and steadily rather than rapidly. And the out-of-order discard counter, which is the early indicator of a path that has started reordering.
The first of those is the one worth alerting on. With protection required, a session failure is already an outage; with protection preferred, it is a silent loss of the thing the deployment was for, and only the count reveals it.
Blueprint framing
The CCIE Enterprise Infrastructure v1.1 blueprint covers Layer 2 encryption within its infrastructure security domain, generally at the level of mechanism rather than a full build. Being able to say what remains visible in a protected frame, that protection is per link rather than end to end, and why the key agreement does not survive a bridge covers the substance of what is asked.
| Failure | Trigger | Prevented by |
|---|---|---|
| Rotation outage | Clock divergence | Authenticated time, generous overlap |
| Link down after upgrade | Support changed for that port group | Check in the upgrade plan |
| Never secures after a swap | Template lost a non-default setting | Document on the link, comment in config |
| Inconsistent protection | Aggregate members differ | Verify every member separately |
| Silent loss of protection | Preferred rather than required | Alert on the secured session count |
Conclusion
The mechanism protects the wire and nothing more. Addressing stays visible so that switching still works, which means an observer learns who is talking and how much. Protection is per link, so every intermediate switch holds the traffic in clear and controls it entirely. That makes this the right answer for a fibre between buildings, a data centre interconnect, or anything handed to a carrier, and the wrong answer for a threat model that includes the switches themselves.
The key agreement is where deployments fail. Between two switches on a bench it works immediately; across a carrier's Ethernet service it frequently never establishes, because the agreement frames go to a reserved multicast address that bridges are specified to consume rather than forward. The carrier's equipment is behaving correctly, so the resolution is either a service option for transparent forwarding or a non-default destination address configured identically at both ends — and whichever is chosen must be documented on the link, because a switch restored from the standard template will lose it.
The setting that decides the worst day is whether protection is required or merely preferred. Required means any key problem is a complete outage with an obvious cause. Preferred means any key problem is traffic passing in clear, silently, at exactly the moment the protection mattered. Requiring it and alerting on the secured session count is the defensible position, and the count is worth more than any amount of configuration review — because every failure in this technology happens to a link that had been working for months, and nothing will tell you it stopped. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.
External Links
- IEEE 802.1AE — MAC Security (MACsec)
- IEEE 802.1X — Port-Based Network Access Control
- RFC 5116 — An Interface and Algorithms for Authenticated Encryption
- RFC 4493 — The AES-CMAC Algorithm
- RFC 3748 — Extensible Authentication Protocol (EAP)
- Cisco Learning Network — CCIE Enterprise Infrastructure
Reference Notes
- IEEE 802.1AE defines MAC Security, in which the destination and source MAC addresses remain unencrypted while the remainder of the frame is encrypted and authenticated.
- IEEE 802.1AE defines the SecTAG inserted after the source address and the integrity check value appended to the frame, which together constitute the protocol's per-frame overhead.
- IEEE 802.1AE defines protection as operating between adjacent stations, so a frame is decrypted and re-encrypted at each protected hop rather than protected end to end.
- IEEE 802.1AE defines replay protection based on the packet number carried in the SecTAG, with a configurable window governing tolerance of out-of-order delivery.
- IEEE 802.1X defines the MACsec Key Agreement protocol, in which a Connectivity Association Key is the root from which further keys are derived.
- IEEE 802.1X defines the election of a key server, which generates the Secure Association Key used to protect data frames and distributes it to the other participants.
- IEEE 802.1X specifies that key agreement frames are carried in EAPOL frames addressed to a reserved group address, which IEEE 802.1D bridges do not forward.
- IEEE 802.1D specifies that frames addressed to the reserved group addresses are not relayed by a bridge, which is the behaviour that prevents key agreement across a bridged service.
- RFC 4493 specifies AES-CMAC, used as the key derivation function in the key agreement.
- RFC 5116 describes authenticated encryption interfaces including GCM, the mode used by the MACsec cipher suites.
- Cisco documentation describes the extended packet numbering cipher suites, which extend the packet number space so that high-speed links do not require frequent rekeying.
- The CCIE Enterprise Infrastructure v1.1 unified exam topics include Layer 2 security within the infrastructure security domain.