Comware

Hi guys, I am trying to assing a tagged vlan from micrsoft 2012 nps (radius) to a switch port but I can't find the appropriate attribute on the nps.   To set the vlan id I used the attibute Tunnel-Pvt-Group-ID.  It works fine. But how to tell the hp 5500 that it should be tagged ?  

On the switch, use these commands to set interface g1/0/3 to support untagged traffic on VLAN 1 and tagged traffic on vlan 220:

[HP] interface g1/0/3

[HP-G1/0/3] port link-type trunk

[HP-G1/0/3] port trunk permit vlan 220

If you want to change the untagged vlan to vlan 5:

[HP-G1/0/3] port trunk pvid vlan 5

[HP-G1/0/3] port trunk permit vlan 5

If you only want the port to support tagged traffic in vlan 220, the config would look like this:

[HP-G1/0/3] port link-type trunk

[HP-G1/0/3] undo port trunk permit vlan 1

[HP-G1/0/3] port trunk permit vlan 220

Cheers,

Eric

EricAtHP, I am trying to get the vlan id from the NPS (microsoft radius server). I am using hybrid port. It works fine for

untagged vlan. But now I need to assing a tagged vlan on the hybrid port. I should be assingned by the radius server.

I am not aware of a way to assign a tagged vlan via RADIUS (802.1x or MAC auth, etc.). I have only ever done untagged dynamic vlan assignment. Anyone else have any suggestions.

I did some more research and it is possible on some switches. For example, the HP 5400 and 3800 support RFC 4675 which allows for tagged VLAN assignment as well as assigning a VLAN by name instead of ID, etc. My install of NPS on 2012R2 doesn't have support for RFC4675 built in. That said, it might be possible to edit the dictionary to support it. Here is some info on RFC 4675: https://tools.ietf.org/html/rfc4675. I am not sure how to do it. I don't see support for RFC 4675 on the 5500 but am asking around to be sure.

Thanks Eric. I have hp 5500 switches and I found in the security manual that "Trunk and hybrid ports support RFC 4675-compliant assignment of only tagged VLANs." . You are right, the Microsoft NPS 2012 does not support RFC 4675 and this is my case.  I already tried to insert a Vendor Specific Attribute in the radius policy.   I used vendor-id = 2011 (Huawey),

attribute id=56  ( attribute number in the RFC 4675) and value 0x3100000A  (31->tagged vlan,  "A" number of my vlan (10)).  But it did not work.  I have already tried vendor-id = 11 (HP). The nps sends the parameter correctly but it makes no effect.   

Good to hear that the 5500 supports 4675. I wouldn't have expected the VSA attributes to work. 4675 defines a very specific format for the data fields in attributes 56, 57, 58, and 59. The spec defines it at https://tools.ietf.org/html/rfc4675. I have searched for instructions to modify the dnary.xml file without any luck. I think the next step is to take this up with Microsoft.

If anyone has any suggestions, please let us all know.

Hi ,

I think you need to enable 802.1x on the switch.

HP>dis dot1x
 Equipment 802.1X protocol is enabled
 EAP authentication is enabled
 EAD quick deploy is disabled

 Configuration: Transmit Period   30 s,  Handshake Period       15 s
                Quiet Period      30 s,  Quiet Period Timer is disabled
                Supp Timeout      15 s,  Server Timeout        100 s
                Reauth Period   3600 s
                The maximal retransmitting times    2
 EAD quick deploy configuration:
                EAD timeout:   30 m

 The maximum 802.1X user resource number is 1024 per slot
 Total current used 802.1X resource number is 0

HP> dot1x
 dot1x timer quiet-period 30
 dot1x timer supp-timeout 15
 dot1x authentication-method eap

int gig x/x/x

 port access vlan XXX(guest vlan)
 loopback-detection enable
 loopback-detection action shutdown
 broadcast-suppression 10
 stp edged-port enable
 dot1x max-user 2
 dot1x guest-vlan XXX(guest vlan)
 dot1x auth-fail vlan XXX(guest vlan)
 undo dot1x handshake
 dot1x mandatory-domain xxxxxx.com (FQDN)
 dot1x port-method portbased
 dot1x

