Skip to content

MACsec

MACsec (Media Access Control Security) is a standard security technology defined by IEEE 802.1AE that provides confidentiality, integrity, and authenticity for data transmitted over Ethernet networks. Unlike IPsec which operates at the network layer, MACsec secures traffic at the data link layer, encrypting all Ethernet frames including DHCP, ARP, LLDP, and higher-layer protocols.

MACsec utilizes GCM-AES-128 encryption to protect traffic between directly connected devices. Each MACsec-protected link forms a secure association using connectivity association keys (CAK) and connectivity association names (CKN) for authentication, with the MACsec Key Agreement (MKA) protocol managing key distribution and session maintenance.

On MikroTik RouterOS, MACsec interfaces function like standard Ethernet interfaces and can be assigned IP addresses, placed in bridges, or used with any interface-based feature. This makes MACsec suitable for securing point-to-point links between routers, switches, hosts, and other network devices where layer 2 security is required.

MACsec encrypts Ethernet frames using GCM-AES-128, providing cryptographic protection for all traffic on a secured link. When MACsec is enabled, the interface operates in one of two modes: authenticated (without encryption) or encrypted. The default mode encrypts all traffic, ensuring that even metadata like ARP requests and DHCP transactions cannot be intercepted.

The encryption covers the entire Ethernet payload but preserves the original source and destination MAC addresses. This allows switches to continue forwarding frames based on MAC tables while the payload remains protected. Frames include an integrity check value (ICV) that recipients verify to ensure frames have not been tampered with in transit.

The MKA protocol manages the lifecycle of MACsec sessions. When two devices establish a MACsec link, they first authenticate using pre-shared CAK/CKN pairs. Once authenticated, MKA elects a key server (in point-to-point connections, one endpoint becomes the key server) which generates Secure Association Keys (SAK). These SAKs encrypt the actual data traffic and are periodically refreshed to maintain security.

MKA continuously monitors the link health and manages key rollover. If the link is interrupted or keys expire, MKA renegotiates the secure association. The protocol ensures that only authorized devices can participate in the MACsec domain and that encryption keys are never transmitted in cleartext.

MACsec adds a Secure Content Identifier (SCI) and optional Secure Tag to each Ethernet frame. The SCI uniquely identifies the transmitting device and secure association, while the Secure Tag includes a packet number used with the SAK to generate unique encryption for each frame. This prevents replay attacks where an attacker might resend previously captured frames.

The most straightforward MACsec deployment connects two hosts directly. Each device creates a MACsec interface bound to its physical Ethernet port. RouterOS can automatically generate the CAK and CKN if not specified, which you can retrieve after creation.

# On Host1
/interface macsec
add interface=ether1 name=macsec1
# Verify and note the auto-generated keys
/interface macsec print show-sensitive
Flags: I - inactive, X - disabled, R - running
0 name="macsec1" mtu=1468 interface=ether1 status="negotiating" cak=71a7c363794da400dbde595d3926b0e9
ckn=f2c4660060169391d29d8db8a1f06e5d4b84a128bad06ad43ea2bd4f7d21968f profile=default
# On Host2
/interface macsec
add interface=ether1 name=macsec1
# Verify and note the auto-generated keys
/interface macsec print show-sensitive
Flags: I - inactive, X - disabled, R - running
0 name="macsec1" mtu=1468 interface=ether1 status="negotiating" cak=dc47d94291d19a6bb26a0c393a1af9a4
ckn=e9bd0811dad1e56f06876aa7715de1855f1aee0baf5982ac8b508d4fc0f162d9 profile=default

After creating the interfaces, verify the connection status transitions from “negotiating” to “open-encrypted”:

/interface macsec print
Flags: I - inactive, X - disabled, R - running
0 R name="macsec1" mtu=1468 interface=ether1 status="open-encrypted" cak=*o \
ckn=*o profile=default

When deploying MACsec through a switch, you must manually configure matching CAK/CKN pairs on both ends. The switch needs the exact keys from each connected device. This example assumes Host1 connects to switch ether1 and Host2 connects to switch ether2.

