# Allowed VLANs

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/allowed-vlans

## Quick definition

On a network switch, a trunk port can carry traffic for many different VLANs at once. The allowed VLANs list tells that trunk port exactly which VLANs it is allowed to carry. If a VLAN is not on that list, its traffic is blocked from crossing that link.

## Simple meaning

Imagine a large apartment building with many separate offices, each office belonging to a different company. There is a shared hallway (the trunk link) that connects all the offices to the outside world. Each office has its own private door, but to get to the main entrance, an employee must walk through the hallway. Now, the building manager decides that only certain companies are allowed to use that hallway at any given time. The manager keeps a list on the hallway door that says which company IDs are permitted to walk through. If a company ID is not on the list, its employees cannot step into the hallway and must stay in their office, even if they have a door. 

 In a computer network, VLANs are like these separate companies. A trunk link is the shared pathway that carries traffic for many VLANs between switches. The configuration called allowed VLANs is exactly that list on the hallway door. When a switch receives a frame tagged with a specific VLAN ID on that trunk, it checks the allowed list. If the VLAN ID is allowed, the frame passes through. If it is not allowed, the switch drops the frame immediately. This prevents traffic from unauthorized VLANs from crossing a trunk link, which is an important security and management feature. 

 The allowed VLANs list can exclude certain VLANs for security reasons, for example, keeping the voice VLAN traffic completely separate from the data VLAN traffic. It can also be used to limit the number of VLANs that travel across a specific link to reduce unnecessary broadcast traffic. Every trunk port on a Cisco switch, by default, allows all VLANs from 1 to 4095. Network engineers change this list on purpose to enforce policy. It is a simple but powerful tool that gives granular control over which VLANs share a trunk connection.

## Technical definition

Allowed VLANs is a per-interface configuration parameter on a trunk port that explicitly defines the set of VLAN IDs whose frames are permitted to ingress and egress that specific link. This parameter is implemented as a filter at the port level of the switch, typically applied after the dot1q tagging process. When a frame arrives on a trunk port with an 802.1Q header containing a VLAN ID, the switch’s forwarding engine consults the allowed VLAN list for that port. If the VLAN ID is present, the frame is processed normally. If not, the frame is silently discarded. 

 The standard implementation in Cisco IOS uses the command `switchport trunk allowed vlan` followed by a list or a range of VLAN IDs. For example, `switchport trunk allowed vlan 10,20,30` allows only those three VLANs. There is also a keyword `add` to append VLANs, `remove` to delete specific VLANs, and `except` to allow all but a specified set. The keyword `all` restores the default of permitting all VLANs. Importantly, the native VLAN is not subject to the allowed VLAN list in the same way because native VLAN frames are untagged. However, the native VLAN must still be present in the allowed list, otherwise the port will not forward any frames, even untagged ones. 

 The allowed VLANs list interacts directly with the VLAN Trunking Protocol (VTP). In VTP transparent mode, the allowed list is configured manually. In VTP server or client mode, the allowed list can still be set per port and is not overridden by VTP. However, if a VLAN is pruned by VTP, it cannot be allowed on any trunk port, even if listed. The concept also applies to private VLANs and extended VLANs (1006-4094). On modern switches, the list is stored in the running configuration and can be a powerful tool to segment traffic, reduce broadcast domain size, and provide isolation between different parts of the network. In a service provider or enterprise environment, allowed VLANs are essential for offering Layer 2 transport services to multiple customers across a single physical infrastructure without leaking traffic between customers.

## Real-life example

Think of a large hospital with multiple departments: Emergency, Radiology, Pharmacy, and Administration. Each department has its own private wireless network (like a VLAN). The hospital has a main corridor (the trunk link) that connects the department’s switch closet to the main data center. Now, the hospital’s IT policy says that the Pharmacy network must never be accessible from the Administration network, and vice versa. To enforce this, the network engineer configures the allowed VLANs list on the trunk port that connects the Administration switch to the main corridor. On that trunk, only the Administration VLAN is allowed. The Pharmacy VLAN is not in the list. 

 In the real world, this prevents a curious administrator from accidentally or intentionally connecting to a Pharmacy printer or accessing patient prescription data. The allowed VLANs list works like a gatekeeper that says, This corridor is only for these specific groups. Anyone else trying to use it will be stopped at the entrance. 

 Another everyday analogy is a paid parking lot that has different sections for different permit types. The gate at the entrance reads your permit sticker (VLAN tag). If your sticker matches one of the allowed permit types listed on the gate (allowed VLANs), the gate opens and you can park. If your permit is not on the list, the gate stays down and you are turned away. This simple filter prevents chaos and ensures that only authorized vehicles use that particular entrance.

## Why it matters

In real IT networks, the allowed VLANs configuration is a foundational security and traffic management tool. Without it, every trunk port would carry every VLAN by default. This creates a serious risk: if a switch port is misconfigured as a trunk, an attacker connected to that port could potentially access any VLAN in the network, including management VLANs, voice VLANs, or sensitive data VLANs. By restricting allowed VLANs, a network engineer reduces the attack surface. For example, a trunk port connecting an access layer switch to a distribution switch might only need to carry the user data VLAN and the voice VLAN. There is no reason to allow the storage VLAN or the management VLAN on that link. 

 From a performance standpoint, allowed VLANs reduce the amount of broadcast and unknown multicast traffic that must traverse a link. Each VLAN has its own broadcast domain. If a trunk port permits 100 VLANs, all broadcast traffic for those 100 VLANs will flood across that link. If the link only needs 10 VLANs, limiting the list cuts broadcast overhead by 90%, improving overall network efficiency. In large data centers or campus networks, this can make a significant difference in link utilization. 

 For network troubleshooting, knowing which VLANs are allowed on a trunk is often the first step in diagnosing connectivity issues. If a host cannot reach a server on a different VLAN, one of the first questions is: Is the VLAN allowed on the trunk path between them? Many connectivity problems stem from a missing VLAN in an allowed list. Because of this, network engineers regularly audit trunk configurations to ensure that allowed VLAN lists match the current network design. Not doing so can lead to silent failures or security breaches.

## Why it matters in exams

Allowed VLANs is a core topic in the CCNA certification exam. It appears under the Switching Technologies domain, specifically in the section on configure and verify trunk ports. Exam objectives require candidates to understand the difference between default behavior (all VLANs allowed) and how to restrict that list using commands. They also need to know how the native VLAN interacts with the allowed list. 

 On the CCNA exam, you will encounter multiple-choice questions, simulations, and drag-and-drop scenarios that test your knowledge of the command syntax. For example, you might be given a running configuration snippet and asked which VLANs are allowed on a specific trunk. Or you might be asked to identify the correct command to add a VLAN to an existing allowed list without disrupting traffic. A classic question type asks: What happens to traffic from VLAN 99 on a trunk port that has `switchport trunk allowed vlan 1-50` configured? The answer is that VLAN 99 traffic is dropped because it is not in the allowed range. 

 The exam also tests troubleshooting. You may get a scenario where users in VLAN 20 cannot communicate across a trunk, and the candidate must identify that VLAN 20 is not in the allowed list on an intermediate switch. The exam often combines allowed VLANs with VTP and DTP. For instance, if a dynamic trunk port negotiates a trunk, it will inherit the default allowed VLAN list unless manually changed. Understanding this interaction is critical for answering simulation questions correctly. 

 CCNA candidates should memorize the exact syntax: `switchport trunk allowed vlan {vlan-list}` and the modifiers `add`, `remove`, `except`, and `all`. Knowing that removing VLAN 1 from the allowed list will block the native VLAN traffic (even if it is untagged) is a common exam trap. Also, remember that the trunk must be up and the VLAN must exist in the VLAN database for the allowed list to take effect. These nuances are frequently tested to ensure depth of understanding.

## How it appears in exam questions

