Mac-based VLAN Assignment on switches


I’d like Mac-based VLAN assignment in a peplink switch which corresponds to the DHCP reservations on my balance 305.

I want to be able to set a single rule and have all-ports on all-switches behave as trunks that tag untagged macs with the prescribed vlan. None of this managing specific ports business. I think I can’t be the only person who is in charge of a large campus but can’t afford the staff to assign a permanent switch-port babysitter.

I have been experimenting with several kinds of switches (including the peplink switch). The traditional way to assign a wired mac to a vlan is using ‘access’ rules on a switch port or by using 802.1X and dynamic vlan assignment.

Access rules are difficult for us because we have a non-traditional network structure due to our sprawling theme park campus that makes managed switches everywhere impractical. We cannot physically lock up every switch. And we use technicians that often will switch cables around ports. Maintaining cable-port mapping is not feasible.

Multi-session 802.1X is poorly implemented across most manufacturers (including peplink). We’ve suffered from bricking during power failures because booting switches cannot access the radius server. Or switches don’t periodically re-authorize to check if a vlan has changed. At minimum, downlink ports have to be excluded from such 802.1X port rules to avoid re-authorizing already authorized macs. Also, most manufacturers put a limit on the number of macs that may be authorized on a port.

A few manufacturers have “mac-based vlan” as an option. This feature is very useful as 1) the list of macs are stored locally on each switch which avoids any disruption connectivity issues, 2) the list is not port specific, but is applied to any untagged packets coming into the switch. However, most manufacturers have a limit of macs which can be stored on each switch (128 netgear, 256 cisco) and in some cases do not allow natively tagged vlan packets and mac-based tagging to occur on the same port.

In order to use the mac-based vlan option, I have to write a script which frequently 1) gets the current list of dhcp reservations from my peplink balance, 2) checks each managed switch mac-address table to discover if any macs from the dhcp reservations table are coming in on non-uplink ports, 3) synchronize the mac-based vlan table on the switch with the applicable peplink dhcp table. This is made difficult because the switches limit the number of mac-based vlan entries they can have. (it is fewer than the dhcp reservations I have)

I have to imagine that switch maintenance and vlan-mac mapping is a huge task for many IT professionals. It would be WELL WORTH the $$ to switch all my switches to peplink switches if you solved this issue for me and made this an automatic integration with the balance.

Honestly, if not for mac-vlan mapping, I would just install unmanaged switches everywhere. Managed switches are a pain. Perhaps I’m off-base here, but I think you can simplify most L2 switching requirements to this one task.



You bring up some interesting points, can you PM me your script that you use on the other vendor , maybe we can come up with something together.

1 Like

Steps to OWN the small/medium -sized business market:

Step 1) Implement mac-based VLAN mapping on the switch (see netgear, cisco, juniper, fortinet, …)
Step 2) Allow mac-based VLAN assignments to take place on a port regardless of ‘trunk’ or ‘access’ status. I want to set ALL switch ports with this mac-based vlan mapping policy. (This would be enough that I’d buy your product at install it everywhere)
Step 3) Allow an unlimited list of mac-vlans to be mapped in a local ‘mac-based vlan’ switch table. As hardware allows, only match a subset of these that are currently arriving to the switch untagged (you are smart). Notify via log if number of macs being locally tagged exceeds hardware ability.
Step 4) Allow switches to be adopted in peplink router, just like APs.
Step 4a) Synchronize VLANs in switch with VLANs in peplink router.
Step 4b) Synchronize ‘mac-based vlan’ switch table with ‘dhcp reservation macs’ in peplink router.
Step 5) Market this unit as having the ability to replace entire IT departments.
Step 6) Profit.


Agreed. Step 4a and 4b alone would markedly reduce config time.

1 Like

Agree with you Ben_Adams.

Step 4 + 4a is already sort of done via IC2.

Ideally all these features could be implemented both on local and IC2 level.

1 Like

I think the features built into modern switches benefit the 2004 IT professional. We’re not configuring standalone switches anymore. All the information needed for a switch with vlans and port security is known by the router. Yet somehow these two need to be configured separately. (to great agony)

The ‘high level’ information needed:

  • Vlan ids
  • The macs you want on each vlan

Bam! Why all this monkey business with assigning vlans to specific ports using access rules? ACLs? Or the most unholy of unholies, 802.1x?

1 Like

Yes – if – and that is a “big if” – one can use IC2. Sadly, Peplink has built vital functionality into a wide variety of products but required IC2 to take advantage of it.