# On the switch, configure MACsec for Host1
/interface macsec
add comment=Host1 cak=71a7c363794da400dbde595d3926b0e9 \
ckn=f2c4660060169391d29d8db8a1f06e5d4b84a128bad06ad43ea2bd4f7d21968f \
interface=ether1 name=macsec-host1
# On the switch, configure MACsec for Host2
/interface macsec
add comment=Host2 cak=dc47d94291d19a6bb26a0c393a1af9a4 \
ckn=e9bd0811dad1e56f06876aa7715de1855f1aee0baf5982ac8b508d4fc0f162d9 \
interface=ether2 name=macsec-host2

After establishing the MACsec link, configure IP addresses just like any other interface:

# Host1 configuration
/ip address
add address=192.168.10.10/24 interface=macsec1
# Host2 configuration
/ip address
add address=192.168.10.20/24 interface=macsec1
# Verify connectivity
ping 192.168.10.20

For layer 2 forwarding, add MACsec interfaces to a bridge:

# Switch configuration
/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 interface=macsec-host1
add bridge=bridge1 interface=macsec-host2

MACsec provides per-link encryption for connections between servers and switches in data center environments. This protects against physical tampering where someone might tap into Ethernet cables to intercept traffic. Since MACsec encrypts all layer 2 traffic, including storage protocols like iSCSI and management traffic like IPMI, sensitive data remains protected even on internal networks.

Deploy MACsec on uplinks between Top-of-Rack switches and aggregation switches, and on server connections where PCI-DSS or other compliance requirements mandate encryption. The encryption is transparent to applications and operating systems, requiring no changes to existing workloads.

Industrial environments often have physical security concerns where network cables may be accessible in manufacturing floors or utility substations. MACsec secures SCADA traffic, PLC communications, and other operational technology without modifying industrial protocols or adding encapsulation overhead that could affect real-time requirements.

For organizations using carrier Ethernet services to connect locations, MACsec adds an additional layer of security beyond what the service provider offers. This ensures that even if the provider’s network is compromised, traffic remains encrypted end-to-end. This is particularly valuable for financial institutions, healthcare organizations, and government agencies with strict data protection requirements.

Sub-menu: /interface/macsec

PropertyTypeDescriptionDefault
cakstringA 16-byte pre-shared connectivity association key (CAK) in hexadecimal format. Configure matching CAK and CKN on both ends to enable MACsec. Leave unset for automatic random generation.auto-generated
cknstringA 32-byte connectivity association name (CKN) in hexadecimal format. Configure matching CAK and CKN on both ends to enable MACsec. Leave unset for automatic random generation.auto-generated
commentstringShort description of the interface for identification purposes.
disabledyes | noDisables or enables the MACsec interface without removing configuration.no
interfacenameThe underlying Ethernet interface where MACsec is enabled. Each physical interface supports only one MACsec interface.
mtuintegerMaximum transmission unit for the MACsec interface. The Layer 2 MTU is derived from the parent interface minus 32 bytes for MACsec encapsulation and cannot be changed manually.1468
namestringAdministrative name for the MACsec interface.macsecN
profilenameMACsec profile name that determines key server behavior.default
statusread-onlyCurrent operational status: disabled, initializing, invalid, negotiating, or open-encrypted.

Sub-menu: /interface/macsec/profile

PropertyTypeDescriptionDefault
namestringName identifier for the MACsec profile.
server-priorityinteger: 0..255Priority for key server election in point-to-point connections. Lower values indicate higher priority. If priorities match, the interface with the lower MAC address becomes the key server.10

The MACsec interface status indicates the current state of the secure association:

  • disabled: Interface is administratively disabled
  • initializing: Interface is starting up and performing initial negotiation
  • invalid: CAK/CKN authentication failed or keys do not match peer
  • negotiating: Keys matched but MKA session is still establishing
  • open-encrypted: Secure association established and traffic is encrypted