Exam questions about allowed VLANs come in several distinct patterns. The most common is the configuration question: You are given a partial switch configuration and asked to complete it so that only VLANs 10, 20, and 30 are permitted on interface GigabitEthernet0/1. The correct answer would be to add the command `switchport trunk allowed vlan 10,20,30` under that interface. 

 Another pattern is the output interpretation question. The candidate is shown the output of `show interfaces trunk` or `show running-config interface` and must determine which VLANs are allowed. For example, the output might show: `Vlans allowed on trunk: 1-100,105,200`. A question could ask: What would happen to a frame tagged with VLAN 150 arriving on this port? The answer is that it is dropped. 

 Scenario-based troubleshooting questions are also common. A typical scenario: A new server is deployed in VLAN 50. Clients in VLAN 50 can reach other clients in the same VLAN but cannot reach the server, which is connected to a different switch. All switches are configured correctly except that the trunk between the two switches only allows VLANs 1-49. The candidate must identify the root cause and propose the fix: add VLAN 50 to the allowed list on the trunk. 

 There is also the 'what is the default behavior' type of question. For instance: By default, how many VLANs are allowed on a trunk port? The answer is all VLANs from 1 to 4095. But there is a nuance: VLANs 1002-1005 are reserved and cannot be removed, so the default includes them. A tricky variation asks: If you configure `switchport trunk allowed vlan 10`, what happens to VLAN 1? The answer is that VLAN 1 is removed from the allowed list, and any native VLAN traffic (which is normally untagged and associated with VLAN 1) will be blocked. This is a frequent exam trap.

## Example scenario

You are a network technician for a medium-sized company. There are two switches: SwitchA in the server room and SwitchB in the user area. They are connected by a single trunk link. The company uses VLAN 10 for data, VLAN 20 for voice, and VLAN 30 for printers. All three VLANs exist on both switches. Currently, the trunk port on SwitchA has the default configuration that allows all VLANs. Yesterday, the IT manager decided that printer traffic (VLAN 30) should never cross the trunk to the server room because all print servers are in a different part of the building. The manager wants VLAN 30 traffic to stay local on SwitchB. 

 You log into SwitchA and go to interface GigabitEthernet0/1, which is the trunk port to SwitchB. You type the command `switchport trunk allowed vlan 10,20`. This removes VLAN 30 from the allowed list. After this change, any frame that arrives on SwitchA with a VLAN 30 tag from the trunk is immediately dropped. The printers on SwitchB can still talk to each other locally, but they cannot reach any server or device on SwitchA across that trunk. The voice and data traffic continues to flow normally. 

 Later, a user complains that they cannot print from their computer to a network printer located on the other side of the trunk. They are in VLAN 10, and the printer is in VLAN 30. You check the trunk and realize that VLAN 30 is not allowed, so the print job is blocked at the trunk. To fix this, you decide to add VLAN 30 back to the allowed list using the command `switchport trunk allowed vlan add 30`. Now the trunk allows VLANs 10, 20, and 30 again, and the print job succeeds. This scenario illustrates how allowed VLANs directly affect connectivity and how adding a VLAN is a safe operation if done with the 'add' keyword rather than rewriting the whole list.

## Common mistakes

- **Mistake:** Using the command `switchport trunk allowed vlan 10` thinking it adds VLAN 10 to the existing list.
  - Why it is wrong: This command replaces the entire allowed VLAN list with only VLAN 10. It does not add; it overwrites. All other VLANs are removed immediately, which can cause an outage for all other VLAN traffic on that trunk.
  - Fix: Always use the `add` keyword to preserve existing allowed VLANs: `switchport trunk allowed vlan add 10`.
- **Mistake:** Assuming the native VLAN is always allowed even if not in the allowed VLAN list.
  - Why it is wrong: The native VLAN must be explicitly allowed in the allowed VLAN list. If you remove the native VLAN (typically VLAN 1) from the list, untagged frames on that port will be dropped, disrupting all native VLAN traffic.
  - Fix: Always include the native VLAN in the allowed list if you expect it to pass traffic. Use `show interfaces trunk` to verify.
- **Mistake:** Forgetting that changing the allowed VLAN list on one end of a trunk only affects traffic arriving at that port.
  - Why it is wrong: The allowed VLAN list is applied per port. If you restrict the allowed VLANs on SwitchA but not on SwitchB, traffic from SwitchB in a restricted VLAN might still be sent across the trunk but will be dropped at SwitchA. However, SwitchB will still send the traffic, wasting bandwidth. Both ends should be configured consistently.
  - Fix: Configure the same allowed VLAN list on both ends of a trunk to ensure symmetric behavior and efficient bandwidth use.
