CCNP Study Notes – VLANs and Trunks

By | March 4, 2012

Static VLANs

Port-based membership.  End user devices are members of VLANs based on the physical switchport they are connected to, and are not aware of which VLAN they are in.  Ports are assigned to VLANs by an administrator and the port receives a Port VLAN ID (PVID) that links it to a VLAN number.  Switchports can be assigned to many different VLANs but no communication is possible between devices in different VLANs without a Layer 3 device to route packets or an external Layer 2 bridge device.

By default, all switchports are assigned to VLAN 1, type Ethernet with an MTU of 1500.  First a VLAN is created (by giving it a number) and then porrts are assigned to it.  Standard VLAN numbers are 1 to 1005, with 1 (default), 1002 – 1005 (reserved for legacy functions) created automatically.  Catalyst IOS switches can support extended range VLANs (1 – 4096) for compatability with IEEE 802.1Q.  Extended range is only enabled when the switch is configured for VTP transparent mode, as extended range VLANs are not stored in the VLAN database.


Create the VLAN:

Switch(config)# vlan vlan-num (creates the VLAN)

Switch(config-vlan)# name vlan-name (optional, if not used then the name is stored as VLAN XXX, where XXX is the numnber of the VLAN)

Switch(config)# no vlan vlan-num (deletes the VLAN)


Assign ports to the VLAN:


Switch(config)# interface type module/number

Switch(config-if)# switchport

Switch(config-if)# switchport mode access

Switch(config-if)# switchport access vlan vlan-num


On a L3 IOS switch, every port is configured for L3 operation by default so the switchport command is needed to make it L2

Verify the VLAN Config

Switch# show vlan


VLAN Name                             Status                Ports

—- ——————————– ——— ——————————-

1    default                                 active

500  Marketing                          active                Et0/1

1002 fddi-default                         act/unsup

1003 token-ring-default                act/unsup

1004 fddinet-default                    act/unsup

1005 trnet-default                       act/unsup


Dynamic VLANs

VLAN membership is based on the MAC address of the attached devices.  MAC addresses are assigned to a VLAN in a database on the VLAN Membership Policy Server (VMPS), by an administrator using a tool such as CiscoWorks.  More mobility for end users = more admin overhead.


VLAN Considerations

The number of VLANS depends on: traffic patterns, application types, workgroup segmentation and management requirements.  There should be a 1-to-1 correlation between a VLAN and an IP subnet.  VLANS should not extend beyond the Layer 2 domain of the Distribution switch, ie. not across the core in to another switch block.


End to End VLANs

AKA Campuswide VLANS – Span the entire switch fabric of a network, and are not reccomeded unless there is a good reason.  Each VLAN is available at each access layer of each switch block.  100% of traffic can cross the network core, so VLAN trunking has to be used to carry all VLAN’s between the Access and Distribution layer switches.


Local VLANs

20/80 rule is no common, ie 20% of traffic local and 80% is destined outside the VLAN.  Layer 3 functions can route inter-VLAN traffic intelligently, allowing maximum availability using multiple paths, scalabitlity and manageability.


VLAN Trunks

A switch port can support only one VLAN, although it can support multiple subnets.  A trunk link transports more than one VLAN through a single switch port – typically used to connect switch<–>switch or switch<–>router.  A trunk link is not assigned to a specific VLAN, but one, many or all active VLANS can be transported between switches on a single physical trunk link.  Separate inter-switch links can be used for each VLAN but it is much more efficient to use trunking instead of multiple single links.  Cisco supports trunking on fast and gigabit ethernet ports, and aggregated fast and gigabit etherchannels.

A switch needs to identify frames and their respective VLAN’s as they traverse a trunk link.  Each side of the link must be using the same method to “tag” frames with their user-defined VLAN ID.  The tagging process involves placing an identifier in the frame header, which is then examined as each frame passes through a swtich and is then removed.  The VLAN identifier is added back to the frame header if the frame is to be forwarded out over another turnk link, otherwise remains removed before the frame is forwarded out of an access port to its destination.  The sending and receiving hosts have no concept of VLAN’s. There are 2 methods for identifying VLAN’s:

Inter-Switch Link Protocol (ISL)

Cisco proprietary, encapsulates each frame between a 26 byte header and a 4 byte trailer.  The source VLAN is identified by a 15 bit VLAN ID field in the header, and the trailer contains a CRC value to ensure data integrity.  AKA double-tagging.  No longer supported on all Catalyst switch platforms.

