Skip to main content

 

Cisco Meraki Documentation

VLAN Tagging

Virtual Local Area Networks (VLANs) allow a single physical Ethernet network to appear to be multiple logical networks. There are a couple of reasons to use VLANs, including:

  • Enhance network security by preventing wireless devices from accessing LAN resources.
  • Increase performance by limiting broadcast domains.

Note that VLAN tagging typically requires a non-trivial amount of LAN configuration on the upstream switches, routers, and firewalls. If the primary motivation for VLAN tagging is the first use case, an administrator should consider using Meraki’s LAN isolation or Custom Firewall rules features.

A typical VLAN configuration might break up a physical LAN by department (e.g., Engineering, HR, Marketing) or by user class (Employee, Guest). The figure below shows an example:

Screen Shot 2012-02-01 at 1.50.58 PM.png

 

VLANs can be port-based (assigning a physical port on a device to a VLAN) or tag-based (tagging particular kinds of traffic with a VLAN tag, as defined by 802.1q). Meraki APs use tag-based VLANs (i.e., VLAN tagging) to identify wireless traffic to an upstream switch/router. When the switch/router sees VLAN- tagged traffic from a Meraki AP, it can apply different policies to that traffic, including access control (e.g., send traffic straight to the firewall for Internet-only access) or QoS (e.g., prioritize traffic on the VOIP SSID). Conversely, when the AP receives VLAN-tagged traffic from the upstream switch/router, it forwards that traffic to the correct client and/or SSID. The AP drops all packets with VLAN IDs that are not associated to any of its wireless users or SSIDs. 

VLAN tagging can be configured either per SSID, per user, or per device type. In either case, the SSID must be configured in bridge mode.

Because a Meraki AP can be sending/receiving tagged data traffic as well as untagged management traffic, all Meraki APs must be connected to a trunk port on the upstream switch/router that is configured to handle any of the VLANs used by the wireless network.

 

Other Considerations

  • For greater security, no SSID should be untagged (i.e., on the “native VLAN”).

  • The amount of broadcast traffic on the trunk port to which the Meraki AP is attached should be limited. Limiting broadcast traffic improves wireless performance.
  • Currently, VLAN tagging is only supported in a deployment in which Meraki APs are used to form a wireless bridge between two wired LANs if they're running MR28 firmware or higher
    • Please contact Meraki Support to enable this feature if it is needed.

Per-SSID VLAN Tagging

When VLAN tagging is configured per SSID, all data traffic from wireless users associated to that SSID is tagged with the configured VLAN ID. Multiple SSIDs also can be configured to use the same VLAN tag. For instance, a single VLAN ID could be used to identify all wireless traffic traversing the network, regardless of the SSID.

You can also have different VLAN tags per-SSID based on AP tags.

VLAN tagging is configured for an SSID under the Configure tab on the Access Control page.

Per-User VLAN Tagging

When VLAN tagging is configured per user, multiple users can be associated to the same SSID, but their traffic is tagged with different VLAN IDs. This configuration is achieved by authenticating wireless devices or users against a customer-premise RADIUS server, which can return RADIUS attributes that convey the VLAN ID that should be assigned to a particular user’s traffic.

 

In order to perform per-user VLAN tagging, a RADIUS server must be used with one of the following settings:

  • MAC-based access control (no encryption)

  • WPA2-Enterprise with 802.1X authentication

 

A per-user VLAN tag can be applied in 3 different ways:

  1. The RADIUS server returns a Tunnel-Private-Group-ID (e.g. 500), Tunnel-Type (VLAN), and Tunnel-Medium-Type (IEEE-802) attributes in the Access-Accept message, which specifies the VLAN ID that should be applied to the wireless user. This VLAN ID could override whatever may be configured in the MMC (which could be no VLAN tagging, or a per-SSID VLAN tag). To have this VLAN ID take effect, “RADIUS override” must be set to “RADIUS response can override VLAN tag” under the Configure tab on the Access Control page in the “VLAN setup” section.
  2. 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.
  3. On the Client Details page, a client can be manually assigned a group policy. If the group policy includes a VLAN ID, the group policy’s VLAN ID will be applied to the user.  

Per-Device Type VLAN Tagging

Group policies can automatically be assigned to different device types such as Android, iPad, iPhone, iPod, Mac OS X, Windows, etc. If the group policy includes a VLAN ID, then group policy’s VLAN ID will be applied to the user and override any VLAN settings for that SSID or user. 

Group policies can also be manually assigned to devices in the in the Monitor->Clients->Edit Details page.

Management Traffic VLAN Tagging

Management traffic is untagged by default between the Meraki AP and the upstream switch/router. In this situation, the wired network must be configured to allow untagged traffic from the APs to the Internet so they can communicate with Dashboard. An AP's management traffic can be tagged by assigning a VLAN alongside its IP address.