CCNA Routing and Switching

For now, the resource intended for people who may want to study for the Cisco CCNA Routing and Switching is covered by Introduction to Cisco equipment. Most of the information designed for basic Cisco tasks will be in that section.

There may be quite a few more details worth learning about, like how Cisco devices implement the OSPF protocol or the Spanning-Tree Protocol. Understanding how Cisco devices implement such technologies (like the OSPF protocol, or the Spanning-Tree Protocol protocol) may involve having a good understanding of the technologies work, in general (whether a Cisco device is being used, or not). Many such details have been documented by the author of this text, and so may be getting added to this guide in the future.

Perhaps see: Wikibooks: CCNA Certification.

Following are some notes related to material that is approximately what may be expected for the Cisco CCNA. This guide does not currently make any statements about being a resource that is sufficiently complete to generally be suitable for preparing for the Cisco CCNA. In other words, additional training is very likely to be extremely helpful, and, quite realistically, may be expected to be necessary at this time. One option may be to use Cisco's official training. An example of such a resource may be: Cisco Network Academy.

Following are some resources, which may or may not also be helpful.

Some basics

See: Cisco (Professional-level) Equipment: seeing output for some details about how to start seeing output fromt he device.

After hooking things up, information from the Cisco IOS basic usage guide (including its sub-topics) should be very familiar knowledge. People will certainly be familiar with most of the abilities described in that section if they are familiar enough with the equipment to be able to pass the CCNA examinations within the examination's time limit.

Routing

Information about routing is covered by the networking routing section.

People should be familiar with routing tables (see: showing routing tables in Cisco IOS). People should also be able to make routes as needed. (See: adding network routes, information related to Cisco IOS.)

Some information on routing protocols is available. (The information provided in the following references may be helpful, but might not cover things in sufficient depth to provide the mastery needed for the Cisco routing.) See: using routing protocols.

The CCNA R&S certification may require quite a bit more details than just the commands shown by that guide. For instance, people signing up for the certification examination may be expected to:

  • have a good understanding of how the protocols operate. (For instance, what happens if a device stops responding? Specifically, how do other devices on a network react to such a problem?)
  • Know the effect of various options
  • Know how to get information related to those protocols from a device that is capable of supporting those protocols and is running IOS.

At the time of this writing, some of those details may be beyond what is provided by the section on using routing protocols. So, knowing much of the information from the section on using routing protocols may be good/required, but not sufficient.