Thanks to the guidance in the discussion above, I got this to work using Windows Server 2012 R2 NPS.  I have a very specific use case where I have some hospitality-type APs (HP 527's) with passthrough ports; I needed the switch to automatically tag through the VLANs I might need on the switch ports on the 527.

The attributes in RFC 4675 are RADIUS-Standard attributes; no amount of tinkering with vendor-specific attributes (which is actually atribute ID 26) will cause them to be passed to the switch correctly - unless you're using the pre-standard ProCurve attributes.  It would therefore seem that the only way to expose the option in the GUI is to hack the dnary.xml file.

This modification described here is of course totally unsupported by Microsoft, and implementing it may cause a rip in the space-time continuum. Or not.

If you do go ahead with hacking away at dnary.xml, MAKE A BACKUP BEFORE YOU MAKE ANY CHANGES! 

I added the bit below to the dnary.xml file on my 2012 R2 server.  I'm not sure whether it makes a difference where you place the text, as long as it's at the same level as the other Attribute entries.  It made sense to me to put it between attributes 56 & 60.  (Yes, I had to reboot for it to take effect; not sure how else to trigger a reload of the dnary.xml file.)

 <Attribute>
  <ID>56</ID>
  <Name>Egress-VLANID</Name>
  <Syntax>OctetString</Syntax>
  <MultiValued>1</MultiValued>
  <Is-Security-Sensitive>0</Is-Security-Sensitive>
  <IsAllowedInProfile>1</IsAllowedInProfile>
  <IsAllowedInCondition>0</IsAllowedInCondition>
  <IsAllowedInProxyProfile>1</IsAllowedInProxyProfile>
  <IsAllowedInProxyCondition>0</IsAllowedInProxyCondition>
  <LDAPName>msRADIUSEgress-VLANID</LDAPName>
  <IsTunnelAttribute>0</IsTunnelAttribute>
 </Attribute>

Once in place, I was able to add the Egress-VLANID attribute as a setting under Standard RADIUS attributes, and add multiple tagged VLANs inside it.  For my specific use case I used it in the Connection Request Policy, but the settings can be set in a Network Policy as well.  The 2530 ProCurve switch I used this on happily accepted and applied the values, provided *all* the VLANs are defined on the switch.  I will be testing more on Comware soon; the HP 830 Unified-WLAN I tested on did not seem to support RFC 4675, but the manuals for the 5120 (Comware 5) and 5130 (Comware 7) do explicitly mention RFC 4675 compliance so I'm hopeful they'll work.

In the screenshots below, I set the PVID and Untagged VLAN to 500, and tag VLANs 501, 502, 504, 506, 508, 510, 511 and 512.

Just some feedback on this following raising a support incident: this particular feature does *not* work on Comware 7 switches yet (as of December 2015.)  I must have looked in the wrong document when I thought I saw mention of the 5130 supporting it.  The 5120 and 5500 (Comware 5) switches support it, as documented in the 5120 Security Configuration Guide.

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

It's a bit disappointing that this arguably premium switch lags behind feature-wise, but I'd admit that it's a niche capability.  I'll be submitting a feature request, but given that it already correctly parses the EGRESS-VLANID attribute, I suspect the feature is already in the works.

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

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?

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?

---

@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

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.

---

@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

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?

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

OK that is very interesting.

Can you provide an example config for guidance please?

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.

I have just found an old 2530 I can use, so will test with that and see how it goes.

FYI the use case is that a customer wants to be able to roll out some cloud managed APs across a campus without worrying about where they are patched, so needs to be able to deliver a specific untagged management network and a bunch of tagged VLANs for specific wifi networks based on identifying the APs by MAC address.

Regarding the support for RFC4675 the 5120 does seem to accept the relevant radius attribute, but only with a single VLAN and it doesn't work (in my testing) in combination with a standard RFC3580 response (Tunnel-Private-Group-Id).

Yeah, had a similar requirement at two remote sites (main sites are all controller-based) but as mine was only for a handful of APs I was able to justify configuring those ports statically.

The symptoms you're seeing sounds similar to what I saw on the 5130, but I can't say for sure.

If you can get it working on the 2530 you may decide to raise a support incident for the 5120, but I would still start looking at alternatives in parallel.  Incredibly useful as it seems, RFC 4675 does not seem to have wide adoption.