08-18-2016 07:48 AM - edited 08-18-2016 07:50 AM
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:
- dot1x authentication-method eap
- mac-authentication domain system
- port-security enable
- port-security mac-move permit
- 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;
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
08-30-2016 08:10 AM
09-01-2016 06:27 AM
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...
Aruba Customer Engineering
Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base
09-06-2016 02:19 AM
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.
09-15-2016 06:31 PM
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).
09-19-2016 07:48 AM - edited 09-19-2016 07:50 AM
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 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).
2 weeks ago
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.