Cisco Blogs

Prevent an Encryption Bottleneck on High-Speed Links

- September 6, 2017 - 3 Comments

What if you had a car with a powerful, turbo-charged engine that could fly along at 130 mph —until you turned on the air conditioner and watched the max speed drop to 50? Pick up two friends, and it struggles to maintain 30 mph.

This would be depressing for you as a driver, but it does make a good analogy for IT managers trying to leverage Internet Protocol Security (IPSec) for high speed link encryption requirements. In this approach, the routers’ throughput capabilities are restricted to the IPSec encryption engine limits, rather than using an encryption solution that can leverage the maximum aggregate throughput capabilities of the router.


IPSec hits forwarding limitations well below what the router’s aggregate forwarding capabilities are capable of.

As is depicted in the diagram above, IPSec hits forwarding limitations well below what the router’s aggregate forwarding capabilities are capable of. This restriction basically removes IPSec as an option as the industry moves toward 25G, 40G and 100G, with 400G in the near future; smaller packet-size applications can drop this clipping point even lower.

These limitations, as well as customers needing 40/100GE link encryption, are precisely why Cisco re-introduced Media Access Control Security, or “MACSec” into its product lines for routers, data center and campus switches.

MACSec, in simple terms, provides data encryption at the Ethernet frame level, encrypting the IEEE Ethernet frame (on ingress to the wire), and de-encrypting off the wire, per-hop, and at line-rate. The real advantage for MACSec is that the encryption/de-encryption function is done at the PHY level of the router/switch, enabling the encryption rates to equal the link speed rates (minus very little encryption header overhead), as shown below.


With MACSec, encryption rates equal the link speed rates (minus a small amount of overhead).

On the other hand, IPSec is limited to an offload engine or chip, and is typically a fraction of the overall throughput capabilities of the router or switch.

For example, if a router has 200Gbps packet throughput capabilities, but the bi-directional IPSec encryption engine is 35Gbps, the real performance of the router with IPSec enabled is 35Gbps (assuming all traffic requires encryption). In the case of the same router with MACSec, if the forwarding engine of the router is 200Gb and the interfaces running MACSec are equal to the forwarding engine:

MACSec: Encrypted Throughput = Router Aggregate Throughput (e.g. 200Gbps)

You want your car to perform to its maximum capabilities, even when the air conditioner is running and you are carrying some passengers. The same applies to network encryption: You want to leverage the overall forwarding throughput of the router, regardless of whether encryption is enabled, regardless of the frame sizes being transferred. MACSec provides this capability.

While the benefits of MACSec are clear, it should be noted that designers should not consider it as a rival to IPSec. IPSec is still the dominant encryption solution in WAN designs, as well as SD-WAN moving forward. Rather, think of MACSec as another tool in the tool bag of design options when high-speed encryption is required, and Ethernet transport (or dark fiber) is an available option in the design.

Want to know more? My colleague Stephen Orr (@StephenMOrr) and I co-authored a white paper that probes much deeper into multiple areas around MACSec, its advantages, use cases, and how it can be leveraged in high-speed WAN designs for federal customers. You can download it here.

Leave a comment

We'd love to hear from you! To earn points and badges for participating in the conversation, join Cisco Social Rewards. Your comment(s) will appear instantly on the live site. Spam, promotional and derogatory comments will be removed.


    Wow! Good job on the MACSec blog. I am really impress. You presented it like a Professor. Thank you.

    Your white paper is the best introduction to MacSec I've read so far. Great work! BTW: There is a little typo (or a missing capability of the publishing system) on page 7: It reads "264 Ethernet frames" instead of "2^64 Ethernet Frames". But the targeted audience will probably spot that ...

    Great analogy Craig! This will be the future on securing those high speed segments...!!!