Deploy tagged vlans to ports with UAM as part of a service?

[NeilR]

Not seeing any capability or reference in docs to add VLAN tagged settings to a port on succesful authentication.

I can set a port as untagged, but not add tagged for a single or multiple vlans to a port where no tags are set.

Did I miss this capability in IMC or is it not there? 

I can do it in PCM - a handy feature, which I use in my current configurations.

thx

[Pack3tL0ss · Accepted solution]

Neil,

The ability is there, it's not just built in yet.  It's possible via RFC 4675 which was actually drafted by a couple of HP technologist.  To configure it in IMC: User-->User Access Policy-->Access Device Management-->Access Device Type Select the vendor and click the configure proprietary attributes button.  If it's already there, you are good, if not....

Add

Name: Egress-VLANID

ID: 56

Type: String Type

Max Length: 6

Add

Name: Egress-VLAN-Name

ID: 58

Type: String Type

Max Length: 10

One is obviously used to assign the vlan by PVID the other by name.

Then User-->User Access Policy-->Access Device Management-->Proprietary Attribute

Add a Proprietary Attribute and call it whatever you like

Select Add to Add an Attribute list and select one of the Egress-VLAN attributes you just configured (if they didn't already exist)

Check the box to send the attribute in the Access-Accept and enter the appropriate value which should be

1<VLAN-NAME (string)>  The one indicates tagged use 2 for untagged (but you could just use the built-in function for untagged.

If you chose to send it by PVID I believe the format is <tagged/untagged(0x31 or 0x32)>000<VLAN_ID (as hex)>  Note the 000 is a required pad and is always the same.

Once your proprietary attribute policy is configured You need to configure it as the Proprietary attribute policy in the access service being used to authenticate the client (either as the default or in the access scenario the client would match).  UAM will then send the tagged vlan in the access accept and the switch should add that vlan once the client successfully authenticates.

There is also a proprietary attribute for the procurve gear (what we used before the RFC was drafted)

NAME: HP-Egress-VLANID -- ID 64 and NAME: HP-Egress-VLAN-Name -- ID:65  The rest is the same.

For more on the rfc see

http://tools.ietf.org/html/rfc4675

http://wiki.freeradius.org/vendor/HP

Hope it helps.

PL

[NeilR]

Yes - that works!

Of course like all things iMC I seem to need to circle the block a few times..took me a few tries to realize the proprietary attibutes policy is added on the access scenario - can't add it as the default policy because there is no authentication settings with it

UPDATE: spotted the Default Proprietary Attibute assignment policy option on the left side of access service screen - no scenario necessary needed just for this.

I am using procurve gear and the attributes were not already configured, so I added them no problem. Handy that it can send multiples with the same function - I sent 3 tagged VIDs

I did notice that I could not add attributes to HP Comware or H3C devices (and there were none to query) - do these not support that function?

Thanks so much for that tip. That fills a hole in the toolkit.

Best,

Neil

[Pack3tL0ss]

Glad it helped,  I noticed that the comware/3Com/H3C devices didn't allow, but I had thought that perhaps this was because they must have pre-configured all of the available proprietary attributes, but that doesn't seem to be the case.

I haven't tried RFC 4675 against a comware device to see if it will accept it (I would think so), but you should be able to get around the attribute issue by creating a new vendor using vendor ID 25506 (I used short name HP and Device Type ComwareCustom the combination of the 2 have to be unique).  Then you could change the HPCW access devices to that type and set the attributes.  I didn't test that far to see if there were any gotchas though.

I'll see if I can determine why we can't specify attributes on the comware based gear.

- set the first response as answered if you could, helps other folks searching the forum.

Thanks,

PL

[NeilR]

Fortunately at this time all my access switches are procurve, so good to go. 

I was just using access control to lock exposed trunk ports, But someone could still wireshark them. Now I can turn the tags up with the access.

thx again