Monthly Archives: March 2012

CCNP Study Notes – VLANs and Trunks

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

CCNP Study Notes – Switch Port Configuration


Ethernet (10Mbps) – IEEE 802.3, 10mbps bandwidth between users, shared medium, both a collison domain and and a broadcast domain, CSMA/CD = half-duplex operation, more devices sharing the medium = more collisions = poor performance.  Ethernet switching allows full-duplex operation due to the fact that the switch dynamically allocates a dedicated 10Mbps to each port – this means that becasue collisions are not likely, devices can operate in full-duplex mode, which increases performance further as throughput is 10Mbps in both directions giving 20Mbps total throughput.  Cabling used is UTP 10Base-T, which is restricted to 100 metres end-to-end distance.

Fast Ethernet (100Mbps) –  IEEE.3u.  CSMS/CD and upper layer protocol operations are the same as with Ethernet.  Cabling can be UTP or Fibre:

100Base-TX – EIA/TIA Cat 5 UTP       – 2 pairs – 100m

100Base-T2 – EIA/TIA Cat 3,4,5 UTP – 2 pairs – 100m

100Base-T4 – EIA/TIA Cat 3,4,5 UTP – 4 pairs – 100m

100Base-FX – MM Fibre 62.5/125      – 1 pair –   400m half duplex  / 2000m full duplex

– SM Fibre                       – 1 pair –   10KM

Full-Duplex Fast Ethernet – 100Mbps in each direction giving 200Mbps total throughput, if devices at both ends of the link support it.  Fast Ethernet is also backwards compatible to 10Mbps, so if both ends of a link are set to aut-negotiate and one end is only cabpable of 10Mbps, then this will become then negotiated speed.  For auto-negiation to work, both ends of a link must be configured for it.  If duplex negotiation fails then a switchport always falls back to it’s default setting og half-duplex.  FEC (Fast Etherchannel) is the bundling together of up to 8 full-duplex fast ethernet links, giving 400Mbps – 1600Mbps duplex bandwidth.

Gigabit Ethernet – 1000Mbps, same 802.3 Ethernet frame format as 10 & 100, Physical layer has been modified to increase data speeds – the result is IEEE 802.3z.  Gigabit Ethernet port duplex is always set to full on Cisco switches, so dupplex auto-neg is not possible.  GEC (Gigabit EtherChannel) allows aggregation of 2 to 8 connectionsto give up to 16Gbps throughput.

10-Gigabit Ethernet – 10,000Mbps, IEEE 802.3ae, most 10Gbps cables are fibre, with the exception of Copper type CX4 with Infiniband connectors (up to 15 metres)


Switchport Error Conditions

By default Catalyst switches detects error conditions for every possible cause.  If an error is detected the port is put into state errdisable and is disabled.  To fine tune this behaviour and ensure that only certain causes can trigger a port being disabled use the following command from Global Config mode:

Switch(config)# [no] errdisable detect cause [all | cause-name]

To re-enable a port, issue a shut/no-shut command.  You can specifiy that ports will be automatically re-enabled (default after 300 Secs), with the following command:

Switch(config)#errdisbale recovery cause [all | cause-name]

Set the auto recovery timer:

Switch(config)# errdisable recovery interval seconds


Troubleshooting Port Connectivity

S4#sh interfaces e0/1

Ethernet0/1 is up, line protocol is up (connected)

Hardware is AmdP2, address is aabb.cc00.0410 (bia aabb.cc00.0410)

MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,

reliability 255/255, txload 1/255, rxload 1/255


1st up = Physical/Data Link Layer, if down then the link is disconnected for cann to be detected.

2nd up = Layer 2


Switch# show interface status (shows states for all switchports)

Switch# show interface status err-disabled (shows all switchports in the err-disabled state and the cause)

CCNP Study notes – Switch Operation

Layer 2 Switch Operation

