Network Warrior | O'Reilly Media

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Before we get started, I would like to define some terms and set some ground rules. For the purposes of this book (and your professional life, I hope), a computer network can be defined as "two or more computers connected by some means through which they are capable of sharing information." Don't bother looking for that in an RFC because I just made it up, but it suits our needs just fine.

There are many types of networks: Local Area Networks (LANs), Wide Area Networks (WANs), Metropolitan Area Networks (MANs), Campus Area Networks (CANs), Ethernet networks, Token Ring networks, Fiber Distributed Data Interface (FDDI) networks, Asynchronous Transfer Mode (ATM) networks, frame-relay networks, T1 networks, DS3 networks, bridged networks, routed networks, and point-to-point networks, to name a few. If you're old enough to remember the program Laplink, which allowed you to copy files from one computer to another over a special parallel port cable, you can consider that connection a network as well. It wasn't very scalable (only two computers), or very fast, but it was a means of sending data from one computer to another via a connection.

Connection is an important concept. It's what distinguishes a sneaker net, in which information is physically transferred from one computer to another via removable media, from a real network. When you slap a floppy disk into a computer, there is no indication that the files came from another computer—there is no connection. A connection involves some sort of addressing, or identification of the nodes on the network (even if it's just master/slave or primary/secondary).

The machines on a network are often connected physically via cables. However, wireless networks, which are devoid of physical connections, are connected through the use of radios. Each node on a wireless network has an address. Frames received on the wireless network have a specific source and destination, as with any network.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the beginning of Ethernet, 10Base-5 used a very thick cable that was hard to work with (it was nicknamed thicknet). 10Base-2, which later replaced 10Base-5, used a much smaller cable, similar to that used for cable TV. Because the cable was much thinner than that used by 10Base-5, 10Base-2 was nicknamed thin-net. These cable technologies required large metal couplers called N connectors (10Base-5) and BNC connectors (10Base-2). These networks also required special terminators to be installed at the end of cable runs. When these couplers or terminators were removed, the entire network would stop working. These cables formed the physical backbones for Ethernet networks.

With the introduction of Ethernet running over unshielded twisted pair (UTP) cables terminated with RJ45 connectors, hubs became the new backbones in most installations. Many companies attached hubs to their existing thin-net networks to allow greater flexibility as well. Hubs were made to support UTP and BNC 10Base-2 installations, but UTP was so much easier to work with that it became the de facto standard.

A hub is simply a means of connecting Ethernet cables together so that their signals can be repeated to every other connected cable on the hub. Hubs may also be called repeaters for this reason, but it is important to understand that while a hub is a repeater, a repeater is not necessarily a hub.

A repeater repeats a signal. Repeaters are usually used to extend a connection to a remote host, or to connect a group of users who exceed the distance limitation of 10Base-T. In other words, if the usable distance of a 10Base-T cable is exceeded, a repeater can be placed inline to increase the usable distance.

I was surprised to learn that there is no specific distance limitation included in the 10Base-T standard. While 10Base-5 and 10Base-2 do include distance limitations (500 meters and 200 meters, respectively), the 10Base-T spec instead describes certain characteristics that a cable should meet. To be safe, I usually try to keep my 10Base-T cables within 100 meters.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the beginning of Ethernet, 10Base-5 used a very thick cable that was hard to work with (it was nicknamed thicknet). 10Base-2, which later replaced 10Base-5, used a much smaller cable, similar to that used for cable TV. Because the cable was much thinner than that used by 10Base-5, 10Base-2 was nicknamed thin-net. These cable technologies required large metal couplers called N connectors (10Base-5) and BNC connectors (10Base-2). These networks also required special terminators to be installed at the end of cable runs. When these couplers or terminators were removed, the entire network would stop working. These cables formed the physical backbones for Ethernet networks.

With the introduction of Ethernet running over unshielded twisted pair (UTP) cables terminated with RJ45 connectors, hubs became the new backbones in most installations. Many companies attached hubs to their existing thin-net networks to allow greater flexibility as well. Hubs were made to support UTP and BNC 10Base-2 installations, but UTP was so much easier to work with that it became the de facto standard.

A hub is simply a means of connecting Ethernet cables together so that their signals can be repeated to every other connected cable on the hub. Hubs may also be called repeaters for this reason, but it is important to understand that while a hub is a repeater, a repeater is not necessarily a hub.

A repeater repeats a signal. Repeaters are usually used to extend a connection to a remote host, or to connect a group of users who exceed the distance limitation of 10Base-T. In other words, if the usable distance of a 10Base-T cable is exceeded, a repeater can be placed inline to increase the usable distance.

