Wired Intelligent Edge

A 5130 switch is configured to do 802.1X and Mac-authentication on all ports.
One of these ports is connected to an unmanaged switch (HP 1410).

Behind the unmanaged switch is one laptop and one printer connected.
- Laptop is doing 802.1X with certificates
- Printer is doing Mac-Authentication

current config of the 5130 switch:
 Global:
 - dot1x authentication-method eap
 - mac-authentication domain system
 - port-security enable
 - port-security mac-move permit
 Per Port:
 - undo enable snmp trap updown
 - port link-type hybrid
 - port hybrid vlan 1 untagged
 - mac-vlan enable
 - poe enable
 - undo dot1x handshake
 - undo dot1x multicast-trigger
 - dot1x critical vlan 2
 - dot1x re-authenticate server-unreachable keep-online
 - mac-authentication re-authenticate server-unreachable keep-online
 - mac-authentication guest-vlan 3
 - mac-authentication guest-vlan auth-period 300
 - mac-authentication critical vlan 2
 - port-security port-mode userlogin-secure-or-mac-ext
 - loopback-detection action shutdown

When I move these clients and connect them directly to the 5130 switch mac-move is NOT triggered.
Important: the unmanaged switch is not disconnected from the 5130!
HPE advices to enable "mac-vlan trigger" on each port;
 - http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c03734767

This seems to work great for 802.1X clients, but not at all for MAC-Authenticated clients.

802.1X Client (Laptop): (mac-vlan trigger enabled)
 - Client connects to port
 - Client reauthenticates
 - Switch logs of the old session and deletes old mactable-entry of the old port
 - Switch Creates new session and creates new mactable-entry on the new port

Mac-authenticated Client (Printer):
 - Client connects to port
 - Switch wait to mac-address to time-out and offline-detect (15 min.) to kick-in and logs off current session and mactable-entry of the old port
 - With mac-vlan trigger enabled
     - Switch learnes MAC-address and creates mactable-entry instead of doing radius reauthentication.
 - With mac-vlan trigger disabled
     - Switch triggers radius reauthentication
     - Switch creates new session and creates new mactable-entry

So my issue:

I need mac-move for both authentication methods to work.
 - direct move to other port
 - re-authentication at all time

@networkingdvi @networkingdvo @CMDumitrache

Do you know who might help with the above situation?

remi.batist@axez.nl You should be able to also see an escalation button on top of the thread if you do not receiva an answer.

Would you please let me know if this is visible for you?

Bedankt

Cristina

It is entirely possible that this is a bug that is fixed in the latest version of code:

""201606230218: Symptom: Dynamically learned secure MAC addresses of a port cannot be deleted after the
port goes down."  Please contact TAC if you can...

Hi Colin Joseph,

thank you for your response!

it seems that the latest firmware for the HP5130EI with "201606230218" is not yet posted on the web.

Last week I created a case @ HPE. I hope they can help me with this one.

Regards,

Remi

Hi Remi,

To solve the "re-authentication at all time" problem, disable the handshake check on the switch: undo dot1x handshake enable (Disable and enable the dot1x globally after you applied the previous command).

Just got some good input for HPE support, which resolved the problem.

By simply adding the 'authorized vlans' to the ports tagged or untagged,

depending on your needs.

For example;

for printers in vlan 100: "port hybrid vlan 100 untagged"

for laptops in vlan 200: "port hybrid vlan 200 untagged"

Even though adding vlan's is not required for mapping devices in vlans assigned by a remote Radius server, it seems to be required when moving devices between ports(mac-move).

Thanks for sharing remi.batist@axez.nl and good to hear that this is solved!

A thought on this. It isn't really a solution, it's a workaround and it doesn't scale. So we have dozens of vlans on all our switches. This config would lead to broadcast traffic from all our vlans hitting all ports of the 5130 stack. This just isn't an option.

Having chased this for a long time now my understanding is this is a problem with the OS drivers talking to the ASIC in the 5130. I'm hopeful of a fix for this bug, but certainly not holding my breath.

For anyone struggling with this, the bottom line is this aspect of the 5130 doesn't work correctly at this time. It's a fairly niche use case, but nonetheless the switch does not behave as per the documentation.