An ethernet switch decides where to forward incoming frames based on the destination MAC address contained within the received frame. Using this method means that the ethernet media is no longer shared between all connected devices. A switch will not forward a frame unless it knows which switch port the destination MAC address is connected to. Each switch port is it’s own isolated Ethernet LAN segment. The switch isolates connected devices in the following ways:

  • collision domains are limited and made up of the switch port itself and either a single host or a connected hub
  • all devices can operate in full duplex mode
  • each device has dedicated bandwidth across the switching fabric to another switch port
  • “store and forward” = frames are checked for errors, if OK the frame is regenerated when forwarded or transmitted. Receive / Store & Inspect / Forward
  • broadcast traffic is limited to a volume threshold
  • intelligent filtering and forwarding becomes possible

MAC address / switch port mappings can either be statically configured via the CLI, or learned by the switch dynamically. To learn dynamically the switch checks the source MAC address of incoming frames and adds the MAC address, switch port and VLAN on which it arrived into a table (if it isn’t already in the table). The switch also checks the destination MAC address of the incoming frame, and then checks the table for a match to find the switchport and VLAN that the destination MAC is attached to. If there is a match, the frame is then forwarded out of the corresponding switch port. If there is no match then the frame is flooded out of all switch ports assigned to the source VLAN – known as unknown unicast flooding. A switch port will only listen and learn source MAC addresses if allowed to do so by STP (Spanning Tree Protocol), ie. the port is not in a blocking state.

Frames destined for broadcast or multicast MAC addresses are also flooded by the switch to all ports in the same VLAN as the port that the frame originated on.


Layer 2 Frame Forwarding Decision Process

RX ports —> Ingress Queue —> Inbound & Outbound Security ACL’s (TCAM) —> Egress Queues —>TX ports

—> Qos ACL’s Clasification & Policing (TCAM) —>

—> L2 Fowarding Table (CAM) —>

CAM Table – contains: MAC Address | Egress Port | VLAN

Incoming frames are placed into one of the receiving port’s Ingress queues. Each queue has a different priority or service level, allowing the ports to be configured so that important frames get priority treament and are processed and forwarded before less important frames.

Frames are pulled of the ingress queue to be processed and at this point the switch needs to work out where to forward the frame to, and also whether or not it should be forwarded and if it should, then how to forward it. In other words, the the switch asks itself where is this frame destined for? (destination MAC address), is it allowed to be forwarded there? (security ACL’s) if so how do I get it there? (Qos ACL’s, switch port, egress queue) . These decisions are made simultaneoulsy by separate elementrs of the switching hardware:

  • L2 Fowarding Table – The CAM (Content-Addressable Memory) table contains MAC Address | Egress Port | VLAN records and is searched using the destination MAC address as the key. If there’s a match, then the egress port and VLAN ID are read from the table. No match means the frame is marked for floooding out of every port in the VLAN.
  • Security ACL’s – The TCAM (Ternary Content-Addressable Memory) table stores ACL’s and a single look up will determine if a frame can be forwarded or not. Security ACL’s can use MAC address, protocol types (non IP), IP addresses layer 4 port numbers to match frames.
  • Qos ACL’s – As with security ACL’s, a single TCAM table look up can determine if Qos should be applied to frames. This will effect which egress queue a frame is placed into.


Multilayer Switch Operation

Multilayer switching is defined as the ability to forward frames based on layer 3 and 4 data contained in packets. The fact that the layer 3 and 4 encapsulations are contained in ethernet frames means that layer 2 switching happens at the same time. There are 2 types of MLS:

  • Route Caching – first generation technology, no longer used by Cisco Catalyst switches.
  • Topology Based – second generation, uses a database built from layer 3 routing information, that contains the entire network topology. The database is updated dynamically as the topolgoy changes. Longest match found = correct layer 3 destination. Also known as Cisco Express Forwarding (CEF). The routing process runnning on the switch downloads the current routing table database into the Forward Information Base (FIB) area of hardware.


Layer 3 Packet Forwarding Decision Process

RX ports —> Ingress Queue —> Inbound & Outbound Security ACL’s (TCAM) —> L3 Packet Rewrite —> Egress Queues —>TX ports

—> Qos ACL’s Clasification & Policing (TCAM) —>

—> L3 Fowarding Table (FIB) —>

—> L2 Fowarding Table (CAM) —>


FIB Table – contains: IP address | Next Hop IP address | Next Hop MAC address | Egress Port

