VLAN Profiles
Overview
VLAN Profiles is a new feature spanning MR and MS as a means to provide both dynamic, RADIUS based assignment of VLANs to devices/users/endpoints based on an alphanumeric name, but also as a means to abstract VLAN IDs from certain elements in Dashboard using relatable terminology instead of numbers.
VLAN profiles can work along with 802.1X/MAB authentication to assign authenticated users and devices to specific VLANs according to a VLAN name rather than an integer. This can reduce the configuration and management burden on the RADIUS server by allowing fewer authentication policies to be used for multiple sites which may use different VLAN IDs for the same functional group of users and devices. For example, sites A and B may both have a "guest" VLAN, which is VLAN ID 100 at site A but ID 99 at site B. Without VLAN profiles, a separate RADIUS policy or rule would normally be created on the RADIUS server for each of site A and site B. With VLAN profiles, a single policy can be created on the RADIUS server which sends the VLAN name "guest" to the switches at each site, which then can map the "guest" VLAN name to the appropriate VLAN ID.
Requirements, guidelines, and limitations
VLAN profiles is supported on the following platforms and firmware versions:
|
Platform Family |
Model | Minimum Firmware |
| MS100 Series | MS120 | MS 15 |
| MS125 | MS 15 | |
| MS130 | MS 15.22 | |
| MS200 Series | MS210 | MS 15 |
| MS225 | MS 15 | |
| MS250 | MS 15 | |
| MS300 Series | MS350 | MS 15 |
| MS355 | MS 15 | |
| MS390 | CS16 | |
| MR WIFI5 | 20/30H/33/42/42E/52/53E/70/74/84 | MR 30 |
| MR WIFI6/E | all models | MR 30 |
| Catalyst C9300 | C9300-M | CS16 |
The VLAN Profiles feature is not available for Meraki Dashboard templates or networks bound to a template.
Key Profile Management Details (please do not skip this section)
- All devices are assigned to the default profile unless explicitly assigned to a non-default profile.
- To add or remove a VLAN name or group, you do so under the default profile, which will then propagate the added/removed profile to the non-default profiles.
- The default profile will always be the source list for every VLAN name and group used in any of the profiles in the network, and is the validation list for Dashboard use across switchports, access policies etc.
- When adding a name or group to the default, the name and ID mapping will automatically get added to every non-default profile.
- Non-Default profiles are intended to allow for VLAN mappings to be overridden from the default, but not intended to provide a completely separate list of names and groups. This ensures that all devices across the network have a common list of names that are selectable for configuration elements or RADIUS based assignment. When a new profile is created, the VLAN name to ID mappings are copied over from the default profile. If the new profile does not require a specific VLAN name to ID mapping to be overridden from the default, the initial values can be left matching the default profile.
VLAN Profiles in Dashboard
VLAN Profiles are a Network-wide configuration as the feature is supported across multiple products (MR and MS).
Configuration
Navigate to Network-wide > Configure > VLAN Profiles. This will bring up the profile assignment page listing each device/switch stack and its assigned profile
Here you can see which profiles are assigned to each switch or switch stack.
Managing VLAN profiles
Click on the VLAN profiles tab. Here you can add, delete, and edit VLAN profiles.
Default Profile
When VLAN profiles are enabled, a default profile is automatically applied to all switches and switch stacks in the network. If a VLAN profile is not explicitly assigned to a switch or stack by an administrator, it will use the default profile. The default profile is indicated by the Default name and Iname values, and on the VLAN profiles tab the (Default) label.
Creating a non-default profile
To create a new profile click "Add VLAN Profile".
Give the profile a unique name and Iname (Iname is used as the API unique ID).
The Iname is used as the unique ID for the profile in the API. It must be unique, and unlike the profile name, the Iname can't be modified after the profile is created.
To edit an existing profile click the edit buttons of the appropriate profile through the 3 dot widget.
Next, create mappings for VLAN names to VLAN IDs. The VLAN name entered is the value that must be sent by the RADIUS server to the switch in order to map to that VLAN ID. When finished. click "Save".
Each profile can include up to 1024 VLAN name to ID mappings, and each VLAN name can be up to 32 characters long. The VLAN profile name itself has a 255 character limit.
You can also map more than one VLAN ID to a VLAN Group using commas or hyphens to separate non-contiguous and contiguous ranges (e.g. 100,200,120-130)
VLAN groups used for RADIUS assignment are limited to 32 VLAN IDs per group. Otherwise there is no limit to the number of VLAN IDs in a VLAN group.
Assigning VLAN profiles
On the profile assignment tab, select the access points, switch(es), and/or stack(s) to assign a profile to.
Choose the profile to apply by clicking the drop down profile menu, then "Assign profile".
Note: VLAN profiles are applied to standalone switches or entire switch stacks. You cannot apply different VLAN profiles to switch members of the same stack (all switches in the stack use the same profile).
Removing non-default profile assignments
You can reassign a VLAN profile assignment from a device or stack back to the default profile. This is done by selecting the devices and assigning the default.
Verifying VLAN profiles
You can verify the VLAN profile applied to a device or stack from the Switching > Monitor > Switches page. If the "VLAN profile" column isn't visible, click the wrench icon in the top right corner of the switch list table and enable the column.
On the switch details page, the VLAN profile is listed in the left hand column below the config status.
VLAN Profiles and RADIUS
VLAN profiles were originally designed to be used only for RADIUS. A RADIUS server can respond back to the authenticator (network device like switch or AP performing 802.1X / MAB) with a name, that is then translated to a VLAN ID to place the device in. A VLAN Group can be used to perform load balancing of clients between the list of VLANs. The load balancing behavior is semi-intelligent, performing hashing to ensure a re-authentication of a client does not bounce them to another VLAN ID in the group, which could result in triggering connectivity issues. The following section walks through how to enable RADIUS support, reviews a use case, and then walks through troubleshooting.
Enabling RADIUS Support
VLAN profiles can be enabled or disabled for use with RADIUS globally for the network. When VLAN profiles are disabled you can still configure and assign profiles, but they won't be deployed to the switch configuration for use with RADIUS until you enable VLAN profiles for the network. This also allows the feature to be temporarily removed from the switches and switch stacks without losing the existing configurations in Dashboard.
Navigate to Network-wide > Configure > VLAN Profiles and choose the Settings tab choose to enable or disable VLANs for use with RADIUS. Then click "Save changes".
Note:
- This can be helpful when testing and/or troubleshooting VLAN profiles with RADIUS.
- The VLAN pool DHCP monitoring configuration is specific to MR and is not applicable to MS as of MS15 firmware.
- MS390s perform DHCP monitoring, and upon 3 clients failing to get and address in a VLAN within 5 minutes, the switch/stack will mark the VLAN dirty for 30 minutes before adding it back to the pool.
How VLAN Profiles work with RADIUS
Example Scenario:
In this scenario, the network is divided into multiple floors, and each floor has different VLAN assignments for the same functional groups (workstation, voice, and IoT devices). Rather than configuring an authentication policy for each floor on the RADIUS server, a single policy can be used that will return the VLAN names to the switches or access points that are acting as the 802.1X authenticator. The authenticators will then map the VLAN names to the appropriate VLAN ID for each floor according to the VLAN profile assigned to the authenticator in the Meraki Dashboard.
In order to use VLAN profiles with MS, an access policy must be first configured and assigned to switchports to authenticate users and devices connecting to those ports. For information on configuring and assigning access policies, see MS Switch Access Policies (802.1X).
The RADIUS server must be configured to send three attributes as part of the RADIUS Access-Accept message sent to the authenticator (switch/AP) as a result of a successful 802.1X/MAB authentication. These attributes tell the authenticator which VLAN name to assign to the session for that user or device. The required attributes are:
[64] Tunnel-type = VLAN [65] Tunnel-Medium-Type = 802 [81] Tunnel-Private-Group-ID = <vlan name>
These are the same three attributes used when assigning a VLAN ID to a 802.1X/MAB session for a user or device. The difference when using VLAN profiles is that the RADIUS server is configured to send a VLAN name rather than the VLAN ID. Here's an example of this usage in Cisco Identity Services Engine:
In the above example, the RADIUS server will return the "WORKSTATION" value to the authenticator (switch/AP), which causes the authenticator to look for a VLAN ID mapping matching that name value. The authenticator will then assign the client to that VLAN based on the Profile assigned to that authenticator.
In the example below, the "WORKSTATION" value could map to VLAN ID 101, 201, 301, or 401 depending on which profile the authenticator has applied.
If the RADIUS server returns a name that is not defined in the VLAN profile, the switchport will fail-closed and the client device will not be able to access the network. If the RADIUS server returns a VLAN ID, the switchport will be authorized as an access port in that VLAN.
Also, when using multi-auth mode, multiple devices may be connected to each port, but each connected device is required to authenticate (all MS excluding the MS390**). After a VLAN is assigned to a host on the port, subsequent hosts must have matching VLAN information or the switch will deny access and those sessions will fail closed (the first session will remain active). Only one client is supported on the voice VLAN. Guest VLANs are not supported in this mode.
** Note: The MS390 allows for multiple devices behind a multi-auth port to have different VLANs assigned to each session. This means when multiple hosts authenticate to a single port on the MS390, each host may be assigned a unique VLAN to their session. For example, the first host to authenticate on a switch port might be assigned to VLAN 3, and a subsequently authenticated host may be assigned to VLAN 5.
Troubleshooting VLAN Profiles with RADIUS
As with most things RADIUS related, there are 4 places to look for troubleshooting information.
- The RADIUS server and the authentication/authorization logs. For Cisco ISE, this would be under Operations > RADIUS > Live Logs
- The authenticator (Switch or AP) event logs
- The endpoint/client device to validate the IP addressing it received
- A packet capture done between the authenticator and RADIUS server to peek at the info sent from the RADIUS server
Note: For guidance on RADIUS server troubleshooting and/or client device/endpoint troubleshooting, please refer to the appropriate documentation for those products.
Cisco Identity Services Engine Live Logs (example)
This section is just an example of using Cisco ISE, it is not the most comprehensive guide and thus for detailed troubleshooting please see the Cisco ISE troubleshooting guides created by the ISE team.
To view the AAA logs in Cisco ISE navigate to Operations > RADIUS > Live Logs, and search for the endpoint/device that is being used for troubleshooting. This can be filtered using the Endpoint ID and populating all or part of the client's MAC Address. Once filtered, find the log line with a green checkmark and click the magnifying glass as seen in the example below.
A new window / tab will open with a lot of information. Scrolling down to the bottom section labeled "Result" will show the response sent from the RADIUS server to the authenticator (switch in this case).
We can see here that the Tunnel-Private-Group-ID shows the VLAN name of WORKSTATION.
MR Named VLAN / VLAN Pooling / VLAN Blocking
- Navigate to Network-wide > Configure > VLAN Profiles and choose the Settings tab.
- Choose to enable or disable VLANs for use with RADIUS.
- Click "Save changes".
The VLAN pool contains multiple VLAN IDs. If a specific VLAN experiences a client connection issue, such as repeated DHCP failures for a single client, it may be temporarily blocked before being reassigned.
- In the dashboard, navigate to Wireless > Configure > Access control.
- Select the desired SSID from the drop-down menu.
- Under Security, select Enterprise with and choose any 802.1X authentication framework.
4. Under RADIUS, click Add server.
5. Enter the following information and click Done:
- Host IP or FQDN - Public IP address or Fully Qualified Domain Name of the RADIUS server.
- Auth Port - UDP port that the RADIUS server listens on for access requests, typically 1812.
- Secret - RADIUS client shared secret (if a RADIUS server has not been configured yet, select a shared secret here and make note for later).
6. Within Client IP and VLAN select External DHCP server assigned and SSID is set to Bridged mode.
7. Allow Radius override to override the VLAN tag with the RADIUS response
.png?revision=1)
8. Within VLAN tagging, select your VLAN attribute type:
- Named VLAN - Wireless, Employee
- VLAN ID - VLAN ID i.e. 10
- None - Use mapping
This will determine what attribute we accept from RADIUS. VLAN ID will accept the IEEE standard attributes 64/65/81, Named VLAN will support the IEEE standard as well as the Airespace-Interface-Name VSA
The Default Access Point Tag is used when there is no RADIUS attribute sent, or we do not have a mapping for the sent attribute. This can be controlled per AP tag if you are using tags to differentiate where Access Points are located.
Note: The assignment of multiple VLAN values to a single Named attribute (VLAN Groups). VLAN ID would be assigned round-robin from the defined pool of VLANs.
Meraki Dashboard Troubleshooting for VLAN Profiles
Event Logs:
To look and see the applicable logs associated from the network device's perspective navigate to Network-wide > Monitor > Event log. For switching and wireless there is a filter for "All 802.1X" and "All client events" which will filter the logs to the necessary events. Example:
As seen there are logs showing 802.1X and RADIUS dynamic VLAN assignment. In this case, the switchport has multiple clients behind it, so we see a log stating there is a Multi-Auth VLAN Restriction to the WORKSTATION VLAN, showing the username and port as well as the Session ID.
Switch Port Details
Under the MS port 13 in this example we can see the client, its IP Address, and the VLAN ID assigned.
Note: At times there are 2 client entries for the same MAC Address. This is purely cosmetic and does not mean there are multiple clients using the same MAC address.
Switch Detail VLAN Profile Assignment
To validate the switch's VLAN Profile assignment, either navigate to VLAN Profiles > Profile assignment or in this example, under the switch details page there is a field for VLAN PROFILE under the switch's information.
VLAN Profile Mapping Review
To check the mappings, navigate to Network-wide > Configure > VLAN Profiles and click the arrow next to the applicable profile to drop down the details. Here we can see WORKSTATION is mapped to VLAN 401 as is the client above.
Packet Capture Walkthrough
When trying to troubleshoot issues with VLAN Profiles, it can also be advantageous to perform a packet capture on the authenticator's uplink port, bouncing the switchport where the client is connected, and waiting for the 802.1X / MAB process to complete before stopping the capture. In this example the switch's uplink port is port is port 24 as indicated by the arrow in the interface.
To obtain a packet capture, either navigate to Network-wide > Monitor > Packet capture, or under the switch port's details page scrolling down to Troubleshooting:
This will automatically take you to the Network-wide > Monitor > Packet capture along with a filter on the switch and port (24 in this case).
To filter the capture to only capturing RADIUS traffic (essential for busy networks to ensure the packet capture grabs the right information) you can populate filters for traffic. In this example we are filtering the standard RADIUS ports for authentication (1812/1645), accounting (1813/1646), and Change of Authorization (1700/3799).
port 1812 or port 1813 or port 1645 or port 1646 or port 1700 or port 3799
Start the packet capture (it may be necessary to increase the capture timeframe to a few minutes - 300 seconds is a safe value as long as there is a good filter in place).
Next open a separate tab, navigate to the client port, and under the Troubleshooting section, cycle the port:
Using Wireshark
Once the packet capture is complete, open the .pcap file in Wireshark. If you do not have it installed please see https://www.wireshark.org/download.html.
Under the Access-Accept packet (packet 5 in this capture above) if you drop the Attribute Value Pairs section down, there is the field for Tunnel-Private-Group-Id where the VLAN name or ID will be populated, and in this case is set to WORKSTATION.
Using Dashboard's tcpdump display
If installing Wireshark is not possible, Dashboard has a tcpdump functionality that can also be used to spot check the response from the RADIUS server. Instead of download .pcap file, select View output below and set the verbosity to medium:
Once the capture is started, cycle the port the client is connected to, and watch the output under the packet capture page for things to complete. Then parse the output for the Access-Accept packet and the Tunnel-Private-Group-ID attribute:
