This chapter discusses the LAN topics discussed in depth in the first three chapters, plus a few prerequisite topics, from a troubleshooting perspective.

Troubleshooting for any networking topic requires a slightly different mindset as compared to thinking about configuration and verification. When thinking about configuration and verification, it helps to think about basic designs, learn how to configure the feature correctly, and learn how to verify the correct configuration is indeed working correctly. However, to learn how to troubleshoot, you need to think about symptoms when the design is incorrect, or if the configuration does not match the good design. What symptoms occur when you make one type of mistake or another? This chapter looks at the common types of mistakes, and works through how to look at the status with show commands to find those mistakes.

This chapter breaks the material into four major sections. The first section tackles the largest topic, STP troubleshooting. STP is not likely to fail as a protocol; instead, STP may not be operating as designed, so the task is to find how STP is currently working and discover how to then make the configuration implement the correct design. The second major section then moves on to Layer 2 EtherChannels, which have a variety of small potential problems that can prevent the dynamic formation of an EtherChannel.

The third major section of the chapter focuses on the data plane forwarding of Ethernet frames on LAN switches, in light of VLANs, trunks, STP, and EtherChannels. That same section reviews the Layer 2 forwarding logic of a switch in light of these features. The fourth and final major section then examines VLAN and trunking issues, and how those issues impact switch forwarding.

Note that a few of the subtopics listed within the exam topics at the beginning of this chapter are not discussed in this chapter. This chapter does not discuss VTP beyond its basic features (VTP is discussed in depth in Chapter 5) or Layer 3 EtherChannels (discussed in Chapter 19).

STP questions tend to intimidate many test takers. STP uses many rules, with tiebreakers in case one rule ends with a tie. Without much experience with STP, people tend to distrust their own answers. Also, even those of us with networking jobs already probably do not troubleshoot STP very often, because STP works well. Often, troubleshooting STP is not about STP failing to do its job but rather about STP working differently than designed, with a different root switch, or different root ports (RP), and so on. Seldom does STP troubleshooting begin with a case in which STP has failed to prevent a loop.

This section reviews the rules for STP, while emphasizing some important troubleshooting points. In particular, this section takes a closer look at the tiebreakers that STP uses to make decisions. It also makes some practical suggestions about how to go about answering exam questions such as “which switch is the root switch?”

Determining the STP root switch is easy if you know all the switches’ BIDs: Just pick the lowest value. If the question lists the priority and MAC address separately, as is common in some show command output, pick the switch with the lowest priority, or in the case of a tie, pick the lower MAC address value.

And just to be extra clear, STP does not have nor need a tiebreaker for electing the root switch. The BID uses a switch universal MAC address as the last 48 bits of the BID. These MAC addresses are unique in the universe, so there should never be identical BIDs or the need for a tiebreaker.

For the exam, a question that asks about the root switch might not be so simple as listing a bunch of BIDs and asking you which one is “best.” A more likely question is a simulator (sim) question in which you have to do any show commands you like or a multiple choice question that lists the output from only one or two commands. Then you have to apply the STP algorithm to figure out the rest.

When faced with an exam question using a simulator, or just the output in an exhibit, use a simple strategy of ruling out switches, as follows:

Step 1. Begin with a list or diagram of switches, and consider all as possible root switches.

Step 2. Rule out any switches that have an RP (show spanning-tree, show spanning-tree root), because root switches do not have an RP.

Step 3. Always try show spanning-tree, because it identifies the local switch as root directly: “This switch is the root” on the fifth line of output.

Step 4. Always try show spanning-tree root, because it identifies the local switch as root indirectly: The RP column is empty if the local switch is the root.

Step 5. When using a sim, rather than try switches randomly, chase the RPs. For example, if starting with SW1, and SW1’s G0/1 is an RP, next try the switch on the other end of SW1’s G0/1 port.

Step 6. When using a sim, use show spanning-tree vlan x on a few switches and record the root switch, RP, and designated port (DP). This strategy can quickly show you most STP facts.

The one step in this list that most people ignore is the idea of ruling out switches that have an RP. Root switches do not have an RP, so any switch with an RP can be ruled out as not being the root switch for that VLAN. Example 4-1 shows two commands on switch SW2 in some LAN that confirms that SW2 has an RP and is therefore not the root switch.

Example 4-1 Ruling Out Switches as Root Based on Having a Root Port

Both commands identify SW2’s G0/2 port as its RP, so if you follow the suggestions, the next switch to try in a sim question would be the switch on the other end of SW2’s G0/2 interface.

Determining the RP of a switch when show command output is available is relatively easy. As shown recently in Example 4-1, both show spanning-tree and show spanning-tree root list the root port of the local switch, assuming it is not the root switch. The challenge comes more when an exam question makes you think through how the switches choose the RP based on the root cost of each path to the root switch, with some tiebreakers as necessary.

As a review, each nonroot switch has one, and only one, RP for a VLAN. To choose its RP, a switch listens for incoming Hello bridge protocol data units (BPDU). For each received Hello, the switch adds the cost listed in the hello BPDU to the cost of the incoming interface (the interface on which the Hello was received). That total is the root cost over that path. The lowest root cost wins, and the local switch uses its local port that is part of the least root cost path as its root port.

Although that description has a lot of twists and turns in the words, it is the same concept described for Chapter 2’s Figure 2-8.

Most humans can analyze what STP chooses by using a network diagram and a slightly different algorithm. Instead of thinking about Hello messages and so on, approach the question as this: the sum of all outgoing port costs between the nonroot switch and the root. Repeating a familiar example, with a twist, Figure 4-1 shows the calculation of the root cost. Note that SW3’s Gi0/1 port has yet again had its cost configured to a different value.

STP Tiebreakers When Choosing the Root Port

Figure 4-1 shows the easier process of adding the STP costs of the outgoing interfaces over each from SW3, a nonroot, to SW1, the root. It also shows a tie (on purpose), to talk about the tiebreakers.

When a switch chooses its root port, the first choice is to choose the local port that is part of the least root cost path. When those costs tie, the switch picks the port connected to the neighbor with the lowest BID. This tiebreaker usually breaks the tie, but not always. So, for completeness, the three tiebreakers are, in the order a switch uses them, as follows:

1. Choose based on the lowest neighbor bridge ID.

2. Choose based on the lowest neighbor port priority.

3. Choose based on the lowest neighbor internal port number.

(Note that the switch only considers the root paths that tie when thinking about these tiebreakers.)

For example, Figure 4-1 shows that SW3 is not root and that its two paths to reach the root tie with their root costs of 8. The first tiebreaker is the lowest neighbor’s BID. SW1’s BID value is lower than SW2’s, so SW3 chooses its G0/1 interface as its RP in this case.

The last two RP tiebreakers come into play only when two switches connect to each other with multiple links, as shown in Figure 4-2. In that case, a switch receives Hellos on more than one port from the same neighboring switch, so the BIDs tie.

In this particular example, SW2 becomes root, and SW1 needs to choose its RP. SW1’s port costs tie, at 19 each, so SW1’s root cost over each path will tie at 19. SW2 sends Hellos over each link to SW1, so SW1 cannot break the tie based on SW1’s neighbor BID because both list SW2’s BID. So, SW1 has to turn to the other two tiebreakers.

NOTE: In real life, most engineers would put these two links into an EtherChannel.

The next tiebreaker is a configurable option: the neighboring switch’s port priority on each neighboring switch interface. Cisco switch ports default to a setting of 128, with a range of values from 0 through 255, with lower being better (as usual). In this example, the network engineer has set SW2’s F0/16 interface with the spanning-tree vlan 10 port-priority 112 command. SW1 learns that the neighbor has a port priority of 112 on the top link and 128 on the bottom, so SW1 uses its top (F0/14) interface as the root port.

If the port priority ties, which it often does due to the default values, STP relies on an internal port numbering on the neighbor. Cisco switches assign an internal integer to identify each interface on the switch. The nonroot looks for the neighbor’s lowest internal port number (as listed in the Hello messages) and chooses its RP based on the lower number.

Cisco switches use an obvious numbering, with Fa0/1 having the lowest number, then Fa0/2, then Fa0/3, and so on. So, in Figure 4-2, SW2’s Fa0/16 would have a lower internal port number than Fa0/17; SW1 would learn those numbers in the Hello; and SW1 would use its Fa0/14 port as its RP.

Suggestions for Attacking Root Port Problems on the Exam

Exam questions that make you think about the RP can be easy if you know where to look and the output of a few key commands is available. However, the more conceptual the question, the more you have to calculate the root cost over each path, correlate that to different show commands, and put the ideas together. The following list makes a few suggestions about how to approach STP problems on the exam:

1. If available, look at the show spanning-tree and show spanning-tree root commands. Both commands list the root port and the root cost (see Example 4-1).

2. The show spanning-tree command lists cost in two places: the root cost at the top, in the section about the root switch; and the interface cost, at the bottom, in the per-interface section. Be careful, though; the cost at the bottom is the interface cost, not the root cost!

3. For problems where you have to calculate a switch’s root cost:

a. Memorize the default cost values: 100 for 10 Mbps, 19 for 100 Mbps, 4 for 1 Gbps, and 2 for 10 Gbps.

b. Look for any evidence of the spanning-tree cost configuration command on an interface, because it overrides the default cost. Do not assume default costs are used.

c. When you know a default cost is used, if you can, check the current actual speed as well. Cisco switches choose STP cost defaults based on the current speed, not the 

Each LAN segment has a single switch that acts as the designated port (DP) on that segment. On segments that connect a switch to a device that does not even use STP—for example, segments connecting a switch to a PC or a router—the switch always wins, because it is the only device sending a Hello onto the link. However, links with two switches require a little more work to discover which should be the DP. By definition:

Step 1. For switches connected to the same LAN segment, the switch with the lowest cost to reach the root, as advertised in the Hello they send onto the link, becomes the DP on that link.

Step 2. In case of a tie, among the switches that tied on cost, the switch with the lowest BID becomes the DP.

For example, consider Figure 4-3. This figure notes the root, RPs, and DPs and each switch’s least cost to reach the root over its respective RP.

Focus on the segments that connect the nonroot switches for a moment:

SW2–SW4 segment: SW4 wins because of its root cost of 19, compared to SW2’s root cost of 20.

SW2–SW3 segment: SW3 wins because of its root cost of 19, compared to SW2’s root cost of 20.

SW3–SW4 segment: SW3 and SW4 tie on root cost, both with root cost 19. SW3 wins due to its better (lower) BID value.

Interestingly, SW2 loses and does not become DP on the links to SW3 and SW4 even though SW2 has the better (lower) BID value. The DP tiebreaker does use the lowest BID, but the first DP criteria is the lowest root cost, and SW2’s root cost happens to be higher than SW3’s and SW4’s.

NOTE: A single switch can connect two or more interfaces to the same collision domain, and compete to become DP, if hubs are used. In such cases, two different switch ports on the same switch tie, the DP choice uses the same two final tiebreakers as used with the RP selection: the lowest interface STP priority, and if that ties, the lowest internal interface number.

Suggestions for Attacking Designated Port Problems on the Exam

As with exam questions asking about the RP, exam questions that make you think about the DP can be easy if you know where to look and the output of a few key commands is available. However, the more conceptual the question, the more you have to think about the criteria for choosing the DP: first the root cost of the competing switches, and then the better BID if they tie based on root cost.

The following list gives some tips to keep in mind when digging into a given DP issue. Some of this list repeats the suggestions for finding the RP, but to be complete, this list includes each idea as well.

1. If available, look at the show spanning-tree commands, at the list of interfaces at the end of the output. Then, look for the Role column, and look for Desg, to identify any DPs.

2. Identify the root cost of a switch directly by using the show spanning-tree command. But be careful! This command lists the cost in two places, and only the mention at the top, in the section about the root, lists the root cost.

3. For problems where you have to calculate a switch’s root cost, do the following:

a. Memorize the default cost values: 100 for 10 Mbps, 19 for 100 Mbps, 4 for 1 Gbps, and 2 for 10 Gbps.

b. Look for any evidence of the spanning-tree cost configuration command on an interface, because it overrides the default cost. Do not assume default costs are used.

c. When you know a default cost is used, if you can, check the current actual speed as well. Cisco switches choose STP cost defaults based on the current speed, not the maximum speed.

STP puts each RP and DP into a forwarding state, and ports that are neither RP nor DP into a blocking state. Those states may remain as is for days, weeks, or months. But at some point, some switch or link will fail, a link may change speeds (changing the STP cost), or the STP configuration may change. Any of these events can cause switches to repeat their STP algorithm, which may in turn change their own RP and any ports that are DPs.

When STP converges based on some change, not all the ports have to change their state. For instance, a port that was forwarding, if it still needs to forward, just keeps on forwarding. Ports that were blocking that still need to block keep on blocking. But when a port needs to change state, something has to happen, based on the following rules:

For interfaces that stay in the same STP state, nothing needs to change.

For interfaces that need to move from a forwarding state to a blocking state, the switch immediately changes the state to blocking.

For interfaces that need to move from a blocking state to a forwarding state, the switch first moves the interface to listening state, then learning state, each for the time specified by the forward delay timer (default 15 seconds). Only then is the interface placed into forwarding state.

Because the transition from blocking to forwarding does require some extra steps, you should be ready to respond to conceptual questions about the transition. To be ready, review the section “Reacting to State Changes That Affect the STP Topology” in Chapter 2.

EtherChannels can prove particularly challenging to troubleshoot for a couple of reasons. First, you have to be careful to match the correct configuration, and there are many more incorrect configuration combinations than there are correct combinations. Second, many interface settings must match on the physical links, both on the local switch and on the neighboring switch, before a switch will add the physical link to the channel. This second major section in the chapter works through both sets of issues.

In Chapter 3, the section titled “Configuring EtherChannel” listed the small set of working configuration options on the channel-group command. Those rules can be summarized as follows, for a single EtherChannel:

1. On the local switch, all the channel-group commands for all the physical interfaces must use the same channel-group number.

2. The channel-group number can be different on the neighboring switches.

3. If using the on keyword, you must use it on the corresponding interfaces of both switches.

4. If you use the desirable keyword on one switch, the switch uses PAgP; the other switch must use either desirable or auto.

5. If you use the active keyword on one switch, the switch uses LACP; the other switch must use either active or passive.

These rules summarize the correct configuration options, but the options actually leave many more incorrect choices. The following list shows some incorrect configurations that the switches allow, even though they would result in the EtherChannel not working. The list compares the configuration on one switch to another based on the physical interface configuration. Each lists the reasons why the configuration is incorrect.

Configuring the on keyword on one switch, and desirable, auto, active, or passive on the other switch. The on keyword does not enable PAgP, and does not enable LACP, and the other options rely on PAgP or LACP.

Configuring the auto keyword on both switches. Both use PAgP, but both wait on the other switch to begin negotiations.

Configuring the passive keyword on both switches. Both use LACP, but both wait on the other switch to begin negotiations.

Configuring the active keyword on one switch and either desirable or auto on the other switch. The active keyword uses LACP, whereas the other keywords use PAgP.

Configuring the desirable keyword on one switch and either active or passive on the other switch. The desirable keyword uses PAgP, whereas the other keywords use LACP.

Example 4-2 shows an example that matches the last item in the list. In this case, SW1’s two ports (F0/14 and F0/15) have been configured with the desirable keyword, and SW2’s matching F0/16 and F0/17 have been configured with the active keyword. The example lists some telling status information about the failure, with notes following the example.

Example 4-2 Incorrect Configuration Using Mismatched PortChannel Protocols

Start at the top, in the legend of the show etherchannel summary command. The D code letter means that the channel itself is down, with S meaning that the channel is a Layer 2 EtherChannel. Code I means that the physical interface is working independently from the PortChannel (described as “stand-alone”). Then, the bottom of that command’s output highlights PortChannel 1 (Po1) as Layer 2 EtherChannel in a down state (SD), with F0/14 and F0/15 as stand-alone interfaces (I).

Interestingly, because the problem is a configuration mistake, the two physical interfaces still operate independently, as if the PortChannel did not exist. The last command in the example shows that while the PortChannel 1 interface is down, the two physical interfaces are in a connected state.

NOTE: As a suggestion for attacking EtherChannel problems on the exam, rather than memorizing all the incorrect configuration options, concentrate on the list of correct configuration options. Then look for any differences between a given question’s configuration as compared to the known correct configurations and work from there.

Even when the channel-group commands have all been configured correctly, other configuration settings can cause problems as well. This last topic examines those configuration settings and their impact.

First, a local switch checks each new physical interface that is configured to be part of an EtherChannel, comparing each new link to the existing links. That new physical interface’s settings must be the same as the existing links’ settings; otherwise, the switch does not add the new link to the list of approved and working interfaces in the channel. That is, the physical interface remains configured as part of the PortChannel, but it is not used as part of the channel, often being placed into some nonworking state.

The list of items the switch checks includes the following:

Speed

Duplex

Operational access or trunking state (all must be access, or all must be trunks)

If an access port, the access VLAN

If a trunk port, the allowed VLAN list (per the switchport trunk allowed command)

If a trunk port, the native VLAN

STP interface settings

In addition, switches check the settings on the neighboring switch. To do so, the switches either use PAgP or LACP (if already in use), or use Cisco Discovery Protocol (CDP) if using manual configuration. The neighbor must match on all parameters in this list except the STP settings.

As an example, SW1 and SW2 again use two links in one EtherChannel. Before configuring the EtherChannel, SW1’s F0/15 was given a different STP port cost than F0/14. Example 4-3 picks up the story just after configuring the correct channel-group commands, when the switch is deciding whether to use F0/14 and F0/15 in this EtherChannel.

Example 4-3 Local Interfaces Fail in EtherChannel Because of Mismatched STP Cost

The messages at the top of the example specifically state what the switch does when determining whether the interface settings match. In this case, SW1 detects the different STP costs. SW1 does not use F0/14, does not use F0/15, and even places them into an err-disabled state. The switch also puts the PortChannel into err-disabled state. As a result, the PortChannel is not operational, and the physical interfaces are also not operational.

To solve this problem, you must reconfigure the physical interfaces to use the same STP settings. In addition, the PortChannel and physical interfaces must be shutdown, and then no shutdown, to recover from the err-disabled state. (Note that when a switch applies the shutdown and no shutdown commands to a PortChannel, it applies those same commands to the physical interfaces, as well; so, just do the shutdown/no shutdown on the PortChannel interface.)

STP and EtherChannel both have an impact on what a switch’s forwarding logic can use. STP limits which interfaces the data plane even considers using by placing some ports in a blocking state (STP) or discarding state (RSTP), which in turn tells the data plane to simply not use that port. EtherChannel gives the data plane new ports to use in the switch’s MAC address table—EtherChannels—while telling the data plane to not use the underlying physical interfaces in an EtherChannel in the MAC table.

This (short) third major section of the chapter explores the impact of STP and EtherChannel on data plane logic and a switch’s MAC address table.

Consider the small LAN shown in Figure 4-4. The LAN has only three switches, with redundancy, just big enough to make the point for this next example. The LAN supports two VLANs, 1 and 2, and the engineer has configured STP such that SW3 blocks on a different port in each of the two VLANs. As a result, VLAN 1 traffic would flow from SW3 to SW1 next, and in VLAN 2, traffic would flow from SW3 to SW2 next instead.

Looking at diagrams like those in Figure 4-4 makes the forwarding path obvious. Although the figure shows the traffic path, that path is determined by switch MAC learning, which is then impacted by the ports on which STP has set a blocking or discarding state.

For example, consider VLAN 1’s STP topology in Figure 4-4. Remember, STP blocks on a port on one switch, not on both ends of the link. So, in the case of VLAN 1, SW3’s G0/2 port blocks, but SW2’s G0/1 does not. Even so, by blocking on a port on one end of the link, that act effectively stops any MAC learning from happening by either device on the link. That is, SW3 learns no MAC addresses on its G0/2 port, and SW2 learns no MAC addresses on its G0/1 port, for these reasons:

SW2 learns no MAC addresses on G0/1: On the blocking (SW3) end of the SW3–SW2 trunk, SW3 will not send frames out that link to SW2, so SW2 will never receive frames from which to learn MAC addresses on SW2’s G0/1.

SW3 learns no MAC addresses on G0/2: On the not blocking (SW2) end of the SW3–SW2 trunk, SW2 will flood frames out that port. SW3 receives those frames, but because SW3 blocks, SW3 ignores those received frames and does not learn their MAC addresses.

Given that discussion, can you predict the MAC table entries on each of the three switches for the MAC addresses of servers A and B in Figure 4-4? On switch SW2, the entry for server A, in VLAN 1, should refer to SW2’s G0/2 port, pointing to SW1 next, matching the figure. But SW2’s entry for server B, in VLAN 2, references SW2’s G0/1 port, again matching the figure. Example 4-4 shows the MAC tables on SW1 and SW2 as a confirmation.

Example 4-4 Examining SW1 and SW2 Dynamic MAC Address Table Entries

