MAC-based VLANs in the ProCurve

In the ProCurve normally only one untagged VLAN is allowed on each switch port. Here’s the reason:

The VLAN ID is carried in the VLAN tag of the Layer 2 (Ethernet) frame, so as long as there’s a VLAN tag in the frame header we can tell which frame is associated with which VLAN. On the other hand in an untagged frame there is no VLAN tag, so there’s no way to tell directly from the frame header which VLAN the frame is associated with. However on a specific port we can always associate that “frame with no tag” with one single VLAN, and we do that by switch configuration. For example:

vlan 3
    name "VLAN3"
    untagged A1
    no ip address
    exit

From the above configuration we know that on port A1, an untagged frame is associated with VLAN 3. All untagged frames at all ports are associated with VLAN 1 by default, unless they are explicitly configured otherwise like in the above example.

Now, MAC-based VLANs (MBVs) use the source MAC address of an untagged frame as the basis for VLAN assignment. Therefore an untagged frame is no longer bound to a single configured VLAN. In this case each switch port can support untagged frames that belong to more than one VLANs.

In the ProCurve, MAC-based VLANs are not configurable, i.e. there is no command to enable or disable or modify it. This feature is used mostly for an authentication server such as RADIUS to allow multiple clients on the same switch port to receive different untagged VLAN assignments. The VLAN assignment for each client is done by the authentication server according to the configured server policy; and in case different untagged VLANs are assigned to clients attached to the same switch port, MBVs will automatically kick in.

A side-effect of this feature is that it allows egress traffic from one client’s VLAN to reach all untagged clients on the same port even though these other clients might not be in the same VLAN. For example, suppose clients A and B are both attached to the same switch port but untagged for different VLANs. Then if A is subscribing to a multicast stream then B will receive the same multicast stream as well.

An important point to remember is that MBVs are not supported on V1 hardware. They are only available on V2 or later hardware. When a situation arises where 2 clients are assigned different untagged VLANs on the same switch port and the switch hardware does not support MBVs, warnings about “untagged VLAN-id arbitration error” will appear in the event log.

Below is an interesting case study:

Two clients, an IP phone and a PC, were connected to the same switch port which was configured to do both MAC-based and 802.1X authentication. The RADIUS server policy was that once authenticated the phone should be assigned to VLAN 5 as tagged, while the PC should be assigned to VLAN 2 as untagged.

The problem was that there was always one client that failed authentication and was dropped from the switch port. In some cases the phone failed, in some other cases the PC failed. In the event log there were warnings such as:

W 07/14/17 09:35:48 02402 dca: macAuth client untagged VLAN-id arbitration error, MAC ………… port A1
W 07/13/17 08:02:27 02402 dca: 8021X client untagged VLAN-id arbitration error, MAC ………… port B2

What added to the puzzle was that out of 5 switches of the same model, 3 switches saw the issue while the other 2 did not.

Here’s what happened:

- The RADIUS server policy was misconfigured, instead of the phone to be put into VLAN 5 as tagged it was configured for VLAN 5 as untagged. This led to a situation where 2 clients were assigned to 2 different untagged VLANs on the same switch port. This was where MBV kicked in.

- However the MBV feature was available only on V2 hardware and later. So for switches that had V2 hardware there was no issue. The switches that had issues were the V1 switches