2

Scenario

I have an environment with several hundred wireless devices. I am trying to break down a fairly large network into several VLANs. There are wireless devices in carts (groups of 30) that I would like to have in their own private VLANs. It seems that MAC-based assignment would be the logical approach.

Question

How can I accomplish MAC-based VLAN assignment for wireless devices?

Information

  • I have some experience with VLANs and subnetting, but I'm not as familiar with RADIUS, GVRP, or similar technologies.

  • We are a Meraki shop for AP's

  • We run HP 2510 switches

Research

Meraki Documentation (including some RADIUS stuff)

Meraki VLAN Tagging Documentation

From the latter link (specifically regarding user-based assignment) I found this information which may be helpful, but I do need MAC-based assignment and not user-based.

The RADIUS server returns a group policy attribute (e.g., Filter-ID) in the Access-Accept message. The group policy attribute specifies a group policy that should be applied to the wireless user, overriding the policy configured on the SSID itself. If the group policy includes a VLAN ID, the group policy’s VLAN ID will be applied to the user.

Other Information

If any important details were left out, please comment and let me know. I'll add any information needed promptly. Thank you!

Improve this question
6
  • I guess you've pretty much nailed it: you need 802.1X authentication via RADIUS and assign the VLAN ID on the server. On the 2510 and all APs you need to configure the up/downlinks as VLAN trunks. Commented Jul 5, 2017 at 17:24
  • 1
    Are you sure you really need VLAN assignment by MAC? It sounds nice, but setting up RADIUS and 802.1x is not a simple thing. Maybe there are easier ways to accomplish what you really need. Do you really need private VLANs? Commented Jul 6, 2017 at 14:20
  • @RonTrunk We use a program that generates large amounts of broadcast traffic that doesn't need to reach beyond each cart. It's just part of our environment, so we would like to use VLANs to solve the problem. It's not simple but we would like to accomplish that level of segmentation in order to reduce unnecessary traffic across the LAN. Commented Jul 6, 2017 at 17:47
  • @trademark Based on your description I don't think you really mean "private VLAN" (in Cisco terms). Are you planning to prevent data going from one VLAN to another? Or are you just trying to limit broadcasts? Commented Jul 7, 2017 at 12:06
  • 1
    Ron's right to suggest caution. A VLAN broadcast is still a WLAN broadcast. In fact by having multiple VLANs you may have just increased the sum total of WLAN broadcasts, and thus reduced the throughput of the WLAN even further. Commented Jul 12, 2017 at 4:48

1 Answer 1

Reset to default
1

Answer

I wound up realizing that MAC-based VLANs isn't really what I wanted, and that Group-based VLANs are actually much more flexible. From here on out, the information will regard to accomplishing VLAN assignment based on group membership.

Bench Test

I followed this really great guide published by Meraki. It is 99% generic so if you're not a Meraki shop don't worry. There were just 2-3 settings to change in the Meraki and you can probably translate that into your system easily enough.

  • Windows Server 2012 R2 (in VMware Workstation)
    • Domain Controller
    • DHCP
      • 192.168.3.1 /24 (primary scope)
      • 192.168.4.1 /24 (scope will be used for VLAN 400)
      • 192.168.5.1 /24 (scope will be used for VLAN 500)
      • Option 3 (Router) set to point to Aruba switch (192.198.3.6)
    • DNS (standard setup)
    • Certificate Services
      • (I followed this guide. Skip the part where they have you test revoking a cert. It made a bit of extra work)
    • NAP
    • Connected to port 1 on the switch
  • L3 Aruba 2920-24G Switch
    • Configured for routing inside test network (but not out to the Internet)
    • Don't forget IP helpers
    • sho config listed below for reference
  • Cisco Meraki MR18 WAP
    • Connected to port 3 on the switch
    • Configured to use RADIUS (link in comments...I'm new to this stackexchange network and I can't post more than 2 in the body)
  • 2x Lenovo ThinkPad 11e Laptops (wireless clients to test with)
    • Joined to domain
    • Named "WIRELESSLAPTOP" and "WIRELESSLAPTOP2"
  • AD Structure
    • OU: "Test Machines" containing both laptops
    • OU: "VLAN Assignment Groups"
      • Group: "VLAN 400" with member "WIRELESSLAPTOP2"
      • Group: "VLAN 500" with member "WIRELESSLAPTOP"

Result

Following the guide and then expanding a little, I wound up with three network policies. There is a VLAN 400 Policy which injects the VLANID 400 into the RADIUS-ACCEPT packet, and there's a VLAN 500 Policy which works the same way. There is also a required default policy of sorts (explained in the guide). Each of these policies has a "Conditions" list, and that is where you assign that policy to a group. Just stick your computers in that group and they'll be good to go.

Now when I connect these two laptops to the network, one lands on the 400 VLAN and gets a 4.x address, and the other lands on the 500 VLAN and gets a 5.x address. These assignments can be changed as easily as group membership.

I believe this will be a pretty robust solution for us moving forward. Note to the reader, this is a complex solution so while the manageability is nice, be sure it's something you'll need and use before introducing several new layers of complexity into your environment.

sho config placed here for reference ; J9727A Configuration Editor; Created on release #WB.16.03.0004 ; Ver #10:08.3f.f3.b8.ee.34.79.3c.29.eb.9f.fc.f3.ff.37.ef:86 hostname "HP-2920-24G-PoEP" module 1 type j9727a gvrp ip route 0.0.0.0 0.0.0.0 10.1.30.1 (config for routing to the production network) ip routing snmp-server community <removed> unrestricted oobm ip address dhcp-bootp exit vlan 1 name "DEFAULT_VLAN" no untagged 5,15 untagged 1-4,6-14,16-24 ip address dhcp-bootp exit vlan 300 name "aovlan" untagged 5 (this is an uplink to our production environment. Not currently in use) ip address 10.1.30.100 255.255.255.0 exit vlan 400 name "TestA" tagged 3 (this is where the AP lives) ip address 192.168.4.1 255.255.255.0 ip helper-address 192.168.3.1 exit vlan 500 name "TestB" untagged 15 (port 15 was used in previous testing...not really important here) tagged 3 (this is where the AP lives) ip address 192.168.5.1 255.255.255.0 ip helper-address 192.168.3.1 exit device-profile name "default-ap-profile" cos 0 exit activate software-update disable activate provision disable ----------
Improve this answer
5
  • RADIUS attribute configuration guide documentation.meraki.com/MR/Client_Addressing_and_Bridging/… Commented Jul 12, 2017 at 14:54
  • Fixed your formatting. Now that you've separated your traffic into VLANs, now what? Commented Jul 12, 2017 at 15:07
  • @RonTrunk Thanks for the format fix! I was mostly asking what sort of approach to take, and I documented the one which seems to work nicely. As far as where I go now, I'm going to look to implement it in that building and hopefully enjoy fewer addressing problems, smaller networks, and smaller broadcast domains. Does that answer your question? Commented Jul 12, 2017 at 15:18
  • You should accept your answer so that the question doesn't keep popping up forever, looking for an answer. Commented Jul 12, 2017 at 16:10
  • 1
    Fair enough. Just be aware, as @vk5tu mentioned, that VLANs will not reduce broadcasts on your wireless network. Commented Jul 12, 2017 at 17:17

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.