In a point-to-point MACsec connection, one device must act as the key server to generate and distribute SAKs. The key server election uses the server-priority value, with lower values winning. If both devices have the same priority, the device with the lower MAC address becomes the key server.

# Create a profile with custom priority
/interface macsec/profile
add name=high-priority server-priority=5
# Apply the profile to the interface
/interface macsec set [find name=macsec1] profile=high-priority

Multiple profiles are useful when connecting to different devices that may have different key server preferences or when managing complex multi-vendor environments. Each MACsec interface references one profile, and the profile settings affect only that interface’s key server behavior.

MACsec encryption in RouterOS is performed entirely in software by the CPU. This means throughput is limited by the device’s processor speed rather than interface speeds. For example, a CCR2004 might achieve significantly lower throughput on a MACsec link compared to its non-encrypted interfaces.

When planning MACsec deployments, benchmark realistic traffic patterns before production deployment. Sustained high-throughput workloads may not achieve expected performance levels. Consider the aggregate throughput requirements across all MACsec interfaces when sizing hardware.

MACsec encapsulation adds 32 bytes to each frame (16 bytes for the Secure Tag and 16 bytes for the ICV). RouterOS automatically sets the L2MTU to the parent interface value minus 32 bytes. This means the effective MTU for payloads is reduced by 32 bytes.

If the parent interface supports jumbo frames (9000 byte MTU), the MACsec interface will have an L2MTU of 8968 bytes. Ensure that Path MTU Discovery accounts for this reduction, particularly for VPN tunnels or other encapsulated traffic that might already have overhead.

The encryption process adds per-packet processing latency. While minimal for small frames, high-frequency trading or real-time control systems should test MACsec latency impact before deployment. The key rollover process (typically every few seconds) does not interrupt traffic but involves cryptographic operations that may cause micro-bursts in latency.

If the status remains “negotiating” for extended periods:

  1. Verify CAK and CKN match exactly on both ends (32 hex characters for CKN, 16 hex bytes for CAK)
  2. Confirm the physical link is operational with /interface ethernet print
  3. Check for firewall rules blocking EAPOL or MKA traffic (UDP ports 4789 and 6081)
  4. Ensure only one MACsec interface exists per physical port
  5. Review logs with /log print for MACsec-specific error messages

An “invalid” status indicates authentication failure:

  1. Confirm both devices use the same CAK/CKN pair
  2. Verify hexadecimal format without spaces or prefixes (0x)
  3. Ensure no whitespace or case differences in the key strings
  4. Delete and recreate the interface with corrected keys if necessary

When the interface shows “open-encrypted” but traffic fails:

  1. Verify IP addressing if using routed mode
  2. Confirm bridge membership if using layer 2 mode
  3. Check for firewall rules blocking traffic on the MACsec interface
  4. Test with /tool ping to confirm basic connectivity
  5. Review /interface macsec monitor for packet counters
/interface macsec monitor [find name=macsec1]

Monitor shows encrypted and decrypted packet counts, as well as dropped packet statistics. Unexpected drops may indicate MTU mismatches or resource constraints.

The RouterOS MACsec implementation has several important limitations to consider during deployment planning. Dynamic key management through 802.1X (Dot1X) is not supported, requiring manual CAK/CKN configuration on each endpoint. This increases operational complexity and the risk of key mismatches during configuration.

Hardware acceleration is not available, meaning all encryption operations use the main CPU. This significantly impacts throughput and may affect other device functions under high load. Review MikroTik’s documentation for your specific hardware model to understand expected performance characteristics.

MACsec interfaces cannot be added to bonding interfaces directly. For redundant MACsec links, consider using failover bridge configurations or routing protocols with redundant paths. Additionally, MACsec on CRS3xx series switches requires specific switch chip configuration and may have hardware-specific limitations.

MACsec requires compatible devices on both ends. While most modern switches and network adapters support IEEE 802.1AE, verify compatibility before deployment. Interoperability testing between MikroTik devices and other vendors is recommended, as implementation details may vary.