I was surprised to learn that there is no specific distance limitation included in the 10Base-T standard. While 10Base-5 and 10Base-2 do include distance limitations (500 meters and 200 meters, respectively), the 10Base-T spec instead describes certain characteristics that a cable should meet. To be safe, I usually try to keep my 10Base-T cables within 100 meters.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The next step in the evolution of Ethernet after the hub was the switch. Switches differ from hubs in that switches play an active role in how frames are forwarded. Remember that a hub simply repeats every signal it receives via any of its ports out every other port. A switch, in contrast, keeps track of what devices are on what ports, and forwards frames only to the devices for which they are intended.

What we refer to as a packet in TCP/IP is called a frame when speaking about hubs, bridges, and switches. Technically, they are different things, since a TCP packet is encapsulated with layer-2 information to form a frame. However, the terms "frames" and "packets" are often thrown around interchangeably (I'm guilty of this myself). To be perfectly correct, always refer to frames when speaking of hubs and switches.

When other companies began developing switches, Cisco had all of its energies concentrated in routers, so it did not have a solution that could compete. Hence, Cisco did the smartest thing it could do at the time—it acquired the best of the new switching companies, like Kalpana, and added their devices to the Cisco lineup. As a result, Cisco switches did not have the same operating system that their routers did. While Cisco routers used the Internetwork Operating System (IOS), the Cisco switches sometimes used menus, or an operating system called CatOS. (Cisco calls its switch line by the name Catalyst; thus, the Catalyst Operating System was CatOS.)

A quick word about terminology is in order. The words "switching" and "switch" have multiple meanings, even in the networking world. There are Ethernet switches, frame-relay switches, layer-3 switches, multilayer switches, and so on. Here are some terms that are in common use:

Switch

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When I get called to a client's site to diagnose a network slowdown or a "slow" device, the first things I look at are the error statistics and the auto-negotiation settings on the switches and the devices connected to them. If I had to list the most common problems I've seen during my years in the field, auto-negotiation issues would be in the top five, if not number one.

Why is auto-negotiation such a widespread problem? The truth is, too many people don't really understand what it does and how it works, so they make assumptions that lead to trouble.

Auto-negotiation is the feature that allows a port on a switch, router, server, or other device to communicate with the device on the other end of the link to determine the optimal duplex mode and speed for the connection. The driver then dynamically configures the interface to the values determined for the link. Let's examine these parameters:

Speed: Speed is the rate of the interface, usually listed in megabits per second (Mbps). Common Ethernet speeds include 10 Mbps, 100 Mbps, and 1,000 Mbps. 1,000 Mbps Ethernet is also referred to as Gigabit Ethernet.
Duplex: Duplex refers to how data flows on the interface. On a half-duplex interface, data can only be transmitted or received at any given time. A conversation on a two-way radio is usually half-duplex—each person must push a button to talk, and, while talking, that person cannot listen. A full-duplex interface, on the other hand, can send and receive data simultaneously. A conversation on a telephone is full duplex.

First, let's cover what auto-negotiation does not do: when auto-negotiation is enabled on a port, it does not automatically determine the configuration of the port on the other side of the Ethernet cable and then match it. This is a common misconception that often leads to problems.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Auto-negotiation is the feature that allows a port on a switch, router, server, or other device to communicate with the device on the other end of the link to determine the optimal duplex mode and speed for the connection. The driver then dynamically configures the interface to the values determined for the link. Let's examine these parameters:

Speed: Speed is the rate of the interface, usually listed in megabits per second (Mbps). Common Ethernet speeds include 10 Mbps, 100 Mbps, and 1,000 Mbps. 1,000 Mbps Ethernet is also referred to as Gigabit Ethernet.
Duplex: Duplex refers to how data flows on the interface. On a half-duplex interface, data can only be transmitted or received at any given time. A conversation on a two-way radio is usually half-duplex—each person must push a button to talk, and, while talking, that person cannot listen. A full-duplex interface, on the other hand, can send and receive data simultaneously. A conversation on a telephone is full duplex.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

First, let's cover what auto-negotiation does not do: when auto-negotiation is enabled on a port, it does not automatically determine the configuration of the port on the other side of the Ethernet cable and then match it. This is a common misconception that often leads to problems.

Auto-negotiation is a protocol, and as with any protocol, it only works if it's running on both sides of the link. In other words, if one side of a link is running auto-negotiation, and the other side of the link is not, auto-negotiation cannot determine the speed and duplex configuration of the other side. If auto-negotiation is running on the other side of the link, the two devices decide together on the best speed and duplex mode. Each interface advertises the speeds and duplex modes at which it can operate, and the best match is selected (higher speeds and full duplex are preferred).

The confusion exists primarily because auto-negotiation always seems to work. This is because of a feature called parallel detection, which kicks in when the auto-negotiation process fails to find auto-negotiation running on the other end of the link. Parallel detection works by sending the signal being received to the local 10Base-T, 100Base-TX, and 100Base-T4 drivers. If any one of these drivers detects the signal, the interface is set to that speed.

Parallel detection determines only the link speed, not the supported duplex modes. This is an important consideration because the common modes of Ethernet have differing levels of duplex support:

10Base-T: 10Base-T was originally designed without full-duplex support. Some implementations of 10Base-T support full duplex, but most do not.
100Base-T: 100Base-T has long supported full duplex, which has been the preferred method for connecting 100-Mbps links for as long as the technology has existed. However, the default behavior of 100Base-T is usually half duplex, and it must be set to full duplex, if so desired.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When auto-negotiation fails on 10/100 links, the most likely cause is that one side of the link has been set to 100/full, and the other side has been set to auto-negotiation. This results in one side being 100/full, and the other side being 100/half.

shows a half-duplex link. In a half-duplex environment, the receiving (RX) line is monitored. If a frame is present on the RX link, no frames are sent until the RX line is clear. If a frame is received on the RX line while a frame is being sent on the transmitting (TX) line, a collision occurs. Collisions cause the collision error counter to be incremented—and the sending frame to be retransmitted—after a random back-off delay.

Figure 3-1: Half duplex

shows a full-duplex link. In full-duplex operation, the RX line is not monitored, and the TX line is always considered available. Collisions do not occur in full-duplex mode because the RX and TX lines are completely independent.

Figure 3-2: Full duplex

When one side of the link is full-duplex, and the other side is half-duplex, a large number of collisions will occur on the half-duplex side. Because the full-duplex side sends frames without checking the RX line, if it's a busy device, chances are it will be sending frames constantly. The other end of the link, being half-duplex, will listen to the RX line, and will not transmit unless the RX line is available. It will have a hard time getting a chance to transmit, and will record a high number of collisions, resulting in the device appearing to be slow on the network. The issue may not be obvious because a half-duplex interface normally shows collisions. The problem should present itself as excessive collisions.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Using auto-negotiation to your advantage is as easy as remembering one simple rule:

Make sure that both sides of the link are configured the same way.

If one side of the link is set to auto-negotiation, make sure the other side is also set to auto-negotiation. If one side is set to 100/full, make sure the other side is also set to 100/full.

Be careful about using 10/full, as full duplex is not supported on all 10Base-T Ethernet devices.

Gigabit Ethernet uses a substantially more robust auto-negotiation mechanism than the one described in this chapter. Gigabit Ethernet should thus always be set to auto-negotiation, unless there is a compelling reason not to do so (such as an interface that will not properly negotiate). Even then, this should be considered a temporary workaround until the misbehaving part can be replaced.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

For Cisco switches, auto-negotiation is enabled by default. You can configure the speed and duplex mode manually with the speed and duplex interface commands in IOS.

You cannot set the duplex mode without first setting the speed. The switch will complain if you attempt to do so:

2950(config-if)#duplex half
Duplex can not be set until speed is set to non-auto value

To set the speed of the interface, use the speed command. If the interface has previously been configured, you can return it to auto-negotiation with the auto keyword:

2950(config-if)#speed ?
  10    Force 10 Mbps operation
  100   Force 100 Mbps operation
  auto  Enable AUTO speed configuration

Once you've set the speed, you can set the duplex mode to auto, full, or half:

2950(config-if)#duplex ?
  auto  Enable AUTO duplex configuration
  full  Force full duplex operation
  half  Force half-duplex operation

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Virtual LANs, or VLANs, are virtual separations within a switch that provide distinct logical LANs that each behave as if they were configured on a separate physical switch. Before the introduction of VLANs, one switch could serve only one LAN. VLANs enabled a single switch to serve multiple LANs. Assuming no vulnerabilities exist in the switch's operating system, there is no way for a frame that originates on one VLAN to make its way to another.

shows a switch with multiple VLANs. The VLANs have been numbered 10, 20, 30, and 40. In general, VLANs can be named or numbered; Cisco's implementation uses numbers to identify VLANs by default. The default VLAN is numbered 1. If you plug a number of devices into a switch without assigning its ports to specific VLANs, all the devices will be in VLAN 1.

Figure 4-1: VLANs on a switch

Frames cannot leave the VLANs from which they originate. This means that in the example configuration, Jack can communicate with Jill, and Bill can communicate with Ted, but Bill and Ted cannot communicate with Jack or Jill in any way.

For a packet on a layer-2 switch to cross from one VLAN to another, an outside router must be attached to each of the VLANs to be routed. shows an external router connecting VLAN 20 with VLAN 40. Assuming a proper configuration on the router, Bill will now be able to communicate with Jill, but neither workstation will show any indication that they reside on the same physical switch.

Figure 4-2: External routing between VLANs

When expanding a network using VLANs, the same limitations apply. If you connect another switch to a port that is configured for VLAN 20, the new switch will be able to forward frames only to or from VLAN 20. If you wanted to connect two switches, each containing four VLANs, you would need four links between the switches: one for each VLAN. A solution to this problem is to deploy

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

shows a switch with multiple VLANs. The VLANs have been numbered 10, 20, 30, and 40. In general, VLANs can be named or numbered; Cisco's implementation uses numbers to identify VLANs by default. The default VLAN is numbered 1. If you plug a number of devices into a switch without assigning its ports to specific VLANs, all the devices will be in VLAN 1.

Figure 4-1: VLANs on a switch

Frames cannot leave the VLANs from which they originate. This means that in the example configuration, Jack can communicate with Jill, and Bill can communicate with Ted, but Bill and Ted cannot communicate with Jack or Jill in any way.

For a packet on a layer-2 switch to cross from one VLAN to another, an outside router must be attached to each of the VLANs to be routed. shows an external router connecting VLAN 20 with VLAN 40. Assuming a proper configuration on the router, Bill will now be able to communicate with Jill, but neither workstation will show any indication that they reside on the same physical switch.

Figure 4-2: External routing between VLANs

When expanding a network using VLANs, the same limitations apply. If you connect another switch to a port that is configured for VLAN 20, the new switch will be able to forward frames only to or from VLAN 20. If you wanted to connect two switches, each containing four VLANs, you would need four links between the switches: one for each VLAN. A solution to this problem is to deploy trunks between switches. Trunks are links that carry frames for more than one VLAN.

shows two switches connected with a trunk. Jack is connected to VLAN 20 on Switch B, and Diane is connected to VLAN 20 on Switch A. Because there is a trunk connecting these two switches together, assuming the trunk is allowed to carry traffic for all configured VLANs, Jack will be able to communicate with Diane. Notice that the ports to which the trunk is connected are not assigned VLANs. These ports are

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

VLANs are typically configured via the CatOS or IOS command-line interpreter (CLI), like any other feature. However, some IOS models, such as the 2950 and 3550 switches, have a configurable VLAN database with its own configuration mode and commands. This can be a challenge for the uninitiated, especially because the configuration for this database is completely separate from the configuration for the rest of the switch. Even a write erase followed by a reload will not clear the VLAN database on these switches. Configuring through the VLAN database is a throwback to older models that offered no other way to manage VLANs. All newer switches (including those with a VLAN database) offer the option of configuring the VLANs through the normal IOS CLI. Switches like the 6500, when running in native IOS mode, only support IOS commands for switch configuration.

Cisco recommends that the VLAN Trunking Protocol (VTP) be configured as a first step when configuring VLANs. This idea has merit, as trunks will not negotiate without a VTP domain. However, setting a VTP domain is not required to make VLANs function on a single switch. Configuring VTP is covered later (see and ).

For CatOS, creating a VLAN is accomplished with the set vlan command:

Switch1-CatOS# (enable)set vlan 10 name Lab-VLAN
VTP advertisements transmitting temporarily stopped,
and will resume after the command finishes.
Vlan 10 configuration successful

There are a lot of options when creating a VLAN, but for the bare minimum, this is all that's needed. To show the status of the VLANs, execute the show vlan command:

Switch1-CatOS# (enable)sho vlan
VLAN Name                             Status    IfIndex Mod/Ports, Vlans
---- -------------------------------- --------- ------- ------------------------
1    default                          active    7       1/1-2
                                                        2/1-2
                                                        3/5-48
                                                        6/1-48
10   Lab-VLAN                         active    112

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A trunk, using Cisco's terminology, is an interface or link that can carry frames for multiple VLANs at once. As we saw in the previous chapter, a trunk can be used to connect two switches so that devices in VLANs on one switch can communicate with devices in the same VLANs on another switch. Unless there is only one VLAN to be connected, switches are connected at layer two using trunks. shows two switches connected with a trunk.

Figure 5-1: A trunk connecting two switches

Trunking is generally related to switches, but a router can connect to a trunk as well. The router on a stick scenario described in requires a router to communicate with a trunk port on a switch.

shows a visual representation of a trunk. VLANs 10, 20, 30, and 40 exist on both sides of the trunk. Any traffic from VLAN 10 on Switch-1 that is destined for VLAN 10 on Switch-2 must traverse the trunk. (Of course, the reverse is true as well.)

Figure 5-2: Visual representation of a trunk

For the remote switch to know how to forward the frame, the frame must contain a reference to the VLAN to which it belongs. IP packets have no concept of VLANs, though, and nor does TCP, UDP, ICMP, or any other protocol above layer two. Remember that a VLAN is a layer-two concept, so if there were to be any mention of a VLAN, it would happen at the data-link layer. Ethernet was invented before VLANs, so there is no mention of VLANs in any Ethernet protocols, either.

To accomplish the marking or tagging of frames to be sent over a trunk, both sides must agree to a protocol. Currently, the protocols for trunking supported on Cisco switches are Cisco's Inter-Switch Link (ISL) and the IEEE standard 802.1Q. Not all Cisco switches support both protocols. For example, the Cisco 2950 and 4000 switches only support 802.1Q. To determine whether a switch can use a specific trunking protocol, use the IOS command

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

shows a visual representation of a trunk. VLANs 10, 20, 30, and 40 exist on both sides of the trunk. Any traffic from VLAN 10 on Switch-1 that is destined for VLAN 10 on Switch-2 must traverse the trunk. (Of course, the reverse is true as well.)

Figure 5-2: Visual representation of a trunk

For the remote switch to know how to forward the frame, the frame must contain a reference to the VLAN to which it belongs. IP packets have no concept of VLANs, though, and nor does TCP, UDP, ICMP, or any other protocol above layer two. Remember that a VLAN is a layer-two concept, so if there were to be any mention of a VLAN, it would happen at the data-link layer. Ethernet was invented before VLANs, so there is no mention of VLANs in any Ethernet protocols, either.

To accomplish the marking or tagging of frames to be sent over a trunk, both sides must agree to a protocol. Currently, the protocols for trunking supported on Cisco switches are Cisco's Inter-Switch Link (ISL) and the IEEE standard 802.1Q. Not all Cisco switches support both protocols. For example, the Cisco 2950 and 4000 switches only support 802.1Q. To determine whether a switch can use a specific trunking protocol, use the IOS command show interface capabilities, or the CatOS command

show port
        capabilities

:

Switch1-CatOS#sho port capabilities
Model                       WS-X6K-SUP2-2GE
Port                        1/1
Type                        1000BaseSX
Auto MDIX                   no
AuxiliaryVlan               no
Broadcast suppression       percentage(0-100)
Channel                     yes
COPS port group             1/1-2
CoS rewrite                 yes
Dot1q-all-tagged            yes
Dot1x                       yes

Duplex                      full
Fast start                  yes
Flow control                receive-(off,on,desired),send-(off,on,desired)
Inline power                no
Jumbo frames                yes
Link debounce timer         yes
Link debounce timer delay   yes
Membership                  static,dynamic
Port ASIC group             1/1-2
QOS scheduling              rx-(1p1q4t),tx-(1p2q2t)
Security                    yes
SPAN                        source,destination
Speed                       1000
Sync restart delay          yes
ToS rewrite                 DSCP

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Configuring a trunk involves determining what port will be a trunk, what protocol the trunk will run, and whether and how the port will negotiate. Optionally, you may also wish to limit what VLANs are allowed on the trunk link.

The Cisco 3550 is an excellent example of an IOS switch. This section will walk you through configuring one of the Gigabit ports to be an 802.1Q trunk using a 3550 switch.

You might think that the first thing to do would be to specify that the port is a trunk, but as you're about to see, that's not the case:

3550-IOS(config-if)#switchport mode trunk
Command rejected: An interface whose trunk encapsulation is "Auto" can not be
configured to "trunk" mode.

On an IOS switch capable of both ISL and 802.1Q, you must specify a trunk encapsulation before you can configure a port as a trunk. (

trunk
          encapsulation

is an unfortunate choice for the command because, as you now know, 802.1Q does not encapsulate frames like ISL does. Still, you must follow Cisco's syntax.) Once you've chosen a trunking protocol, you are free to declare the port a trunk:

interface GigabitEthernet0/1
 switchport trunk encapsulation dot1q
 switchport mode trunk

Should you wish to subsequently remove trunking from the interface, the command to do so is switchport mode access.

By default, all VLANs on a switch are included in a trunk. But you may have 40 VLANs, and only need to trunk 3 of them. Because broadcasts from all allowed VLANs will be sent on every trunk port, excluding unneeded VLANs can save a lot of bandwidth on your trunk links. You can specify which VLANs are able to traverse a trunk with the switchport trunk allowed command. These are the options for this command:

3550-IOS(config-if)#switchport trunk allowed vlan ?

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In complex networks, managing VLANs can be time-consuming and error-prone. The VLAN Trunking Protocol (VTP) is a means whereby VLAN names and numbers can be managed at central devices, with the resulting configuration distributed automatically to other devices. Take for example the network shown in . This typical three-tier network is composed completely of layer-2 switches. There are 12 switches in all: 2 in the core, 4 in the distribution layer, and 6 in the access layer. (A real network employing this design might have hundreds of switches.)

Figure 6-1: Three-tier switched network

Let's assume that the network has 10 VLANs throughout the entire design. That's not so bad, right? Here's what a 10-VLAN configuration might look like on a 2950:

vlan 10
 name IT
!
vlan 20
 name Personnel
!
vlan 30
 name Accounting
!
vlan 40
 name Warehouse1
!
vlan 50
 name Warehouse2
!
vlan 60
 name Shipping
!
vlan 70
 name MainOffice
!
vlan 80
 name Receiving
!
vlan 90
 name Lab
!
vlan 100
 name Production

Now, consider that every switch in the design needs to have information about every VLAN. To accomplish this, you'll need to enter these commands, exactly the same each time, into every switch. Sure, you can copy the whole thing into a text file, and paste it into each of the switches, but the process still won't be fun. Look at the VLAN names. There are two warehouses, a lab, a main office—this is a big place! You'll have to haul a laptop and a console cable out to each switch, and the whole process could take quite a while.

Now, add into the equation the possibility that you'll need to add or delete a VLAN at some point, or change the name of one of them. You'll have make the rounds all over again each time there's a change to make.

I can hear you thinking, "But I can just telnet to each switch to make the changes!" Yes, you can, but when you change the VLAN you're connected through without thinking, you'll be back out there working on the consoles—and this time you'll have the foreman threatening you with whatever tool he happened to find along the way because the network's been down since you mucked it up. (Don't worry, things like that almost never happen . . . more than once.)

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

On large or congested networks, VTP can create a problem when excess traffic is sent across trunks needlessly. Take, for example, the network shown in . The switches in the gray box all have ports assigned to VLAN 100, while the rest of the switches do not. With VTP active, all of the switches will have VLAN 100 configured, and as such will receive broadcasts initiated on that VLAN. However, those without ports assigned to VLAN 100 have no use for the broadcasts.

Figure 6-3: Broadcast sent to all switches in VTP domain

On a busy VLAN, broadcasts can amount to a significant percentage of traffic. In this case, all that traffic is being needlessly sent over the entire network, and is taking up valuable bandwidth on the inter-switch trunks.

VTP pruning prevents traffic originating from a particular VLAN from being sent to switches on which that VLAN is not active (i.e., switches that do not have ports connected and configured for that VLAN). With VTP pruning enabled, the VLAN 100 broadcasts will be restricted to switches on which VLAN 100 is actively in use, as shown in .

Figure 6-4: VTP pruning limits traffic to switches with active ports in VLANs

Cisco documentation states that pruning is not designed to work with switches in VTP transparent mode.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

VTP offers a lot of advantages, but it can have some pretty serious drawbacks, too, if you're not careful.

Imagine a network in an active office. The office is in Manhattan, and spans 12 floors in a skyscraper. There are a pair of 6509s in the core, a pair of 4507Rs on each floor in the distribution layer, and 3550 access-layer switches throughout the environment. The total number of switches is close to 100. VTP is deployed with the core 6509s being the only VTP servers. The rest of the switches are all configured as VTP clients. All in all, this is a pretty well-built scenario very similar to the one shown in (but on a grander scale).

Now, say that somewhere along the way, someone needed some switches for the lab, and managed to get a couple of 3550s of his own. These 3550s were installed in the lab but were not connected into the network. For months, the 3550s in the lab stayed as a standalone pair, trunked only to each other. The VLAN configuration was changed often, as is usually the case in a lab environment. More importantly, the lab was created as a mirror of the production network, including the same VTP domain.

Then, months after the 3550s were installed, someone else decided that the lab needed to connect to the main network. He successfully created a trunk to one of the distribution-layer 4507R switches. Within a minute, the entire network was down. Remember the angry foreman with the threatening pipe wrench? He's got nothing on a financial institution's CTO on a rampage!

What went wrong? Remember that many switches are VTP servers by default. Remember also that when a switch participating in VTP receives an update that has a higher revision number than its own configuration's revision number, the switch will implement the new scheme. In our scenario, the lab's 3550s had been functioning as a standalone network with the same VTP domain as the regular network. Multiple changes were made to their VLAN configurations, resulting in a high configuration revision number. When these switches, which were VTP servers, were connected to the more stable production network, they automatically sent out updates. Each of the switches on the main network, including the core 6509s, received an update with a higher revision number than its current configuration. Consequently, they all requested the VLAN configuration from the rogue 3550s, and implemented that design.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

To use VTP, you must configure a VTP domain. You'll also need to know how to set the mode on your switches. Further configuration options include setting VTP passwords and configuring VTP pruning.

The default VTP domain is null. Bear this in mind when implementing VTP because trunks negotiated using the null VTP domain will break if you assign a different domain to one side.

This behavior differs from switch to switch. For example, the Catalyst 5000 will not negotiate trunks unless a VTP domain has been set for each switch.

On some switches, such as the Cisco 6500, the null domain will be overwritten if a VTP advertisement is received over a trunk link, and the switch will inherit the VTP domain from the advertisement. (If a VTP domain has been previously configured, this will not occur.)

Note also that once you've changed a switch's VTP domain to something other than null, there is no way to change it back to null short of erasing the configuration and rebooting.

Section 6.3.1.1: IOS

Setting or changing the VTP domain in IOS is done with the vtp domain command:

3550-IOS(config)#vtp domain GAD-Lab
Changing VTP domain name from NULL to GAD-Lab
3550-IOS(config)#
1w4d: %DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Fa0/20
because of VTP domain mismatch.

In this case, changing the domain has resulted in a VTP domain mismatch that will prevent trunk negotiation from occurring on port Fa0/20.

Section 6.3.1.2: CatOS

You can set or change the VTP domain on CatOS with the set vtp domain command:

Switch1-CatOS# (enable)set vtp domain GAD-Lab
VTP domain GAD-Lab modified

In this case, I resolved the trunk issue, so no error was reported. Had my change resulted in a VTP domain mismatch, the switch would have alerted me with a similar message to the one reported on the IOS switch.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

EtherChannel is the Cisco term for the technology that enables the bonding of up to eight physical Ethernet links into a single logical link. EtherChannel was originally called Fast EtherChannel (FEC), as it was only available on Fast Ethernet at the time.

With EtherChannel, the single logical link's speed is equal to the aggregate of the speeds of all the physical links used. For example, if you were to create an EtherChannel out of four 100-Mbps Ethernet links, the EtherChannel would have a speed of 400 Mbps.

This sounds great, and it is, but the idea is not without problems. For one thing, the bandwidth is not truly the aggregate of the physical link speeds in all situations. For example, on an EtherChannel composed of four 1-Gbps links, each conversation will still be limited to 1 Gbps by default.

The default behavior is to assign one of the physical links to each packet that traverses the EtherChannel, based on the packet's destination MAC address. This means that if one workstation talks to one server over an EtherChannel, only one of the physical links will be used. In fact, all of the traffic destined for that server will traverse a single physical link in the EtherChannel. This means that a single user will only ever get 1 Gbps from the EtherChannel at a time. (This behavior can be changed to send each packet over a different physical link, but as we'll see, there are limits to how well this works for applications like VoIP.) The benefit arises when there are multiple destinations, which can each use a different path.

EtherChannels are referenced by different names on IOS and CatOS devices. As shows, on a switch running CatOS, an EtherChannel is called a channel, while on a switch running IOS, an EtherChannel is called a port channel interface. The command to configure an EtherChannel on CatOS is set port channel, and the commands to view channels include

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

As stated earlier, EtherChannel by default does not truly provide the aggregate speed of the included physical links. EtherChannel gives the perceived speed of the combined links by passing certain packets through certain physical links. By default, the physical link used for each packet is determined by the packet's destination MAC address. The algorithm used is Cisco-proprietary, but it is deterministic, in that packets with the same destination MAC address will always travel over the same physical link. This ensures that packets sent to a single destination MAC address never arrive out of order.

The hashing algorithm for determining the physical link to be used may not be public, but the weighting of the links used in the algorithm is published. What is important here is the fact that a perfect balance between the physical links is not necessarily assured.

The hashing algorithm takes the destination MAC address (or another value, as you'll see later), and hashes that value to a number in the range of 0–7. The same range is used regardless of how many links are actually in the EtherChannel. Each physical link is assigned one or more of these eight values, depending on how many links are in the EtherChannel.

shows how packets are distributed according to this method. Notice that the distribution is not always even. This is important to understand because link usage statistics—especially graphs—will bear it out.

Figure 7-3: EtherChannel physical link balancing

On an EtherChannel with eight physical links, each of the links is assigned a single value. On an EtherChannel with six links, two of the links are assigned two values, and the remaining four links are each assigned one value. This means that two of the links (assuming a theoretical perfect distribution) will receive twice as much traffic as the other four. Having an EtherChannel thus does not imply that all links are used equally. Indeed, it should be obvious looking at that the only possible way to distribute traffic equally across all links in an EtherChannel (again, assuming a perfect distribution) is to design one with eight, four, or two physical links. Regardless of the information used to determine the link, the method will still hash the value to a value of 0–7, which will be used to assign a link according to this table.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The device on the other end of the EtherChannel is usually the determining factor in how the EtherChannel is configured. One design rule that must always be applied is that each of the links participating in an EtherChannel must have the same configuration. The descriptions can be different, but each of the physical links must be the same type and speed, and they must all be in the same VLAN. If they are trunks, they must all be configured with the same trunk parameters.

EtherChannel will negotiate with the device on the other side of the link. Two protocols are supported on Cisco devices. The first is the Link Aggregation Control Protocol (LACP), which is defined in IEEE specification 802.3ad. LACP is used when connecting to non-Cisco devices, such as servers. As an example, Solaris will negotiate with a Cisco switch via LACP. The other protocol used in negotiating EtherChannel links is the Port Aggregation Control Protocol (PAgP), which is a Cisco-proprietary protocol. Since PAgP is Cisco-proprietary, it is used only when connecting two Cisco devices via an EtherChannel. Each protocol supports two modes: a passive mode (auto in PAgP and passive in LACP), and an active mode (desirable in PAgP and active in LACP). Alternatively, you can set the mode to on, thus forcing the creation of the EtherChannel. The available protocols and modes are outlined in .

Figure 7-6: EtherChannel protocols and their modes

Generally, when you are configuring EtherChannels between Cisco switches, the ports will be EtherChannels for the life of the installation. Setting all interfaces in the EtherChannel on both sides to desirable makes sense. When connecting a Cisco switch to a non-Cisco device such as a Solaris machine, use the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The Spanning Tree Protocol (STP) is used to ensure that no layer-2 loops exist in a LAN. As you'll see in this chapter, layer-2 loops can cause havoc.

Spanning tree is designed to prevent loops among bridges. A bridge is a device that connects multiple segments within a single collision domain. Hubs and switches are both considered bridges. While the spanning tree documentation always refers to bridges generically, my examples will show switches. Switches are the devices in which you will encounter spanning tree.

When a switch receives a broadcast, it repeats the broadcast on every port (except the one on which it was received). In a looped environment, the broadcasts are repeated forever. The result is called a broadcast storm, and it will quickly bring a network to a halt.

illustrates what can happen when there's a loop in a network.

Figure 8-1: Broadcast storm

The computer on Switch A sends out a broadcast frame. Switch A then sends a copy of the broadcast to Switch B and Switch C. Switch B repeats the broadcast to Switch C, and Switch C repeats the broadcast to Switch B; Switch B and Switch C also repeat the broadcast back to Switch A. Switch A then repeats the broadcast it heard from Switch B to Switch C—and the broadcast it heard from Switch C—to Switch B. This progression will continue indefinitely until the loop is somehow broken. Spanning tree is an automated mechanism used to discover and break loops of this kind.

Spanning tree was developed by Dr. Radia Perlman of Sun Microsystems, Inc., who summed up the idea in a poem titled "Algorhyme" that's based on Joyce Kilmer's "Trees":

I think that I shall never see
A graph more lovely than a tree.
A tree whose crucial property
Is loop-free connectivity.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In the network shown in , there's a simple loop between two switches. Switch A and Switch B are connected to each other with two links: F0/14 and F0/15 on Switch A are connected to the same ports on Switch B. I've disabled spanning tree, which is on by default, to demonstrate the power of a broadcast storm. Both ports are trunks. There are various devices on other ports on the switches, which create normal broadcasts (such as ARP and DHCP broadcasts). There is nothing unusual about this network, aside from spanning tree being disabled.

Figure 8-2: Simple layer-2 loop

Interface F0/15 has already been configured and is operating properly. The output from the

show interface
        f0/15

command shows the input and output rates to be very low (both are around 1,000 bits per second and 2–3 packets per second):

3550-IOS#sho int f0/15
FastEthernet0/15 is up, line protocol is up (connected)
  Hardware is Fast Ethernet, address is 000f.8f5c.5a0f (bia 000f.8f5c.5a0f)
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 100Mb/s, media type is 10/100BaseTX
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:10, output 00:00:00, output hang never
  Last clearing of "show interface"

Table of Contents

Section 6.3.1.1: IOS

Section 6.3.1.2: CatOS