# VLANs & Trunking

By | June 22, 2015

A quick recap: Virtual LANs and Trunking in Cisco Ethernet switches. There are different VLAN ranges, switchport modes and some ways to manage all that.

The Written is coming, so it’s time to start writing short notes to recapture some knowledge leftovers I might still have.

## VLANs and Trunking

Note: I’ll be going over the INE’s Expanded CCIE RnSv5 blueprint for recap. Great many thanks to INE for their blog and community.

First things first, a mindmap brainstorm diagram:

Mindmaps have proven to be extremely useful for my studies over the years.

VLANs are a way of separating a single switch (i.e. broadcast domain) into several more or less isolated virtual switches. The logic is almost the same as in VRFs. Or vice versa.

These VLANs by themselves are local to the switch. To extend a VLAN across several independent switches, trunking is used.

Other vendors may call it just “tagging”, because it’s what it is.

Now let’s get to some details.

### Standard VLANs

In Cisco’s world, VLANs with IDs \in range [1-1005] are called Standard.

The range itself is a legacy of Inter-Switch Link protocol capability. Many switches still support only about a thousand VLANs (why would they need more?), although the whole 4k range is supported for assigning numbers.

In this range there are some special cases:

#### VLAN1

• Default Ethernet access VLAN, default dot1q native
• Cannot be deleted but can be pruned manually
• Cannot be pruned by VTP
• Best practice is not to use it for actual access ports
• VLAN1 is ever present on trunks (tagged or not), even if pruned manually. Used for CDP, VTP, PAgP, MST.

#### VLAN range [1002-1005]

• Was used for token ring and FDDI VLANs
• Cannot be deleted but can be manually pruned from trunks
• Cannot be pruned by VTP
• Cannot be used (on most platforms) for real ports

### Extended VLANs

VLANs with IDs \in range [1006-4094] are called Extended.

To be used successfully, this range requires VTP v3 or VTP Transparent mode, as VTPv1&2 do not support the extended range (again, ISL legacy).

The VLAN IDs from this range are used for internal allocations:

The internal VLANs are allocated in ascending order, starting at VLAN 1006. It is recommended to assign the user VLANs as close to VLAN 4094 as possible in order to avoid conflicts between the user VLANs and the internal VLANs. Issue the command show vlan internal usage on a switch in order to display the internally assigned VLANs.

See <https://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00801b49a4.shtml> – Cat6500/4500 IOS best practice guide

At the same time, other platforms may have a DESCENDING allocation order, so the reverse applies there.

Internal allocation is needed for ports of the switch turned

>no switchport

– rendering it effectively an L3 port. To make it so, apparently, an SVI needs to be created and a VLAN ID is separated (and excluded from VLAN management).

### VLAN Database

A local datastore, containing VLAN information: number, name, assigned ports.

Internally allocated VLANs are hidden from vlan database

>vlan database

– special configuration mode, which is being deprecated. General config mode should be used instead.

VLAN database information is stored in vlan.dat on flash0: of the switch. Even if configuration is cleared, as long as that file remains, so does the VLAN database allocation.

### Access Ports

An Access port is a port allocated to a single VLAN, over which data is transmitted untagged.

There are two special cases I can think of right away:

Voice VLAN: a semi-trunk, with Voice VLAN data transmitted dot1q tagged. VVLAN is either set statically on the phone or communicated via CDP.

VLAN0: a frame sent over an access port of data with a dot1q tag of zero basically means “here’s some data, place it into the native VLAN (of which I do not know)” – used for VoIP QoS applications. Anecdotally, this method is also used somehow by Windows Servers (one Windows admin told me so).

>switchport access vlan [num]

>switchport mode access

### 802.1q Trunk Ports

A port supporting several VLANs by way of tagging [almost] all outgoing frames.

An un-tagged incoming frame is interpreted to come to the Native VLAN.

VLAN1 is ever present on trunks (tagged or not), even if pruned manually. Used for CDP, VTP, PAgP, MST.

With dot1q DTP uses native VLAN, even if it’s pruned

Trunk ports send and receive PAgP protocol data units (PDUs) on the lowest numbered VLAN.

>switchport encapsulation dot1q

>switchport mode trunk

A trunk can be established manually or with DTP negotiation.

### 802.1q Native VLAN

For the Native VLAN the data is transmitted via trunks untagged (can be forced to be tagged). Native VLAN can be pruned from the trunk (prevents any data, except control plane protocols, from being transmitted untagged out of the trunk).

Any incoming untagged data is interpreted as being part of the native VLAN for that trunk.

### Dynamic Trunking Protocol (DTP)

DTP is used to establish a trunk automatically over a link. It is enabled by default.

DTP configuration has two main modes: Desirable or Auto. It works this way: D&D=>trunk; D&A=>trunk;A&A=>access.

>switchport mode [desirable|auto]

>switchport nonegotiate !disables DTP on the link

With dot1q, DTP uses native VLAN, even if it’s pruned.

### Trunking Allowed List

A statically set list of VLANs, allowed to be transmitted over a trunk link.

Default: the full range of [1-4094] is allowed.

Editing of this list is often called “manual pruning”

>switchport trunk allowed vlan [a range or a list of numbers|add|all|none]

An important thing is that pruning, by default, only prevents data for the VLAN to be transmitted out of the port. An incoming frame with the pruned tag will be accepted. Thus, pruning configuration MUST be consistent across the switching domain.