- **Mistake:** Believing that removing a VLAN from the allowed list also deletes the VLAN from the switch.
  - Why it is wrong: The allowed VLAN list only affects per-port forwarding. The VLAN still exists in the switch's VLAN database. The VLAN can still be used on access ports, and its SVI (if configured) still works. The removal only prevents that specific trunk port from carrying its traffic.
  - Fix: Understand that allowed VLANs is a forwarding filter, not a VLAN deletion tool. Use `no vlan` to remove a VLAN entirely from the database.

## Exam trap

{"trap":"The exam might show a trunk port configured with `switchport trunk allowed vlan 10-20` and then ask what happens to VLAN 1 traffic on that trunk.","why_learners_choose_it":"Learners often think that VLAN 1 is the default VLAN and is always permitted on a trunk, so they answer that VLAN 1 traffic is allowed. They overlook the fact that the explicit allowed list has overridden the default and removed VLAN 1.","how_to_avoid_it":"Always remember that any explicit allowed VLAN command replaces the entire list. If the list does not include VLAN 1, then VLAN 1 is blocked. Check the default native VLAN (usually 1) and ensure it is in the list if you need it."}

## Commonly confused with

- **Allowed VLANs vs Native VLAN:** The native VLAN is the VLAN to which untagged frames are assigned on a trunk port. Allowed VLANs is the list of VLANs that can pass. A VLAN can be allowed but not native, and vice versa. However, the native VLAN must be in the allowed list to work. Think of native VLAN as the default language, while allowed VLANs is the list of languages allowed on the conversation. (Example: On a trunk, native VLAN is 99. If allowed VLANs list is 10,20,99, then untagged frames go to VLAN 99 and pass. If allowed list is 10,20, then untagged frames are dropped.)
- **Allowed VLANs vs VLAN Access Map:** A VLAN access map is a more complex security filter that can permit or deny traffic based on MAC addresses, IP addresses, or other criteria within a VLAN. Allowed VLANs is a much simpler per-port filter that either allows or blocks an entire VLAN's traffic. It is like a bouncer at a club (allowed VLANs) versus a detailed guest list with photos (VLAN access map). (Example: Allowed VLANs blocks all traffic from VLAN 50 on a trunk. A VLAN access map might allow traffic from VLAN 50 but only from specific IPs.)
- **Allowed VLANs vs VLAN Pruning (VTP):** VTP pruning is a dynamic feature that prevents a switch from sending broadcast and unknown unicast traffic for a VLAN down a trunk if the VLAN is not needed on the other end. Allowed VLANs is a static, manual configuration. VTP pruning works on top of allowed VLANs; if a VLAN is not allowed, pruning is irrelevant. Allowed VLANs is like a permanent roadblock, while VTP pruning is like a dynamic toll booth that only opens for needed traffic. (Example: With VTP pruning, a trunk might automatically stop carrying VLAN 30 if no switch on the other side has VLAN 30. With allowed VLANs, you must manually remove VLAN 30 to stop it.)

## Step-by-step breakdown

1. **Determine the trunk port to configure** — Identify the interface that is operating as a trunk, typically connecting two switches or a switch to a router. This port will carry multiple VLANs. You must be in global configuration mode to change it.
2. **Enter interface configuration mode** — Use the command `interface GigabitEthernet 0/1` (or similar) to access the specific port. All subsequent commands will apply only to that port.
3. **Verify current allowed VLAN list (optional but recommended)** — Before making changes, use `show interfaces trunk` to see which VLANs are currently allowed. This prevents you from accidentally removing VLANs that are needed.
4. **Apply the allowed VLAN command with the correct keyword** — To set a specific list, use `switchport trunk allowed vlan 10,20,30`. To add a VLAN without removing others, use `switchport trunk allowed vlan add 40`. To remove a VLAN, use `switchport trunk allowed vlan remove 50`. Choosing the wrong keyword is a common mistake.
5. **Verify the configuration** — After applying the command, immediately verify with `show interfaces trunk` or `show running-config interface`. Confirm that the allowed list matches your intent. Also check that the native VLAN is still in the list if you need it.

## Practical mini-lesson

