XMG1915-10E - EAPoL packet dropped.

solarius_

Hello,

I just installed an XMG1915-10E switch in my network and 802.1x stopped working. The client device is connected on port 3 and the authenticator on port 5.

With packet capture I observe that the EAPoL packets targeted to 01:80:c2:00:00:03 sent by the client to trigger the authentication are not forwarded to port 5 and the EAP-Request(Identity) sent by the authenticator to port 3 are not forwarded either. Do you have an idea where it could come from ? Is there any option to enable/disable to change this behavior ?

Best regards,
S-

Zyxel_Judy

Hi @solarius_ ,

Please follow this article to verify your 802.1x configuration is correct.

https://community.zyxel.com/en/discussion/22998/how-to-activate-802-1x-authenticatoin-on-switch

Additionally, ensure ports 3 and 5 don't have any settings that might block EAPoL packets (like unnecessary VLAN configurations). Check that the cable connections between the devices and switch are working properly.

If authentication still fails, please capture the traffic on ports 3 and 5 for 3-5 minutes and share the capture file with us.

solarius_

Hi @Zyxel_Judy ,

I checked the article you sent me but unfortunately there's no "802.1x" item on my switch "Security" menu (see the image below).

I double checked the switch settings and I don't see any particular settings that could block the EAPoL packets from going from one port to another. I captured the traffic on both sides and joined the capture files in attachment.

captures.zip

Best regards,
S-

Zyxel_Judy

Hi @solarius_ ,

We apologize for missing your switch model name. The XMG1915-10E does not support the 802.1x feature. For detailed specifications of the XMG1915-10E, please refer to the product datasheet.

XMG1915-10E_1.pdf

solarius_

Hi @Zyxel_Judy ,

I acknowledge the switch doesn't support 802.1x and that was not really my concern. I would just like to know why it drops 802.1x packets ? Even if it does not support the protocol I would expect it to forward the packets like any un-managed switch would do, otherwise it sounds like a bug to me. Is there any way to obtain this behavior ?

solarius_

Hi @Zyxel_Judy,

Do you have any update on why the switch drops the packets ?

Best regards,

Zyxel_Judy

Hi @solarius_ ,

EAPOL packets use a reserved multicast MAC address defined by IEEE 802.1D and are typically intercepted by the switch CPU instead of being forwarded. The XMG1915 is a Web-Smart switch and it follows IEEE 802.1D rules and drops these packets to prevent network disruptions.

However, unmanaged switches do not process reserved control packets and simply forward all traffic, which is why EAPOL packets can pass through them.

In case, you'd like to let EAPOL passthrough is a feature of fully managed switches, we can help to move your request to the idea list for monitoring and evaluation.

solarius_

Hi @Zyxel_Judy,

Thanks for the detailed reply.

EAPOL packets use a reserved multicast MAC address defined by IEEE 802.1D and are typically intercepted by the switch CPU instead of being forwarded.

I understand why multicast MAC addresses are not forwarded by default to prevent network disruption 😊

However there's two things I'd like to highlight.

1. The EAPoL specification (IEEE 802.1x - 2020) state the following (§ 11.1.1):

The destination address for each MAC service request used to transmit an EAPOL MPDU is an individual address associated with a peer PAE or a group address […]

Thus EAPoL packets do not always use a multicast MAC address. If you look at the captures I provided, the supplicant (client device on port 3) sends EAPoL packets using a multicast address (which will be dropped according to your statement):

However the authenticator (the server device on port 5) sends EAPoL packets directly targeted to the supplicant (using the device MAC address and not a multicast one):

and those packets are also dropped by the switch. In that case the multicast treatment does not apply and it looks like a bug to me.

2. If I understand the switch web configuration correctly, there's a feature to add a MAC multicast group for a set of ports and allow the switch to forward the multicast packets:

It could be the way to workaround a part of the issue. However the configuration interface does not accept the Nearest non TPMR bridge multicast address (01:80:c2:00:00:03), and says it is an invalid multicast address.

Best regards,

Zyxel_Judy

Hi @solarius_ ,

• From our lab testing, at the EAPoL Start step, when the supplicant sends a packet to a multicast group to discover available Authenticators, these packets are dropped because the switch doesn't support 802.1x. There are no EAPoL packets reaching the Authenticator from the supplicant. Therefore, the subsequent steps where the Authenticator would send unicast/multicast packets to the supplicant do not occur. 
  We're not sure about your topology that resulted in the packets you shared; however, it doesn't appear to be a direct PC --- XMG1915-10E --- Authenticator connection.

• The "Static Multicast Forwarding By MAC" feature only accepts non-reserved multicast addresses. Since 01:80:c2:00:00:03 is a reserved multicast address, it cannot be configured here.

solarius_

Hi @Zyxel_Judy,

Thanks for your reply.

From our lab testing, at the EAPoL Start step, when the supplicant sends a packet to a multicast group to discover available Authenticators, these packets are dropped because the switch doesn't support 802.1x. There are no EAPoL packets reaching the Authenticator from the supplicant. Therefore, the subsequent steps where the Authenticator would send unicast/multicast packets to the supplicant do not occur.

I agree that the EAPoL(Start) packet does not go through the switch, thus the authenticator is not triggered by this event. However it detects the presence of a new device on the network and reacts to it by sending an EAP-Request(Identity) as showed in the capture. Once again I agree the packet sent to the multicast group shouldn't be forwarded (according to your saying) however the non multicast one (the EAP-Request(Identity)) should be. In case it helps reproducing, the authenticator is a linux machine connected on port 5 running hostapd as authenticator.

We're not sure about your topology that resulted in the packets you shared; however, it doesn't appear to be a direct PC --- XMG1915-10E --- Authenticator connection.

It is a direct PC ←→ XMG1915-10E ←→ Authenticator connection.

To be more precise here's my topology, described with the MAC addresses and ports as visible in the capture I provided:

+——————————————————————————+              +——————————————————+            +——————————————————————————+
|            PC            |________port3_|      Switch      |_port5______|      Authenticator       |      
| (MAC: 00:e0:4c:68:03:2a) |              |  (XMG1915-10E)   |            | (MAC: 00:e0:4c:68:03:1e) |

+—————————————————————————-+              +——————————————————+            +——————————————————————————+

The "Static Multicast Forwarding By MAC" feature only accepts non-reserved multicast addresses. Since 01:80:c2:00:00:03 is a reserved multicast address, it cannot be configured here.

Makes sense. As a suggestion, it would be nice to document such limitations, because currently the switch documentation states (§40.2.1):

Enter a multicast MAC address which identifies the multicast group. The last binary bit of the first octet pair in a multicast MAC address must be 1. For example, the first octet pair 00000001 is 01 in hexadecimal, so 01:00:5e:00:00:0a and 01:00:5e:00:00:27 are valid multicast MAC addresses.

which does give any indication that the reserved MAC addresses are not accepted.