IEEE 802.1Q Protocol

Standardized, allowing VLAN trunks to work between kit from different vendors.  Rather than encapsulating each frame with VLAN information, it is embedded within the frame.  AKA single tagging or internal tagging.  A 4 byte tag is added is added just after the source address field in the frame.  With 802.1Q there are “native” VLAN’s, and frames belonging to the native vlan are not tagged.

Note – 1518 bytes is the max ethernet frame size and tagging can cause frames to become too large.  Baby Giant frames (reported as ethernet errors or oversize frames) are frames that are only slightly bigger than the MTU.  For 802.1Q switches can comply with IEEE 802.3ac which extends the MTU to 1522 bytes.

Dynamic Trunking Protocol

Cisco proprietary protocol that allows devices to agree on the encapsulation method (dot1q / ISL) and whether to form a trunk or not.  DTP frames are sent out every 30 seconds to inform neighboring switch ports of the links mode.  The command switchport nonegotiate turns off DTP, so no negotiation takes place – useful if both end of a link are fixed as trunks.


VTP Configuration:

Switch(config)# interface type module/number

Switch(config-if)# switchport

Switch(config-if)# switchport trunk encapsulation {isl | dot1q | negotiate}

Switch(config-if)# switchport trunk native vlan vlan-id

Switch(config-if)# switchport trunk allowed vlan {vlan-list | all | {add | except | remove} vlan-list}

Switch(config-if)# switchport mode {trunk | dynamic | desirable | auto}

Switch ports must be in Layer 2 mode to support trunking, by using the switchport command.  negotiate is the default encapsulation, with ISL being favoured if both ends support both types.  For dot1q, you should specifiy the native VLAN also, default is 1. Also, by default, all active (defined + ports assigned) VLANs are allowed.

For the switchport mode command you can set the mode to any fo the following:

trunk – permanent trunk mode, if far end is set to trunk, dymanic desirable or dynamic auto then a trunk is formed.  It is best to set both ends to trunk, and set the encapsulation method if this is definitely required so no negotitaion takes place.

dynamic desirable (default) – port attempts to convert the link to a trunk.   If far end is set to trunk, dymanic desirable or dynamic auto then a trunk is formed.

dynamic auto- port can become a trunk if the far end requests it.  If far end is set to trunk or dymanic desirable then a trunk is formed.

To view the trunking status on a switch port use the show interface type mod/port trunk command


Troubleshooting VLAN’s and Trunks

A VLAN is nothing more than a logical network segment, so if a host in one location cannot access a host in another:

  • are both on the same IP subnet?
  • are both switch ports in the same VLAN?
  • check the path between the 2 hosts
  • is the VLAN carried along the path?
  • is the VLAN being trunked over any trunk links on the way?

To verify a VLAN config:

Switch# show vlan id vlan-id

Make sure the VLAN has an active status and is assigned to the correct ports