Most designs use multiple links between switches, with those links configured to be part of an EtherChannel. What does that do to the MAC forwarding logic? In short, the switch uses the PortChannel interfaces, and not the physical interfaces bundled into the EtherChannel, in the MAC address table. Specifically:

MAC learning: Frames received in a physical interface that is part of a PortChannel are considered to arrive on the PortChannel interface. So, MAC learning adds the PortChannel interface rather than the physical interface to the MAC address table.

MAC forwarding: The forwarding process will find a PortChannel port as an outgoing interface when matching the MAC address table. Then the switch must take the additional step to choose the outgoing physical interface, based on the load-balancing preferences configured for that PortChannel.

For example, consider Figure 4-5, which updates previous Figure 4-4 with two-link PortChannels between each pair of switches. With VLAN 1 blocking again on switch SW3, but this time on SW3’s PortChannel3 interface, what MAC table entries would you expect to see in each switch? Similarly, what MAC table entries would you expect to see for VLAN 2, with SW3 blocking on its PortChannel2 interface?

The logic of which entries exist on which ports mirrors the logic with the earlier example surrounding Figure 4-4. In this case, the interfaces just happen to be PortChannel interfaces. Example 4-5 shows the same command from the same two switches as Example 4-4: show mac address-table dynamic from both SW1 and SW2. (Note that to save length, the MAC table output shows only the entries for the two servers in Figure 4-5.)

Example 4-5 SW1 and SW2 MAC Tables with PortChannel Ports Listed

Switches use one of many load-balancing options to then choose the physical interface to use after matching MAC table entries like those shown in Example 4-5. By default, Cisco Layer 2 switches often default to use a balancing method based on the source MAC address. In particular, the switch looks at the low-order bits of the source MAC address (which are on the far right of the MAC address in written form). This approach increases the chances that the balancing will be spread somewhat evenly based on the source MAC addresses in use.

To wrap up the analysis of switch data plane forwarding, this section mostly reviews topics already discussed, but it serves to emphasize some important points. The topic is simply this: How does a switch know which VLAN a frame is a part of as the frame enters a switch? You have seen all the information needed to answer this question already, but take the time to review.

First, some interfaces trunk, and in those cases, the frame arrives with a VLAN ID listed in the incoming trunking header. In other cases, the frame does not arrive with a trunking header, and the switch must look at local configuration. But because the switch will match both the destination MAC address and the frame VLAN ID when matching the MAC address table, knowing how the switch determines the VLAN ID is important.

The following list reviews and summarizes the key points of how a switch determines the VLAN ID to associate with an incoming frame:

Step 1. If the port is an access port, associate the frame with the configured access VLAN (switchport access vlan vlan_id).

Step 2. If the port is a voice port, or has both an IP Phone and PC (or other data device) connected to the phone:

A. Associate the frames from the data device with the configured access VLAN (as configured with the switchport access vlan vlan_id command).

B. Associate the frames from the phone with the VLAN ID in the 802.1Q header (as configured with the switchport voice vlan vlan_id command).

Step 3. If the port is a trunk, determine the frame’s tagged VLAN, or if there is no tag, use that incoming interface’s native VLAN ID (switchport trunk native vlan_id).

A switch’s data plane forwarding processes depend in part on VLANs and VLAN trunking. Before a switch can forward frames in a particular VLAN, the switch must know about a VLAN and the VLAN must be active. And before a switch can forward a frame over a VLAN trunk, the trunk must currently allow that VLAN to pass over the trunk.

This final major section in this chapter focuses on VLAN and VLAN trunking issues, specifically issues that impact the frame switching process. The issues are as follows:

Step 1. Identify all access interfaces and their assigned access VLANs and reassign into the correct VLANs if incorrect.

Step 2. Determine whether the VLANs both exist (either configured or learned with the VLAN Trunking Protocol [VTP]) and are active on each switch. If not, configure and activate the VLANs to resolve problems as needed.

Step 3. Check the allowed VLAN lists, on the switches on both ends of the trunk, and ensure that the lists of allowed VLANs are the same.

Step 4. Check for incorrect configuration settings that result in one switch operating as a trunk, with the neighboring switch not operating as a trunk.

Step 5. Check the allowed VLANs on each trunk, to make sure that the trunk has not administratively removed a VLAN from being supported on a trunk.

To ensure that each access interface has been assigned to the correct VLAN, engineers simply need to determine which switch interfaces are access interfaces instead of trunk interfaces, determine the assigned access VLANs on each interface, and compare the information to the documentation. The show commands listed in Table 4-1 can be particularly helpful in this process.

If possible, start this step with the show vlan and show vlan brief commands, because they list all the known VLANs and the access interfaces assigned to each VLAN. Be aware, however, that these two commands do not list operational trunks. The output does list all other interfaces (those not currently trunking), no matter whether the interface is in a working or nonworking state.

If the show vlan and show interface switchport commands are not available in a particular exam question, the show mac address-table command can also help identify the access VLAN. This command lists the MAC address table, with each entry including a MAC address, interface, and VLAN ID. If the exam question implies that a switch interface connects to a single device, you should only see one MAC table entry that lists that particular access interface; the VLAN ID listed for that same entry identifies the access VLAN. (You cannot make such assumptions for trunking interfaces.)

After you determine the access interfaces and associated VLANs, if the interface is assigned to the wrong VLAN, use the switchport access vlan vlan-id interface subcommand to assign the correct VLAN ID.

Switches do not forward frames for VLANs that are (a) not known because the VLAN is not configured or has not been learned with VTP or (b) the VLAN is known, but it is disabled (shut down). This section summarizes the best ways to confirm that a switch knows that a particular VLAN exists, and if it exists, determines the shutdown state of the VLAN.

First, on the issue of whether a VLAN exists on a switch, a VLAN can be defined to a switch in two ways: using the vlan number global configuration command, or it can be learned from another switch using VTP. Chapter 5, “VLAN Trunking Protocol,” discusses VTP and how VTP can be used by a switch to learn about VLANs. For this discussion, consider that the only way for a switch to know about a VLAN is to have a vlan command configured on the local switch.

Next, the show vlan command always lists all VLANs known to the switch, but the show running-config command does not. Switches configured as VTP servers and clients do not list the vlan commands in the running-config file nor the startup-config file; on these switches, you must use the show vlan command. Switches configured to use VTP transparent mode, or that disable VTP, list the vlan configuration commands in the configuration files. (Use the show vtp status command to learn the current VTP mode of a switch.)

After you determine that a VLAN does not exist on a switch, the problem might be that the VLAN simply needs to be configured. If so, follow the VLAN configuration process as covered in detail in Chapter 1.

Even for existing VLANs, you must also verify whether the VLAN is active. The show vlan command should list one of two VLAN state values, depending on the current state: either active or act/lshut. The second of these states means that the VLAN is shut down. Shutting down a VLAN disables the VLAN on that switch only, so that the switch will not forward frames in that VLAN.

Switch IOS gives you two similar configuration methods with which to disable (shutdown) and enable (no shutdown) a VLAN. Example 4-6 shows how, first by using the global command [no] shutdown vlan number and then using the VLAN mode subcommand [no] shutdown. The example shows the global commands enabling and disabling VLANs 10 and 20, respectively, and using VLAN subcommands to enable and disable VLANs 30 and 40 (respectively).

Example 4-6 Enabling and Disabling VLANs on a Switch

Trunking can be configured correctly so that both switches forward frames for the same set of VLANs. However, trunks can also be misconfigured, with a couple of different results. In some cases, both switches conclude that their interfaces do not trunk. In other cases, one switch believes that its interface is correctly trunking, while the other switch does not.

The most common incorrect configuration—which results in both switches not trunking—is a configuration that uses the switchport mode dynamic auto command on both switches on the link. The word “auto” just makes us all want to think that the link would trunk automatically, but this command is both automatic and passive. As a result, both switches passively wait on the other device on the link to begin negotiations.

With this particular incorrect configuration, the show interfaces switchport command on both switches confirms both the administrative state (auto) and the fact that both switches operate as “static access” ports. Example 4-7 highlights those parts of the output from this command.

Example 4-7 Operational Trunking State

A different incorrect trunking configuration results in one switch with an operational state of “trunk,” while the other switch has an operational state of “static access.” When this combination of events happens, the interface works a little. The status on each end will be up/up or connected. Traffic in the native VLAN will actually cross the link successfully. However, traffic in all the rest of the VLANs will not cross the link.

Figure 4-6 shows the incorrect configuration along with which side trunks and which does not. The side that trunks (SW1 in this case) enables trunking always, using the command switchport mode trunk. However, this command does not disable Dynamic Trunking Protocol (DTP) negotiations. To cause this particular problem, SW1 also disables DTP negotiation using the switchport nonegotiate command. SW2’s configuration also helps create the problem, by using a trunking option that relies on DTP. Because SW1 has disabled DTP, SW2’s DTP negotiations fail, and SW2 does not trunk.

In this case, SW1 treats its G0/1 interface as a trunk, and SW2 treats its G0/2 interface as an access port (not a trunk). As shown in the figure at Step 1, SW1 could (for example) forward a frame in VLAN 10. However, SW2 would view any frame that arrives with an 802.1Q header as illegal, because SW2 treats its G0/2 port as an access port. So, SW2 discards any 802.1Q frames received on that port.

To deal with the possibility of this problem, always check the trunk’s operational state on both sides of the trunk. The best commands to check trunking-related facts are show interfaces trunk and show interfaces switchport.

NOTE: Frankly, in real life, just avoid this kind of configuration. However, the switches do not prevent you from making these types of mistakes, so you need to be ready. Note that Chapter 1’s Table 1-3 summarizes the list of options on the switchport trunk command, which combinations work, and which ones to completely avoid (like the combination shown here in Figure 4-6.)

VLAN trunks on Cisco switches can forward traffic for all defined and active VLANs. However, a particular trunk may not forward traffic for a defined and active VLAN for a variety of other reasons. You should know how to identify which VLANs a particular trunk port currently supports, and the reasons why the switch might not be forwarding frames for a VLAN on that trunk port.

The first category in this step can be easily done using the show interfaces trunk command, which only lists information about currently operational trunks. The best place to begin with this command is the last section of output, which lists the VLANs whose traffic will be forwarded over the trunk. Any VLANs that make it to this final list of VLANs in the command output meet the following criteria:

The VLAN exists and is active on the local switch (as seen in the show vlan command).

The VLAN has not been removed from the allowed VLAN list on the trunk (as configured with the switchport trunk allowed vlan interface subcommand).

The VLAN has not been VTP-pruned from the trunk. (This is a VTP feature, discussed in Chapter 5, which this section will now otherwise ignore, deferring discussion until Chapter 5. It is only listed here because the show command output mentions it.)

The trunk is in an STP forwarding state in that VLAN (as also seen in the show spanning-tree vlan vlan-id command).

Example 4-8 shows a sample of the command output from the show interfaces trunk command, with the final section of the command output shaded. In this case, the trunk only forwards traffic in VLANs 1 and 4.

Example 4-8 Allowed VLAN List and List of Active VLANs

The absence of a VLAN in this last part of the command’s output does not necessarily mean that a problem has occurred. In fact, a VLAN might be legitimately excluded from a trunk for any of the reasons in the list just before Example 4-8. However, for a given exam question, it can be useful to know why traffic for a VLAN will not be forwarded over a trunk, and the details inside the output identify the specific reasons.

The output of the show interfaces trunk command creates three separate lists of VLANs, each under a separate heading. These three lists show a progression of reasons why a VLAN is not forwarded over a trunk. Table 4-2 summarizes the headings that precede each list and the reasons why a switch chooses to include or not include a VLAN in each list.

Closing with a brief mention of one other trunking topic, you should also check a trunk’s native VLAN configuration at this step. Unfortunately, it is possible to set the native VLAN ID to different VLANs on either end of the trunk, using the switchport trunk native vlan vlan-id command. If the native VLANs differ according to the two neighboring switches, the switches will accidentally cause frames to leave one VLAN and enter another.

For example, if switch SW1 sends a frame using native VLAN 1 on an 802.1Q trunk, SW1 does not add a VLAN header, as is normal for the native VLAN. When switch SW2 receives the frame, noticing that no 802.1Q header exists, SW2 assumes that the frame is part of SW2’s configured native VLAN. If SW2 has been configured to think VLAN 2 is the native VLAN on that trunk, SW2 will try to forward the received frame into VLAN 2.

Cisco IOS–based LAN switches enable Spanning Tree Protocol (STP) by default on all interfaces in every VLAN. However, network engineers who work with medium-size to large-size Ethernet LANs usually want to configure at least some STP settings. First and foremost, Cisco IOS switches traditionally default to use STP rather than Rapid STP (RSTP), and the simple upgrade to RSTP improves convergence. For most LANs with more than a few switches, the network engineer will likely want to influence the choices made by STP, whether using traditional STP or RSTP—choices such as which switch becomes root, with predictability about which switch ports will block/discard when all ports are physically working. The configuration can also be set so that when links or switches fail, the engineer can predict the STP topology in those cases, as well.

This chapter discusses configuration and verification of STP. The first major section weaves a story of how to change different settings, per VLAN, with the show commands that reveal the current STP status affected by each configuration command. Those settings impact both STP and RSTP, but the examples use switches that use traditional 802.1D STP rather than RSTP. The second major section shows how to configure the same optional STP features mentioned in Chapter 2: PortFast, BPDU Guard, and EtherChannel (specifically Layer 2 EtherChannel). The final major section of this chapter looks at the simple (one command) configuration to enable RSTP, and the differences and similarities in show command output that occur when using RSTP versus STP.

Cisco IOS switches usually use STP (IEEE 802.1D) by default rather than RSTP, and with effective default settings. You can buy some Cisco switches and connect them with Ethernet cables in a redundant topology, and STP will ensure that frames do not loop. And you never even have to think about changing any settings!

Although STP works without any configuration, most medium-size to large-size campus LANs benefit from some STP configuration. With all defaults, the switches choose the root based on the lowest burned-in MAC address on the switches because they all default to use the same STP priority. As a better option, configure the switches so that the root is predictable.

For instance, Figure 3-1 shows a typical LAN design model, with two distribution layer switches (D1 and D2). The design may have dozens of access layer switches that connect to end users; the figure shows just three access switches (A1, A2, and A3). For a variety of reasons, most network engineers make the distribution layer switches be the root. For instance, the configuration could make D1 be the root by having a lower priority, with D2 configured with the next lower priority, so it becomes root if D1 fails.

This first section of the chapter examines a variety of topics that somehow relate to STP configuration. It begins with a look at STP configuration options, as a way to link the concepts of Chapter 2 to the configuration choices in this chapter. Following that, this section introduces some show commands for the purpose of verifying the default STP settings before changing any configuration.

Chapter 2 described how 802.1D STP works in one VLAN. Now that this chapter turns our attention to STP configuration in Cisco switches, one of the first questions is this: Which kind of STP do you intend to use in a LAN? And to answer that question, you need to know a little more background.

The IEEE first standardized STP as the IEEE 802.1D standard, first published back in 1990. To put some perspective on that date, Cisco sold no LAN switches at the time, and virtual LANs did not exist yet. Instead of multiple VLANs in a LAN, there was just one broadcast domain, and one instance of STP. However, the addition of VLANs and the introduction of LAN switches into the market have created a need to add to and extend STP.

Today, Cisco IOS–based LAN switches allow you to use one of three STP configuration modes that reflect that history. The first two sections of this chapter use the mode called Per-VLAN Spanning Tree Plus (PVST+, or sometimes PVSTP), a Cisco-proprietary improvement of 802.1D STP. The per-VLAN part of the name gives away the main feature: PVST+ creates a different STP topology per VLAN, whereas 802.1D actually did not. PVST+ also introduced PortFast. Cisco switches often use PVST+ as the default STP mode per a default global command of spanning-tree mode pvst.

Over time, Cisco added RSTP support as well, with two STP modes that happen to use RSTP. One mode basically takes PVST+ and upgrades it to use RSTP logic as well, with a mode called Rapid PVST+, enabled with the global command spanning-tree mode rapid-pvst. Cisco IOS–based switches support a third mode, called Multiple Spanning Tree (MST) (or Multiple Instance of Spanning Tree), enabled with the spanning-tree mode mst command. (This book does not discuss MST beyond this brief mention; the CCNP Switch exam typically includes MST details.)

If you think back to the details of STP operation in Chapter 2, STP uses two types of numbers for most of its decisions: the BID and STP port costs. Focusing on those two types of numbers, consider this summary of what STP does behind the scenes:

Uses the BID to elect the root switch, electing the switch with the numerically lowest BID

