A regional hospital enables MACsec on the link between an access switch and a server. Frames captured on the uplink from that access switch toward the core are still readable. Why is the uplink clear?
Select an answer to reveal the explanation.
Short Explanation
MACsec is a lock on one hallway door, and the next hallway is still open. You encrypted the hop between the server and the access switch, then the access switch forwards the traffic in the clear on the uplink. A contract can permit a flow, and it does not encrypt the frame for the rest of the trip.
Full Explanation
MACsec, defined in 802.1AE, encrypts frames on the link where it is enabled, and MKA agrees the keys for that hop. The hospital protected the server-to-access link only. Once the access switch decrypts the frame and routes or switches it toward the core, the uplink is a different hop with no MACsec, so a capture there is readable. That is hop-by-hop encryption, not a tunnel that survives a routed hop. An ACI contract filter permits or denies traffic between groups. It does not encrypt payloads, and this uplink is not waiting on a contract to become ciphertext. DHCP snooping builds a binding table. It does not encrypt client frames after a lease, and a static address is irrelevant to why the uplink is clear. A routing key chain authenticates protocol peers. It does not encrypt the data frames the access switch forwards upstream. Caveat: if the requirement is encryption across the whole path, every hop needs MACsec or the traffic needs a separate overlay encryption design. Operational check: capture on the uplink and confirm the frames are readable, then enable MACsec on that uplink too if that hop must be protected.