Managed Switches: VLANs and QoS Configuration (2026)

VLANs and QoS on managed switches are surprisingly less about isolating traffic and more about intelligently mixing it.

Let’s see this in action. Imagine a small office with a single managed switch. We’ve got phones, computers, and a server connected.

+-------------------+
|    Managed      |
|     Switch      |
+-------------------+
|                   |
|  [Phone 1] ---->  |
|  [Phone 2] ---->  |
|  [PC 1]   ---->  |
|  [PC 2]   ---->  |
|  [Server] ---->  |
+-------------------+

Without any configuration, all this traffic hits the switch and gets forwarded to every port (except the source port, of course). This is inefficient and can lead to collisions and delays, especially for time-sensitive traffic like voice.

Now, let’s introduce VLANs. We’ll put the phones on VLAN 10 and the computers/server on VLAN 20.

On the switch, this looks like:

interface vlan 10
  name "Voice"
interface vlan 20
  name "Data"

interface gigabitethernet1/0/1  # Phone 1
  switchport mode access
  switchport access vlan 10

interface gigabitethernet1/0/2  # Phone 2
  switchport mode access
  switchport access vlan 10

interface gigabitethernet1/0/3  # PC 1
  switchport mode access
  switchport access vlan 20

interface gigabitethernet1/0/4  # PC 2
  switchport mode access
  switchport access vlan 20

interface gigabitethernet1/0/5  # Server
  switchport mode access
  switchport access vlan 20

Now, the switch internally creates separate broadcast domains. Traffic tagged for VLAN 10 will only be sent out ports configured for VLAN 10. Same for VLAN 20. This drastically reduces the amount of traffic each port needs to process. If phone 1 talks to phone 2, the switch only forwards that traffic between ports 1 and 2. It doesn’t even consider ports 3, 4, or 5.

But what if the server needs to send a large file to PC 1 while phone 1 is on an important call? Even with VLANs, the switch has to decide which packet gets to go first if there’s congestion. This is where QoS (Quality of Service) comes in.

QoS allows us to prioritize traffic. We can tell the switch that voice traffic is more important than data traffic.

We’ll configure a basic QoS policy:

! Assume this is a Cisco-like syntax
mls qos

class-map match-any VOICE_TRAFFIC
  match ip dscp ef  ! EF (Expedited Forwarding) is a common DSCP for voice

class-map match-any DATA_TRAFFIC
  match ip dscp default ! Default DSCP for most data traffic

policy-map MARK_AND_PRIORITIZE
  class VOICE_TRAFFIC
    priority percent 30  ! Dedicate 30% of bandwidth to voice, with low latency
  class DATA_TRAFFIC
    bandwidth percent 70  ! Guarantee 70% of bandwidth for data

interface gigabitethernet1/0/1  # Phone 1
  switchport mode access
  switchport access vlan 10
  service-policy input MARK_AND_PRIORITIZE ! Apply policy on ingress

interface gigabitethernet1/0/3  # PC 1
  switchport mode access
  switchport access vlan 20
  service-policy input MARK_AND_PRIORITIZE ! Apply policy on ingress

interface gigabitethernet1/0/5  # Server
  switchport mode access
  switchport access vlan 20
  service-policy input MARK_AND_PRIORITIZE ! Apply policy on ingress

Here, mls qos enables QoS globally. We define class-maps to identify traffic types (based on DSCP markings, which devices set). The policy-map then dictates how to treat these classes. priority percent 30 gives voice traffic a dedicated, low-latency queue, ensuring calls aren’t dropped due to data floods. bandwidth percent 70 ensures data gets its share but can use more if voice isn’t using its full allocation. Applying the policy on input means the switch classifies and prioritizes traffic as it enters the switch, which is the most effective place to do it.

The true power of VLANs is that they create independent forwarding tables. When a packet arrives on a port, the switch looks at its VLAN tag and consults a specific table for that VLAN. This means broadcast storms within one VLAN don’t spill over into another, and traffic that doesn’t need to talk to other VLANs simply never has its forwarding decision considered by ports in other VLANs. It’s like having multiple, smaller switches inside one physical box, each dedicated to a specific type of traffic or group of users.

The most common mistake people make with QoS is applying it only on the egress (output) of a port. While this can help shape traffic, it doesn’t solve the fundamental problem of congestion occurring before the packet reaches the egress queue. By classifying and queuing traffic on ingress, you ensure that the switch’s internal buffers are managed more effectively, preventing drops and delays from the moment traffic enters the device.

Once you’ve got your VLANs and QoS sorted, you’ll likely be looking at how to route traffic between those VLANs.