A little-known feature of ADTRAN switches is that 802.1X port authentication, used with a RADIUS server, can be used to dynamically assign hosts to different VLANs. For example, let’s say that you have a group of administrators that should be put into an administrative VLAN regardless of where they actually connect to your network (i.e., if they use another user’s computer, they should still be placed into the administrative VLAN, simply because they are administrators). You can accomplish this by enabling port authentication on the switches in your network and using a RADIUS server for authentication.

The NetVanta configuration is a straightforward port authentication config:

vlan 33
aaa on
aaa authentication port-auth default group radius
radius-server host 10.10.10.10 key 8021x-password
interface switchport 0/1
  switchport access vlan 1
  port-auth port-control auto

Here, we have configured VLAN 33, which will be our dynamic VLAN. Note that we haven’t assigned it to the switch port; it’s only here because it must exist in the VLAN database prior to being dynamically assigned.

Once we have ensured that the VLAN exists in the local VLAN database, there is nothing else that needs to be done on the switch. The rest happens in the RADIUS server. For each user, we need to assign three attributes: 1) Tunnel-Type = 13 (VLAN); 2) Tunnel-Medium-Type = 6 (or 802, both of which refer to Ethernet); and 3) Tunnel-Private-Group=VLAN-ID. When the switch forwards authentication requests to the RADIUS server, the server will respond (if authentication is successful) with these three attributes, so that the switch can dynamically assign the user’s port to the VLAN that is specified in #3 above.

As an example, if you have a FreeRADIUS server, users are configured in the “users” file (/etc/raddb/users). Here is what our administrators would look like:

administrator User-Password = "adtran"
  Tunnel-Type = 13,
  Tunnel-Medium-Type = 6,
  Tunnel-Private-Group-ID = 33

For more information on using 802.1X for dynamic VLAN assignment, check out RFC 3580, section 3.31.

Although rare, there are times that you may want to have hosts in a single VLAN, but isolate the hosts from one another. For example, consider a multi-tenant office building or apartment complex. For security reasons, you don’t want users to be able to communicate with one another, but, traditionally, that would mean that each office or apartment would need to be put into a separate VLAN, and security policies would be applied to the gateway router. Depending on the number of users, this can put a high load on the gateway, both in terms of the required number of IP interfaces, as well as filter processing.

Two common ways to isolate these hosts at Layer 2 include private VLANs and protected switch ports. Private VLANs are most well-known in the world of Cisco, although there are other vendors that support them, as well. In my opinion, private VLANs are a little uglier to configure than they really need to be for basic per-port isolation. For the application described above, consider using protected ports.

The theory behind protected ports is straightforward. Assign specific ports on your switch to be “protected,” and those ports cannot communicate with any other port on the switch that is also protected. However, they can communicate with any “unprotected” port, which is really just a plain access port. For example, if User A, User B, and User C are on ports 1, 2, and 3, respectively, and 1 and 2 are protected ports, then User A and User B can communicate with User C, but not with each other. Going back to the example above, ports 1 and 2 would be connected to different offices or apartments, and port 3 would be connected to the gateway.

The configuration is as straightforward as the theory. On an ADTRAN NetVanta switch, go into switchport or ethernet interface config mode (depending on the platform), and enter the command switchport protected for all protected ports. On ADTRAN switches, no broadcast or unknown unicast traffic will be forwarded between protected ports. On Cisco switches, the command is still switchport protected, but to prevent broadcast/multicast and unknown unicast forwarding, use the commands switchport block multicast and switchport block unicast, respectively. (Note that only access ports can be protected ports.)

I mentioned earlier that protected ports are better for basic configs than private VLANs, which implies that private VLANs are better for more advanced configs. What kind of configs? Well, consider a case where one individual company has a few offices in a multi-tenant office building, instead of just one. You wouldn’t want to separate the offices of the same company from each other. In this case, you could use private VLANs and assign that customer to what is known as a community VLAN, and all other tenants would be members of an isolated VLAN. For an excellent intro to private VLANs (with a little introduction to protected ports, as well), check out “Understanding Private VLANs” on the InternetworkExpert blog.