Splitting a VTP domain to support 802.1x dynamic VLAN assignment.

[silemire]

I'm building a network where I have a large number of switches spread across 3 building, all currently running VTP version 2 under the same domain. Each site has 2 core switches running HSRP. I have to implement 802.1x for wired users on 3750/3560 switches with dynamic VLAN assignment. One of the requirement is to keep VTP in the new network. This is a big problem for me since I cannot configure multiple VLANs with the same name and I don't want to put everyone in the same VLAN spread across all 3 sites.

Is there another solution other than splitting my VTP domain across the three sites just to support duplicate VLAN names? Using 3 VTP domains would mean that I would have to manage 3 sets of MST instance database since we'll be migrating to VTP version 3.

[Peter Paluch]

Hello,

If I understand you correctly you want to have several VLANs having the same name and assign them dynamically to users when authenticating via 802.1X, right?

Well, as to the VTP operation, a VLAN name is not relevant. You may have as many VLANs as you want with the same name. VTP happily accepts that becuse the VLANs are still going to be distinguished by their VLAN ID (their number). So there's no problem with running VTP and having many VLANs share the same name.

Regarding the dynamic VLAN assignment for 802.1X-authenticated users, you should assign the VLANs by their VLAN ID instead of their name. The RADIUS-returned attribute about the VLAN can be either its name or its number - both approaches work. So if you assign the VLANs by their ID, you will avoid ambiguosities because of their shared name.

However, it is recommended to avoid sharing VLAN names for obvious purposes - I suppose you could actually slightly modify the VLAN names to include the site number or identification - nothing extensive, perhaps only an additional letter or a digit.

Would some of these approaches be usable for you?

Best regards,

Peter

[silemire]

Hi Peter,

I have tried configuring multiple VLAN with the same name and the 6500 won't let me:

6500(config)#vlan 400

6500(config-vlan)#name managers

6500(config-vlan)#vlan 401

6500(config-vlan)#name managers

VLAN #401 and #400 have an identical name: managers

6500(config-vlan)#name managers

vlan 402

6500(config-vlan)#name managers

VLAN #402 and #400 have an identical name: managers

6500#show vlan

VLAN Name                             Status    Ports

---- -------------------------------- --------- -------------------------------

1    default                          active

400  managers                         active

401  VLAN0401                         active

402  VLAN0402                         active

Basically, the reason why this dynamic VLAN assignment is a problem for me is that I will have more than 1500 users per VRF and I would like to break those users into smaller VLANs. Since ACS can only map a user to one group, I risk having all my users for a particular VRF in one big VLAN spanned across all 3 sites.

I do appreciate your suggestions, I didn't know the switch could use the VLAN-ID instead of the VLAN name. I guess I could keep one VTP domain, use the same VLAN ID as each site, prune the VLAN on the inter-site uplinks and then assign a different subnet to that VLAN at each location.

Too bad there is no way to do a partial match in the switch on the Tunnel-Private-Group-ID name. That would solve my problems, like I would have VLAN name Employees-A in building 1, Employees-B in building 2, etc.

[Peter Paluch]

Hi,

Okay, I see the problem now. Hmmm... How flexible is the ACS? I can imagine than in FreeRadius, I could match on diverse attributes sent in the Access-Request message, including the identity of the NAS. According to which NAS (in this case, the access switch) a user connects, the Access-Accept response from the FreeRadius would indicate the appropriate VLAN for that building. Is there any possibility to do a similar matching in the ACS?

Best regards,

Peter

[silemire]

I did some research and in ACS 5.2 you can build custom policies and map on groups, network location, etc. I will have to test this in the lab but that sounds like it would fix my problem.

[Peter Paluch]

Hello,

Wonderful. Please be so kind to come back after your lab tests to tell us whether you were able to make it run under the ACS. I would be very interested in learning about that.

Best regards,

Peter