In practice, configuring allowed VLANs is a routine task for any network engineer working with Cisco switches. The process begins with understanding the network topology and which VLANs must traverse each trunk link. For example, in a three-tier architecture, the trunk from the access switch to the distribution switch might only need to carry the user data VLAN and the voice VLAN. The management VLAN and server VLANs should not cross that link. By restricting the allowed list, you enforce a principle of least privilege at Layer 2. 

 To configure it, you enter interface configuration mode on the trunk port. The most common mistake is using the base command without an add or remove keyword, which wipes the entire existing list. For instance, if a trunk currently allows VLANs 1-100, and you type `switchport trunk allowed vlan 10`, the new list becomes only VLAN 10, causing an immediate outage for all other VLANs. Therefore, professionals always use the `add` keyword when they want to include a new VLAN, and `remove` when they want to exclude one. 

 Another practical consideration is documentation. When you change the allowed VLAN list on a trunk, you must update your network diagrams and configuration records. During a network failure, the first thing you check is the trunk configuration. A missing VLAN in the allowed list is a leading cause of connectivity issues between switches. Tools like SNMP and network monitoring software can alert you if a trunk’s allowed list changes unexpectedly. 

 Advanced usage involves automation: using scripts or tools like Ansible to apply consistent allowed VLAN lists across many switches. For example, a script can read a YAML file that defines which VLANs should be allowed on each trunk and then push the configuration. This reduces human error. In a Cisco Catalyst Center environment, you can apply a template that enforces allowed VLANs globally, ensuring compliance with security policies. 

 What can go wrong? Aside from the overwrite issue, a common problem is forgetting that the native VLAN must be in the allowed list. If you remove the native VLAN, the link may still show as up but no untagged traffic (including CDP, STP BPDUs, and DTP) will pass, potentially causing a spanning-tree issue. Another problem is inconsistency between ends of the trunk: if one switch allows VLAN 10 and the other does not, traffic will be sent but dropped at the receiving end, wasting bandwidth. Always verify both sides. Finally, be aware that some older IOS versions treat VLAN 1 specially; removing it might cause unexpected behavior. Always test in a lab environment first.

## Memory tip

Think "ALLO" - Allowed List Only Overrides. The command replaces everything unless you use the Add keyword.

## FAQ

**What is the default allowed VLAN list on a Cisco trunk port?**

By default, a Cisco trunk port allows all VLANs from 1 to 4095, including the reserved VLANs 1002-1005. This is the default behavior unless you explicitly change the list.

**Can I allow only one VLAN on a trunk port?**

Yes, you can configure `switchport trunk allowed vlan 10` to allow only VLAN 10. This will remove all other VLANs from that trunk.

**What happens if I remove the native VLAN from the allowed list?**

If the native VLAN is removed from the allowed list, untagged frames on that trunk port will be dropped. This means CDP, STP, DTP, and any native VLAN traffic will not work.

**Does the allowed VLAN list affect the VLAN database on the switch?**

No, the allowed VLAN list only affects traffic forwarding on that specific trunk port. The VLAN still exists in the switch's VLAN database and can be used on other ports.

**What is the difference between `add` and just specifying VLANs in the allowed command?**

Using `switchport trunk allowed vlan add 10` adds VLAN 10 to the existing list without removing any other VLANs. Using `switchport trunk allowed vlan 10` replaces the entire list with just VLAN 10, removing all others.

**Can I use ranges in the allowed VLAN command?**

Yes, you can use ranges, for example, `switchport trunk allowed vlan 10-20` or `switchport trunk allowed vlan 10,20,30-40`.

## Summary

Allowed VLANs is a fundamental Cisco IOS feature that gives network engineers precise control over which VLANs can traverse a trunk port. It functions as a Layer 2 access control list that either permits or denies entire VLANs on a link. Understanding this concept is essential for designing secure and efficient networks. 

 Without it, every trunk link would be a flood of broadcast traffic from many VLANs, increasing bandwidth consumption and security risk. By restricting the allowed list, you limit the broadcast domain and reduce the attack surface. You also gain the ability to isolate different types of traffic, such as separating voice from data or guest from corporate. 

 For the CCNA exam, you must be comfortable with the exact command syntax, including the use of add, remove, except, and all. You should also understand the interaction with the native VLAN and the common mistakes that can cause outages. In real-world practice, this feature is used every day by network administrators to enforce policy and troubleshoot connectivity issues. Mastering allowed VLANs is a small but critical step toward becoming a proficient network engineer.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/allowed-vlans