Layer 2 Encryption without the hurdles: How to properly prepare your network

Secure Layer 2 services are now a must for carriers and network operators. However, implementation often presents challenges. Our network expert Dmitry Shkurko explains: The real challenge rarely lies in the encryption itself, but rather in whether the existing infrastructure can support it properly.

As a network operator, you’re familiar with this scenario: You’ve purchased a “transparent Layer 2 point-to-point connection” for a new project, installed the appropriate encryption devices and suddenly frames are getting lost. The encryption isn’t working as expected, and customers are becoming dissatisfied. Then comes the troubleshooting, under time pressure.

Faulty devices? Misconfiguration? Incompatibilities? The causes can be manifold - and that is precisely what makes the situation so challenging.

Anyone who wants to deploy Layer 2 encryption must first ensure the infrastructure is properly prepared. Depending on your influence over the “core” of the network, the complexity increases - but so does the scope for design. Good planning is crucial here for project success, costs, and time. What are the key factors to consider?

1. You should know, what's happening in the middle

It’s tempting to assume that everything is working as expected when “some things are up and running” and “tests were successful” - especially when a “transparent connection” is promised. In practice, however, it quickly becomes clear that the more components there are in the data path and the less control you have over them, the higher the risk of errors.

Features such as QoS are implemented hop by hop, which is why the goal should be to minimize the number of hops - as long as this is economically and technically feasible. Typical challenges with Layer 2 connections include bottlenecks, filtering mechanisms, and parameters that aren’t precisely tuned. Added to this are additional overheads caused by further network segments. Even seemingly simple issues, such as determining the minimum L2 MTU, can become difficult in more complex environments.

There are various network scenarios, each with its own requirements and limitations:

• Dark fiber connection with NTEs under one’s own control

• Dark fiber connection with provider-controlled NTEs

• Provider’s DWDM core network in the middle

• Provider’s MPLS core network in the middle

• Mixed environment

These differences in link architecture are a key factor in determining how reliably encrypted Layer 2 connections can actually be operated.

2. Understand the key parameters in your partner’s network

A “transparent 10G link” is by no means sufficient to rely on. It is crucial to understand how the upstream devices are actually configured and whether they can deliver the transparent service you need.

The following questions are relevant:

• Are MACsec frames actually being forwarded? “MACsec-capable” does not automatically mean that frames are transported unchanged. Encryption and forwarding are different functions, and not every device supports both.

• Are there any filters or restrictions in the network? Can certain MAC addresses or Ethertype values cause frames to be mishandled - especially if tests have only worked with specific devices?

• How is the QoS/policing behavior configured? Are parameters such as CBS set so that traffic spikes are handled without issues, or do even moderate deviations lead to frame loss?

• Can the relevant parameters be adjusted? For example, can you adjust the burst behavior of your own systems to match the specifications of the provider’s network?

• Are EBS values supported in addition to CBS? Is there any leeway for short-term bandwidth overages? Or is this behavior strictly limited?

• What MTU limits apply at Layer 2? Is it ensured that all frames remain within the permitted size, since there is no fragmentation here?

• What are the requirements for tagging? Is untagged, C-tagged, or S-tagged traffic used, and are the frames formatted and switched in accordance with the design intention?

• Are MACsec-specific frame components processed correctly? Can intermediate devices even recognize and handle often overlooked information (e.g., Ethertype in the SEC tag)?

• What effective bandwidth is actually available? Does the usable capacity truly correspond to the nominal bandwidth - even when accounting for overheads such as MACsec and VLAN tags?

The figure shows a simplified situation when a group of frames is sent towards a provider router. Here, a sending device produces groups of such frames up to a certain size, called CBS (Commited Burst Size). The receiving device (provider’s router) has own CBS value configured in policing. To avoid some frames being dropped, it’s crucial to ensure that provider’s CBS is configured at least slightly higher than the one of a sending device. Or rather, your CBS should be configured at least slightly lower than the CBS of a provider. Providers are known for being reluctant to change their settings!

 3. Set clear expectations for your provider

To ensure that a Layer 2 connection provided for encrypted services functions reliably, your expectations should be clearly defined from the outset. These include, in particular:

Actual bandwidth: Ensure that the available capacity matches your application’s needs, not just nominally, but effectively.

Traffic behavior margins (CBS/EBS): Ensure that burst sizes are sufficiently dimensioned to handle peak loads, within your budget.

The switchover design: If you wish to use both tagged and untagged frames, this must also be supported in the provider’s network.

Transparent forwarding of MACsec frames: Ideally, clarify in advance and let your provider know which encryption technology is used, including the relevant Ethertype values.

Support for CCM frames (in sopie of CFM technology): This mechanism is essential for automatic connection recovery and should be reliably forwarded.

4. Describe your customer's expectations

In addition to the technical implementation, the customer’s expectations should also be clearly defined and communicated. Two points are particularly important here:

Define realistic bandwidth: Take all overheads into account (e.g., VLAN, MACsec). The effective bandwidth may be lower than the nominal bandwidth. The CIR should be set accordingly.

Define how to handle traffic spikes: Opt for “delay rather than drop.” With appropriate policing and queuing settings, you can handle more traffic and forward it reliably.

5. Test the performance

How you measure the provided performance - and how your customers test it - is just as critical as the configuration itself. Only a properly designed test can yield reliable results.

A structured, consistent approach is essential: Tests should be conducted before the system is handed over to production and should be performed both at the provider’s connection points and on the encryption devices. This makes it possible to verify whether the promised performance is actually being delivered and to assess the impact of encryption.

Comparability is key here. Different testing methods, protocols, or frame sizes can significantly influence the results. Only by consistently using the same methodology for measurement can reliable conclusions be drawn and potential bottlenecks reliably identified.

Conclusion 

The challenge rarely lies in the encryption itself—but rather in integrating it into a well-prepared infrastructure. Layer 2 encryption requires a thorough understanding of the entire path and all relevant parameters. It’s always about more than just the encryption hardware. It’s about implementing solutions reliably under real-world conditions and establishing the necessary transparency across the entire infrastructure.

The dacoso Customer Briefing Center (CBC) demonstrates just how complex Layer 2 encryption can become in multi-vendor environments - and why experience makes all the difference in implementation. Feel free to schedule an appointment; I’m often on-site!