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....