Dymanic TAGGED vlan assingment hp 5500

[Jannie Hanekom]

In an interesting twist to my story, I just found out that HP implemented the Comware concept of "MAC-based VLANs" on ProCurve switches as of the 15.16.006 software stream (~March 2015.)

MAC-based VLANs provide me with the functionality I need for my particular use case, and the fact that I can now use it as a common mechanism across both switch platforms is a deal clincher.  Not to mention that it simplifies the conditional logic on my NPS rules tremendously - I simply deal with each device individually and pass it's VLAN back using the standard Tunnel-Pvt-Group-ID attribute;  the switch takes care of the rest.

 (MAC-based VLANs are enabled by default on supported ProCurve switches and - for the moment - it does not seem that it can be configured in any way.  There are "mbv"-related commands in the CLI but these don't seem to do anything at the moment.  The feature just "works".)

[DannyAa]

Dear Jannie.

You wrote:
It "almost" works on the 5130; debug output indicates it already understands the EGRESS-VLANID attribute, but it cannot yet tag multiple VLANs on a port.  It only actions the last VLAN-related attribute in the RADIUS response (whether that is the last in a list of EGRESS-VLANIDs or a Tunnel-Private-Group-ID attribute.)

Do you know this is solved in the latest version of the Commware7 (5130) switches?

[IanTomkins]

I have been testing this on a 5120 switch running the latest release code (2221P25) and found that the feature seems to be broken.

The problem I am finding is that it seems the switch will only process a single VLAN radius attribute, either untagged specifed via Tunnel-Private-Group-Id or a tagged vlan specified via Egress-VLANID or Egress-VLAN-Name.

When the radius server provides more than 1 radius attribute defining a VLAN the switch only uses the last one in the response which makes the feature pretty useless.

Has anyone made this work with comware switches?

[Mike_ES]

---

@IanTomkins wrote:

I have been testing this on a 5120 switch running the latest release code (2221P25) and found that the feature seems to be broken.

The problem I am finding is that it seems the switch will only process a single VLAN radius attribute, either untagged specifed via Tunnel-Private-Group-Id or a tagged vlan specified via Egress-VLANID or Egress-VLAN-Name.

When the radius server provides more than 1 radius attribute defining a VLAN the switch only uses the last one in the response which makes the feature pretty useless.

Has anyone made this work with comware switches?

---

Hi,

Are you using hybrid port for access in this scenario?

Michal

[IanTomkins]

Yes I have tried with both Hybrid and Trunk ports.

I have also tested this with both Mac and 802.1x auth and with and without mac-vlan.

[Mike_ES]

---

@IanTomkins wrote:

Yes I have tried with both Hybrid and Trunk ports.

I have also tested this with both Mac and 802.1x auth and with and without mac-vlan.

---

Ok, looks like the problem was resolved with the following (mac-auth host-mode) :

mac-authentication host-mode

Use mac-authentication host-mode multi-vlan to enable MAC authentication multi-VLAN mode on a port.

Use undo mac-authentication host-mode to restore the default.

Syntax

mac-authentication host-mode multi-vlan

undo mac-authentication host-mode

Default

MAC authentication multi-VLAN mode is disabled on a port. When the port receives a packet sourced from an authenticated MAC address in a VLAN not matching the existing MAC-VLAN mapping, the device logs off and reauthenticates the user.

Views

Layer 2 Ethernet interface view

Predefined user roles

network-admin

Usage guidelines

The MAC authentication multi-VLAN mode prevents an authenticated online user from service interruption caused by VLAN changes on a port. When the port receives a packet sourced from the user in a VLAN not matching the existing MAC-VLAN mapping, the device neither logs off the user nor reauthenticates the user. The device creates a new MAC-VLAN mapping for the user, and traffic transmission is not interrupted. The original MAC-VLAN mapping for the user remains on the device until it dynamically ages out. H3C recommends that you configure this feature on hybrid or trunk ports.

This feature improves transmission of data that is vulnerable to delay and interference. It is typically applicable to IP phone users.

Examples

# Enable MAC authentication multi-VLAN mode on FortyGigE 1/1/1.

<Sysname> system-view

[Sysname] interface fortygige 1/1/1

Michal

[IanTomkins]

Michal, I have tried using the "mac-authentication host-mode multi-vlan" having found it whilst scouring release notes but unfortunately it did not solve the problem for me.

Have you actually tested this solution?

[Mike_ES]

This multi-vlan functionality works fine on the 5130 switch (Comware 7)

[IanTomkins]

OK that is very interesting.

Can you provide an example config for guidance please?

[Jannie Hanekom]

This most definitely did *not* work when I tried it on the 5130 towards the end of last year (can't remember exact release, but it was current as of November.)  I even raised a support case (case 4653071508) where support confirmed that the 5130 does not provide RFC 4675 compliance.  Yes, arguably that was a Level 1 support brush-off, but the point is that there is no formal claim that the switch supports it.

I've looked through all 523 pages of the historical software feature changes documented in the release notes for 5130_EI_7.10.R3113P03 (June 2016) and can find no mention of RFC 4675 compliance being added over time, so I have no reason to believe things would have changed.

The 5120/5500 documentation *does* list RFC 4675 compliance, so I would expect it to work.  Unfortunately I am not in a position to verify it works in my environment at the moment.

Ian, are you in a position to test your setup on recent-model ArubaOS (nee Provision, Procurve) switches such as the 2530 or 2920?  Those definitely sport RFC 4675 compliance and I was able to make it work on them quite readily.  Just as a way to rule out any issues with the way your RADIUS server is formatting stuff...

I'm also somewhat curious about your use case.  Can you provide more details about what you're trying to achieve?  The MAC-based VLAN feature set is incredibly cool and addresses a very large number of use cases that would otherwise have required RFC 4675-type capabilities.