Session and counter checks
Build an evidence chain from the intended peer to actual encrypted traffic, rather than treating one successful command as proof.
Prerequisite: Introduction to MACsec.
Separate four questions
Use the VLAN 100 R1–R2 link from Protected link configuration. R1's SVI is 192.0.2.1/30 and R2's is 192.0.2.2/30. No alternate path exists in this teaching topology, so the test flow must use the participating physical link when the VLAN is forwarding.
- Membership: is MKA secured with the intended peer and credential identifier?
- Installation: are the expected receive and transmit associations actually in use?
- Policy: are confidentiality, cipher, replay policy and mandatory access control correct?
- Traffic: do encrypted transmit and validated/decrypted receive counts advance when the test traffic crosses?
Collect timestamps and repeat the same checks on both ends. Cumulative counters describe history; counter deltas describe the interval you observed. Key rollover, a process restart or a cleared counter can break a simple subtraction, so record association identity too.
Inspect membership and key installation
R1# show mka sessions interface TenGigabitEthernet1/0/1 detail
Status: SECURED - Secured MKA Session with MACsec
Local Tx-SCI............. 0200.0000.0001/0001
CAK Name (CKN)........... 01
Key Server............... YES
Latest SAK Status........ Rx & Tx
Latest SAK AN............ 0The CKN identifies the intended PSK association without exposing its secret. Check the peer receive SCI against R2's local transmit SCI in the full output. The locally administered MAC addresses here are examples. A secured state does not identify the route of every application flow, and a key server is not the only device that should have active traffic keys.
R1# show macsec interface TenGigabitEthernet1/0/1
MACsec is enabled
Replay protect : enabled
Replay window : 0
Cipher : GCM-AES-128
Confidentiality Offset : 0
Access control : must secure
Transmit Secure Channels
SA State: inUse(1)
Confidentiality : yes
Receive Secure Channels
SA State: inUse(1)This is the intended direct-link policy and both associations are active. A cipher shown only under “Capabilities” would not prove that it is selected. Also distinguish integrity-only packet counts from encrypted packet counts when confidentiality is required.
Compare a controlled interval
First allow ARP and spanning tree to settle. Record association-specific counters, generate a known small test flow, then reread without clearing operational counters. These excerpts focus on the R1→R2 direction; repeat for the reverse direction. Numbers are deliberately constructed and assume no rekey during this interval.
R1# show macsec interface TenGigabitEthernet1/0/1
Transmit Secure Channels
SA Statistics
Encrypted Pkts : 1200
R2# show macsec interface TenGigabitEthernet1/0/1
Receive Secure Channels
SA Statistics
Valid pkts 1200
Invalid pkts 0
Late pkts 0R1# ping 192.0.2.2 source 192.0.2.1
!!!!!
Success rate is 100 percent (5/5)R1# show macsec interface TenGigabitEthernet1/0/1
Transmit Secure Channels
SA Statistics
Encrypted Pkts : 1205
R2# show macsec interface TenGigabitEthernet1/0/1
Receive Secure Channels
SA Statistics
Valid pkts 1205
Invalid pkts 0
Late pkts 0The delta is five encrypted transmissions and five validated receptions, with no added invalid/late drops. In a real network background control/data traffic may also increment counters, so a larger delta is not inherently wrong. Correlate the peer's decrypted-byte count, active confidentiality and reverse echo-reply counters. Read the same SC/SA level at each snapshot; some hardware reports aggregate SC and individual SA counters differently.
Interpret symptoms without overclaiming
| Observation | Next question |
|---|---|
| No secured MKA session | Are EAPOL, active credentials and keying policy working? |
| Secured session, no test-counter delta | Did the test use this port, and is VLAN/SVI forwarding correct? |
| Encrypted Tx grows, peer valid Rx does not | Are frames lost in transport, rejected by validation or attributed to another association? |
| Late counter increases | Is the service reordering frames beyond the permitted window? |
| Small packets pass, large packets fail | Does the full protected frame fit the transport size budget? |
“Invalid” does not prove malicious tampering. Bad keys, stale associations, damaged data or incompatible implementation can produce validation failures. Preserve evidence and compare both peers before changing settings.
Use the right capture boundary
A capture on a host before encryption or after decryption can correctly show plaintext. A wire-side capture on the protected Ethernet segment should show MACsec frames for protected data and separate EAPOL key-management traffic. MACsec packet presence alone does not prove confidentiality: inspect the encryption indication and configured offset, then correlate with active cipher and encrypted counters.
A controlled negative check, when explicitly authorized in a future isolated lab, can confirm that ordinary unsecured data is blocked under the intended mandatory policy. Do not disrupt an operational peer just to obtain that evidence. No capture or failure injection is needed to study these illustrative outputs.
Key Takeaways
- Check intended membership, key installation, active policy and actual traffic as separate evidence.
- Compare expected peer SCI and CKN without exposing secret credentials.
- Use association-specific before/after deltas and record rekeys or resets that affect the comparison.
- Correlate encrypted transmit with peer validated/decrypted receive in both directions.
- Capture location, confidentiality indication and offset determine what a wire observation can prove.
Technical references and example notes
IEEE 802.1AE · IEEE 802.1X and MKA · Platform configuration and verification · Topology-symbol attribution.
Diagrams, frame sequences and command results are constructed teaching examples, not recorded captures or lab measurements.