Customer needs assistance in configuring PE devices to pass the customer's MKA frames.
Customer needs assistance with the following question/configuration:
How do we configure our PE devices to transparently pass MKA frames?
We can consider the following steps to configure PE devices to transparently pass MKA frames:
The workaround that could be considered is Layer 2 protocol tunneling, cause it is one technique to forward Ethernet control protocols over a switched domain.
One of the challenges in transporting MACsec and other link-local Layer 2 protocols, such as LLDP and EAPoL (the transport protocol for MKA), is carrying it over multiple switch hops. The latter case could be a VPLS or pseudowire transport service. In normal situations, LLDP, EAP over LAN (EAPoL), LACP, and other similar protocols, would be locally processed by the switch or router and not propagated further. In our case, we want to extend a multi-access Ethernet network over multiple switch or router hops, so these intermediate devices should not interpret these link-local protocols and should instead transparently forward these control protocols to the next hop rather than locally processing them.
Layer 2 Protocol Tunneling Layer 2 control protocols are identified by their Ether Type and MAC address. In the case of MACsec’s MKA protocol, EAP over LAN (EAPoL), this is 0x888e and the multicast address of 01:80:c2:00:00:03, respectively. A switch that you configure to tunnel EAPoL traffic identifies traffic with this destination MAC address and Ether Type and encapsulates it in a simple Ethernet wrapper ,whose destination MAC address is 01:00:0C:CD:CD:D0, and forwards this onto the next switch hop or hops. Looking at Figure 5.1, the next switch receives packets with a nonspecial destination MAC so the packets are forwarded with no local processing.
At the other end of the tunnel, a switch decapsulates the packet, removing the outer Ethernet wrapper, and rereads the destination MAC, which is the EAPOL destination MAC, and forwards the packet out the port towards the MACsec host. This type of tunneling is a rudimentary but effective way to hide Layer 2 control protocols from otherwise nosey intermediate switches. There are no endpoints to define or keepalives, such as in the case of IPSec Dead Peer Detection (DPD).
Additional and more technical information can be found in the following documentation, page 30:
DAY ONE: MACsec UP AND RUNNING
https://www.juniper.net/documentation/us/en/software/nce/do-macsec-ur/DO_MACsec_UR.pdf
For most Juniper platforms, the configuration is the same: set protocols layer2-control mac-rewrite interface.
Under the interface hierarchy you add specific protocols you want to tunnel:
root@switch# set protocols layer2-control mac-rewrite interface (interface-name) protocol
Note: only the following protocols are supported for layer2-control mac-rewrite interface on the reported platform:
protocol (cdp | elmi | gvrp | ieee8021x | ieee8023ah | lacp | lldp | mmrp | mvrp | stp | udld | vstp | vtp)
Layer 2 Protocol Tunneling (L2PT)
https://www.juniper.net/documentation/us/en/software/junos/multicast-l2/topics/topic-map/layer-2-protocol-tunneling.html
On the other hand, I also found the following documentation that states that the switches (PE) will not pass MACSec frames received from the CE if those frames are from MACSEC (using MAC destination as multicast 01:80:C2:00:00:03 ). This is affecting the MACSec communication from CE's device using MACSec.
To prevent these packets from being consumed in a service provider network, you can change the destination MAC address.
MACSec packet are not being forwarded
The default destination MAC address for an EAPoL packet is a multicast address. In a service provider network, there might be devices that consume these packets, assuming the packets are meant for them. EAPoL is used by 802.1X and other authentication methods, which might cause the devices to drop the packets, depending on their configuration. This would cause the MKA session to fail.
To ensure that the EAPoL packet reaches the correct destination, you can change the destination MAC address so that the service provider network tunnels the packet instead of consuming it.
Important, if the Juniper device role is from ISP perspective we don't need to change anything in the config, instead please advise to change the destination MAC address on the CE. Otherwise if the Juniper device role is from CE (customer) perspective please configure the MAC address dest from the CE. Using this reference:
Configuring the EAPoL Destination MAC Address for MACsec
https://www.juniper.net/documentation/us/en/software/junos/security-services/topics/topic-map/understanding_media_access_control_security_wan.html#id-configuring-the-eapol-destination-mac-address-for-macsec