No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

MACsec cannot be established between two S5720 when there are L2 switches between them

Publication Date:  2018-01-31 Views:  858 Downloads:  0
Issue Description

Version Information:S5720SI-V200R010C00SPC600

Fault symptom : In order to better explain the issue I will provide a topology that can show this scenario :

 

Let’s suppose that between our two S5720 switches there are only L2 switches which allows all the packets. Even so, the MACsec cannot be established. When the two-end Switches are directly connected the MACsec connection it’s succesful.

 

Alarm Information


Handling Process

 

1)     1)Asked for the following information:

a)[Switch1/2] display mka interface gigabitethernet 0/0/1

   <Swithc1/2>reset mka statistics interface gigabitethernet 0/0/1

Please collect the macsec statistics during the negotiation, wait for a minute, reset the statistics and then run again the first command.

 

b)<Swithc1/2> display macsec statistics interface gigabitethernet 0/0/1

      <Swithc1/2>reset macsec statistics interface gigabitethernet 0/0/1

Please collect the macsec statistics during the negotiation, wait for a minute, reset the statistics and then run again the first command.

 

c)View the MACsec entries of the bottom-layer chip on GE0/0/1.

 < Swithc1/2> system-view

 [Swithc1/2] diagnose

 [Swithc1/2-diagnose] display macsec configuration interface GigabitEthernet 0/0/1

 

d)enable the MKA debugging on both switches(below you send the output only from the second switch and we noticed the packets were sent to request the negotiation):

The debugging mka all interface gigabitethernet 0/0/1 command enables MKA debugging.

The undo debugging mka command disables MKA debugging

2)     2)Asked if there are packets dropped by the dumb switch that could go to fail the negotiation by making some packet captures in inbound and inbound direction.

 

Root Cause

MACsec (Media Access Control Security) is based on 802.1AE and 802.1X protocol on the LAN security communication method.

The EAP protocol packet in the MACsec session negotiation process is a BPDU packet.

IEEE Std 802.1X-2010 Clause 11 describes the MAC format of the EAP protocol packets, as shown in the following figure:


From the packet captures the stp bpdu packet destination MAC was different from the 0180-c200-0003 which is required for the negotiation of MACsec.

 

From the capture we only can see the packets sent by switch1 . The dumb switch didn’t forward them . The packet lost in the dumb switch .
Our switch sends by default the packet at each 2s. If the dumb switch would forward the packet there should be another packet between 1-4 .




Solution

MACsec negotiation needs the BPDU packets in this process and we suspected that the dumb switch droped the BPDU packets as a default behavior when there is no configuration.
That’s why, it’s required to configure the l2protocol-tunnel  to transport the packets.

For BPDUs, the destination MAC is  0180-c200-0003

First solution and recommended one:


In system-view apply this command on both switches :

l2protocol-tunnel user-defined-protocol test1 protocol-mac 0180-c200-0003  group-mac 0100-0008-0008

on interface view apply those commands

interface GigabitEthernet0/0/34
port link-type access
port default vlan 10
l2protocol-tunnel user-defined-protocol test1 enable

 

Second solution if l2protocol-tunnel cannot be configured on the directly connected to end-switches :

After connecting the G0/0/3 to the dumb switch and applied l2tp configuration on G0/0/2 which is connected to G0/0/1( L3 interface) then the MACsec connection could be established but this scenario is not recommended and needs to be tested with precautions.

 

END