Wired Intelligent Edge

Hey everyone,

We are evaluating some 2930M, and had a question that someone might be able to answer for me. 

We are trying to use user-roles. We have that working to a point. The way we have it now, is clearpass returns the hpe: user-role vsa, and the switch accepts it very happily. This is assuming we have the vlan defined on the switch. 

What I would like to do, is have clearpass assign the user-role AND the untagged VLAN. However, when I updated the enforcement profile with the vlan information, the switch complains that the user role is invalid. 

Is this something that can be done, or is it a limitation? 

To assist in explaining what I mean, here is the config for a user-role

User Role Information

Name : Standard_Student
Type : local
Reauthentication Period (seconds) : 64800
Untagged VLAN : 108
Tagged VLAN :
Captive Portal Profile :
Policy : Policy-Standard_Student
Tunnelednode Server Redirect : Disabled
Secondary Role Name :

When I remove the untagged VLAN, and add it to the enforcement profile in clearpass(screenshot attached), i get the user-role is invalid. 

Any ideas? 

Chris 

Did you follow the ClearPass Solution Guide for Wired Policy Enforcement?

I actually looked through it right before I posted, just to make sure. From what I saw, everything in there showed the user-role already having the VLAN defined if using local user roles. 

I understand I could use downloadable user roles and assign a VLAN that way, however, my end goal is to have multiple devices having the same role, but different VLANs. 

My use case being, we have different VLANs for a wide range of  devices, however, they all require a very similar set of ACLs. 

The role should really be the security context and each role would have a VLAN attached. VLAN names are recommended to abstract the VLAN-ID across the environment from a policy standpoint

Examples:

STUDENT
vlan-name student
FACULTY
vlan-name faculty
STAFF
vlan-name staff
MEDIA-PLAYER
vlan-name headless
PRINTER
vlan-name headless
QUARANTINE
Vlan-name quarantine
PROFILE
vlan-name guest
GUEST-REG
vlan-name guest
GUEST
vlan-name guest

That makes sense. Thanks a ton for your clarification. 

---

@cappalli wrote:
The role should really be the security context and each role would have a VLAN attached. VLAN names are recommended to abstract the VLAN-ID across the environment from a policy standpoint

Examples:

STUDENT
vlan-name student
FACULTY
vlan-name faculty
STAFF
vlan-name staff
MEDIA-PLAYER
vlan-name headless
PRINTER
vlan-name headless
QUARANTINE
Vlan-name quarantine
PROFILE
vlan-name guest
GUEST-REG
vlan-name guest
GUEST
vlan-name guest

---

Tim, do you have any suggestion for someone who wants the VLAN names to be unique to each VLAN ID? 

 

For example I use a VLAN ID of 2314 for printers at one site and 2414 for printers at another.  Rather than calling both VLANs "PRINTERS", I like to name them uniquely to avoid any possible confusion, such as "SITEA_PRINTERS" and "SITEB_PRINTERS".

 

Is there any other soluton besides changing my naming convention to be more ambigious(IMO)?

 

It seems like it would work if there was a way to do VLAN translation (I'm thinking of IAP clusters, where I can pass the same VLAN name as a VSA for all sites, but translate it in each site's IAP to the correct VLAN ID).  However, I'm not seeing a way to do this with DURs on the switches.  Wanted to make sure I wasn't missing anything. 

 

My next-best workaround (besides an insane amount of logic and additional enforcement profiles) is to use LURs and define the different VLANs within them on each switch.  For example on SITEA switch:

aaa authorization user-role name "PRINTERS"
reauth-period 86400
vlan-name "SITEA_PRINTERS"
exit

 

And on SITEB switch:

aaa authorization user-role name "PRINTERS"
reauth-period 86400
vlan-name "SITEB_PRINTERS"
exit

 

That way I can just pass back PRINTERS as the HPE-User-Role to all sites.

 

Using switch-specific names completely defeats the point of using VLAN names and will make your ClearPass policy very complex.

Thanks so much for your prompt response!  I've always used VLAN names as an English version of the VLAN ID (coming from Cisco-land it was called a "description"), so this is a new concept I'll have to make peace with I guess (or cause myself some extra work). 

I wish there was an extra description field where I could uniquely describe the VLAN in the switch config while still abstracting the name...that would make me feel better.  :-)

What I tried to do is add the VLAN ID's as an attribute to the NADs in CPPM (because of the VLAN names being specific per stack):

Normally this works if we take that attribute as a variable in our enforcement profile like %{device.attribute} where the value equals the VLAN ID which differs per stack/SER.

Doing that with a DUR the access tracker shows the access list with the right VLAN-ID as output, however the switch downloads a DUR from CPPM (6.7.7) that fails because of the DUR having 'vlan-id = %{device.attribute}' regarding to the switch log. TAC told this is per design and a feature request could be raised.

 

Anyone who could confirm this behavior?

What you are doing with the NAD attributes is how I have the rest of my switches setup. 

With the Aruba DUR, I had to forgo that, and just use the same VLAN Name across all the switches. In our example, I have it as a Building-Default, across all the switches. It works well enough, and hasn't caused any confusion yet.

To put it simply, yes, I encountered the same issue as you, and my workaround was to use the same VLAN Name across all the Aruba Switches. 

Thank you Cwickline!

 

So you also had that variable in the enforcement profile and the access tracker some sort of fooling you filling in the variable with the right value, while the switch receives the %{Device:attribute} (like below)?

I got support from TAC for this, they told this works as designed. I feel like submitting a feature request, would you vote for it? :-)

Variables are not supported in downloadable user roles. You should be using VLAN names.

Ok, clear. Thank you.

 

Regards,

Johan