In the world of network switches, it’s hard to escape the shadow of Cisco. Cisco owns roughly 70% of the switching market, with something like 80% of installed switches and over 60% of all new switch sales. Cisco engineers are plentiful, and the CCNA/CCNP/CCIE certifications are considered some of the best in the industry. Because of how much momentum Cisco has behind them, it forces other vendors to emulate their product in order to emulate their success.
There are two basic approaches to configuring VLANs: interface-centric and VLAN-centric. Cisco switches are all interface-centric, which means that most of the industry follows suit. However, there are a few manufacturers out there that believe VLAN-centric configuration is the better solution.
I’ll start by talking about the incumbent. Interface-centric VLANs all revolve around the individual interfaces. Let’s talk about a hypothetical voice/VoIP VLAN, named “voice” and with the VLAN ID (tag) 225.
In an interface-centric world, you add the VLAN to each interface. Here’s an example:
interface gi1/5 switchport access vlan 225 exit interface gi1/6 switchport trunk allowed vlan add 225 exit
If you created a new voice VLAN on an edge switch and wanted to enable users to plug their phones into any port, you would have to configure each and every port on the switch. You can typically edit multiple interfaces (or an interface range) at once to make the job easier. The VLAN membership is contained in the configuration of each interface. Your worst case scenario is creating a new VLAN and being forced to add that VLAN to each port individually. If you can configure your multiple interfaces at once, this isn’t so bad.
In a VLAN-centric configuration paradigm, all VLAN membership configuration is done at the VLAN level, not at the interface level. You add each interface to the VLAN. Let’s go back to our old voice VLAN example.
create vlan voice configure vlan voice add ports gi1/5 untagged configure vlan voice add ports gi1/6 tagged
As you can see, you’re not going into each interface’s configuration to set the VLAN. This make it very easy to run a command like “show vlan” to show you all of the member ports in a particular VLAN. If you make a new VLAN, you can add all of the switch’s ports to the VLAN with one command. Your worst case scenario is adding multiple VLANs to the same interface, because you would have to go into each VLAN individually, rather than just adding all of the VLANs at once to the interface. There’s not really any good ways to mitigate this. Extreme Networks and HP are the only pure VLAN-centric switching manufacturers I’ve worked with.
Juniper’s Junos does things a bit differently, and actually allows you to configure your VLANs either way. You can focus on an interface-centric configuration if your network engineers work with Cisco gear, or you can switch to a VLAN-centric design if you have a bunch of ex-Extreme Networks engineers working for you. The key is to be very careful to avoid overlapping both approaches on the same switch, which can have unintended results. Pick one design or the other and stick with it. I have heard that Juniper recommends configuring the untagged/access ports as VLAN-centric, and the tagged VLANs under each interface.