Uses the total STP cost in each path to the root, when each nonroot switch chooses its own root port (RP

Uses each switch’s root cost, which is in turn based on STP port costs, when switches decide which switch port becomes the designated port (DP) on each LAN segment

Unsurprisingly, Cisco switches let you configure part of a switch’s BID and the STP port cost, which in turn influences the choices each switch makes with STP.

Per-VLAN Configuration Settings

Beyond supporting the configuration of the BID and STP port costs, Cisco switches support configuring both settings per VLAN. By default, Cisco switches use IEEE 802.1D, not RSTP (802.1w), with a Cisco-proprietary feature called Per-VLAN Spanning Tree Plus (PVST+). PVST+ (often abbreviated as simply PVST today) creates a different instance of STP for each VLAN. So, before looking at the tunable STP parameters, you need to have a basic understanding of PVST+, because the configuration settings can differ for each instance of STP.

PVST+ gives engineers a load-balancing tool with STP. By changing some STP configuration parameters differently for different VLANs, the engineer could cause switches to pick different RPs and DPs in different VLANs. As a result, some traffic in some VLANs can be forwarded over one trunk, and traffic for other VLANs can be forwarded over a different trunk.

Figure 3-2 shows the basic idea, with SW3 forwarding odd-numbered VLAN traffic over the left trunk (Gi0/1) and even-numbered VLANs over the right trunk (Gi0/2).

The next few pages look specifically at how to change the BID and STP port cost settings, per VLAN, when using the default PVST+ mode.

The Bridge ID and System ID Extension

Originally, a switch’s BID was formed by combining the switch’s 2-byte priority and its 6-byte MAC address. Later, the IEEE changed the rules, splitting the original priority field into two separate fields, as shown in Figure 3-3: a 4-bit priority field and a 12-bit subfield called the system ID extension (which represents the VLAN ID).

Per-VLAN Port Costs

Each switch interface defaults its per-VLAN STP cost based on the IEEE recommendations listed in Table 2-6 in Chapter 2. On interfaces that support multiple speeds, Cisco switches base the cost on the current actual speed. So, if an interface negotiates to use a lower speed, the default STP cost reflects that lower speed. If the interface negotiates to use a different speed, the switch dynamically changes the STP port cost as well.

Alternatively, you can configure a switch’s STP port cost with the spanning-tree [vlan vlan-id] cost cost interface subcommand. You see this command most often on trunks because setting the cost on trunks has an impact on the switch’s root cost, whereas setting STP costs on access ports does not.

For the command itself, it can include the VLAN ID, or not. The command only needs a vlan parameter on trunk ports to set the cost per VLAN. On a trunk, if the command omits the VLAN parameter, it sets the STP cost for all VLANs whose cost is not set by a spanning-tree vlan x cost command for that VLAN.

STP Configuration Option Summary

Table 3-2 summarizes the default settings for both the BID and the port costs and lists the optional configuration commands covered in this chapter.

Before taking a look at how to change the configuration, first consider a few STP verification commands. Looking at these commands first will help reinforce the default STP settings. In particular, the examples in this section use the network shown in Figure 3-4.

Changing the STP port costs requires a simple interface subcommand: spanning-tree [vlan x] cost x. To show how it works, consider the following example, which changes what happens in the network shown in Figure 3-4.

Back in Figure 3-4, with default settings, SW1 became root, and SW3 blocked on its G0/2 interface. A brief scan of the figure, based on the default STP cost of 4 for Gigabit interfaces, shows that SW3 should have found a cost 4 path and a cost 8 path to reach the root, as shown in Figure 3-5.

To show the effects of changing the port cost, the next example shows a change to SW3’s configuration, setting its G0/1 port cost higher so that the better path to the root goes out SW3’s G0/2 port instead. Example 3-3 also shows several other interesting effects.

Example 3-3 Manipulating STP Port Cost and Watching the Transition to Forwarding State

This example starts with the debug spanning-tree events command on SW3. This command tells the switch to issue debug log messages whenever STP performs changes to an interface’s role or state. These messages show up in the example as a result of the configuration.

Next, the example shows the configuration to change SW3’s port cost, in VLAN 10, to 30, with the spanning-tree vlan 10 cost 30 interface subcommand. Based on the figure, the root cost through SW3’s G0/1 will now be 30 instead of 4. As a result, SW3’s best cost to reach the root is cost 8, with SW3’s G0/2 as its root port.

The debug messages tell us what STP on SW3 is thinking behind the scenes, with timestamps. Note that the first five debug messages, displayed immediately after the user exited configuration mode in this case, all happen at the same time (down to the same millisecond). Notably, G0/1, which had been forwarding, immediately moves to a blocking state. Interface G0/2, which had been blocking, does not go to a forwarding state, instead moving to a listening state (at least, according to this message).

Now look for the debug message that lists G0/2 transitioning to learning state, and then the next one that shows it finally reaching forwarding state. How long between the messages? In each case, the message’s timestamps show that 15 seconds passed. In this experiment, the switches used a default setting of forward delay (15 seconds). So, these debug messages confirm the steps that STP takes to transition an interface from blocking to forwarding state.

If you did not happen to enable a debug when configuring the cost, using show commands later can confirm the same choice by SW3, to now use its G0/2 port as its RP. Example 3-4 shows the new STP port cost setting on SW3, along with the new root port and root cost, using the show spanning-tree vlan 10 command. Note that G0/2 is now listed as the root port. The top of the output lists SW3’s root cost as 8, matching the analysis shown in Figure 3-5.

Example 3-4 New STP Status and Settings on SW3

The other big STP configuration option is to influence the root election by changing the priority of a switch. The priority can be set explicitly with the spanning-tree vlan vlan-id priority value global configuration command, which sets the base priority of the switch. (This is the command that requires a parameter of a multiple of 4096.)

However, Cisco gives us a better configuration option than configuring a specific priority value. In most designs, the network engineers pick two switches to be root: one to be root if all switches are up, and another to take over if the first switch fails. Switch IOS supports this idea with the spanning-tree vlan vlan-id root primary and spanning-tree vlan vlan-id root secondary commands.

The spanning-tree vlan vlan-id root primary command tells the switch to set its priority low enough to become root right now. The switch looks at the current root in that VLAN, and at the root’s priority. Then the local switch chooses a priority value that causes the local switch to take over as root.

Remembering that Cisco switches use a default base priority of 32,768, this command chooses the base priority as follows:

If the current root has a base priority higher than 24,576, the local switch uses a base priority of 24,576.

If the current root’s base priority is 24,576 or lower, the local switch sets its base priority to the highest multiple of 4096 that still results in the local switch becoming root.

For the switch intended to take over as the root if the first switch fails, use the spanning-tree vlan vlan-id root secondary command. This command is much like the spanning-tree vlan vlan-id root primary command, but with a priority value worse than the primary switch but better than all the other switches. This command sets the switch’s base priority to 28,672 regardless of the current root’s current priority value.

For example, in Figures 3-4 and 3-5, SW1 was the root switch, and as shown in various commands, all three switches defaulted to use a base priority of 32,768. Example 3-5 shows a configuration that makes SW2 the primary root, and SW1 the secondary, just to show the role move from one to the other. These commands result in SW2 having a base priority of 24,576, and SW1 having a base priority of 28,672.

Example 3-5 Making SW2 Become Root Primary, and SW1 Root Secondary

The output of the two show commands clearly points out the resulting priority values on each switch. First, the show spanning-tree bridge command lists the local switch’s BID information, while the show spanning-tree root command lists the root’s BID, plus the local switch’s root cost and root port (assuming it is not the root switch). So, SW1 lists its own BID, with priority 28,682 (base 28,672, with VLAN 10) with the show spanning-tree bridge command. Still on SW1, the output lists the root’s priority as 24,586 in VLAN 10, implied as base 24,576 plus 10 for VLAN 10, with the show spanning-tree root command.

Note that alternatively you could have configured the priority settings specifically. SW1 could have used the spanning-tree vlan 10 priority 28672 command, with SW2 using the spanning-tree vlan 10 priority 24576 command. In this particular case, both options would result in the same STP operation.

This just-completed first major section of the chapter showed examples that used PVST+ only, assuming a default global command of spanning-tree mode pvst. At the same time, all the configuration commands shown in that first section, commands that influence STP operation, would influence both traditional STP and RSTP operation.

This section, the second of three major sections in this chapter, now moves on to discuss some useful but optional features that make both STP and RSTP work even better.

You can easily configure the PortFast and BPDU Guard features on any interface, but with two different configuration options. One option works best when you want to enable these features only on a few ports, and the other works best when you want to enable these features on most every access port.

First, to enable the features on just one port at a time, use the spanning-tree portfast and the spanning-tree bpduguard enable interface subcommands. Example 3-6 shows an example of the process, with SW3’s F0/4 interface enabling both features. (Also, note the long warning message IOS lists when enabling PortFast; using PortFast on a port connected to other switches can indeed cause serious problems.)

Example 3-6 Enabling PortFast and BPDU Guard on One Interface

Example 3-7 shows some brief information about the interface configuration of both PortFast and BPDU Guard. Of course, the show running-config command (not shown) would confirm the configuration commands from Example 3-6. The show spanning-tree interface fastethernet0/4 portfast command in Example 3-7 lists the PortFast status of the interface; note that the status value of enabled is displayed only if PortFast is configured and the interface is up. The show spanning-tree interface detail command then shows a line near the end of the output that states that PortFast and BPDU Guard are enabled. Note that this command would not list those two highlighted lines of output if these two features were not enabled.

Example 3-7 Verifying PortFast and BPDU Guard Configuration

PortFast and BPDU Guard are disabled by default on all interfaces, and to use them, each interface requires interface subcommands like those in Example 3-6. Alternately, for both features, you can enable the feature globally. Then, for interfaces for which the feature should be disabled, you can use another interface subcommand to disable the feature.

The ability to change the global default for these features reduces the number of interface subcommands required. For instance, on an access layer switch with 48 access ports and two uplinks, you probably want to enable both PortFast and BPDU Guard on all 48 access ports. Rather than requiring the interface subcommands on all 48 of those ports, enable the features globally, and then disable them on the uplink ports.

Table 3-3 summarizes the commands to enable and disable both PortFast and BPDU Guard, both globally and per interface. For instance, the global command spanning-tree portfast default changes the default so that all interfaces use PortFast, unless a port also has the spanning-tree portfast disable interface subcommand configured.

Example 3-8 shows another new command, show spanning-tree summary. This command shows the current global settings for several STP parameters, including the PortFast and BPDU Guard features. This output was gathered on a switch that had enabled both PortFast and BPDU Guard globally.

Example 3-8 Displaying Status of Global Settings for PortFast and BPDU Guard

As introduced back in Chapter 2, two neighboring switches can treat multiple parallel links between each other as a single logical link called an EtherChannel. STP operates on the EtherChannel, instead of the individual physical links, so that STP either forwards or blocks on the entire logical EtherChannel for a given VLAN. As a result, a switch in a forwarding state can then load balance traffic over all the physical links in the EtherChannel. Without EtherChannel, only one of the parallel links between two switches would be allowed to forward traffic, with the rest of the links blocked by STP.

NOTE: All references to EtherChannel in this Chapter refer to Layer 2 EtherChannels, and not to Layer 3 EtherChannels (as discussed in Chapter 19, “IPv4 Routing in the LAN”).

EtherChannel may be one of the most challenging switch features to make work. First, the configuration has several options, so you have to remember the details of which options work together. Second, the switches also require a variety of other interface settings to match among all the links in the channel, so you have to know those settings as well.

This section focuses on the correct EtherChannel configuration. Chapter 4’s section “Troubleshooting Layer 2 EtherChannel” looks at many of the potential problems with EtherChannel, including all those other configuration settings that a switch checks before allowing the EtherChannel to work.

Configuring a Manual EtherChannel

The simplest way to configure an EtherChannel is to add the correct channel-group configuration command to each physical interface, on each switch, all with the on keyword. The on keyword tells the switches to place a physical interface into an EtherChannel.

Before getting into the configuration and verification, however, you need to start using three terms as synonyms: EtherChannel, PortChannel, and Channel-group. Oddly, IOS uses the channel-group configuration command, but then to display its status, IOS uses the show etherchannel command. Then, the output of this show command refers to neither an “EtherChannel” nor a “Channel-group,” instead using the term “PortChannel.” So, pay close attention to these three terms in the example.

To configure an EtherChannel manually, follow these steps:

Step 1. Add the channel-group number mode on command in interface configuration mode under each physical interface that should be in the channel to add it to the channel.

Step 2. Use the same number for all commands on the same switch, but the channel-group number on the neighboring switch can differ.

Example 3-9 shows a simple example, with two links between switches SW1 and SW2, as shown in Figure 3-6. The configuration shows SW1’s two interfaces placed into channel-group 1, with two show commands to follow.

The simplest way to configure an EtherChannel is to add the correct channel-group configuration command to each physical interface, on each switch, all with the on keyword. The on keyword tells the switches to place a physical interface into an EtherChannel.

Before getting into the configuration and verification, however, you need to start using three terms as synonyms: EtherChannel, PortChannel, and Channel-group. Oddly, IOS uses the channel-group configuration command, but then to display its status, IOS uses the show etherchannel command. Then, the output of this show command refers to neither an “EtherChannel” nor a “Channel-group,” instead using the term “PortChannel.” So, pay close attention to these three terms in the example.

To configure an EtherChannel manually, follow these steps:

Step 1. Add the channel-group number mode on command in interface configuration mode under each physical interface that should be in the channel to add it to the channel.

Step 2. Use the same number for all commands on the same switch, but the channel-group number on the neighboring switch can differ.

Example 3-9 shows a simple example, with two links between switches SW1 and SW2, as shown in Figure 3-6. The configuration shows SW1’s two interfaces placed into channel-group 1, with two show commands to follow.

Example 3-9 Configuring and Monitoring EtherChannel

Take a few moments to look at the output in the two show commands in the example, as well. First, the show spanning-tree command lists Po1, short for PortChannel1, as an interface. This interface exists because of the channel-group commands using the 1 parameter. STP no longer operates on physical interfaces F0/14 and F0/15, instead operating on the PortChannel1 interface, so only that interface is listed in the output.

Next, note the output of the show etherchannel 1 summary command. It lists as a heading “Port-channel,” with Po1 below it. It also lists both F0/14 and F0/15 in the list of ports, with a (P) beside each. Per the legend, the P means that the ports are bundled in the port channel, which is a code that means these ports have passed all the configuration checks and are valid to be included in the channel.

NOTE: Cisco uses the term EtherChannel to refer to the concepts discussed in this section. To refer to the item configured in the switch, Cisco instead uses the term port channel, with the command keyword port-channel. For the purposes of understanding the technology, you may treat these terms as synonyms. However, it helps to pay close attention to the use of the terms port channel and EtherChannel as you work through the examples in this section, because IOS uses both.

Configuring Dynamic EtherChannels

Cisco switches support two different protocols that allow the switches to negotiate whether a particular link becomes part of an EtherChannel or not. Basically, the configuration enables the protocol for a particular channel-group number. At that point, the switch can use the protocol to send messages to/from the neighboring switch and discover whether their configuration settings pass all checks. If a given physical link passes, the link is added to the EtherChannel and used; if not, it is placed in a down state, and not used, until the configuration inconsistency can be resolved.

Cisco switches support the Cisco-proprietary Port Aggregation Protocol (PAgP) and the IEEE standard Link Aggregation Control Protocol (LACP), based on IEEE standard 802.3ad. Although differences exist between the two, to the depth discussed here, they both accomplish the same task: negotiate so that only links that pass the configuration checks are actually used in an EtherChannel.

To configure either protocol, a switch uses the channel-group configuration commands on each switch, but with a keyword that either means “use this protocol and begin negotiations” or “use this protocol and wait for the other switch to begin negotiations.” As shown in Figure 3-7, the desirable and auto keywords enable PAgP, and the active and passive keywords enable LACP. With these options, at least one side has to begin the negotiations. In other words, with PAgP, at least one of the two sides must use desirable, and with LACP, at least one of the two sides must use active.

NOTE: Do not use the on parameter on one end, and either auto or desirable (or for LACP, active or passive) on the neighboring switch. The on option uses neither PAgP nor LACP, so a configuration that uses on, with PAgP or LACP options on the other end, would prevent the EtherChannel from working.

For example, in the design shown in Figure 3-7, imagine both physical interfaces on both switches were configured with the channel-group 2 mode desirable interface subcommand. As a result, the two switches would negotiate and create an EtherChannel. Example 3-10 shows the verification of that configuration, with the command show etherchannel 2 port-channel. This command confirms the protocol in use (PAgP, because the desirable keyword was configured), and the list of interfaces in the channel.

Example 3-10 EtherChannel Verification: PAgP Desirable Mode

All you have to do to migrate from STP to RSTP is to configure the spanning-tree mode rapid-pvst global command on all the switches. However, for exam preparation, it helps to work through the various show commands, particularly to prepare for Simlet questions. Those questions can ask you to interpret show command output without allowing you to look at the configuration, and the output of show commands when using STP versus RSTP is very similar.

This third and final major section of this chapter focuses on pointing out the similarities and differences between STP and RSTP as seen in Catalyst switch configuration and verification commands. This section explains the configuration and verification of RSTP, with emphasis on how to identify RSTP features.

To determine whether a Cisco Catalyst switch uses RSTP, you can look for two types of information. First, you can look at the configuration, as noted in the left column of Table 3-4. Also, some show commands list the STP protocol as a reference to the configuration of the spanning-tree mode global configuration command. A protocol of rstp or mst refers to one of the modes that uses RSTP, and a protocol of ieee refers to the mode that happens to use STP.

Before looking at an example of the output, review the topology in Figure 3-8. The remaining RSTP examples in this chapter use this topology. In the RSTP examples in this chapter, SW1 will become root, and SW3 will block on one port (G0/2), as shown.

The first example focuses on VLAN 10, with all switches using 802.1D STP and the default setting of spanning-tree mode pvst. This setting creates an instance of STP per VLAN (which is the per-VLAN part of the name) and uses 802.1D STP. Each switch places the port connected to the PC into VLAN 10 and enables both PortFast and BPDU Guard. Example 3-11 shows a sample configuration from switch SW3, with identical interface subcommands configured on SW1’s F0/11 and SW2’s F0/12 ports, respectively.

Example 3-11 Sample Configuration from Switch SW3

At this point, the three switches use 802.1D STP because all use the default PVST mode. Example 3-12 shows the evidence of STP’s work, with only subtle and indirect clues that STP happens to be in use.

Example 3-12 Output That Confirms the Use of 802.1D STP on Switch SW3

The highlighted parts of the example note the references to the STP protocol as ieee, which implies that STP is in use. The term ieee is a reference to the original IEEE 802.1D STP standard.

To migrate this small network to use RSTP, configure the spanning-tree mode rapid-pvst command. This continues the use of per-VLAN spanning-tree instances, but it applies RSTP logic to each STP instance. Example 3-13 shows the output of the same two commands from Example 3-12 after configuring the spanning-tree mode rapid-pvst command on all three switches.

Example 3-13 Output That Confirms the Use of 802.1w RSTP on Switch SW3

Pay close attention to the differences between the 802.1D STP output in Example 3-12 and the 802.1w RSTP output in Example 3-13. Literally, the only difference is rstp instead of ieee in one place in the output of each of the two commands listed. In this case, rstp refers to the configuration of the spanning-tree mode rapid-pvst global config command, which implied the use of RSTP.

The good news is that the output clearly lists which port is the root port (Gi0/1) and which port is the alternate root port (Gi0/2). The only trick is to know that Altn is a shortened version of the word alternate.

Pay close attention to this short description of an oddity about the STP and RSTP output on Catalyst switches! Cisco Catalyst switches often show the alternate and backup ports in output even when using STP and not RSTP. The alternate and backup port concepts are RSTP concepts. The switches only converge faster using these concepts when using RSTP. But show command output, when using STP and not RSTP, happens to identify what would be the alternate and backup ports if RSTP were used.

Why might you care about such trivia? Seeing output that lists an RSTP alternate port does not confirm that the switch is using RSTP. So, do not make that assumption on the exam. To confirm that a switch uses RSTP, you must look at the configuration of the spanning-tree mode command, or look for the protocol as summarized back in Table 3-4.

For instance, just compare the output of Example 3-12 and Example 3-14. Example 3-12 shows output for this same SW3, with the same parameters, except that all switches used PVST mode, meaning all the switches used STP. Example 3-12’s output (based on STP) lists SW3’s G0/2 as Altn, meaning alternate, even though the alternate port concept is not an STP concept, but an RSTP concept.

RSTP added one new port state compared to STP, discarding, using it as a replacement for the STP port states of disabled and blocking. You might think that after you configure a switch to use RSTP rather than STP, instead of seeing ports in a blocking state, you would now see the discarding state. However, the Cisco Catalyst switch output basically ignores the new term discarding, continuing to use the old term blocking instead.

For example, scan back to the most recent RSTP example (Example 3-14), to the line for SW3’s port G0/2. Then look for the column with heading STS, which refers to the status or state. The output shows G0/2 is listed as BLK, or blocking. In theory, because SW3 uses RSTP, the port state ought to be discarding, but the switch IOS continues to use the older notation of BLK for blocking.

Just as one more bit of evidence, the command show spanning-tree vlan 10 interface gigabitethernet0/2 state lists the STP or RSTP port state with the state fully spelled out. Example 3-15 shows this command, taken from SW3, for interface G0/2. Note the fully spelled-out blocking term instead of the RSTP term discarding.

Example 3-15 SW3, an RSTP Switch, Continues to Use the Old Blocking Term

Cisco Catalyst switches determine the RSTP port type based on two port settings: the current duplex (full or half) and whether the PortFast feature is enabled. First, full duplex tells the switch to use port type point-to-point, with half duplex telling the switch to use port type shared. Enabling PortFast tells the switch to treat the port as an edge port. Table 3-5 summarizes the combinations.

For exam prep, again note an odd fact about the highlighted output in Example 3-16: The port type details appear in the output when using both STP and RSTP. For example, refer to Example 3-12 again, which shows output from SW3 when using STP (when configured for PVST mode). The Type column also identifies point-to-point and edge interfaces.

Most entry-level networking jobs require you to operate and troubleshoot a network using a preexisting IP addressing and subnetting plan.

The CCNA Routing and Switching exams assess your readiness to use preexisting IP addressing and subnetting information to perform typical operations tasks, like monitoring the network, reacting to possible problems, and troubleshooting those problems.

However, you also need to understand how networks are designed and why.

The thought processes used when monitoring any network continually ask the question, “Is the network working as designed?”

If a problem exists, you must consider questions such as, “What happens when the network works normally, and what is different right now?”

Both questions require you to understand the intended design of the network, including details of the IP addressing and subnetting design.

This lesson provides some perspectives and answers for the bigger issues in IPv4 addressing.

What addresses can be used so that they work properly? What addresses should be used? When told to use certain numbers, what does that tell you about the choices made by some other network engineer?

How do these choices impact the practical job of configuring switches, routers, hosts, and operating the network on a daily basis?

This lesson hopes to answer these questions while revealing details of how IPv4 addresses work.

Say you just happened to be at the sandwich shop when they were selling the world’s longest sandwich. You’re pretty hungry, so you go for it. Now you have one sandwich, but at over 2 kilometers long, you realize it’s a bit more than you need for lunch all by yourself.

To make the sandwich more useful (and more portable), you chop the sandwich into meal-size pieces, and give the pieces to other folks around you, who are also ready for lunch.

Huh? Well, subnetting, at least the main concept, is similar to this sandwich story. You start with one network, but it is just one large network.

As a single large entity, it might not be useful, and it is probably far too large. To make it useful, you chop it into smaller pieces, called subnets, and assign those subnets to be used in different parts of the enterprise internetwork.

This lesson introduces IP subnetting. First, it shows the general ideas behind a completed subnet design that indeed chops (or subnets) one network into subnets. 

An IP network—in other words, a Class A, B, or C network—is simply a set of consecutively numbered IP addresses that follows some preset rules.

These Class A, B, and C rules define that for a given network, all the addresses in the network have the same value in some of the octets of the addresses.

For example, Class B network 172.16.0.0 consists of all IP addresses that begin with 172.16: 172.16.0.0, 172.16.0.1, 172.16.0.2, and so on, through 172.16.255.255.

Another example: Class A network 10.0.0.0 includes all addresses that begin with 10.

An IP subnet is simply a subset of a Class A, B, or C network. If fact, the word subnet is a shortened version of the phrase subdivided network.

For example, one subnet of Class B network 172.16.0.0 could be the set of all IP addresses that begin with 172.16.1, and would include 172.16.1.0, 172.16.1.1, 172.16.1.2, and so on, up through 172.16.1.255.

Another subnet of that same Class B network could be all addresses that begin with 172.16.2.

To give you a general idea, Figure 1 shows some basic documentation from a completed subnet design that could be used when an engineer subnets Class B network 172.16.0.0.

The design shows five subnets: one for each of the three LANs and one each for the two WAN links. The small text note shows the rationale used by the engineer for the subnets: Each subnet includes addresses that have the same value in the first three octets.

For example, for the LAN on the left, the number shows 172.16.1.__, meaning “all addresses that begin with 172.16.1.”

Also, note that the design, as shown, does not use all the addresses in Class B network 172.16.0.0, so the engineer has left plenty of room for growth.

Most IT jobs require you to work with subnetting from an operational view. That is, someone else, before you got the job, designed how IP addressing and subnetting would work for that particular enterprise network. You need to interpret what someone else has already chosen.

To fully understand IP addressing and subnetting, you need to think about subnetting from both a design and operational perspective.

For example, Figure 1 simply states that in all these subnets, the first three octets must be equal. Why was that convention chosen? What alternatives exist? Would those alternatives be better for your internetwork today? All these questions relate more to subnetting design rather than to operation.

The remaining three main sections of this lesson examine each of the steps listed in Figure 2, in sequence.

This section discusses the meaning of four basic questions that can be used to analyze the addressing and subnetting needs for any new or changing enterprise network:

1. Which hosts should be grouped together into a subnet?
2. How many subnets does this network require?
3. How many host IP addresses does each subnet require?
4. Will we use a single subnet size for simplicity, or not?

Every device that connects to an IP internetwork needs to have an IP address. These devices include computers used by end users, servers, mobile phones, laptops, IP phones, tablets, and networking devices like routers, switches, and firewalls. In short, any device that uses IP to send and receive packets needs an IP address.

NOTE: When discussing IP addressing, the term network has specific meaning: a Class A, B, or C IP network. To avoid confusion with that use of the term network, this lesson uses the terms internetwork and enterprise network when referring to a collection of hosts, routers, switches, and so on.

The IP addresses must be assigned according to some basic rules, and for good reasons. To make routing work efficiently, IP addressing rules group addresses into groups called subnets. The rules are as follows:

• Addresses in the same subnet are not separated by a router.
• Addresses in different subnets are separated by at least one router.

Figure 3 shows the general concept, with hosts A and B in one subnet and host C in another. In particular, note that hosts A and B are not separated from each other by any routers. However, host C, separated from A and B by at least one router, must be in a different subnet.

The idea that hosts on the same link must be in the same subnet is much like the postal/zip code concept. All mailing addresses in the same town use the same postal code. 

Addresses in another town, whether relatively nearby or on the other side of the country, have a different postal code. The postal code gives the postal service a better ability to automatically sort the mail to deliver it to the right location. For the same general reasons, hosts on the same LAN are in the same subnet, and hosts in different LANs are in different subnets.

Note that the point-to-point WAN link in the figure also needs a subnet. Figure 3 shows Router R1 connected to the LAN subnet on the left and to a WAN subnet on the right. Router R2 connects to that same WAN subnet. To do so, both R1 and R2 will have IP addresses on their WAN interfaces, and the addresses will be in the same subnet. (An Ethernet over MPLS [EoMPLS] WAN link has the same IP addressing needs, with each of the two routers having an IP address in the same subnet.)

The Ethernet LANs in Figure 3 also show a slightly different style of drawing, using simple lines with no Ethernet switch. Drawings of Ethernet LANs when the details of the LAN switches do not matter simply show each device connected to the same line, as shown in Figure 3. (This kind of drawing mimics the original Ethernet cabling before switches and hubs existed.)

Finally, because the routers’ main job is to forward packets from one subnet to another, routers typically connect to multiple subnets. For example, in this case, Router R1 connects to one LAN subnet on the left and one WAN subnet on the right. To do so, R1 will be configured with two different IP addresses, one per interface. These addresses will be in different subnets, because the interfaces connect the router to different subnets.

To determine the number of subnets required, the engineer must think about the internetwork as documented and count the locations that need a subnet. To do so, the engineer requires access to network diagrams, VLAN configuration details, and details about WAN links. For the types of links discussed in this course, you should plan for one subnet for every:

• VLAN
• Point-to-point serial link
• Ethernet emulation WAN link (EoMPLS)

NOTE: WAN technologies like MPLS allow subnetting options other than one subnet per pair of routers on the WAN, but this course only uses WAN technologies that have one subnet for each point-to-point WAN connection between two routers.

For example, imagine that the network planner has only Figure 4 on which to base the subnet design.

The number of subnets required cannot be fully predicted with only this figure. Certainly, three subnets will be needed for the WAN links, one per link. However, each LAN switch can be configured with a single VLAN, or with multiple VLANs. You can be certain that you need at least one subnet for the LAN at each site, but you might need more.

Next, consider the more detailed version of the same figure shown in Figure 5. In this case, the figure shows VLAN counts in addition to the same Layer 3 topology (the routers and the links connected to the routers). It also shows that the central site has many more switches, but the key fact on the left, regardless of how many switches exist, is that the central site has a total of 12 VLANs. Similarly, the figure lists each branch as having two VLANs. Along with the same three WAN subnets, this internetwork requires 21 subnets.

Finally, in a real job, you would consider the needs today as well as how much growth you expect in the internetwork over time. Any subnetting plan should include a reasonable estimate of the number of subnets you need to meet future needs.

Determining the number of hosts per subnet requires knowing a few simple concepts and then doing a lot of research and questioning. Every device that connects to a subnet needs an IP address. For a totally new network, you can look at business plans—numbers of people at the site, devices on order, and so on—to get some idea of the possible devices. When expanding an existing network to add new sites, you can use existing sites as a point of comparison, and then find out which sites will get bigger or smaller. And don’t forget to count the router interface IP address in each subnet and the switch IP address used to remotely manage the switch.

Instead of gathering data for each and every site, planners often just use a few typical sites for planning purposes. For example, maybe you have some large sales offices and some small sales offices. You might dig in and learn a lot about only one large sales office and only one small sales office. Add that analysis to the fact that point-to-point links need a subnet with just two addresses, plus any analysis of more one-of-a-kind subnets, and you have enough information to plan the addressing and subnetting design.

For example, in Figure 6, the engineer has built a diagram that shows the number of hosts per LAN subnet in the largest branch, B1. For the two other branches, the engineer did not bother to dig to find out the number of required hosts. As long as the number of required IP addresses at sites B2 and B3 stays below the estimate of 50, based on larger site B1, the engineer can plan for 50 hosts in each branch LAN subnet and have plenty of addresses per subnet.

The final choice in the initial planning step is to decide whether you will use a simpler design by using a one-size-subnet-fits-all philosophy. A subnet’s size, or length, is simply the number of usable IP addresses in the subnet. A subnetting design can either use one size subnet, or varied sizes of subnets, with pros and cons for each choice.

Defining the Size of a Subnet

Before you finish this course, you will learn all the details of how to determine the size of the subnet. For now, you just need to know a few specific facts about the size of subnets.

The engineer assigns each subnet a subnet mask, and that mask, among other things, defines the size of that subnet. The mask sets aside a number of host bits whose purpose is to number different host IP addresses in that subnet. Because you can number 2^x things with x bits, if the mask defines H host bits, the subnet contains 2^H – 2 unique numeric values.

However, the subnet’s size is not 2^H. It’s 2^H – 2, because two numbers in each subnet are reserved for other purposes. Each subnet reserves the numerically lowest value for the subnet number and the numerically highest value as the subnet broadcast address. As a result, the number of usable IP addresses per subnet is 2^H – 2.

NOTE: The terms subnet number, subnet ID, and subnet address all refer to the number that represents or identifies a subnet.

Figure 7 shows the general concept behind the three-part structure of an IP address, focusing on the host part and the resulting subnet size.

One-Size Subnet Fits All

To choose to use a single-size subnet in an enterprise network, you must use the same mask for all subnets, because the mask defines the size of the subnet. But which mask?

One requirement to consider when choosing that one mask is this: That one mask must provide enough host IP addresses to support the largest subnet. To do so, the number of host bits (H) defined by the mask must be large enough so that 2^H – 2 is larger than (or equal to) the number of host IP addresses required in the largest subnet.

For example, consider Figure 8. It shows the required number of hosts per LAN subnet. (The figure ignores the subnets on the WAN links, which require only two IP addresses each.) The branch LAN subnets require only 50 host addresses, but the main site LAN subnet requires 200 host addresses. To accommodate the largest subnet, you need at least 8 host bits. Seven host bits would not be enough, because 2⁷ – 2 = 126. Eight host bits would be enough, because 2⁸ – 2 = 254, which is more than enough to support 200 hosts in a subnet.

What’s the big advantage when using a single-size subnet? Operational simplicity. In other words, keeping it simple. Everyone on the IT staff who has to work with networking can get used to working with one mask—and one mask only. They will be able to answer all subnetting questions more easily, because everyone gets used to doing subnetting math with that one mask.

The big disadvantage for using a single-size subnet is that it wastes IP addresses. For example, in Figure 8, all the branch LAN subnets support 254 addresses, while the largest branch subnet needs only 50 addresses. The WAN subnets only need two IP addresses, but each supports 254 addresses, again wasting more IP addresses.

The wasted IP addresses do not actually cause a problem in most cases, however. Most organizations use private IP networks in their enterprise internetworks, and a single Class A or Class B private network can supply plenty of IP addresses, even with the waste.

Multiple Subnet Sizes (Variable-Length Subnet Masks)

To create multiple sizes of subnets in one Class A, B, or C network, the engineer must create some subnets using one mask, some with another, and so on. Different masks mean different numbers of host bits, and a different number of hosts in some subnets based on the 2^H – 2 formula.

For example, consider the requirements listed earlier in Figure 8. It showed one LAN subnet on the left that needs 200 host addresses, three branch subnets that need 50 addresses, and three WAN links that need two addresses. To meet those needs, but waste fewer IP addresses, three subnet masks could be used, creating subnets of three different sizes, as shown in Figure 9.

The smaller subnets now waste fewer IP addresses compared to the design shown earlier in Figure 8. The subnets on the right that need 50 IP addresses have subnets with 6 host bits, for 2⁶ – 2 = 62 available addresses per subnet. The WAN links use masks with 2 host bits, for 2² – 2 = 2 available addresses per subnet.

However, some are still wasted, because you cannot set the size of the subnet as some arbitrary size. All subnets will be a size based on the 2H – 2 formula, with H being the number of host bits defined by the mask for each subnet.

One-Size Subnet Fits All (Mostly)

For the most part, this course explains subnetting using designs that use a single mask, creating a single subnet size for all subnets. Why? First, it makes the process of learning subnetting easier. Second, some types of analysis that you can do about a network—specifically, calculating the number of subnets in the classful network—only make sense when a single mask is used.

However, you still need to be ready to work with variable-length subnet masks (VLSM), which is the practice of using different masks for different subnets in the same classful IP network. However, all the examples and discussion up until that lesson purposefully avoid VLSM just to keep the discussion simpler, for the sake of learning to walk before you run.

Now that you know how to analyze the IP addressing and subnetting needs, the next major step examines how to apply the rules of IP addressing and subnetting to those needs and make some choices. In other words, now that you know how many subnets you need and how many host addresses you need in the largest subnet, how do you create a useful subnetting design that meets those requirements? The short answer is that you need to do the three tasks shown on the right side of Figure 10.

In the original design for what we know of today as the Internet, companies used registered public classful IP networks when implementing TCP/IP inside the company. By the mid- 1990s, an alternative became more popular: private IP networks. This section discusses the background behind these two choices, because it impacts the choice of what IP network a company will then subnet and implement in its enterprise internetwork.

Public IP Networks

The original design of the Internet required that any company that connected to the Internet had to use a registered public IP network. To do so, the company would complete some paperwork, describing the enterprise’s internetwork and the number of hosts existing, plus plans for growth. After submitting the paperwork, the company would receive an assignment of either a Class A, B, or C network.

Public IP networks, and the administrative processes surrounding them, ensure that all the companies that connect to the Internet all use unique IP addresses. In particular, after a public IP network is assigned to a company, only that company should use the addresses in that network. That guarantee of uniqueness means that Internet routing can work well, because there are no duplicate public IP addresses.

For example, consider the example shown in Figure 11. Company 1 has been assigned public Class A network 1.0.0.0, and company 2 has been assigned public Class A network 2.0.0.0. Per the original intent for public addressing in the Internet, after these public network assignments have been made, no other companies can use addresses in Class A networks 1.0.0.0 or 2.0.0.0.

This original address assignment process ensured unique IP addresses across the entire planet. The idea is much like the fact that your telephone number should be unique in the universe, your postal mailing address should also be unique, and your email address should also be unique. If someone calls you, your phone rings, but no one else’s phone rings. Similarly, if company 1 is assigned Class A network 1.0.0.0, and it assigns address 1.1.1.1 to a particular PC, that address should be unique in the universe. A packet sent through the Internet to destination 1.1.1.1 should only arrive at this one PC inside company 1, instead of being delivered to some other host.

Growth Exhausts the Public IP Address Space

By the early 1990s, the world was running out of public IP networks that could be assigned. During most of the 1990s, the number of hosts newly connected to the Internet was growing at a double-digit pace, per month. Companies kept following the rules, asking for public IP networks, and it was clear that the current address-assignment scheme could not continue without some changes. Simply put, the number of Class A, B, and C networks supported by the 32-bit address in IP version 4 (IPv4) was not enough to support one public classful network per organization, while also providing enough IP addresses in each company.

NOTE: The universe has run out of public IPv4 addresses in a couple of significant ways. IANA, which assigns public IPv4 address blocks to the five Regional Internet Registries (RIR) around the globe, assigned the last of the IPv4 address space in early 2011. By 2015, ARIN, the RIR for North America, exhausted its supply of IPv4 addresses, so that companies must return unused public IPv4 addresses to ARIN before they have more to assign to new companies. Try an online search for “ARIN depletion” to see pages about the current status of available IPv4 address space for just one RIR example.

The Internet community worked hard during the 1990s to solve this problem, coming up with several solutions, including the following:

• A new version of IP (IPv6), with much larger addresses (128 bit)
• Assigning a subset of a public IP network to each company, instead of an entire public IP network, to reduce waste
• Network Address Translation (NAT), which allows the use of private IP networks

These three solutions matter to real networks today. However, to stay focused on the topic of subnet design, this lesson focuses on the third option, and in particular, the private IP networks that can be used by an enterprise when also using NAT.

Focusing on the third item in the bullet list, NAT allows multiple companies to use the exact same private IP network, using the same IP addresses as other companies while still connecting to the Internet. For example, Figure 12 shows the same two companies connecting to the Internet as in Figure 11, but now with both using the same private Class A network 10.0.0.0.

Both companies use the same classful IP network (10.0.0.0). Both companies can implement their subnet design internal to their respective enterprise internetworks, without discussing their plans. The two companies can even use the exact same IP addresses inside network 10.0.0.0. And amazingly, at the same time, both companies can even communicate with each other through the Internet.

The technology called Network Address Translation makes it possible for companies to reuse the same IP networks, as shown in Figure 12. NAT does this by translating the IP addresses inside the packets as they go from the enterprise to the Internet, using a small number of public IP addresses to support tens of thousands of private IP addresses. For now, accept that most companies use NAT, and therefore, they can use private IP networks for their internetworks.

Private IP Networks

Request For Comments (RFC) 1918 defines the set of private IP networks, as listed in Table 1. By definition, these private IP networks

• Will never be assigned to an organization as a public IP network
• Can be used by organizations that will use NAT when sending packets into the Internet
• Can also be used by organizations that never need to send packets into the Internet

So, when using NAT—and almost every organization that connects to the Internet uses NAT—the company can simply pick one or more of the private IP networks from the list of reserved private IP network numbers. RFC 1918 defines the list, which is summarized in Table 1.

NOTE: According to an informal survey I ran on my blog a few years back, about half of the respondents said that their networks use private Class A network 10.0.0.0, as opposed to other private networks or public networks.

Choosing an IP Network During the Design Phase

Today, some organizations use private IP networks along with NAT, and some use public IP networks. Most new enterprise internetworks use private IP addresses throughout the network, along with NAT, as part of the connection to the Internet. Those organizations that already have registered public IP networks—often obtained before the addresses started running short in the early 1990s—can continue to use those public addresses throughout their enterprise networks.

After the choice to use a private IP network has been made, just pick one that has enough IP addresses. You can have a small internetwork and still choose to use private Class A network 10.0.0.0. It might seem wasteful to choose a Class A network that has over 16 million IP addresses, especially if you only need a few hundred. However, there’s no penalty or problem with using a private network that is too large for your current or future needs.

For the purposes of this course, most examples use private IP network numbers. For the design step to choose a network number, just choose a private Class A, B, or C network from the list of RFC 1918 private networks.

Regardless, from a math and concept perspective, the methods to subnet a public IP network versus a private IP network are the same.

If a design engineer followed the topics in this lesson so far, in order, he would know the following:

• The number of subnets required
• The number of hosts/subnet required
• That a choice was made to use only one mask for all subnets, so that all subnets are the same size (same number of hosts/subnet)
• The classful IP network number that will be subnetted

This section completes the design process, at least the parts described in this lesson, by discussing how to choose that one mask to use for all subnets. First, this section examines default masks, used when a network is not subnetted, as a point of comparison. Next, the concept of borrowing host bits to create subnet bits is explored. Finally, this section ends with an example of how to create a subnet mask based on the analysis of the requirements.

Classful IP Networks Before Subnetting

Before an engineer subnets a classful network, the network is a single group of addresses. In other words, the engineer has not yet subdivided the network into many smaller subsets called subnets.

When thinking about an unsubnetted classful network, the addresses in a network have only two parts: the network part and host part. Comparing any two addresses in the classful network:

The addresses have the same value in the network part.

The addresses have different values in the host part.

The actual sizes of the network and host part of the addresses in a network can be easily predicted, as shown in Figure 13.

In Figure 13, N and H represent the number of network and host bits, respectively. Class rules define the number of network octets (1, 2, or 3) for Classes A, B, and C, respectively; the figure shows these values as a number of bits. The number of host octets is 3, 2, or 1, respectively.

Continuing the analysis of classful network before subnetting, the number of addresses in one classful IP network can be calculated with the same 2^H – 2 formula previously discussed. In particular, the size of an unsubnetted Class A, B, or C network is as follows:

• Class A: 2²⁴ – 2 = 16,777,214
• Class B: 2¹⁶ – 2 = 65,534
• Class C: 2⁸ – 2 = 254

Borrowing Host Bits to Create Subnet Bits

To subnet a network, the designer thinks about the network and host parts, as shown in Figure 13, and then the engineer adds a third part in the middle: the subnet part. However, the designer cannot change the size of the network part or the size of the entire address (32 bits). To create a subnet part of the address structure, the engineer borrows bits from the host part. Figure 14 shows the general idea.

Figure 14 shows a rectangle that represents the subnet mask. N, representing the number of network bits, remains locked at 8, 16, or 24, depending on the class. Conceptually, the designer moves a (dashed) dividing line into the host field, with subnet bits (S) between the network and host parts, and the remaining host bits (H) on the right. The three parts must add up to 32, because IPv4 addresses consist of 32 bits.

Choosing Enough Subnet and Host Bits

The design process requires a choice of where to place the dashed line shown in Figure 14. But what is the right choice? How many subnet and host bits should the designer choose? The answers hinge on the requirements gathered in the early stages of the planning process:

• Number of subnets required
• Number of hosts/subnet

The bits in the subnet part create a way to uniquely number the different subnets that the design engineer wants to create. With 1 subnet bit, you can number 21 or 2 subnets. With 2 bits, 22 or 4 subnets, with 3 bits, 23 or 8 subnets, and so on. The number of subnet bits must be large enough to uniquely number all the subnets, as determined during the planning process.

At the same time, the remaining number of host bits must also be large enough to number the host IP addresses in the largest subnet. Remember, in this lesson, we assume the use of a single mask for all subnets. This single mask must support both the required number of subnets and the required number of hosts in the largest subnet. Figure 15 shows the concept.

Figure 15 shows the idea of the designer choosing a number of subnet (S) and host (H) bits and then checking the math. 2^S must be more than the number of required subnets, or the mask will not supply enough subnets in this IP network. Also, 2^H – 2 must be more than the required number of hosts/subnet.

NOTE: The idea of calculating the number of subnets as 2^S applies only in cases where a single mask is used for all subnets of a single classful network, as is being assumed in this lesson.

To effectively design masks, or to interpret masks that were chosen by someone else, you need a good working memory of the powers of 2. Use Numeric Reference Tables for your reference.

Example Design: 172.16.0.0, 200 Subnets, 200 Hosts

To help make sense of the theoretical discussion so far, consider an example that focuses on the design choice for the subnet mask. In this case, the planning and design choices so far tell us the following

• Use a single mask for all subnets.
• Plan for 200 subnets.
• Plan for 200 host IP addresses per subnet.
• Use private Class B network 172.16.0.0.

To choose the mask, the designer asks this question:

How many subnet (S) bits do I need to number 200 subnets?

From Table 2, you can see that S = 7 is not large enough (2⁷ = 128), but S = 8 is enough (2⁸ = 256). So, you need at least 8 subnet bits.

Next, the designer asks a similar question, based on the number of hosts per subnet:

How many host (H) bits do I need to number 200 hosts per subnet?

The math is basically the same, but the formula subtracts 2 when counting the number of hosts/subnet. From Table 2, you can see that H = 7 is not large enough (2⁷ – 2 = 126), but H = 8 is enough (2⁸ – 2 = 254).

Only one possible mask meets all the requirements in this case. First, the number of network bits (N) must be 16, because the design uses a Class B network. The requirements tell us that the mask needs at least 8 subnet bits, and at least 8 host bits. The mask only has 32 bits in it; Figure 16 shows the resulting mask.

Masks and Mask Formats

Although engineers think about IP addresses in three parts when making design choices (network, subnet, and host), the subnet mask gives the engineer a way to communicate those design choices to all the devices in the subnet.

The subnet mask is a 32-bit binary number with a number of binary 1s on the left and with binary 0s on the right. By definition, the number of binary 0s equals the number of host bits; in fact, that is exactly how the mask communicates the idea of the size of the host part of the addresses in a subnet. The beginning bits in the mask equal binary 1, with those bit positions representing the combined network and subnet parts of the addresses in the subnet.

Because the network part always comes first, then the subnet part, and then the host part, the subnet mask, in binary form, cannot have interleaved 1s and 0s. Each subnet mask has one unbroken string of binary 1s on the left, with the rest of the bits as binary 0s.

After the engineer chooses the classful network and the number of subnet and host bits in a subnet, creating the binary subnet mask is easy. Just write down N 1s, S 1s, and then H 0s (assuming that N, S, and H represent the number of network, subnet, and host bits). Figure 17 shows the mask based on the previous example, which subnets a Class B network by creating 8 subnet bits, leaving 8 host bits.

In addition to the binary mask shown in Figure 17, masks can also be written in two other formats: the familiar dotted-decimal notation (DDN) seen in IP addresses and an even briefer prefix notation.

This final task of the subnet design step determines the actual subnets that can be used, based on all the earlier choices. The earlier design work determined the Class A, B, or C network to use, and the (one) subnet mask to use that supplies enough subnets and enough host IP addresses per subnet. But what are those subnets? How do you identify or describe a subnet? This section answers these questions.

A subnet consists of a group of consecutive numbers. Most of these numbers can be used as IP addresses by hosts. However, each subnet reserves the first and last numbers in the group, and these two numbers cannot be used as IP addresses. In particular, each subnet contains the following:

Subnet number: Also called the subnet ID or subnet address, this number identifies the subnet. It is the numerically smallest number in the subnet. It cannot be used as an IP address by a host.

Subnet broadcast: Also called the subnet broadcast address or directed broadcast address, this is the last (numerically highest) number in the subnet. It also cannot be used as an IP address by a host.

IP addresses: All the numbers between the subnet ID and the subnet broadcast address can be used as a host IP address.

For example, consider the earlier case in which the design results were as follows:

• Network 172.16.0.0 (Class B)
• Mask 255.255.255.0 (for all subnets)

With some math, the facts about each subnet that exists in this Class B network can be calculated. In this case, Table 2 shows the first ten such subnets. It then skips many subnets and shows the last two (numerically largest) subnets.

After you have the network number and the mask, calculating the subnet IDs and other details for all subnets requires some math. In real life, most people use subnet calculators or subnet-planning tools. 

The next step, planning the implementation, is the last step before actually configuring the devices to create a subnet. The engineer first needs to choose where to use each subnet. For example, at a branch office in a particular city, which subnet from the subnet planning chart (Table 2) should be used for each VLAN at that site? Also, for any interfaces that require static IP addresses, which addresses should be used in each case? Finally, what range of IP addresses from inside each subnet should be configured in the DHCP server, to be dynamically leased to hosts for use as their IP address? Figure 18 summarizes the list of implementation planning tasks.

The job is simple: Look at your network diagram, identify each location that needs a subnet, and pick one from the table you made of all the possible subnets. Then, track it so that you know which ones you use where, using a spreadsheet or some other purpose-built subnet-planning tool. That’s it! Figure 19 shows a sample of a completed design using Table 2, which happens to match the initial design sample shown way back in Figure 1.

Although this design could have used any five subnets from Table 2, in real networks, engineers usually give more thought to some strategy for assigning subnets. For example, you might assign all LAN subnets lower numbers and WAN subnets higher numbers. Or you might slice off large ranges of subnets for different divisions of the company. Or you might follow that same strategy, but ignore organizational divisions in the company, paying more attention to geographies.

For example, for a U.S.-based company with a smaller presence in both Europe and Asia, you might plan to reserve ranges of subnets based on continent. This kind of choice is particularly useful when later trying to use a feature called route summarization.

Figure 20 shows the general benefit of placing addressing in the network for easier route summarization, using the same subnets from Table 2 again.

Devices receive their IP address and mask assignment in one of two ways: dynamically by using Dynamic Host Configuration Protocol (DHCP) or statically through configuration. For DHCP to work, the network engineer must tell the DHCP server the subnets for which it must assign IP addresses. In addition, that configuration limits the DHCP server to only a subset of the addresses in the subnet. For static addresses, you simply configure the device to tell it what IP address and mask to use.

To keep things as simple as possible, most shops use a strategy to separate the static IP addresses on one end of each subnet, and the DHCP-assigned dynamic addresses on the other. It does not really matter whether the static addresses sit on the low end of the range of addresses or the high end.

For example, imagine that the engineer decides that, for the LAN subnets in Figure 19, the DHCP pool comes from the high end of the range, namely, addresses that end in .101 through .254. (The address that ends in .255 is, of course, reserved.) The engineer also assigns static addresses from the lower end, with addresses ending in .1 through .100. Figure 21 shows the idea.

Figure 21 shows all three routers with statically assigned IP addresses that end in .1. The only other static IP address in the figure is assigned to the server on the left, with address 172.16.1.11 (abbreviated simply as .11 in the figure).

On the right, each LAN has two PCs that use DHCP to dynamically lease their IP addresses. DHCP servers often begin by leasing the addresses at the bottom of the range of addresses, so in each LAN, the hosts have leased addresses that end in .101 and .102, which are at the low end of the range chosen by design.

This lesson focuses on the processes of verification and troubleshooting.

Verification refers to the process of confirming whether a network is working as designed. 

Troubleshooting refers to the follow-on process that occurs when the network is not working as designed, by trying to determine the real reason why the network is not working correctly, so that it can be fixed.

Sometimes, when people take their first Cisco exam, they are surprised at the number of verification and troubleshooting questions. Each of these questions requires you to apply networking knowledge to unique problems, rather than just being ready to answer questions about lists of facts that you’ve memorized. You need to have skills beyond simply remembering a lot of facts.

This lesson discusses a wide number of topics.

• Analyzing switch interfaces and cabling
• Predicting where switches will forward frames
• Troubleshooting port security
• Analyzing VLANs and VLAN trunks

This first section of the lesson takes a brief diversion for one particular big idea: what troubleshooting processes could be used to resolve networking problems? Most CCNA Routing and Switching exam topics list the word “troubleshoot” along with some technology, mostly with some feature that you configure on a switch or router. One exam topic makes mention of the troubleshooting process. This first section examines the troubleshooting process as an end to itself.

The first important perspective on the troubleshooting process is this: you can troubleshoot using any process or method that you want. However, all good methods have the same characteristics that result in faster resolution of the problem, and a better chance of avoiding that same problem in the future.

The one exam topic that mentions troubleshooting methods uses some pretty common terminology found in troubleshooting methods both inside IT and in other industries as well.

The ideas make good common sense. From the exam topics:

• Step 1. Problem isolation and documentation: Problem isolation refers to the process of taking what you know about a possible issue, confirming that there is a problem, and determining which devices and cables could be part of the problem, and which ones are not part of the problem. This step also works best when the person troubleshooting the problem documents what they find, typically in a problem tracking system.
• Step 2. Resolve or escalate: Problem isolation should eventually uncover the root cause of the problem—that is, the cause which, if fixed, will resolve the problem. In short, resolving the problem means finding the root cause of the problem and fixing that problem. Of course, what do you do if you cannot find the root cause, or fix (resolve) that root cause once found? Escalate the problem. Most companies have a defined escalation process, with different levels of technical support and management support depending on whether the next step requires more technical expertise or management decision making.
• Step 3. Verify or monitor: You hear of a problem, you isolate the problem, document it, determine a possible root cause, and you try to resolve it. Now you need to verify that it really worked. In some cases, that may mean that you just do a few show commands. In other cases, you may need to keep an eye on it over a period of time, especially when you do not know what caused the root problem in the first place.

Like most real-life processes, the real troubleshooting process is seldom as neat as the three troubleshooting steps listed here.

You move between them, you attempt to resolve the problem, it may or may not work, you work through the process over and over, get help from the escalation team as needed, and so on. But following these kinds of steps can help you resolve problems more consistently, more quickly, especially when the team must get involved in troubleshooting a problem

The exams ask you questions that not only assess your knowledge, but they assess your troubleshooting skills. To do that, the exam does not require you to follow any particular troubleshooting methods.

On the exam, you should focus on isolating the root cause of the problem, after which you will either (a) fix the problem or (b) answer a multichoice question about the symptoms and the root cause of the problem.

The exam uses two question types as the primary means to test troubleshooting skills. Sim questions begin with a broken configuration; your job is to find the configuration problem, and answer the question by fixing or completing the configuration. These are straightforward configuration troubleshooting questions, and you can recognize them on the exam when the exam tells you to answer the question by changing the configuration.

Simlet questions also give you a simulator where you access the command-line interface (CLI).

However, instead of changing the configuration, these questions require you to verify the current operation of the network and then answer multichoice questions about the current operation. These questions make you do the same kinds of commands you would use when doing problem isolation and documentation, and then assess what you found by asking you several multichoice questions.

At some point, whether you stop now or sometime when you have 10 to 15 spare minutes, take the time to search Cisco.com for “exam tutorial.” Cisco’s exam tutorial shows all the question types, including Sim and Simlet types, and you can take over the user interface to get a better sense for how to navigate in the same user interface you will see on exam day.

On the exam, you may do 5–10 show commands in a Simlet question before finding all the answers to all the multichoice questions within that one Simlet question. So it sometimes helps to go through problem isolation like what you would do in a real network.

In some questions, it may be obvious that the problem will be something to do with the switches or VLANs, but in others, you may have to do extra problem isolation work to even determine whether the problem is a WAN or LAN or routing problem, and which part of the network has the problem.

For example, consider the following problem based on the network in Figure 1. PC1 and PC2 supposedly sit in the same VLAN (10). At one time, the ping 10.1.1.2 command on PC1 worked; now it does not.

NOTE: Ping command sends messages (inside IPv4 packets) that flow from one device to the other, and back, to test whether the IP network can deliver packets in both directions.

So, how do you attack this problem? If you doubt whether the figure is even correct, you could look at show command output to confirm the network topology. After it is confirmed, you could predict its normal working behavior based on your knowledge of LAN switching.

As a result, you could predict where a frame sent by PC1 to PC2 should flow. To isolate the problem, you could look in the switch MAC tables to confirm the interfaces out which the frame should be forwarded, possibly then finding that the interface connected to PC2 has failed.

This first problem showed a relatively small network, with only two networking devices (two Layer 2 switches). As a result, you would probably guess that the exam question focused on either interface issues or VLAN issues.

Other Simlet questions might instead begin with a larger network, but they might still require you to do problem isolation about the Ethernet topics. However, that problem isolation might need to start with Layer 3, just to decide where to begin looking for other problems.

For example, the user of PC1 in Figure 2 can usually connect to the web server on the right by entering www.example.com in PC1’s web browser. However, that web-browsing attempt fails right now. The user calls the help desk, and the problem is assigned to a network engineer to solve.

To begin the analysis, the network engineer can begin with the first tasks that would have to happen for a successful web-browsing session to occur.

For example, the engineer would try to confirm that PC1 can resolve the hostname (www.example.com) to the correct IP address used by the server on the right. At that point, the Layer 3 IP problem isolation process can proceed, to determine which of the six routing steps shown in the figure has failed.

The routing steps shown in Figure 2 are as follows:

• Step 1. PC1 sends the packet to its default gateway (R1) because the destination IP address (of the web server) is in a different subnet.
• Step 2. R1 forwards the packet to R2 based on R1’s routing table.
• Step 3. R2 forwards the packet to the web server based on R2’s routing table.
• Step 4. The web server sends a packet back toward PC1 based on the web server’s default gateway setting (R2).
• Step 5. R2 forwards the packet destined for PC1 by forwarding the packet to R1 according to R2’s routing table.
• Step 6. R1 forwards the packet to PC1 based on R1’s routing table.

Many engineers break down network problems as in this list, analyzing the Layer 3 path through the network, hop by hop, in both directions. This process helps you take the first attempt at problem isolation.

When the analysis shows which hop in the layer path fails, you can then look further at those details. And if in this case the Layer 3 problem isolation process discovers that Step 1, 3, 4, or 6 fails, the root cause might be related to Ethernet or other Layer 2 issues.

For example, imagine that the Layer 3 analysis determined that PC1 cannot even send a packet to its default gateway (R1), meaning that Step 1 in Figure 2 fails. To further isolate the problem and find the root causes, the engineer would need to determine the following:

• The MAC address of PC1 and of R1’s LAN interface
• The switch interfaces used on SW1 and SW2
• The interface status of each switch interface
• The VLANs that should be used
• The expected forwarding behavior of a frame sent by PC1 to R1 as the destination MAC address

By gathering and analyzing these facts, the engineer can most likely isolate the problem’s root cause and fix it.

This section makes the transition from the process focus of the previous section to the first of four technology-focused sections of this lesson. That process begins with finding out whether each switch interface works, and if working, whether any statistics reveal any additional problems.

Unsurprisingly, Cisco switches do not use interfaces at all unless the interface is first considered to be in a functional or working state. In addition, the switch interface might be in a working state, but intermittent problems might still be occurring.

This section begins by looking at the Cisco switch interface status codes and what they mean so that you can know whether an interface is working. The rest of this section then looks at those more unusual cases in which the interface is working, but not working well, as revealed by different interface status codes and statistics.

Cisco switches actually use two different sets of interface status codes—one set of two codes (words) that use the same conventions as do router interface status codes, and another set with a single code (word). Both sets of status codes can determine whether an interface is working.

The switch show interfaces and show interfaces description commands list the two-code status named the line status and protocol status. The line status generally refers to whether Layer 1 is working, with protocol status generally referring to whether Layer 2 is working.

NOTE: This section refers to these two status codes in shorthand by just listing the two codes with a slash between them, such as up/up.

The single-code interface status corresponds to different combinations of the traditional two-code interface status codes and can be easily correlated to those codes.

For example, the show interfaces status command lists a connected state for working interfaces, with the same meaning as the up/up state seen with the show interfaces and show interfaces description commands.

Table 1 lists the code combinations and some root causes that could have caused a particular interface status.

Examining the notconnect state for a moment, note that this state has many causes that have been mentioned through this section. 

As you can see in the table, having a bad cable is just one of many reasons for the down/down state (or notconnect, per the show interfaces status command).

Some examples of the root causes of cabling problems include the following:

• The installation of any equipment that uses electricity, even non-IT equipment, can interfere with the transmission on the cabling, and make the link fail.
• The cable could be damaged, for example, if it lies under carpet. If the user’s chair keeps squashing the cable, eventually the electrical signal can degrade.
• Although optical cables do not suffer from electromagnetic interference (EMI), someone can try to be helpful and move a fiber-optic cable out of the way—bending it too much. A bend into too tight a shape can prevent the cable from transmitting bits (called macrobending).

For the other interface states listed in Table 1, only the up/up (connected) state needs more discussion. An interface can be in a working state, and it might really be working—or it might be working in a degraded state.

The next few topics discuss how to examine an up/up (connected) interface to find out whether it is working well or having problems.

Many unshielded twisted-pair (UTP)-based Ethernet interfaces support multiple speeds, either full or half duplex, and support IEEE standard autonegotiation. 

These same interfaces can also be configured to use a specific speed using the speed {10 | 100 | 1000} interface subcommand, and a specific duplex using the duplex {half | full} interface subcommand.

With both configured, a switch or router disables the IEEE-standard autonegotiation process on that interface.

The show interfaces and show interfaces status commands list both the actual speed and duplex settings on an interface, as demonstrated in Example 1.

Although both commands in the example can be useful, only the show interfaces status command implies how the switch determined the speed and duplex settings. The command output lists autonegotiated settings with a prefix of a-.

For example, a-full means full duplex as autonegotiated, whereas full means full duplex but as manually configured. The example shades the command output that implies that the switch’s Fa0/12 interface’s speed and duplex were not found through autonegotiation, but Fa0/13 did use autonegotiation.

Note that the show interfaces fa0/13 command (without the status option) simply lists the speed and duplex for interface Fast Ethernet 0/13, with nothing implying that the values were learned through autonegotiation.

When the IEEE autonegotiation process works on both devices, both devices agree to the fastest speed supported by both devices. In addition, the devices use full duplex if it is supported by both devices, or half duplex if it is not. However, when one device has disabled autonegotiation, and the other device uses autonegotiation, the device using autonegotiation chooses the default duplex setting based on the current speed.

The defaults are as follows:

• If the speed is not known through any means, use 10 Mbps, half duplex.
• If the switch successfully senses the speed without IEEE autonegotiation, by just looking at the signal on the cable:
  • If the speed is 10 or 100 Mbps, default to use half duplex.
  • If the speed is 1,000 Mbps, default to use full duplex.

NOTE: Ethernet interfaces using speeds faster than 1 Gbps always use full duplex.

While autonegotiation works well, these defaults allow for the possibility of a difficult-to-troubleshoot problem called a duplex mismatch.

The “Autonegotiation” section in previous lesson explains how both devices could use the same speed, so the devices would consider the link to be up, but one side would use half-duplex and the other side would use full duplex.

The next example shows a specific case that causes a duplex mismatch.

In Figure 3, imagine that SW2’s Gi0/2 interface was configured with the speed 100 and duplex full commands (these settings are not recommended on a Gigabit-capable interface, by the way).

On Cisco switches, configuring both the speed and duplex commands disables IEEE autonegotiation on that port. If SW1’s Gi0/1 interface tries to use autonegotiation, SW1 would also use a speed of 100 Mbps, but default to use half duplex. Example 2 shows the results of this specific case on SW1.

First, focusing on the command output, the command confirms SW1’s speed and duplex. It also lists a prefix of a- in the output, implying autonegotiation. Even with SW1 using autonegotiation defaults, the command still notes the values as being learned through autonegotiation.

Finding a duplex mismatch can be much more difficult than finding a speed mismatch, because if the duplex settings do not match on the ends of an Ethernet segment, the switch interface will still be in a connected (up/up) state. In this case, the interface works, but it might work poorly, with poor performance, and with symptoms of intermittent problems.

The reason is that the device using half-duplex uses carrier sense multiple access collision detect (CSMA/CD) logic, waiting to send when receiving a frame, believing collisions occur when they physically do not—and actually stopping sending a frame because the switch thinks a collision occurred. With enough traffic load, the interface could be in a connect state, but it’s extremely inefficient for passing traffic.

To identify duplex mismatch problems, check the duplex setting on each end of the link and watch for incrementing collision and late collision counters, as explained in the next section.

When the interface reaches the connect (up/up) state, the switch considers the interface to be working. The switch, of course, tries to use the interface, and at the same time, the switch keeps various interface counters.

These interface counters can help identify problems that can occur even though the interface is in a connect state. This section explains some of the related concepts and a few of the most common problems.

Whenever the physical transmission has problems, the receiving device might receive a frame whose bits have changed values.

These frames do not pass the error detection logic as implemented in the FCS field in the Ethernet trailer.

The receiving device discards the frame and counts it as some kind of input error. Cisco switches list this error as a CRC error, as highlighted in Example 3. (Cyclic redundancy check [CRC] is a term related to how the frame check sequence [FCS] math detects an error.)

The number of input errors, and the number of CRC errors, are just a few of the counters in the output of the show interfaces command. The challenge is to decide which counters you need to think about, which ones show that a problem is happening, and which ones are normal and of no concern.

The example highlights several of the counters as examples so that you can start to understand which ones point to problems and which ones are just counting normal events that are not problems. The following list shows a short description of each highlighted counter, in the order shown in the example:

• Runts: Frames that did not meet the minimum frame size requirement (64 bytes, including the 18-byte destination MAC, source MAC, type, and FCS). Can be caused by collisions.
• Giants: Frames that exceed the maximum frame size requirement (1518 bytes, including the 18-byte destination MAC, source MAC, type, and FCS).
• Input Errors: A total of many counters, including runts, giants, no buffer, CRC, frame, overrun, and ignored counts.
• CRC: Received frames that did not pass the FCS math; can be caused by collisions.
• Frame: Received frames that have an illegal format, for example, ending with a partial byte; can be caused by collisions.
• Packets Output: Total number of packets (frames) forwarded out the interface.
• Output Errors: Total number of packets (frames) that the switch port tried to transmit, but for which some problem occurred.
• Collisions: Counter of all collisions that occur when the interface is transmitting a frame.
• Late Collisions: The subset of all collisions that happen after the 64th byte of the frame has been transmitted. (In a properly working Ethernet LAN, collisions should occur within the first 64 bytes; late collisions today often point to a duplex mismatch.)

Note that many of these counters occur as part of the CSMA/CD process used when half duplex is enabled. Collisions occur as a normal part of the half-duplex logic imposed by CSMA/CD, so a switch interface with an increasing collisions counter might not even have a problem.

However, one problem, called late collisions, points to the classic duplex mismatch problem.

If a LAN design follows cabling guidelines, all collisions should occur by the end of the 64th byte of any frame. When a switch has already sent 64 bytes of a frame, and the switch receives a frame on that same interface, the switch senses a collision.

In this case, the collision is a late collision, and the switch increments the late collision counter in addition to the usual CSMA/CD actions to send a jam signal, wait a random time, and try again.

With a duplex mismatch, like the mismatch between SW1 and SW2 in Figure 3, the half-duplex interface will likely see the late collisions counter increment.

Why? The half-duplex interface sends a frame (SW1), but the full duplex neighbor (SW2) sends at any time, even after the 64th byte of the frame sent by the half-duplex switch.

So, just keep repeating the show interfaces command, and if you see the late collisions counter incrementing on a half-duplex interface, you might have a duplex mismatch problem.

A working interface (in an up/up state) can still suffer from issues related to the physical cabling as well. The cabling problems might not be bad enough to cause a complete failure, but the transmission failures result in some frames failing to pass successfully over the cable.

For example, excessive interference on the cable can cause the various input error counters to keep growing larger, especially the CRC counter. In particular, if the CRC errors grow, but the collisions counters do not, the problem might simply be interference on the cable. (The switch counts each collided frame as one form of input error as well.)

Switches learn MAC addresses and then use the entries in the MAC address table to make a forwarding/filtering decision for each frame.

To know exactly how a particular switch will forward an Ethernet frame, you need to examine the MAC address table on a Cisco switch.

The more formal troubleshooting process begins with a mental process where you predict where frames should flow in the LAN. As an exercise, review Figure 4 and try to create a MAC address table on paper for each switch. Include the MAC addresses for both PCs, as well as the Gi0/1 MAC address for R1. (Assume that all three are assigned to VLAN 10.) Then predict which interfaces would be used to forward a frame sent by Fred, Barney, and R1 to every other device.

The MAC table entries you predict in this case define where you think frames will flow. Even though this sample network in Figure 4 shows only one physical path through the Ethernet LAN, the exercise should be worthwhile, because it forces you to correlate what you’d expect to see in the MAC address table with how the switches forward frames. Figure 5 shows the resulting MAC table entries for PCs Fred and Barney, as well as for Router R1.

While Figure 5 shows the concepts, Example 4 lists the same facts but in the form of the show mac address-table dynamic command on the switches. This command lists all dynamically learned MAC table entries on a switch, for all VLANs.

Example 4 Examining SW1 and SW2 Dynamic MAC Address Table Entries

When predicting the MAC address table entries, you need to imagine a frame sent by a device to another device on the other side of the LAN and then determine which switch ports the frame would enter as it passes through the LAN. For example, if Barney sends a frame to Router R1, the frame would enter SW1’s Fa0/12 interface, so SW1 has a MAC table entry that lists Barney’s 0200.2222.2222 MAC address with Fa0/12. SW1 would forward Barney’s frame to SW2, arriving on SW2’s Gi0/2 interface, so SW2’s MAC table lists Barney’s MAC address (0200.2222.2222) with interface Gi0/2.

After you predict the expected contents of the MAC address tables, you can then examine what is actually happening on the switches, as described in the next section.

Troubleshooting revolves around three big ideas: predicting what should happen, determining what is happening that is different than what should happen, and figuring out why that different behavior is happening. This next section discusses how to look at what is actually happening in a VLAN based on those MAC address tables, first using a summary of switch forwarding logic and then showing an example.

The following list summarizes switch forwarding logic including the LAN switching features discussed in this study:

Step 1. Process functions on the incoming interface, if the interface is currently in an up/up (connected) state, as follows:

A. If configured, apply port security logic to filter the frame as appropriate.

B. If the port is an access port, determine the interface’s access VLAN.

C. If the port is a trunk, determine the frame’s tagged VLAN.

Step 2. Make a forwarding decision. Look for the frame’s destination MAC address in the MAC address table, but only for entries in the VLAN identified in Step 1. If the destination MAC is...

A. Found (unicast), forward the frame out the only interface listed in the matched address table entry.

B. Not found (unicast), flood the frame out all other access ports (except the incoming port) in that same VLAN, plus out trunks that have not restricted the VLAN from that trunk.

C. Broadcast, flood the frame, with the same rules as the previous step.

For an example of this process, consider a frame sent by Barney to its default gateway, R1 (0200.5555.5555). Using the steps just listed, the following occurs:

Step 1. Input interface processing:

A. The port does not happen to have port security enabled.

B. SW1 receives the frame on its Fa0/12 interface, an access port in VLAN 10.

Step 2. Make a forwarding decision: SW1 looks in its MAC address table for entries in VLAN 10:

A. SW1 finds an entry (known unicast) for 0200.5555.5555, associated with VLAN 10, outgoing interface Gi0/1, so SW1 forwards the frame only out interface Gi0/1. (This link is a VLAN trunk, so SW1 adds a VLAN 10 tag to the 802.1Q trunking header.)

At this point, the frame with source 0200.2222.2222 (Barney) and destination 0200.5555.5555 (R1) is on its way to SW2. You can then apply the same logic for SW2, as follows:

Step 1. Input interface processing:

A. The port does not happen to have port security enabled.

B. SW2 receives the frame on its Gi0/2 interface, a trunk; the frame lists a tag of VLAN 10. (SW2 will remove the 802.1Q header as well.)

Step 2. Make a forwarding decision: SW2 looks for its MAC table for entries in VLAN 10:

A. SW2 finds an entry (known unicast) for 0200.5555.5555, associated with VLAN 10, outgoing interface Fa0/13, so SW2 forwards the frame only out interface Fa0/13.

At this point, the frame should be on its way, over the Ethernet cable between SW2 and R1.

Generally speaking, any analysis of the forwarding process should consider any security features that might discard some frames or packets. For example, both routers and switches can be configured with access control lists (ACL) that examine the packets and frames being sent or received on an interface, with the router or switch discarding those packets/frames.

This study does not include coverage of switch ACLs, but the exams do cover a switch feature called port security. Port security feature can be used to cause the switch to discard some frames sent into and out of an interface. Port security has three basic features with which it determines which frames to filter:

Limit which specific MAC addresses can send and receive frames on a switch interface, discarding frames to/from other MAC addresses

Limit the number of MAC addresses using the interface, discarding frames to/from MAC addresses learned after the maximum limit is reached

A combination of the previous two points

The first port security troubleshooting step should be to find which interfaces have port security enabled, followed by a determination as to whether any violations are currently occurring. The trickiest part relates to the differences in what the IOS does in reaction to violations based on the switchport port-security violation violation-mode interface subcommand, which tells the switch what to do when a violation occurs. The general process to find port security issues is as follows:

Step 1. Identify all interfaces on which port security is enabled (show running-config or show port-security).

Step 2. Determine whether a security violation is currently occurring based in part on the violation mode of the interface’s port security configuration, as follows:

A. shutdown: The interface will be in an err-disabled state, and the port security port status will be secure-down.

B. restrict: The interface will be in a connected state, the port security port status will be secure-up, but the show port-security interface command will show an incrementing violations counter.

C. protect: The interface will be in a connected state, and the show port-security interface command will not show an incrementing violations counter.

Step 3. In all cases, compare the port security configuration to the diagram and to the Last Source Address field in the output of the show port-security interface command.

Because IOS reacts so differently with shutdown mode as compared to restrict and protect modes, the next few pages explain the differences—first for shutdown mode, then for the other two modes.

Troubleshooting Step 2A refers to the interface err-disabled (error-disabled) state. This state verifies that the interface has been configured to use port security, that a violation has occurred, and that no traffic is allowed on the interface at the present time. This interface state implies that the shutdown violation mode is used, because it is the only one of the three port security modes that causes the interface to be disabled.

To recover from an err-disabled state, the interface must be shut down with the shutdown command, and then enabled with the no shutdown command. Example 5 lists an example in which the interface is in an err-disabled state.

Example 5 Using Port Security to Define Correct MAC Addresses of Particular Interfaces

The output of the show port-security interface command lists a couple of items helpful in the troubleshooting process. The port status of secure-shutdown means that the interface is disabled for all traffic as a result of a violation while in port security shutdown mode; this state is not used by the protect and restrict modes. The port security port status of secure-shutdown also means that the interface state should be err-disabled.

Note that in shutdown mode, the violations counter (at the bottom of the output) does not keep incrementing. Basically, once the first violating frame triggers IOS to move the port to an err-disabled state, IOS ignores any other incoming frames (not even counting them) until the engineer uses the shutdown and no shutdown commands on the interface, in succession. Note that the process of recovering the interface also resets the violation counter back to 0. Finally, note that the second-to-last line lists the source MAC address of the last frame received on the interface. This value can prove useful in identifying the MAC address of the device that caused the violation.

Figure 6 summarizes these behaviors, assuming the same scenario shown in the example.

The restrict and protect violation modes take a much different approach to securing ports. These modes still discard offending traffic, but the interface remains in a connected (up/up) state, and in a port security state of secure-up. As a result, the port continues to forward good traffic and discard offending traffic.

Having a port in a seemingly good state that also discards traffic can be a challenge when troubleshooting. Basically, you have to know about this possible pitfall, and then know how to tell when port security is discarding some traffic on a port even though the interface status looks good.

The show port-security interface command reveals whether protect mode has discarded frames using the “last source address” item in the output. Example 6 shows a sample configuration and show command when using protect mode. In this case, the port is configured to allow Fa0/13 to receive frames sent by 0200.1111.1111 only. Ten frames have arrived, with a variety of source MAC addresses, with the last frame’s source MAC address being 0200.3333.3333.

Example 6 Port Security Using Protect Mode

In protect mode, the show port-security interface command reveals practically nothing about whether the interfaces happen to be discarding traffic or not. For instance, in this case, this show command output was gathered after many frames had been sent by a PC with MAC address 0200.3333.3333, with all the frames being discarded by the switch because of port security. The command output shows the disallowed PC’s 0200.3333.3333 MAC address as the last source MAC address in a received frame. However, if another frame with an allowed MAC address arrived (in this case, source MAC 0200.1111.1111), the next instance of the show command would list 0200.1111.1111 as the last source address. In particular, note that the interface remains in a secure-up state, and the violation counter does not increment.

Figure 7 summarizes the key points about the operation of Port Security protect mode, assuming a mix of frames with different source addresses. The figure emphasizes unpredictability of the last source MAC listed in the output, and the fact that the counter does not increment and that no syslog messages are generated for violating frames.

If this example had used violation mode restrict instead of protect, the port status would have also remained in a secure-up state; however, IOS would show some indication of port security activity, such as the incrementing violation counter as well as syslog messages. Example 7 shows an example of the violation counter and ends with an example port security syslog message. In this case, 97 incoming frames so far violated the rules, with the most recent frame having a source MAC address of 0200.3333.3333.

Example 7 Port Security Using Violation Mode Restrict

Figure 8 summarizes the key points about the restrict mode for port security. In this case, the figure matches the same scenario as the example again, with 97 total violating frames arriving so far, with the most recent being from source MAC MAC3.

For the exams, a port security violation might not be a problem; it might be the exact function intended. The question text might well explicitly state what port security should be doing. In these cases, it can be quicker to just immediately look at the port security configuration. Then, compare the configuration to the MAC addresses of the devices connected to the interface. The most likely problem on the exams is that the MAC addresses have been misconfigured or that the maximum number of MAC addresses has been set too low.

A switch’s forwarding process, as discussed earlier in the section “Analyzing the Forwarding Path,” depends in part on VLANs and VLAN trunking. Before a switch can forward frames in a particular VLAN, the switch must know about a VLAN and the VLAN must be active. And before a switch can forward a frame over a VLAN trunk, the trunk must currently allow that VLAN to pass over the trunk. This final of the five major sections in this lesson focuses on VLAN and VLAN trunking issues, specifically issues that impact the frame switching process. The four potential issues are as follows:

Step 1. Identify all access interfaces and their assigned access VLANs and reassign into the correct VLANs as needed.

Step 2. Determine whether the VLANs both exist (configured or learned with VTP) and are active on each switch. If not, configure and activate the VLANs to resolve problems as needed.

Step 3. Check the allowed VLAN lists, on the switches on both ends of the trunk, and ensure that the lists of allowed VLANs are the same.

Step 4. Check for incorrect configuration settings that result in one switch operating as a trunk, with the neighboring switch not operating as a trunk.

To ensure that each access interface has been assigned to the correct VLAN, engineers simply need to determine which switch interfaces are access interfaces instead of trunk interfaces, determine the assigned access VLANs on each interface, and compare the information to the documentation. The show commands listed in Table 2 can be particularly helpful in this process.

If possible, start this step with the show vlan and show vlan brief commands, because they list all the known VLANs and the access interfaces assigned to each VLAN. Be aware, however, that these two commands do not list operational trunks. The output does list all other interfaces (those not currently trunking), no matter whether the interface is in a working or nonworking state.

If the show vlan and show interface switchport commands are not available in a particular exam question, the show mac address-table command can also help identify the access VLAN. This command lists the MAC address table, with each entry including a MAC address, interface, and VLAN ID. If the exam question implies that a switch interface connects to a single device PC, you should only see one MAC table entry that lists that particular access interface; the VLAN ID listed for that same entry identifies the access VLAN. (You cannot make such assumptions for trunking interfaces.)

After you determine the access interfaces and associated VLANs, if the interface is assigned to the wrong VLAN, use the switchport access vlan vlan-id interface subcommand to assign the correct VLAN ID.

Switches do not forward frames for VLANs that are (a) not configured or (b) configured but disabled (shut down). This section summarizes the best ways to confirm that a switch knows that a particular VLAN exists, and if it exists, determines the state of the VLAN.

First, on the issue of whether a VLAN is defined, a VLAN can be defined to a switch in two ways: using the vlan number global configuration command, or it can be learned from another switch using VTP. This study purposefully ignores VTP as much as possible, so for this discussion, consider that the only way for a switch to know about a VLAN is to have a vlan command configured on the local switch.

Next, the show vlan command always lists all VLANs known to the switch, but the show running-config command does not. Switches configured as VTP servers and clients do not list the vlan commands in the running-config nor the startup-config file; on these switches, you must use the show vlan command. Switches configured to use VTP transparent mode, or that disable VTP, list the vlan configuration commands in the configuration files. (Use the show vtp status command to learn the current VTP mode of a switch.)

After you determine that a VLAN does not exist, the problem might be that the VLAN simply needs to be defined. 

For any existing VLANs, also verify whether the VLAN is active. The show vlan command should list one of two VLAN state values, depending on the current state: either active or act/lshut. The second of these states means that the VLAN is shut down. Shutting down a VLAN disables the VLAN on that switch only, so that the switch will not forward frames in that VLAN.

Switch IOS gives you two similar configuration methods with which to disable (shutdown) and enable (no shutdown) a VLAN. Example 8 shows how, first by using the global command [no] shutdown vlan number and then using the VLAN mode subcommand [no] shutdown. The example shows the global commands enabling and disabling VLANs 10 and 20, respectively, and using VLAN subcommands to enable and disable VLANs 30 and 40 (respectively).

Example 8 Enabling and Disabling VLANs on a Switch

Trunking can be configured correctly so that both switches forward frames for the same set of VLANs. However, trunks can also be misconfigured, with a couple of different results. In some cases, both switches conclude that their interfaces do not trunk. In other cases, one switch believes that its interface is correctly trunking, while the other switch does not.

The most common incorrect configuration—which results in both switches not trunking—is a configuration that uses the switchport mode dynamic auto command on both switches on the link. The word “auto” just makes us all want to think that the link would trunk automatically, but this command is both automatic and passive. As a result, both switches passively wait on the other device on the link to begin negotiations.

With this particular incorrect configuration, the show interfaces switchport command on both switches confirms both the administrative state (auto), as well as the fact that both switches operate as “static access” ports. Example 9 highlights those parts of the output from this command.

Example 9 Operational Trunking State

A different incorrect trunking configuration results in one switch with an operational state of “trunk,” while the other switch has an operational state of “static access.” When this combination of events happens, the interface works a little. The status on each end will be up/up or connected. Traffic in the native VLAN will actually cross the link successfully. However, traffic in all the rest of the VLANs will not cross the link.

Figure 9 shows the incorrect configuration along with which side trunks and which does not. The side that trunks (SW1 in this case) enables trunking always, using the command switchport mode trunk. However, this command does not disable DTP negotiations. To cause this particular problem, SW1 also disables DTP negotiation using the switchport nonegotiate command. SW2’s configuration also helps create the problem, by using a trunking option that relies on DTP. Because SW1 has disabled DTP, SW2’s DTP negotiations fail, and SW2 does not trunk.

In this case, SW1 treats its G0/1 interface as a trunk, and SW2 treats its G0/2 interface as an access port (not a trunk). As shown in the figure at Step 1, SW1 could (for example) forward a frame in VLAN 10 (Step 1). However, SW2 would view any frame that arrives with an 802.1Q header as illegal, because SW2 treats its G0/2 port as an access port. So, SW2 discards any 802.1Q frames received on that port.

To deal with the possibility of this problem, always check the trunk’s operational state on both sides of the trunk. The best commands to check trunking-related facts are show interfaces trunk and show interfaces switchport.

NOTE: Frankly, in real life, just avoid this kind of configuration. However, the switches do not prevent you from making these types of mistakes, so you need to be ready.

So far, you have learned the skills to navigate the command-line interface (CLI) and use commands that configure and verify switch features.

You learned about the primary purpose of a switch—forwarding Ethernet frames—and learned how to see that process in action by looking at the switch MAC address table.

After learning about the switch data plane in the lesson, “Analyzing Ethernet LAN Switching,” you learned a few management plane features in the lesson, “Configuring Basic Switch Management,” like how to configure the switch to support Telnet and Secure Shell (SSH) by configuring IP address and login security.

In this lesson, you pick up tools that loosely fit in the switch control plane.

First, this lesson shows how you can configure and change the operation of switch interfaces: how to change the speed, duplex, or even disable the interface.

The second half then shows how to add a security feature called port security, which monitors the source MAC address of incoming frames, deciding which frames are allowed and which cause a security violation.

IOS uses the term interface to refer to physical ports used to forward data to and from other devices. Each interface can be configured with several settings, each of which might differ from interface to interface. IOS uses interface subcommands to configure these settings.

Each of these settings may be different from one interface to the next, so you would first identify the specific interface, and then configure the specific setting.

This section begins with a discussion of three relatively basic per-interface settings: the port speed, duplex, and a text description. Following that, the text takes a short look at a pair of the most common interface subcommands: the shutdown and no shutdown commands, which administratively disable and enable the interface, respectively.

This section ends with a discussion about autonegotiation concepts, which in turn dictates what settings a switch chooses to use when using autonegotiation.

Switch interfaces that support multiple speeds (10/100 and 10/100/1000 interfaces), by default, will autonegotiate what speed to use. However, you can configure the speed and duplex settings with the duplex {auto | full | half} and speed {auto | 10 | 100 | 1000} interface subcommands. Simple enough.

Most of the time, using autonegotiation makes good sense, so when you set the duplex and speed, you typically have a good reason to do so. For instance, maybe you want to set the speed to the fastest possible on links between switches just to avoid the chance that auto-negotiation chooses a slower speed.

The description text interface subcommand lets you add a text description to the interface. For instance, if you have good reason to configure the speed and duplex on a port, maybe add a description that says why you did. Example 1 shows how to configure duplex and speed, as well as the description command, which is simply a text description that can be configured by the administrator.
Image

First, focus on the mechanics of moving around in configuration mode again by looking closely at the command prompts. The various interface commands move the user from global mode into interface configuration mode for a specific interface. For instance, the example configures the duplex, speed, and description commands all just after the interface FastEthernet 0/1 command, which means that all three of those configuration settings apply to interface Fa0/1, and not to the other interfaces.

The show interfaces status command lists much of the detail configured in Example 1, even with only one line of output per interface. Example 2 shows an example, just after the configuration in Example 1 was added to the switch.

Working through the output in the example:

FastEthernet 0/1 (Fa0/1): This output lists the first few characters of the configured description. It also lists the configured speed of 100 and duplex full per the speed and duplex commands in Example 1. However, it also states that Fa0/1 has a status of notconnect, meaning that the interface is not currently working. (That switch port did not have a cable connected when collecting this example, on purpose.)

FastEthernet 0/2 (Fa0/2): Example 1 did not configure this port at all. This port had all default configuration. Note that the “auto” text under the speed and duplex heading means that this port will attempt to autonegotiate both settings when the port comes up. However, this port also does not have a cable connected (again on purpose, for comparison).

FastEthernet 0/4 (Fa0/4): Like Fa0/2, this port has all default configuration, but was cabled to another working device to give yet another contrasting example. This device completed the autonegotiation process, so instead of “auto” under the speed and duplex headings, the output lists the negotiated speed and duplex (a-full and a-100). Note that the text includes the a- to mean that the listed speed and duplex values were autonegotiated.

The bottom of the configuration in Example 1 shows a way to shorten your configuration work when making the same setting on multiple consecutive interfaces. To do so, use the interface range command. In the example, the interface range FastEthernet 0/11 - 20 command tells IOS that the next subcommand(s) apply to interfaces Fa0/11 through Fa0/20. You can define a range as long as all interfaces are the same type and are numbered consecutively.

NOTE: This lesson spells out all parameters fully to avoid confusion. However, most everyone abbreviates what they type in the CLI to the shortest unique abbreviation. For instance, the configuration commands int f0/1 and int ran f0/11 - 20 would also be acceptable.

IOS does not actually put the interface range command into the configuration. Instead, it acts as if you had typed the subcommand under every single interface in the specified range.

Example 3 shows an excerpt from the show running-config command, listing the configuration of interfaces F0/11–12 from the configuration in Example 1. 

The example shows the same description command on both interfaces; to save space the example did not bother to show all 10 interfaces that have the same description text.

As you might imagine, network engineers need a way to bring down an interface without having to travel to the switch and remove a cable. In short, we need to be able to decide which ports should be enabled, and which should be disabled.

In an odd turn of phrase, Cisco uses two interface subcommands to configure the idea of administratively enabling and disabling an interface: the shutdown command (to disable), and the no shutdown command (to enable). While the no shutdown command might seem like an odd command to enable an interface at first, you will use this command a lot in lab, and it will become second nature. (Most people in fact use the abbreviations shut and no shut.)

Example 4 shows an example of disabling an interface using the shutdown interface subcommand. In this case, switch SW1 has a working interface F0/1. The user connects at the console and disables the interface. IOS generates a log message each time an interface fails or recovers, and log messages appear at the console, as shown in the example.

To bring the interface back up again, all you have to do is follow the same process but use the no shutdown command instead.

Before leaving the simple but oddly named shutdown/no shutdown commands, take a look at two important show commands that list the status of a shutdown interface. The show interfaces status command lists one line of output per interface, and when shut down, lists the interface status as “disabled.” That makes logical sense to most people. The show interfaces command (without the status keyword) lists many lines of output per interface, giving a much more detailed picture of interface status and statistics. With that command, the interface status comes in two parts, with one part using the phrase “administratively down,” matching the highlighted log message in Example 4.

Example 5 shows an example of each of these commands. Note that both examples also use the F0/1 parameter (short for Fast Ethernet0/1), which limits the output to the messages about F0/1 only. Also note that F0/1 is still shut down at this point.

In some cases, the commands are not the end goal, and the text is attempting to teach you something about how the CLI works. This next short topic is more about the process than about the commands.

With some IOS configuration commands (but not all), you can revert to the default setting by issuing a no version of the command. What does that mean? Let me give you a few examples:

• If you earlier had configured speed 100 on an interface, the no speed command on that same interface reverts to the default speed setting (which happens to be speed auto).
• Same idea with the duplex command: an earlier configuration of duplex half or duplex full, followed by no duplex on the same interface, reverts the configuration back to the default of duplex auto.
• If you had configured a description command with some text, to go back to the default state of having no description command at all for that interface, use the no description command.

Example 6 shows the process. In this case, switch SW1’s F0/2 port has been configured with speed 100, duplex half, description link to 2901-2, and shutdown. You can see evidence of all four settings in the command that begins the example. (This command lists the running-config, but only the part for that one interface.)

The example then shows the no versions of those commands, and closes with a confirmation that all the commands have reverted to default.

NOTE: The show running-config and show startup-config commands typically do not display default configuration settings, so the absence of commands listed under interface F0/2 at the end of the example means that those commands now use default values.

For any 10/100 or 10/100/1000 interfaces—that is, interfaces that can run at different speeds—Cisco Catalyst switches default to a setting of duplex auto and speed auto. As a result, those interfaces attempt to automatically determine the speed and duplex setting to use. Alternatively, you can configure most devices, switch interfaces included, to use a specific speed and/or duplex.

In practice, using autonegotiation is easy: just leave the speed and duplex at the default setting, and let the switch port negotiate what settings to use on each port. However, problems can occur due to unfortunate combinations of configuration. Therefore, this next topic walks through more detail about the concepts behind autonegotiation, so you know better how to interpret the meaning of the switch show commands and when to choose to use a particular configuration setting.

Autonegotiation Under Working Conditions

Ethernet devices on the ends of a link must use the same standard or they cannot correctly send data. For example, a NIC cannot use 100BASE-T, which uses a two-pair UTP cable with a 100-Mbps speed, while the switch port on the other end of the link uses 1000BASE-T. Even if you used a cable that works with Gigabit Ethernet, the link would not work with one end trying to send at 100 Mbps while the other tried to receive the data at 1000 Mbps.

Upgrading to new and faster Ethernet standards becomes a problem because both ends have to use the same standard. For example, if you replace an old PC with a new one, the old one might have been using 100BASE-T while the new one uses 1000BASE-T. The switch port on the other end of the link needs to now use 1000BASE-T, so you upgrade the switch. If that switch had ports that would use only 1000BASE-T, you would need to upgrade all the other PCs connected to the switch. So, having both PC network interface cards (NIC) and switch ports that support multiple standards/speeds makes it much easier to migrate to the next better standard.

The IEEE autonegotiation protocol helps makes it much easier to operate a LAN when NICs and switch ports support multiple speeds. IEEE autonegotiation (IEEE standard 802.3u) defines a protocol that lets the two UTP-based Ethernet nodes on a link negotiate so that they each choose to use the same speed and duplex settings. The protocol messages flow outside the normal Ethernet electrical frequencies as out-of-band signals over the UTP cable. Basically, each node states what it can do, and then each node picks the best options that both nodes support: the fastest speed and the best duplex setting, with full duplex being better than half duplex.

NOTE: Autonegotiation relies on the fact that the IEEE uses the same wiring pinouts for 10BASE-T and 100BASE-T, and that 1000BASE-T simply adds to those pinouts, adding two pairs.

Many networks use autonegotiation every day, particularly between user devices and the access layer LAN switches, as shown in Figure 1. The company installed four-pair cabling of the right quality to support 1000BASE-T, to be ready to support Gigabit Ethernet. As a result, the wiring supports 10-Mbps, 100-Mbps, and 1000-Mbps Ethernet options. Both nodes on each link send autonegotiation messages to each other. The switch in this case has all 10/100/1000 ports, while the PC NICs support different options.

The following list breaks down the logic, one PC at a time:

• PC1: The switch port claims it can go as fast as 1000 Mbps, but PC1’s NIC claims a top speed of 10 Mbps. Both the PC and switch choose the best speed both support (10 Mbps) and the best duplex (full).
• PC2: PC2 claims a best speed of 100 Mbps, which means it can use 10BASE-T or 100BASE-T. The switch port and NIC negotiate to use the best speed of 100 Mbps and full duplex.
• PC3: It uses a 10/100/1000 NIC, supporting all three speeds and standards, so both the NIC and switch port choose 1000 Mbps and full duplex.

Autonegotiation Results When Only One Node Uses Autonegotiation

Figure 1 shows the IEEE autonegotiation results when both nodes use the process. However, most Ethernet devices can disable autonegotiation, so it is just as important to know what happens when a node tries to use autonegotiation but the node gets no response.

Disabling autonegotiation is not always a bad idea. For instance, many network engineers disable autonegotiation on links between switches and simply configure the desired speed and duplex on both switches. However, mistakes can happen when one device on an Ethernet predefines speed and duplex (and disables autonegotiation), while the device on the other end attempts autonegotiation. In that case, the link might not work at all, or it might just work poorly.

NOTE: Configuring both the speed and duplex on a Cisco switch interface disables autonegotiation.

IEEE autonegotiation defines some rules (defaults) that nodes should use as defaults when autonegotiation fails—that is, when a node tries to use autonegotiation but hears nothing from the device. The rules:

• Speed: Use your slowest supported speed (often 10 Mbps).
• Duplex: If your speed = 10 or 100, use half duplex; otherwise, use full duplex.

Cisco switches can make a better choice than that base IEEE logic, because Cisco switches can actually sense the speed used by other nodes, even without IEEE autonegotiation. As a result, Cisco switches use this slightly different logic to choose the speed when autonegotiation fails:

• Speed: Sense the speed (without using autonegotiation), but if that fails, use the IEEE default (slowest supported speed, often 10 Mbps).
• Duplex: Use the IEEE defaults: If speed = 10 or 100, use half duplex; otherwise, use full duplex.

Figure 2 shows three examples in which three users change their NIC settings and disable autonegotiation, while the switch (with all 10/100/1000 ports) attempts autonegotiation. That is, the switch ports all default to speed auto and duplex auto. The top of the figure shows the configured settings on each PC NIC, with the choices made by the switch listed next to each switch port.

Reviewing each link, left to right:

• PC1: The switch receives no autonegotiation messages, so it senses the electrical signal to learn that PC1 is sending data at 100 Mbps. The switch uses the IEEE default duplex based on the 100 Mbps speed (half duplex).
• PC2: The switch uses the same steps and logic as with the link to PC1, except that the switch chooses to use full duplex because the speed is 1000 Mbps.
• PC3: The user picks poorly, choosing the slower speed (10 Mbps) and the worse duplex setting (half). However, the Cisco switch senses the speed without using IEEE autonegotiation and then uses the IEEE duplex default for 10-Mbps links (half duplex).

PC1 shows a classic and unfortunately common end result: a duplex mismatch. The two nodes (PC1 and SW1’s port F0/1) both use 100 Mbps, so they can send data. However, PC1, using full duplex, does not attempt to use carrier sense multiple access with collision detection (CSMA/CD) logic and sends frames at any time. Switch port F0/1, with half duplex, does use CSMA/CD. As a result, switch port F0/1 will believe collisions occur on the link, even if none physically occur. The switch port will stop transmitting, back off, resend frames, and so on. As a result, the link is up, but it performs poorly.

Autonegotiation and LAN Hubs

LAN hubs also impact how autonegotiation works. Basically, hubs do not react to autonegotiation messages, and they do not forward the messages. As a result, devices connected to a hub must use the IEEE rules for choosing default settings, which often results in the devices using 10 Mbps and half duplex.

Figure 3 shows an example of a small Ethernet LAN that uses a 20-year-old 10BASE-T hub. In this LAN, all devices and switch ports are 10/100/1000 ports. The hub supports only 10BASE-T.

Note that the devices on the right need to use half duplex because the hub requires the use of the CSMA/CD algorithm to avoid collisions.

If the network engineer knows what devices should be cabled and connected to particular interfaces on a switch, the engineer can use port security to restrict that interface so that only the expected devices can use it. This reduces exposure to attacks in which the attacker connects a laptop to some unused switch port. When that inappropriate device attempts to send frames to the switch interface, the switch can take different actions, ranging from simply issuing informational messages to effectively shutting down the interface.

Port security identifies devices based on the source MAC address of Ethernet frames the devices send. For example, in Figure 4, PC1 sends a frame, with PC1’s MAC address as the source address. SW1’s F0/1 interface can be configured with port security, and if so, SW1 would examine PC1’s MAC address and decide whether PC1 was allowed to send frames into port F0/1.

Port security also has no restrictions on whether the frame came from a local device or was forwarded through other switches. For example, switch SW1 could use port security on its G0/1 interface, checking the source MAC address of the frame from PC2, when forwarded up to SW1 from SW2.

Port security has several flexible options, but all operate with the same core concepts. First, switches enable port security per port, with different settings available per port. Each port has a maximum number of allowed MAC addresses, meaning that for all frames entering that port, only that number of different source MAC addresses can be used in different incoming frames before port security thinks a violation has occurred. When a frame with a new source MAC address arrives, pushing the number of MAC addresses past the allowed maximum, a port security violation occurs. At that point, the switch takes action—by default, discarding all future incoming traffic on that port.

The following list summarizes these ideas common to all variations of port security:

• Define a maximum number of source MAC addresses allowed for all frames coming in the interface.
• Watch all incoming frames, and keep a list of all source MAC addresses, plus a counter of the number of different source MAC addresses.
• When adding a new source MAC address to the list, if the number of MAC addresses pushes past the configured maximum, a port security violation has occurred. The switch takes action (the default action is to shut down the interface).

Those rules define the basics, but port security allows other options as well, including letting you configure the specific MAC addresses allowed to send frames in an interface. For example, in Figure 4, switch SW1 connects through interface F0/1 to PC1, so the port security configuration could list PC1’s MAC address as the specific allowed MAC address. But predefining MAC addresses for port security is optional: You can predefine all MAC addresses, none, or a subset of the MAC addresses.

You might like the idea of predefining the MAC addresses for port security, but finding the MAC address of each device can be a bother. Port security provides an easy way to discover the MAC addresses used off each port using a feature called sticky secure MAC addresses. With this feature, port security learns the MAC addresses off each port and stores them in the port security configuration (in the running-config file). This feature helps reduce the big effort of finding out the MAC address of each device.

As you can see, port security has a lot of detailed options. The next few sections walk you through these options to pull the ideas together.

Port security configuration involves several steps.

First, you need to disable the negotiation of a feature whether the port is an access or trunk port. This will be shown in next lesson.

For now, accept that port security requires a port to be configured to either be an access port or a trunking port.

The rest of the commands enable port security, set the maximum allowed MAC addresses per port, and configure the actual MAC addresses, as detailed in this list:

• Step 1. Make the switch interface either a static access or trunk interface using the switchport mode access or the switchport mode trunk interface subcommands, respectively.
• Step 2. Enable port security using the switchport port-security interface subcommand.
• Step 3. (Optional) Override the default maximum number of allowed MAC addresses associated with the interface (1) by using the switchport port-security maximum number interface subcommand.
• Step 4. (Optional) Override the default action to take upon a security violation (shutdown) using the switchport port-security violation {protect | restrict | shutdown} interface subcommand.
• Step 5. (Optional) Predefine any allowed source MAC addresses for this interface using the switchport port-security mac-address mac-address command. Use the command multiple times to define more than one MAC address.
• Step 6. (Optional) Tell the switch to “sticky learn” dynamically learned MAC addresses with the switchport port-security mac-address sticky interface subcommand.

Figure 5 and Example 7 show four examples of port security. Three ports operate as access ports, while port F0/4, connected to another switch, operates as a trunk. Note that port security allows either a trunk or an access port, but requires that the port be statically set as one or the other.

First, scan the configuration for all four interfaces in Example 7, focusing on the first two interface subcommands. Note that the first three interfaces in the example use the same first two interface subcommands, matching the first two configuration steps noted before Figure 5. The switchport port-security command enables port security, with all defaults, with the switchport mode access command meeting the requirement to configure the port as either an access or trunk port. The final port, F0/4, has a similar configuration, except that it has been configured as a trunk rather than as an access port.

Next, scan all four interfaces again, and note that the configuration differs on each interface after those first two interface subcommands. Each interface simply shows a different example for perspective.

The first interface, FastEthernet 0/1, adds one optional port security subcommand: switchport port-security mac-address 0200.1111.1111, which defines a specific source MAC address. With the default maximum source address setting of 1, only frames with source MAC 0200.1111.1111 will be allowed in this port. When a frame with a source other than 0200.1111.1111 enters F0/1, the switch will take the default violation action and disable the interface.

As a second example, FastEthernet 0/2 uses the same logic as FastEthernet 0/1, except that it uses the sticky learning feature. For port F0/2, the configuration the switchport port-security mac-address sticky command, which tells the switch to dynamically learn source MAC addresses and add port-security commands to the running-config. The end of upcoming Example 8 shows the running-config file that lists the sticky-learned MAC address in this case.

NOTE: Port security does not save the configuration of the sticky addresses, so use the copy running-config startup-config command if desired.

The other two interfaces do not predefine MAC addresses, nor do they sticky-learn the MAC addresses. The only difference between these two interfaces’ port security configuration is that FastEthernet 0/4 supports eight MAC addresses, because it connects to another switch and should receive frames with multiple source MAC addresses. Interface F0/3 uses the default maximum of one MAC address.

Example 8 lists the output of two examples of the show port-security interface command. This command lists the configuration settings for port security on an interface, plus it lists several important facts about the current operation of port security, including information about any security violations. The two commands in the example show interfaces F0/1 and F0/2, based on Example 7’s configuration.

The first two commands in Example 8 confirm that a security violation has occurred on FastEthernet 0/1, but no violations have occurred on FastEthernet 0/2. The show port-security interface fastethernet 0/1 command shows that the interface is in a secure-shutdown state, which means that the interface has been disabled because of port security. In this case, another device connected to port F0/1, sending a frame with a source MAC address other than 0200.1111.1111, is causing a violation. However, port Fa0/2, which used sticky learning, simply learned the MAC address used by Server 2.

The bottom of Example 8, as compared to the configuration in Example 7, shows the changes in the running-config because of sticky learning, with the switchport port-security mac-address sticky 0200.2222.2222 interface subcommand.

Finally, the switch can be configured to use one of three actions when a violation occurs. All three options cause the switch to discard the offending frame, but some of the options make the switch take additional actions. The actions include the sending of syslog messages to the console, sending SNMP trap messages to the network management station, and disabling the interface. Table 1 lists the options of the switchport port-security violation {protect | restrict | shutdown} command and their meanings.

Note that the shutdown option does not actually add the shutdown subcommand to the interface configuration. Instead, IOS puts the interface in an error disabled (err-disabled) state, which makes the switch stop all inbound and outbound frames. To recover from this state, someone must manually disable the interface with the shutdown interface command and then enable the interface with the no shutdown command.

To complete this lesson, take a moment to think about ​Analyzing Ethernet LAN Switching’s discussions about switching, along with all those examples of output from the show mac address-table dynamic EXEC command.

Once a switch port has been configured with port security, the switch no longer considers MAC addresses associated with that port as being dynamic entries as listed with the show mac address-table dynamic EXEC command. Even if the MAC addresses are dynamically learned, once port security has been enabled, you need to use one of these options to see the MAC table entries associated with ports using port security:

• show mac address-table secure: Lists MAC addresses associated with ports that use port security
• show mac address-table static: Lists MAC addresses associated with ports that use port security, as well as any other statically defined MAC addresses

Example 9 proves the point. It shows two commands about interface F0/2 from the port security example shown in Figure 5 and Example 7. In that example, port security was configured on F0/2 with sticky learning, so from a literal sense, the switch learned a MAC address off that port (0200.2222.2222). However, the show mac address-table dynamic command does not list the address and port, because IOS considers that MAC table entry to be a static entry. The show mac address-table secure command does list the address and port.

The work related to what a networking device does can be broken into three broad categories.

The first and most obvious, called the data plane, is the work a switch does to forward frames generated by the devices connected to the switch. In other words, the data plane is the main purpose of the switch.

Second, the control plane refers to the configuration and processes that control and change the choices made by the switch’s data plane. The network engineer can control which interfaces are enabled and disabled, which ports run at which speeds, how Spanning Tree blocks some ports to prevent loops, and so on.

The third category, the management plane, is the topic of this chapter. The management plane deals with managing the device itself, rather than controlling what the device is doing.

In particular, this lesson looks at the most basic management features that can be configured in a Cisco switch.

The first section of the lesson works through the configuration of different kinds of login security. The second section shows how to configure IPv4 settings on a switch so it can be remotely managed.

The last (short) section then explains a few practical matters that can make your life in lab a little easier.

By default, a Cisco Catalyst switch allows anyone to connect to the console port, access user mode, and then move on to enable and configuration modes without any kind of security.

That default makes sense, given that if you can get to the console port of the switch, you already have control over the switch physically.

However, everyone needs to operate switches remotely, and the first step in that process is to secure the switch so that only the appropriate users can access the switch command-line interface (CLI).

This first topic in the lesson examines how to configure login security for a Cisco Catalyst switch.

Securing the CLI includes protecting access to enable mode, because from enable mode, an attacker could reload the switch or change the configuration.

Protecting user mode is also important, because attackers can see the status of the switch, learn about the network, and find new ways to attack the network.

Note that all remote access and management protocols require that the switch IP configuration be completed and working.

A switch’s IPv4 configuration has nothing to do with how a Layer 2 switch forwards Ethernet frames (as discussed in the lesson, “Analyzing Ethernet LAN Switching”), but to Telnet and Secure Shell (SSH) to a switch, the switch needs to be configured with an IP address.

In particular, this section covers the following login security topics:

• Securing user mode and privileged mode with simple passwords
• Securing user mode access with local usernames
• Securing user mode access with external authentication servers
• Securing remote access with Secure Shell (SSH)

Although the default switch configuration allows a console user to move into user mode and then privileged mode with no passwords required, unsurprisingly, the default settings prevent Telnet and SSH users from even accessing user mode.

And while the defaults work well to prevent unwanted access when you first install the switch, you need to add some configuration to then be able to sit at your desk and log in to all the switches in the LAN. In addition, of course, you should not allow just anyone to log in and change the configuration, so some type of secure login should be used.

The first option most people learn to secure access to user mode, one best used in a lab rather than in production, is a simple shared password. This method uses a password only—with no username—with one password for console users and a different password for Telnet users.

Console users must supply the console password, as configured in console line configuration mode. Telnet users must supply the Telnet password, also called the vty password, so called because the configuration sits in vty line configuration mode. Figure 1 summarizes these options for using shared passwords from the perspective of the user logging into the switch.

NOTE: This section refers to several passwords as shared passwords. These passwords are shared in the sense that when a new worker comes to the company, others must tell them (share) what the password is. In other words, each user does not have a unique username/password to use, but rather, all the appropriate staff knows the passwords.

In addition, Cisco switches protect enable mode (also called privileged mode) with yet another shared password called the enable password.

From the perspective of the network engineer connecting to the CLI of the switch, once in user mode, the user types the enable EXEC command. This command prompts the user for this enable password; if the user types the correct password, IOS moves the user to enable mode.

Example 1 shows an example of the user experience of logging into a switch from the console when the shared console password and the enable password have both been set.

Note that before this example began, the user started their terminal emulator, physically connected their laptop to the console cable, and then pressed the return key to make the switch respond as shown at the top of the example.

Note that the example shows the password text as if typed (hope and love), along with the enable command that moves the user from user mode to enable mode. In reality, the switch hides the passwords when typed, to prevent someone from reading over your shoulder to see the password.

To configure the shared passwords for the console, Telnet, and for enable mode, you need to configure several commands. However, the parameters of the commands can be pretty intuitive. Figure 2 shows the configuration of all three of these passwords.

The configuration for these three passwords does not require a lot of work. First, the console and vty password configuration sets the password based on the context: console mode for the console (line con 0), and vty line configuration mode for the Telnet password (line vty 0 15). Then inside console mode and vty mode, respectively, the two commands in each mode are:

• login: Tells IOS to enable the use of a simple shared password (with no username) on this line (console or vty), so that the switch asks the user for a password
• password password-value: Defines the actual password used on the console or vty

The configured enable password, shown on the right side of the figure, applies to all users, no matter whether they connect to user mode via the console, Telnet, or otherwise. The command to configure the enable password is a global configuration command: enable secret password-value.

NOTE: Older IOS versions used the command enable password password-value to set the enable password, and that command still exists in IOS. However, the enable secret command is much more secure. In real networks, use enable secret. When we reach the devices security features lesson, we'll explain more about the security levels of various password mechanisms, including a comparison of the enable secret and enable password commands.

To help you follow the process, use the configuration checklist before the example.

The configuration checklist collects the required and optional steps to configure a feature. The configuration checklist for shared passwords for the console, Telnet, and enable passwords is:

• Step 1. Configure the enable password with the enable secret password-value command.
• Step 2. Configure the console password:
  • A. Use the line con 0 command to enter console configuration mode.
  • B. Use the login subcommand to enable console password security using a simple password.
  • C. Use the password password-value subcommand to set the value of the console password.
• Step 3. Configure the Telnet (vty) password:
  • A. Use the line vty 0 15 command to enter vty configuration mode for all 16 vty lines (numbered 0 through 15).
  • B. Use the login subcommand to enable password security for vty sessions using a simple password.
  • C. Use the password password-value subcommand to set the value of the vty password.

Example 2 shows the configuration process as noted in the configuration checklist, along with setting the enable secret password. 

Note that the lines which begin with a ! are comment lines; they are there to guide you through the configuration.

Example 3 shows the resulting configuration in the switch per the show running-config command. The gray lines highlight the new configuration. Note that many unrelated lines of output have been deleted from the output to keep focused on the password configuration.

Cisco switches support two other login security methods that both use per-user username/password pairs instead of a shared password with no username.

One method, referred to as local usernames and passwords, configures the username/password pairs locally—that is, in the switch’s configuration.

Switches support this local username/password option for the console, for Telnet, and even for SSH, but do not replace the enable password used to reach enable mode.

The configuration to migrate from using the simple shared passwords to instead use local usernames/passwords requires only some small configuration changes, as shown in Figure 3.

Working through the configuration in the figure, first, the switch of course needs to know the list of username/password pairs. To create these, repeatedly use the username name secret password global configuration command.

Then, to enable this different type of console or Telnet security, simply enable this login security method with the login local line.

Basically, this command means “use the local list of usernames for login.”

You can also use the no password command (without even typing in the password) to clean up any remaining password subcommands from console or vty mode, because these commands are not needed when using local usernames and passwords.

The following checklist details the commands to configure local username login, mainly as a method for easier study and review:

• Step 1. Use the username name secret password global configuration command to add one or more username/password pairs on the local switch.
• Step 2. Configure the console to use locally configured username/password pairs:
  • A. Use the line con 0 command to enter console configuration mode.
  • B. Use the login local subcommand to enable the console to prompt for both username and password, checked versus the list of local usernames/passwords.
  • C. (Optional) Use the no password subcommand to remove any existing simple shared passwords, just for good housekeeping of the configuration file.
• Step 3. Configure Telnet (vty) to use locally configured username/password pairs.
  • A. Use the line vty 0 15 command to enter vty configuration mode for all 16 vty lines (numbered 0 through 15).
  • B. Use the login local subcommand to enable the switch to prompt for both username and password for all inbound Telnet users, checked versus the list of local usernames/passwords.
  • C. (Optional) Use the no password subcommand to remove any existing simple shared passwords, just for good housekeeping of the configuration file.

When a Telnet user connects to the switch configured as shown in Figure 3, the user will be prompted first for a username and then for a password, as shown in Example 4. 

The username/password pair must be from the list of local usernames or the login is rejected.

NOTE: Example 4 does not show the password value as having been typed because Cisco switches do not display the typed password for security reasons.

NOTE: The username secret command has an older less-secure cousin, the username password command. Today, use the more secure username secret command.

The end of Example 4 points out one of the many security improvements when requiring each user to log in with their own username. The end of the example shows the user entering configuration mode (configure terminal), and then immediately leaving (end). Note that when a user exits configuration mode, the switch generates a log message. If the user logged in with a username, the log message identifies that username; note the “wendell” in the log message.

However, using a username/password configured directly on the switch causes some administrative headaches. For instance, every switch and router needs the configuration for all users who might need to log in to the devices. Then, when any changes need to happen, like an occasional change to the passwords for good security practices, the configuration of all devices must be changed.

A better option would be to use tools like those used for many other IT login functions. Those tools allow for a central place to securely store all username/password pairs, with tools to make the user change their passwords regularly, tools to revoke users when they leave their current jobs, and so on.

Cisco switches allow exactly that option using an external server called an authentication, authorization, and accounting (AAA) server. These servers hold the usernames/passwords. Typically, these servers allow users to do self service and forced maintenance to their passwords. Many production networks use AAA servers for their switches and routers today.

The underlying login process requires some additional work on the part of the switch for each user login, but once set up, the username/password administration is much less. When using a AAA server for authentication, the switch (or router) simply sends a message to the AAA server asking whether the username and password are allowed, and the AAA server replies.

Figure 4 shows an example, with the user first supplying his username/password, the switch asking the AAA server, and the server replying to the switch stating that the username/password is valid.

While the figure shows the general idea, note that the information flows with a couple of different protocols. On the left, the connection between the user and the switch or router uses Telnet or SSH. On the right, the switch and AAA server typically use either the RADIUS or TACACS+ protocol, both of which encrypt the passwords as they traverse the network.

So far, this lesson has focused on the console and on Telnet, mostly ignoring SSH. Telnet has one serious disadvantage: all data in the Telnet session flows as clear text, including the password exchanges. So, anyone that can capture the messages between the user and the switch (in what is called a man-in-the-middle attack) can see the passwords. SSH encrypts all data transmitted between the SSH client and server, protecting the data and passwords.

SSH can use the same local login authentication method as Telnet, with the locally configured username and password. (SSH cannot rely on a password only.) So, the configuration to support local usernames for Telnet, as shown previously in Figure 3, also enables local username authentication for incoming SSH connections.

Figure 5 shows one example configuration of what is required to support SSH. The figure repeats the local username configuration as shown earlier in Figure 3, as used for Telnet.

Figure 5 shows three additional commands required to complete the configuration of SSH on the switch.

IOS uses the three SSH-specific configuration commands in the figure to create the SSH encryption keys. The SSH server uses the fully qualified domain name (FQDN) of the switch as input to create that key. The term FQDN combines the hostname of a host and its domain name, in this case the hostname and domain name of the switch.

Figure 5 begins by setting both values (just in case they are not already configured). Then the third command, the crypto key generate rsa command, generates the SSH encryption keys.

The configuration in Figure 5 relies on two default settings that the figure therefore conveniently ignored. IOS runs an SSH server by default. In addition, IOS allows SSH connections into the vty lines by default.

Seeing the configuration happen in configuration mode, step by step, can be particularly helpful with SSH configuration. Note in particular that in this example, the crypto key command prompts the user for the key modulus; you could also add the parameters modulus modulus-value to the end of the crypto key command to add this setting on the command.

Example 5 shows the commands in Figure 5 being configured, with the encryption key as the final step.

Earlier, I mentioned that one useful default was that the switch defaults to support both SSH and Telnet on the vty lines. However, because Telnet is a security risk, you could disable Telnet to enforce a tighter security policy. (For that matter, you can disable SSH support and allow Telnet on the vty lines as well.)

To control which protocols a switch supports on its vty lines, use the transport input {all | none | telnet | ssh} vty subcommand in vty mode, with the following options:

• transport input all or transport input telnet ssh: Support both Telnet and SSH
• transport input none: Support neither
• transport input telnet: Support only Telnet
• transport input ssh: Support only SSH

To complete this section about SSH, the following configuration checklist details the steps for one method to configure a Cisco switch to support SSH using local usernames. (SSH support in IOS can be configured in several ways; this checklist shows one simple way to configure it.)

The process shown here ends with a comment to configure local username support on vty lines, as was discussed earlier in the section titled “Securing User Mode Access with Local Usernames and Passwords.”

• Step 1. Configure the switch to generate a matched public and private key pair to use for encryption:
  • A. If not already configured, use the hostname name in global configuration mode to configure a hostname for this switch.
  • B. If not already configured, use the ip domain-name name in global configuration mode to configure a domain name for the switch, completing the switch’s FQDN.
  • C. Use the crypto key generate rsa command in global configuration mode (or the crypto key generate rsa modulus modulus-value command to avoid being prompted for the key modulus) to generate the keys. (Use at least a 768-bit key to support SSH version 2.)
• Step 2. (Optional) Use the ip ssh version 2 command in global configuration mode to override the default of supporting both versions 1 and 2, so that only SSHv2 connections are allowed.
• Step 3. (Optional) If not already configured with the setting you want, configure the vty lines to accept SSH and whether to also allow Telnet:
  • A. Use the transport input ssh command in vty line configuration mode to allow SSH only.
  • B. Use the transport input all command (default) or transport input telnet ssh command in vty line configuration mode to allow both SSH and Telnet.
• Step 4. Use various commands in vty line configuration mode to configure local username login authentication as discussed earlier in this chapter.

NOTE: Cisco routers default to transport input none, so that you must add the transport input line subcommand to enable Telnet and/or SSH into a router.

Two key commands give some information about the status of SSH on the switch. First, the show ip ssh command lists status information about the SSH server itself.

The show ssh command then lists information about each SSH client currently connected into the switch. Example 6 shows samples of each, with user Wendell currently connected to the switch.

To allow Telnet or SSH access to the switch, and to allow other IP-based management protocols (for example, Simple Network Management Protocol, or SNMP) to function as intended, the switch needs an IP address, as well as a few other related settings. The IP address has nothing to do with how switches forward Ethernet frames; it simply exists to support overhead management traffic.

This next topic begins by explaining the IPv4 settings needed on a switch, followed by the configuration. Note that although switches can be configured with IPv6 addresses with commands similar to those shown in this chapter, this lesson focuses solely on IPv4. All references to IP in this lesson imply IPv4.

A switch needs the same kind of IP settings as a PC with a single Ethernet interface. For perspective, a PC has a CPU, with the operating system running on the CPU. It has an Ethernet network interface card (NIC). The OS configuration includes an IP address associated with the NIC, either configured or learned dynamically with DHCP.

A switch uses the same ideas, except that the switch needs to use a virtual NIC inside the switch. Like a PC, a switch has a real CPU, running an OS (called IOS). The switch obviously has lots of Ethernet ports, but instead of assigning its management IP address to any of those ports, the switch then uses a NIC-like concept called a switched virtual interface (SVI), or more commonly, a VLAN interface, that acts like the switch’s own NIC.

Then the settings on the switch look something like a host, with the switch configuration assigning IP settings, like an IP address, to this VLAN interface, as shown in Figure 6.

By using interface VLAN 1 for the IP configuration, the switch can then send and receive frames on any of the ports in VLAN 1. In a Cisco switch, by default, all ports are assigned to VLAN 1.

In most networks, switches configure many VLANs, so the network engineer has a choice of where to configure the IP address. That is, the management IP address does not have to be configured on the VLAN 1 interface (as configured with the interface vlan 1 command seen in Figure 6).

A Layer 2 Cisco LAN switch often uses a single VLAN interface at a time, although multiple VLAN interfaces can be configured. The switch only needs one IP address for management purposes. But you can configure VLAN interfaces and assign them IP addresses for any working VLAN.

For example, Figure 7 shows a Layer 2 switch with some physical ports in two different VLANs (VLANs 1 and 2). 

The figure also shows the subnets used on those VLANs. The network engineer could choose to create a VLAN 1 interface, a VLAN 2 interface, or both. In most cases, the engineer plans which VLAN to use when managing a group of switches, and creates a VLAN interface for that VLAN only.

Note that you should not try to use a VLAN interface for which there are no physical ports assigned to the same VLAN. If you do, the VLAN interface will not reach an up/up state, and the switch will not have the physical ability to communicate outside the switch.

NOTE: Some Cisco switches can be configured to act as either a Layer 2 switch or a Layer 3 switch. When acting as a Layer 2 switch, a switch forwards Ethernet frames as discussed in depth in the lesson, “Analyzing Ethernet LAN Switching.” Alternatively, a switch can also act as a multilayer switch or Layer 3 switch, which means the switch can do both Layer 2 switching and Layer 3 IP routing of IP packets, using the Layer 3 logic normally used by routers. This lesson assumes all switches are Layer 2 switches.

Configuring the IP address (and mask) on one VLAN interface allows the switch to send and receive IP packets with other hosts in a subnet that exists on that VLAN; however, the switch cannot communicate outside the local subnet without another configuration setting called the default gateway. The reason a switch needs a default gateway setting is the same reason that hosts need the same setting—because of how hosts think when sending IP packets. Specifically:

• To send IP packets to hosts in the same subnet, send them directly
• To send IP packets to hosts in a different subnet, send them to the local router; that is, the default gateway

Figure 8 shows the ideas. In this case, the switch (on the right) will use IP address 192.168.1.200 as configured on interface VLAN 1. However, to communicate with host A, on the far left of the figure, the switch must use Router R1 (the default gateway) to forward IP packets to host A. To make that work, the switch needs to configure a default gateway setting, pointing to Router R1’s IP address (192.168.1.1 in this case). Note that the switch and router both use the same mask, 255.255.255.0, which puts the addresses in the same subnet.

A switch configures its IPv4 address and mask on this special NIC-like VLAN interface. The following steps list the commands used to configure IPv4 on a switch, assuming that the IP address is configured to be in VLAN 1, with Example 7 that follows showing an example configuration.

• Step 1. Use the interface vlan 1 command in global configuration mode to enter interface VLAN 1 configuration mode.
• Step 2. Use the ip address ip-address mask command in interface configuration mode to assign an IP address and mask.
• Step 3. Use the no shutdown command in interface configuration mode to enable the VLAN 1 interface if it is not already enabled.
• Step 4. Add the ip default-gateway ip-address command in global configuration mode to configure the default gateway.
• Step 5. (Optional) Add the ip name-server ip-address1 ip-address2 ... command in global configuration mode to configure the switch to use Domain Name System (DNS) to resolve names into their matching IP address.

On a side note, this example shows a particularly important and common command: the [no] shutdown command. To administratively enable an interface on a switch, use the no shutdown interface subcommand; to disable an interface, use the shutdown interface subcommand.

This command can be used on the physical Ethernet interfaces that the switch uses to switch Ethernet messages in addition to the VLAN interface shown here in this example.

Also, pause long enough to look at the messages that appear just below the no shutdown command in Example 7. Those messages are syslog messages generated by the switch stating that the switch did indeed enable the interface. Switches (and routers) generate syslog messages in response to a variety of events, and by default, those messages appear at the console. 

The switch can also use Dynamic Host Configuration Protocol (DHCP) to dynamically learn its IPv4 settings. Basically, all you have to do is tell the switch to use DHCP on the interface, and enable the interface. Assuming that DHCP works in this network, the switch will learn all its settings. The following list details the steps, again assuming the use of interface VLAN 1, with Example 8 that follows showing an example:

Step 1. Enter VLAN 1 configuration mode using the interface vlan 1 global configuration command, and enable the interface using the no shutdown command as necessary.
Step 2. Assign an IP address and mask using the ip address dhcp interface subcommand.

The switch IPv4 configuration can be checked in several places.

First, you can always look at the current configuration using the show running-config command.

Second, you can look at the IP address and mask information using the show interfaces vlan x command, which shows detailed status information about the VLAN interface in VLAN x.

Finally, if using DHCP, use the show dhcp lease command to see the (temporarily) leased IP address and other parameters. (Note that the switch does not store the DHCP-learned IP configuration in the running-config file.)

Example 9 shows sample output from these commands to match the configuration in Example 8.

The output of the show interfaces vlan 1 command lists two very important details related to switch IP addressing.

First, this show command lists the interface status of the VLAN 1 interface—in this case, “up and up.” If the VLAN 1 interface is not up, the switch cannot use its IP address to send and receive management traffic. Notably, if you forget to issue the no shutdown command, the VLAN 1 interface remains in its default shutdown state and is listed as “administratively down” in the show command output.

Second, note that the output lists the interface’s IP address on the third line. If you statically configure the IP address, as in Example 7, the IP address will always be listed; however, if you use DHCP and DHCP fails, the show interfaces vlan x command will not list an IP address here. When DHCP works, you can see the IP address with the show interfaces vlan 1 command, but that output does not remind you whether the address is either statically configured or DHCP leased. So it does take a little extra effort to make sure you know whether the address is statically configured or DHCP-learned on the VLAN interface.

This last short section of the lesson touches on a couple of commands that can help you be a little more productive when practicing in a lab.

When you enter commands from the CLI, the switch saves the last several commands in the history buffer. Then, as mentioned in Chapter 6, “Using the Command-Line Interface,” you can use the up-arrow key or press Ctrl+P to move back in the history buffer to retrieve a command you entered a few commands ago. This feature makes it very easy and fast to use a set of commands repeatedly. Table 1 lists some of the key commands related to the history buffer.

These next three configuration commands have little in common, other than the fact that they can be useful settings to reduce your frustration when using the console of a switch or router.

The console automatically receives copies of all unsolicited syslog messages on a switch. The idea is that if the switch needs to tell the network administrator some important and possibly urgent information, the administrator might be at the console and might notice the message.

Unfortunately, IOS (by default) displays these syslog messages on the console’s screen at any time—including right in the middle of a command you are entering, or in the middle of the output of a show command. Having a bunch of text show up unexpectedly can be a bit annoying.

You could simply disable the feature that sends these messages to the console, and then re-enable the feature later, using the no logging console and logging console global commands. For example, when working from the console, if you want to temporarily not be bothered by log messages, you can disable the display of these messages with the no logging console global configuration command, and then when finished, enable them again.

However, IOS supplies a reasonable compromise, telling the switch to display syslog messages only at more convenient times, such as at the end of output from a show command. To do so, just configure the logging synchronous console line subcommand, which basically tells IOS to synchronize the syslog message display with the messages requested using show commands.

Another way to improve the user experience at the console is to control timeouts of the login session from the console or when using Telnet or SSH. By default, the switch automatically disconnects console and vty (Telnet and SSH) users after 5 minutes of inactivity. The exec-timeout minutes seconds line subcommand enables you to set the length of that inactivity timer. In lab (but not in production), you might want to use the special value of 0 minutes and 0 seconds meaning “never time out.”

Finally, IOS has an interesting combination of features that can make you wait for a minute or so when you mistype a command. First, IOS tries to use DNS name resolution on IP hostnames—a generally useful feature. If you mistype a command, however, IOS thinks you want to Telnet to a host by that name. With all default settings in the switch, the switch tries to resolve the hostname, cannot find a DNS server, and takes about a minute to timeout and give you control of the CLI again.

To avoid this problem, configure the no ip domain-lookup global configuration command, which disables IOS’s attempt to resolve the hostname into an IP address.

Example 10 collects all these commands into a single example, as a template for some good settings to add in a lab switch to make you more productive.