Incoming packets are placed into one of the receiving port’s Ingress queues, and both the L2 and L3 destination addresses are checked. This means that the forwarding decision is based on two address tables, and the decision of how to forward is based on the Security and Qos access lists as with layer 2 switching. The L3 Fowarding Table is searched using the destination IP address as the key, the longest match (IP and netmask) is found which then results in the next hop IP address being obtained. The FIB also has a record of the next hop MAC address and VLAN ID.

The final step before the packet is placed in the appropriate egress queue is to to re-write the packet, because it has gone through a routing process so therefore the destination MAC address needs to be changed to the next hop MAC address, the source MAC address is changed to that of the switch, and the TTL value is decremented by one. Also both the layer 2 and layer 3 header checksums must be recalculated as the contents of the frame/packet have changed.

Some packets cannot be handled by CEF and have to be forwarded to the switch CPU for “procsess switching”. Example packet types are: ARP, IP packets needing a response from a router, IP broadcasts relayed as unicasts (DHCP, IP helper-address), routing protocol updates, CDP, IPX, packets to be NAT’ed or encrypted, Appletalk, DecNet etc.


Content Addressable Memory (CAM)

Used by all Catalyst switches for L2 switching. As a frame arrives into a switchport it’s source MAC address, port and VLAN ID are all recorded in the CAM table. One extra item recorded is a timestamp – if a MAC addreses is already recorded in the CAM table then only the time stamp is updated. Also if a device has moved and it’s MAC address is learned on a new switchport then the most recent port and timestamp is recorded, and the old entry removed from the table. Stale entries (by default >300 seconds old) are aged out and deleted from the table. If a MAC address is being learned on alternating switchports then the switch generates an error.


Add a static CAM table entry:

Switch(config)# mac address-table static mac-address vlan vlan-id interface type mod/num.

Change the aging time via the CLI:

Switch(config)# mac address-table aging-time seconds

View contents of the CAM table:

Switch# show mac address-table dynamic [address mac-address | interface type mod/num | vlan vlan-id ]

Check the size of the CAM table:

Switch# show mac address-table count (shows results per VLAN)

Clear an entry from the CAM table:

Switch# clear mac address-table dynamic [address mac-address | interface type mod/num | vlan vlan-id ]


Ternary Content Addressable Memory (TCAM)

An extension of the CAM table concept, with entries composed of Value, Mask and Result (VMR) combinations. Multilayer switches check for matching Access Control Entities (ACE’s) in ACL’s is done in hardaware – as opposed to routers where evaluating traffic against ACL’s can add latency to packets. TCAM allows a packet to be evaluated against an entire ACL in a single table lookup. Multiple TCAM’s allow this process to happen for both inbound and outbound traffic simultaneously. There are 2 components of TCAM:


  • Feature Manager (FM) – merges ACE’s into the TCAM table
  • Switching Database Manager (SMD) – configures/tunes the TCAM. On some switch models the TCAM can be partitioned (not on 45/6500 platform)

Review of CCNP SWITCH instructor led course

As part of my prep for the exam, I attended the Implementing Cisco IP Switched Networks training course in Manchester this week. The course was run by QA Training and delivered by an instructor from Fast Lane. The course follows the official Cisco curriculum and for the lab exercises the students work in pairs on actual Cisco switches and routers hosted at Fast Lane’s data centre in Berlin.

The course itself was very enjoyable, if a little hard going at times. There’s a lot of ground to cover in five days, but the instructor did a great job of delivering the content in a way that kept your interest and attention. Having said that, there’s only so many hours you can take of going round and round the intricacies of STP before your brain starts blocking data – boom boom!! See what I did there, fellow network geeks?

The instructor also did a fantastic job of coping with the fact that we had not one, not two, but THREE power cuts during the week!! It’s surprising how much you can cover with a whiteboard and marker pen when you have to, and this clearly demonstrated the fact that the instructor really knew his stuff! In fairness to QA, they did all they could to ensure the power cuts were as short as possible, and even threw in free lunches each day to apologise!

Overall, I’d have to say that I really enjoyed the course and definitely got a lot out of it. I feel much better prepared for the SWITCH exam than I did at the start of the week and I would definitely recommend QA as a training company. I certainly hope to use them again for the ROUTE course later this year.


Follow me on Twitter