For Trunks to work, make sure the following are agreed at both ends:

  • Trunking mode
  • encapsulation method
  • Native VLAN (you can bring a trunk up with different native VLAN’s on each end but the switches will log errors about mismatches and it’s possible that traffic will not pass correctly between the 2 native VLAN’s
  • The native VLAN mismatch is discovered through the exchange of CDP messages.  Native VLAN is configured separately to the encapsulation type, so it is possible to have a native VLAN mismatch even with ISL – although this will be purely cosmetic and not cause a problem
  • Allowed VLAN’s – check that the VLAN in question is allowed over the trunk – all are by default


To check how a switch port is operating compared to how it is configured, issue:

Switch# show interface type mod/num switchport

for example the, administrative mode may be set to dynamic auto, yet the the operational mode is actually static access – this could mean that both ends are set to auto so neither request a trunk.  For more concise trunk info issue:

Switch# show interface type mod/num trunk

To see whether and how DTP is being used:

Switch# show dtp type mod/num


VLAN Trunkning Protocol

Used to manage VLAN’s amongst a group of switches spread over a campus network.  Using VTP trunk frames it manages addition, deletion, renaming of VLAN’s from a central point of control.  VTP is organised into management domains, or areas with common VLAN requirements, and a switch can belong to only one VTP domain.  VLAN information is not shared between switches in different VTP domains.

  • Server (default mode) – full control over VLAN creation/modification.  all VTP information is advertised to other switches in the domain, and all received VTP info is sync’d with the other switches.  Each VTP domain must have at least one server, and VLANs must be configured on only one server
  • Client – from a client, the administrator cannot create, change or delete any VLANs.  client switches listen to advertisements and then modify their VLAN config.  Advertisement are also relayed out of trunk links to other switches in the domain.
  • Transparent Mode – switches in this mode do not participate in VTP.  any VLAN config are local only to that switch.  for VTP version 1 the switches VTP domain name and version number must match those of other switches if it is to act as a relay, but version 2 will relay regardless.


VTP Advertisements

VTP advertisements (sent as multicast frames out of trunk ports) sent between switches, contain information about the management domain, VTP revision numbers, known VLAN’s (only 1 to 1005) and specific VLAN parameters.  Advertisements are non-secure by default, but a password can be added (secure mode), that must be configured on every switch to ensure that they all use identical encryption methods.

The revision number is incremented by the server when changes are made.  VTP Configuration Revision Numbers are used as an index to keep track of the most recent information.  This always starts at 0 and the last revision number that the switch heard is stored locally and then overwritten with the latest revision number when a new advertisement is received.  The revision number is stored in NVRAM and survives a reboot.

There are 2 ways to reset a switch’s VTP revision number back to 0 (to avoid problems with new switches trashing VTP domains with a higher revision number):

  • change the mode back to transparent, and then back to server
  • change the VTP domain name to something bogus and then back to the original again

Advertisements can originate as requests from a client on boot up, or from a server when changes have been made.  There are 3 advertisement forms:

  • Summary – sent by servers every 300 secs and whenever there is a change.  One or more subset advertisements will then follow
  • Subset – sent after a change occurs, listing the specific changes such as deleting a VLAN
  • Advertisement requests from clients – requested by switches for any VLAN information they may lack, such as after a reset when the VLAN database has been cleared

Catalyst switches in server mode store VLAN and VTP data in the flash file system (vlan.dat) so this information is retained after a reboot


VTP Configuration

By default a switch is in Server mode, with a NULL management domain, no password or secure mode.  If a VTP advertisement is heard on a trunk port the the switch learns the VTP domain name, VLAN’s, and the configuration revision  number/

Switch (config)# vtp domain domain-name

Switch (config)# vtp mode {server | client | transparent}

Switch (config)# vtp password password

Switch (config)# vtp version {1 | 2} (version 1 is default)

Switch # show vtp status – displays VTP parameters for a Management domain

Switch # show vtp counters – displays VTP messages and error counters


VTP Pruning

By default a trunk link transports traffic from all VLANs unless specific VLANs are removed from the trunk.  Pruning reduces unnecessary flooded traffic, so that broadcast and unknown unicast frames are forwarded over trunk link only if the switch on the receiving end has ports in that VLAN.  VTP pruning is an extension of VTP version 1, using an additional VTP message type.  When a switch has ports in a VLAN it advertises the fact to its connected switches, so they know whether to flood traffic from a VLAN or not.  VTP pruning disabled by default.  By default VLANs 2 to 1001 are eligible for pruning. VLAN 1 is never eligible.

Switch (config)# vtp pruning

If the above command is issued on a server then all other switches in the management domain will also enable pruning.  All general purpose VLANs are eligible for pruning on all trunk links by default.  To change the default list of pruning eligibility issue the following interface command:

Switch (config)# interface mod/num

Switch (config-if)# switchport trunk pruning vlan {{{add | except | remove} vlan-list} | none}

NB – even with pruning running, an instance of STP will still run for every VLAN that is allowed on a trunk, so to reduce the number of instances running you should manually “prune” un-needed VLANs from the trunk using the switchport trunk allowed vlan command.


Troubleshooting VTP

If a switch is not receiving updated information from a VTP server:

  • is it configured for transparent mode?
  • if it’s a client, is there actually a server? if not, make the client a server
  • the link toward the server may not be in trunking mode (show interface mod/num switchport)
  • VTP domain name matches the server?
  • VTP version is compatible with other switches in the domain?
  • VTP password matches? or isn’t being used?
  • show vtp status
  • show vtp counters
  • show vlan brief
  • show interface type mod/num switchport
  • show interface type mod/num pruning

Leave a Reply

Your email address will not be published. Required fields are marked *