5130 mac-authentication not detecting a device moving

[legoman]

I'm experiencing a curious mac-auth issue, which I think is a bug but wondered if I'd missed a command. Using hybrid ports to assign vlans to mac addresses, so we can have multiple devices on different vlans through the same port. This is necessary because in many locations we're using mini-switches like the NJ5000 to provide additional connections.

Everything works just fine until a device that was plugged into a daisychained switch (be it an NJ5000 or a phone) is moved to another port on the same switch or IRF. 

At this point because the original port doesn't go down, the mac-authentication doesn't detect the device has moved. It is never authenticated in the new port. When the re-auth period comes around the switch continues to authenticate the device on the old port it's no longer connected to. The mac address continues to be listed as attached to the original port, even though it's been moved.

I have raised a support ticket for this, as I think it's a bug... but let me know your thoughts.

[tux_box]

Same Problem here with a HPE 1950 which are somewhat the same switches without cli interface. Clients are not re-authenticated if they move from a daisychained switch behind the mac authentication enabled port to another on a HPE 1950. It only works when the port of the HPE 1950 goes down when the client moves, but this does not happen in that case.  Seems to be a Comware issue, because a Procurve or Aruba 2910 works in this setup.

Any news regarding this case?

[legoman]

After a lot of chasing, this has been a lot of work... it's been labelled as a "driver issue" which has been closed as a case and passed through as a feature request. Personally that has irritated me because if a switch doesn't work as per the documentation that's a bug and should be treated as such.

My simplistic understanding of the behaviour is the mac-table appears to live partially within the vlan. So if the mac address appears on another port, it's initially in our onboarding vlan and therefore the switch seems completely blind to it. Certainly the system drivers don't detect the mac flap and trigger anything to do with the mac-auth.

It continues to be a significant headache for us with issues caused on a weekly, if not daily basis. 

I've just chased this up with our HP rep to see where we're at but nothing back from development as yet.

[tux_box]

Hi Legoman,

and thank you for the quick reply.  Even in my humble opinion it's also clearly a bug, the switch doesn't work as expected, it makes no difference if there are more switches behind a port, a moving MAC should trigger re-authentication or should simply passed on to the new port.

For the procurve series exists a special option for this:

Allowing addresses to move without re-authentication
Syntax:
    [no] aaa port-access mac-based [e] <port-list> [addr-moves]

    Allows client moves between the specified ports under MAC authenticated control. When enabled, the switch allows addresses to move without requiring a re-authentication.
    When disabled, the switch does not allow moves and when one occurs, the user will be forced to re-authenticate. At least two ports (from ports and to ports) must be specified.
    Use the no form of the command to disable MAC address moves between ports under MAC authenticated control.

    Default: Disabled – no moves allowed

Even without this option the procurve switch does make a re-authentication and the MAC is validated, how it should be.

You could go more to edge, the NJ5000 should also have this feature, but your adminisrated zoo would continue to grow...

[tux_box]

One Question: Did you try to enable the the mac-move option?

Enabling MAC move
MAC move allows 802.1X or MAC authenticated users to move between ports on a device. For
example, if an authenticated 802.1X user moves to another 802.1X-enabled port on the device, the
authentication session is deleted from the first port. The user is reauthenticated on the new port.
If MAC move is disabled and an 802.1X authenticated user moves to another port, the user is not
reauthenticated.
An online user cannot move between ports on a device when the number of concurrent logins using
the local username reaches the limit set by using the access-limit command.
As a best practice, enable MAC move for wireless users that roam between ports to access the
network.
To enable MAC move:
Step Command Remarks
1. Enter system view. system-view N/A
2. Enable MAC move. port-security mac-move permit By default, MAC move is
disabled. 

I guess there is no similar option on the HPE 1950 :-(...

[legoman]

Yes, tried that. In fact that excerpt from the documentation was the basis of my argument when Level-4 tried to tell me it was working as designed.

mac-move permit didn't actually do anything at all as far as I can tell. With the situation of a device moving from an intermediate switch mac-auth simply doesn't work but 802.1X always does, even though it shouldn't without mac-move permit.

[tux_box]

Ok, I'm going to open a case for my two HPE 1950 regarding this issue, maybe this starts to hot up the things a little bit...

So long!

[tux_box]

Hi it's me again,

HPE Support told me to enable the "port-security mac-move permit" , which is undocumented and on the HPE 1950 only available in xtd-cli-mode. First tests were successful, a user MAC is re-authenticated when it moves to a new port, on the same time the switch logs that the MAC authentication user was logged off, even when the port doesn't go down, e.g. when a additonal switch is behind the port and the user. So I guess in my case i.e. for the 1950 series it does the trick, it's somewhat odd that it doesn't work on your 5130...

Greetings from Germany!

[legoman]

That's very interesting.... I believe the 1950 is based on comware5 whereas the 5130 is comware7. That further underlines it being an OS driver issue. I might have to do some tests with a comware5 device and see if it works. Just asked our HP tech contact to chase this up with the developers, see if we can get any progress.

I won't hold my breath ;)

[tux_box]

CLI says my software image is 1950-cmw710-boot-r3113p05, so it should also be a Comware 7 OS....

[_biv_]

Please try this:

<SW1>sys
System View: return to User View with Ctrl+Z. 
[SW1]port-security mac-move permit 
[SW1]display port-security

Port security parameters:
   Port security          : Disabled
   AutoLearn aging time   : 0 min
   Disableport timeout    : 20 s
   MAC move               : Permited 
...[snip]...

[dannyvanderaa]

We have the same problem over here.

The port-security mac-move permit was already enabled, but don't help us.

[dannyvanderaa]

Found article on Airheads:

http://community.arubanetworks.com/t5/Campus-Switching-and-Routing/issues-with-mac-move-on-a-5130-with-port-security-issues/td-p/273909

Last answer resolved our issue

[legoman]

Yeah, the comware devs tried to suggest that as an option. It isn't a solution, but a workaround. It might be fine if you have a few vlans. We have hundreds. This doesn't scale... it also doesn't seem to work reliably either.

[legoman]

Interesting this works on the 1950... Hadn't realised they were comware7.

We've had confirmation this is a problem with the 5130. It seems to be related to the comware system drivers talking to the ASIC in the 5130 specifically. It's with the devs, who haven't managed to give our rep any feedback on when this might be fixed.

So essentially we have a 5130 bug here, which doesn't behave as per the documentation. It's causing us reputational damage now, we're very unhappy about it.... but what can you do? We're hopeful of a fix for this bug soon.

[legoman · Accepted solution]

An old thread, but there's a conclusion!

The problem I had is something to do with the way the mac-auth works. Here's my primitive interpretation of what I think is happening (probably incorrect): When a mac address is authenticated it's placed within the vlan returned by radius. When this moves to a different port, it's then attempting to authenticate from a different vlan and that isn't possible... so nothing happens. 

This is one of the reasons why making all vlans available on a hybrid port would sort of make things work in some circumstances.

There's a new code version that we were given at the end of 2017, 3301P01, which has yet to appear on the download site.... 

This contains a feature that allows the mac-auth process to bypass the vlan check so no matter whether there's an existing auth session placing the mac in a vlan, it will do a new auth.

This does actually work, but it requires a config change. At the global level you need: port-security mac-move permit
Then at the port level: port-security mac-move bypass-vlan-check

I'm not sure when this firmware is going to hit the website, we were told it was good for production.