[#ciscocdp]: Cisco Discovery Protocol (“CDP”)

Information was here, and has been moved to: Cisco IOS basic usage guide: disabling CDP.

Spanning-Tree Protocol (and variations)

This topic is hardly discussed at all here, yet. This is not yet covered very extensively here.

See: the “Spanning-Tree Protocol.

One possible resource: Spanning Tree from PVST+ to Rapid-PVST Migration Configuration Example

For the moment, some details are at: Using commands to show (CCNA/Pre-CCNA). That currently discusses port types (designated/root/non-designated). (That information should be moved from there, perhaps to right here.

VLANs

See: networking VLANs for a basic introduction to VLANs.

Then, see: Cisco IOS VLANs for some other information.

As noted in the Cisco-specific section: familiarity with VTP/DTP may be expected.

[#vlantrnk]: VLAN Trunking

Note: This section on trunking has grown suitably large that a new sub-section has been created. Information that has been placed here will be moved to VLAN trunks in Cisco IOS.

Difference between access ports and trunk ports

With this type of design, network interface ports are considered to be either an “access port” or a “trunk”. There are some similar terms, like a port acting in either “access mode” or “trunk mode”, or the phrase “trunk link”, which refer to the same concept.

Traffic that is “tagged” with VLAN information is traffic that uses a modified frame format, which is a bit different than standard Ethernet. The modifications to the frame format allow a device to easily identify which VLAN a traffic is intended to be a part of.

A trunk port is capable of carrying multiple VLANs. Connections between multiple infrastructure devices (like hubs, routers, etc.) are typically connected to network interfaces that will be called a “trunk port” when talking about this type of design.

A general definition for an access port is that an access port does not support receiving traffic on more than one VLAN, nor sending traffic on more than one VLAN.

That is the simple definition of an access port. An access port supports only one VLAN. Cisco 3550 switch VLAN info complicates this definition by stating, “A voice VLAN port is an access port attached to a Cisco IP Phone, configured to use one VLAN for voice traffic and another VLAN for data traffic from a device attached to the phone.” So there is an example of an “access port” supporting more than one VLAN. However, that is a “voice VLAN”, and that seems to be treated as a special case. Until any more clear definition is provided, the simple way to think about things is that an “access port” doesn't support more than one VLAN.

(Notes removed from here, for review...) A network interface which is an access port is often/typically a network interface port that would be good to make an edge port for Spanning-Tree Protocol. And, vice versa: A network interface which would be good to make an edge port for Spanning-Tree Protocol is typically a network interface port that would be good to mark as an access port.

(Notes removed from here, for review...) Trunks are capable of using multiple VLANs, but don't have to. (A trunk can effectively using the settings of a “native VLAN”, which results in traffic not being tagged. This is even default behavior.)

If multiple VLANs are needed, then VLAN tagging will be required, and so a trunk is required.

Setting port mode

As mentioned before, a network interface port can be either an “access port” or a “trunk” port.

Specifying an access port
deviceName#config terminal
deviceName(config)#interface fa0/0
deviceName(config-if)#switchport mode access

... or, if the port had previously been configured to specifically be a trunk port:

deviceName#config terminal
deviceName(config)#interface fa0/0
deviceName(config-if)#no switchport mode trunk

After doing “switchport mode access”:

deviceName(config-if)#switchport mode access
deviceName(config-if)#end
deviceName#show interfaces f0/1 switchport

Exmaple output may include this line:

Administrative Mode: static access

The term “static” may refer to a VLAN “type”. Altneratives may be dynamic or voice. A port with dynamic VLAN membership may get details from a VLAN Membership Policy Server (“VMPS”). A voice VLAN may send messages to a VOIP phone providing a VLAN ID and configuration, and then voice traffic may be sent at higher priority. Both dynamic VLANs and voice VLANs are probably mostly beyond the realm of CCNA Routing and Switching certification examination (they are mentioned by Exploration 3 3.1.3.1); this info is just being provided to satisfy curiosity on what the word “static” may be referring to.

making a port be a “trunk” port
Switch trunk port

This may be the most basic setting of a trunk port.

Setting the mode

There are actually four different ways to specify that a port should be a trunk port. The first example shown will start with a basic approach. Alternative options will be discussed soon, when getting into the details of Cisco's Dynamic Trunking Protocol (“DTP”).

deviceName#config terminal
deviceName(config)#interface fa0/0
deviceName(config-if)#switchport mode trunk

This makes the network interface port enter “trunk” mode without enabling outgoing messages that use Cisco's Dynamic Trunking Protocol (“DTP”). Using Cisco's Dynamic Trunking Protocol (“DTP”) can involve a sort of “negotiation”, which is why this command says “nonegotiate”.

Note: This term “nonegotiate” is only related to Cisco's Dynamic Trunking Protocol (“DTP”), and is unrelated to the negotiate option for determining the trunking encapsulation method.)

Also, identifying the encapsulation may be necessary. (This might need to be done after switching the mode to nonegotiate or one of the other alternatives that cause the network interface port to act in “trunk” mode.)

Specifying encapsulation

The general syntax is:

deviceName(config-if)#switchport trunk encapsulation encapsType

The three possible values for encapsType are:

deviceName(config-if)#switchport trunk encapsulation negotiate

which specifies to auto-detect.

Note: This term negotiate is specifically for determining the trunking encapsulation method, and is unrelated to the “nonegotiate” mode that is related to Cisco's Dynamic Trunking Protocol (“DTP”) Despite the similarity in these options, they are completely unrelated things.

Or, insetad of auto-detection, a device can try to use 802.1Q trunking:

deviceName(config-if)#switchport trunk encapsulation dot1q

Or, for compatibility with Cisco's proprietary Inter-Switch Link (“ISL”) protocol:

deviceName(config-if)#switchport trunk encapsulation isl

Whether an encapsulation command is required, or not, is a bit questionable}: Cisco Network Academy CCNA training “Discovery 3” slide “3.4.1.3” states, “Switches that support both 802.1Q and ISL require the” ...[“switchport trunk encapsulation”] “configuration statement. The 2960” [model of Cisco switch] “does not require that statement because it only supports 802.1Q.” However, the next sentence states, “The negotiate parameter is the default mode on many Cisco switches.” (Why would there be a default mode if encapsulation was not required.) Specifying a mode (trying dot1q and then trying to switch to negotiate) is probably the approach that would generally work with most equipment. (The reason that it may be desirable to try dot1q first is just in case negotiate might unnecessarily choose the ISL option, if that is even a possibility.)

Cisco Network Academy CCNA training “Discovery 3” slide “3.4.1.2” states, “Higher-end switches, such as the Catalyst 6500 series, still support both tagging protocols; however, most LAN switches, such as the 2960, support only 802.1Q.”

Specifying what VLANs are allowed
deviceName(config-if)#switchport trunk allowed vlan add vlanCSVList

e.g.:

deviceName(config-if)#switchport trunk allowed vlan add 2,3
deviceName(config-if)#end
deviceName#show interfaces f0/1 switchport

Output may include: “Trunking VLANs Enabled: 1,2” or “Trunking VLANs Enabled: All

: [#iostnvln]: Specifying a native VLAN (in IOS)

One VLAN number per network port/interface may be described as “native”. Incoming traffic which is not tagged as belonging to a specific VLAN is considered to be part of the VLAN that is the native VLAN number for that interface/port. Outgoing traffic which is destined for the native VLAN number will not be tagged. (If the traffic has been tagged when the traffic was received by the switch, then the traffic will become untagged before it is sent out.) The default “native” VLAN number for each network port is VLAN 1.

deviceName>enable
deviceName#config terminal
deviceName(config)#interface NICid
deviceName(config-if)#dot1q native vlan VIDnum

e.g.:

deviceName>enable
deviceName#config terminal
deviceName(config)#interface fa0/0
deviceName(config-if)#dot1q native vlan 2

(Another version of text...)

A VLAN can be assigned to be the “native“ VLAN on a trunk. Then, incoming traffic that is received without a VLAN tag will be treated as if it is part of the “native” VLAN. Also, a switch may remove the trunk (802.1q) tag from an outgoing frame if the frame is using the trunk's “native” VLAN. As long as the remote switch uses the same “native” VLAN, which is generally the intended/expected design, then the remote switch will recognize which VLAN the untagged traffic is meant to use.

deviceName(config-if)#switchport trunk native vlan vlanIDNum

e.g.:

deviceName(config-if)#switchport trunk native vlan 2
deviceName(config-if)#end
deviceName#show interfaces f0/1 switchport

Output may include: “Trunking Native Mode VLAN: # (VLANname)” or “Trunking VLANs Enabled: All

deviceName(config-if)#no> switchport trunk native vlan
deviceName(config-if)#end
deviceName#show interfaces f0/1 switchport

Output should include: “Trunking Native Mode VLAN: 1 (VLANname)

Router on a stick

The “router on a stick” setup refers to a router that has multiple VLANs on one network interface port. In the classic setup that is typically envisioned, each VLAN is on a different subnet and a switch is connected to the router. The switch may not be able to route traffic from one subnet to another. So what the swtich will do is send traffic to a router connected to the same VLAN. The router will then send the traffic out to the other subnet, which means sending the traffic out the other VLAN. The traffic may be described as taking a “lollipop” path, as it goes up a stick, and then essentially makes a loop, and then goes back down the stick. Drawing that out may look like a classic lollipop.

As silly as the term “router on a stick” may sound, it is used in serious discussion to describe this sort of setup.

For the switch, this is done quite straightforwardly. Just have the network interface port be on both VLANs. Since switching is done at layer 2, the switch doesn't need to know about any difference in subnets. After all, switches can simply ignore IP addresses. The switch will send traffic to the router because the router is part of the same broadcast domain since the switch will think that the network interface port is part of the first VLAN that gets used.

The router then receives the traffic, and routes it, and then sends the traffic out the appropriate network interface. The switch then realizes that the traffic is on the second VLAN, and everything works.

The fancy part of this configuration is how the router is configured.

deviceName> enable 15
deviceName# config terminal
deviceName(config)# interface netInterfacePortName
deviceName(config-if)# no shutdown

Then, for each VLAN, assign information using a “sub-interface”. This is done using the following sort of syntax:

deviceName(config-if)# interface netInterfacePortName.subInterfaceNumber
deviceName(config-sub-if)# encapsulation dot1q vlanIDNum

That syntax will probably seem new to somebody who has worked with Cisco routers but who hasn't yet seen the “router on a stick” implementation. Some further details about those customizable parts are described later. First, though, let's just see another example which looks closer to what is actually seen. (The only difference between this example and what should be reality is that this example uses IP addresses that are reserved for documentation use, and actual deployments would use other addresses.)

deviceName> enable 15
deviceName# config terminal
deviceName(config)# interface Fa0/1
deviceName(config-if)# no shutdown
deviceName(config-if)# interface Fa0/1.3
deviceName(config-sub-if)# encapsulation dot1q 3
deviceName(config-sub-if)# ip address 192.0.2.1 255.255.255.0

That takes care of one interface. For a true “router on a stick” implementation, we'll need two.

deviceName(config-if)# interface Fa0/1.4
deviceName(config-sub-if)# encapsulation dot1q 4
deviceName(config-sub-if)# ip address 198.51.100.1 255.255.255.0

Note that in this example, the number “3” is used in two differnet ways. One is as a “sub-interface” number. The other is a “VLAN ID”. They don't have to match. However, people are usually trained with the recommendation to have them match, because there is no compelling reason to make them mismatch. Making them match will typically make sense, and it may be what some people are used to. So, the recommended process is to have those numbers match (like they do in the example just shown), even though that is not technically required.

What is required is that the encapsulation's VLAN ID number will need to be correct, matching what is expected by the equipment on the other end of the link.

There's no particular reason why this technology is limited to just two VLANs... just that if a third VLAN was used...

deviceName(config-if)# interface Fa0/1.5000
deviceName(config-sub-if)# encapsulation dot1q 55
deviceName(config-sub-if)# ip address 203.0.113.1 255.255.255.0

... then it would be “router on sticks”, rather than the more common phrase of “router on a stick”.

That that in that example, the router is using the non-recommended approach of making the local sub-interface number mismatch; it does not match the VLAN number. The assumption here is that the switch is using the matching VLAN number. If the switch is using vLAN 55 in this example, this example can work as expected.

The sub-interfaces will show up just like normal interfaces. Their names will simply have a period and a number as part of the name, just like how their names get typed when the sub-interfaces get created. For example, they will be seen with these commands:

show ip interface brief
show running-config | inc interface

To destroy sub-interfaces, use the no command to remove the unwanted command. (Something like: “no interface physicalInterfaceName.#”)

[#ciosdtp]: Details about Cisco's Dynamic Trunking Protocol (“DTP”) in Cisco IOS
Expected background

This guide is also geared towards using Cisco IOS. For further details, see: Cisco introduction. VLANs in Cisco IOS may discuss some topics that people are expected to know before they are successful in using this guide to effectively use Cisco's Dynamic Trunking Protocol (“DTP”).

Note: This is simply a part of the section about trunking. Familiarity with the concept of a “trunk” is likely to help people to be able to see the usefulness of this protocol. For further details, see sections on VLANs, and VLAN trunking.)

[#cioswptm]: Switchport Mode basics in Cisco IOS

Okay, take a deep breath. It is time for a quick assessment.

Have you got the concept of a “trunk port” down pat?

This is being asked, because understanding that may be crucially important to being able to understand the next set of material that is related to the Cisco CCNA exam: studying Cisco's Dynamic Trunking Protocol (“DTP”) (in Cisco IOS) and (perhaps?) also Cisco's VLAN Trunking Protocol (“VTP”) (in Cisco IOS). This is clear simply by even just looking at the names of those protocols: they are related to “trunking”, which refers simply to the process of making a network interface port behave in “trunk mode”.

To re-iterate what's been said before:

  • When frames are “tagged” with VLAN data, this simply means that the frames are using a recognized format that includes some bits that store the VLAN data.
  • Each network interface port is configured to be either “trunking”, which can be described as having the port be in “trunk” mode, or the network interface port is configured to be an “access port”, which can be described as having the port be in “access” mode.
    • A trunking port can handle frames that have been “tagged” with VLAN data.
    • An “access port” does not have the capability. There may be some benefit to identifying a port as an access port, like being a good candidate to be an edge port which may have some advantages like taking far less time with Cisco's Spanning-Tree Protocol implementation. (Notes removed from here, for review...)

Those concepts should be reviewed and studied as much as needed to be thoroughly understood before complicating things further by learning more about one of Cisco's proprietary “trunking” protocols. This basic knowledge should be understood before delving further into studying either Cisco's Dynamic Trunking Protocol (“DTP”), or Cisco's VLAN Trunking Protocol (“VTP”).

Similarities

Note that Cisco's Dynamic Trunking Protocol (“DTP”) is a different thing from Cisco's VLAN Trunking Protocol (“VTP”). Whenever learning about either of these protocols, make efforts to ensure that these topics are kept sufficiently separate, so that information about one is not bleeding over information about the other.

This may be discussed more in the section about Cisco's VLAN Trunking Protocol (“VTP”) in Cisco IOS.

Alternatives

This section about alternatives simply provides some background information, and is unlikely to be on a Cisco Certified Networking Associate (“CCNA”) certification examination.

Cisco's “Dynamic Trunking Protocol (DTP) is a proprietary networking protocol” according to Wikipedia's article for “Dynamic Trunking Protocol. People looking for a less proprietary alternative may wish to check into Multiple VLAN Registration Protocol (“MVRP”). Wikipedia's article for “Dynamic Trunking Protocol referred to the Generic Attribute Registration Protocol (“GARP”) VLAN Registration Protocol (“GVRP”). (Yes, the full expansion of that acronym seems to use the term &dlquo;Protocol” twice.) However, GVRP is older than the newer MVRP.

A key thing to remember about Cisco's Dynamic Trunking Protocol (“DTP”) is that the protocol's primary purpose is fulfilled based on a device sharing what mode the network interface port is in. So, an overview of the different modes is the critically big piece to learn in order to understand Cisco's Dynamic Trunking Protocol (“DTP”).

nonegotiate” mode

(Note: it may be natural to try to start a word that starts with “non” by thinking that the word starts with the syllable “non”. However, this does not say “non-negotiate” without a hyphen. This says “no negotiate” without a space.)

This setting makes the network interface port act like “trunk mode”, although the device does not send out traffic that uses Cisco's Dynamic Trunking Protocol (“DTP”) to let other devices know details about what mode the network interface port uses.

To cut down on unnecessary traffic, this is probably the best mode to use when it is known that the network will not have any other Cisco devices that will be using Cisco's Dynamic Trunking Protocol (“DTP”).

Note: Advice has been given, during training related to the “CCNA Security” certification, to use “nonegotiate” on an access port. So perhaps this mode might not be trunk-specific...

This probably determines the “Negotiation of Trunking: Off” line when running “deviceName#show interface fa0/1 switchport”.

The “trunk” mode of Cisco's Dynamic Trunking Protocol (“DTP”)

In this mode, the device does send out traffic that uses Cisco's Dynamic Trunking Protocol (“DTP”) to let other devices know that the network interface port is in the basic “trunk” mode.

It is rather unfortunate that some ambiguity, which causes potential for confusion, may exist regarding the term “trunk” mode. This mode is entered by using the “trunk” command, but the term “trunk mode” may also refer to the way that a network interface port is operating when that port supports “trunk”-style communications, which basically means that the port supports receiving traffic on multiple VLANs.

There are some other modes that can be used.

dynamic desirable

The switch will try to determine whether the remote end is a trunk, or an access port. If the remote end responds that it is willing to be a trunk port, then the switch becomes a trunk port (and so does the remote switch).

deviceName#config terminal
deviceName(config)#interface fa0/0
deviceName(config-if)#switchport mode dynamic desirable
dynamic auto
deviceName#config terminal
deviceName(config)#interface fa0/0
deviceName(config-if)#switchport mode dynamic auto

This will configure the switch to be a trunk port if the remote end is set to use trunking, or is set to dynamic desirable. However, although this switch can set the port to be a trunk, this switch is not desiring to be a trunk. So, if both switches are set to dynamic auto, then they remain as access ports.

Altogether, this means there are basically five different modes that the device can be placed in. To recap, those modes are:

access port

The network interface port will act as an access port, and will not switch the port into a “trunk” mode just because of incoming traffic that uses Cisco's Dynamic Trunking Protocol (“DTP”).

nonegotiate

The network interface port will act like a “trunk port”. Device still not use this network port to send out traffic that uses Cisco's Dynamic Trunking Protocol (“DTP”) to identify.

the mode named “trunk”

The network interface port will act like a “trunk port”. The device will use Cisco's Dynamic Trunking Protocol (“DTP”) to let other devices know that it is in “trunk” mode. The device does not use Cisco's Dynamic Trunking Protocol (“DTP”) to change modes, but just to let other devices know what it is doing.

dynamic desirable

The network interface port will start out acting like an “access port”. However, the device will be using Cisco's Dynamic Trunking Protocol (“DTP”) to try to communicate with a remote device that is using the mode named “trunk” or one of the “dynamic” modes. If any such remote device is found, then the device will start using “trunk” mode.

dynamic auto

The network interface port will start out acting like an “access port”. However, the device will be using Cisco's Dynamic Trunking Protocol (“DTP”) to try to communicate with a remote device that is using the mode named “trunk” or the “dynamic desirable” mode. If such a remote device is found, then the network interface port will act in a way that tries to support the communications that seem desired by the remote device. Specifically, this means that that the network interface port will switch to start acting like a trunk.

However, trunk support is really being done reluctantly, out of apparent necessity or desire by the remote device. If the remote device is in “dynamic auto” mode, then the network interface port (on this device, and also the network interface port on the remote device) may be happy to simply remain acting like an “access port”. The network interface port still continues to keep using Cisco's Dynamic Trunking Protocol (“DTP”), in case there are any remote changes that require the network interface port to change modes.

In four of those modes, the port is acting like a trunk or it will as soon as Cisco's Dynamic Trunking Protocol (“DTP”) indicates that trunk mode is desired.

Switches handling untagged traffic

Some types of traffic may simply be untagged. One example (from Cisco Network Academy CCNA training “Discovery 3” slide “3.4.2.1”) is traffic from Cisco Discovery Protocol (CDP).

Outgoing traffic which goes to an access port will only be permitted if the traffic matches the VLAN number of that access port. If the traffic does match that VLAN number, then the traffic becomes untagged, because most hosts do not support VLAN tagging.

For trunks, traffic that goes to the native VLAN will be sent out untagged. Incoming traffic that is not tagged will be treated as if it is part of the native VLAN.

[#ciosvtp]: Cisco's VLAN Trunking Protocol (“VTP”) in Cisco IOS
Cisco's VLAN Trunking Protocol (“VTP”) differences from Cisco's Dynamic Trunking Protocol (“DTP”)

Cisco's Dynamic Trunking Protocol (“DTP”) and Cisco's VLAN Trunking Protocol (“VTP”) are probably often taught relatively close to each other. On one hand, that may seem quite sensible. Both topics are related to using a Cisco proprietary protocol where devices are sharing information about VLANs.

However, they are not the same thing. Whenever learning about either of these protocols, make efforts to ensure that these topics are kept sufficiently separate, so that information about one is not bleeding over information about the other. Without having a clear break like this, multiple people have simply tried to memorize the new and additional information, and then found some confusion when some of it seemed very similar to other information that has been recently memorized. Keep these details separate.

Before continuing on with any other details about how to use Cisco's VLAN Trunking Protocol (“VTP”) in Cisco IOS, see: Switchport Mode basics in Cisco IOS. Make sure that is mastered before continuing on.

Purpose

The basic purpose of Cisco's VLAN Trunking Protocol (“VTP”) is to share information about which VLANs are supported on individual network interface ports.

Misc/side note

PacketLife.net: Jeremy Stretch's “Disabling Dynamic Trunking Protocol (DTP)” mentions both VTP and, unsurprisingly (given the title of the article), DTP.

3 VTP modes

A switch will be operating in one of three modes:

server

Being a VTP server is the default mode. Modifies configurations for itself, and sends updated configurations to all other devices that are participating in the same VTP (configuration) domain. Saves VTP configuration into NVRAM.

client

A VTP client accepts configuration revisions from any VTP servers. Furthermore, the VTP client passes on updates to other devices that may be using VTP. The most notable difference between a VTP client and a VTP server is that the VTP client Does not allow locally-made changes to VTP configuration (as long as it is still using the role of being a VTP client). (Note: The word “Does” was capitalized. Was that some output quoted from an error message?)

A device using this mode is expected to get the VLAN information from the VTP server. Modifying VLANs, including creating new VLANs or destroying unwanted VLANs, may not be permitted while the device is remaining in the VTPOperating Mode of being a VTP Client.

This is the one mode that does not try to store VLAN information in NVRAM.

transparent

A device in “transparent mode” forwards VTP advertisements that have been received by other devices. Other than that, does not participate in Cisco's VLAN Trunking Protocol (“VTP”).

To see what mode a device is operating in, “sh vtp status” provides some VTP-related output, including a line that says “Operating Mode”.

Settings
VTP domain

The VTP domain setting refers to a name that gets assigned.

A client will not accept updates if the updates are meant for a different VTP domain. (This means that the client will not apply the settings. It is also believed that the client will not forard the settings on, although that may need to be double-checked...)

To see the VTP domain that a device is using, use “sh vtp status”.

To customize the value of the VTP domain:

deviceName>enable 15
deviceName#config terminal
deviceName#vtp domain domName
VTP password

To see the vtp password that a device is using, run “sh vtp password

deviceName>show vtp password

The password is more useful to prevent unwanted (possibly accidental) updates from another device that communicates with Cisco's VLAN Trunking Protocol (“VTP”). For a VTP-related update to occur, both devices need to be using both the same VTP password and also the same value for the VTP domain (name) setting.

The password may be updated:

deviceName>enable
deviceName#config terminal
deviceName#vtp password sample

The author of this text does not have many details about just how securely the password gets handled while a device is communicating with Cisco's VLAN Trunking Protocol (“VTP”). It seems possible that the password may be more effective at preventing accidental updates than preventing a dedicated attacker from gathering or updating information related to Cisco's VLAN Trunking Protocol (“VTP”).

The VTP password is not affected by using service password-encryption.

Reviewing status

Some of the commands have already been mentioned:

deviceName?show vtp status
deviceName?show vtp password

Another command that may be quite useful in seeing information related to VTP is:

deviceName?show vtp counters

Currently, some sample output for these commands may be shown by Using commands to show information in Cisco IOS (Generally CCNA/Pre-CCNA level).

Misc details

There are additional details that get covered in official Cisco CCNA training, like the different communications types that a VTP update/message may be. Another example may be understanding “VTP Pruning.

Such details are not currently covered extensively by this guide, but may be good topics for a person to be familiar with if a person is trying to prepare for the Cisco Certified Network Associate (“CCNA”) Routing and Switching certification examination(s).

Access Control Lists

Information on Access Control Lists (and Access Control Entries) : Cisco IOS ACLs.

Misc

perhaps... exectimeout (e.g. defaults to 10 minutes by CCP's security audit)