By Thomas Chipman
“The network is slow” … four little words that are the bane of every network administrator. You will find that no matter how well a network design meets an organization’s current or projected needs, the day will surely come when those four dreaded words will find their way into a trouble ticket. If anecdotal evidence is to be believed, you will most likely hear those four words about 12 minutes before you had planned to head out for a weekend getaway; and they are usually uttered by your CEO as she is standing in your doorway with her laptop. Well, today’s that day and she isn’t going to leave your office until you’ve worked your magic. After all, that IS why she made YOU senior vice architect of network engineering.
You are already prioritizing, shaping, and working your usual quality of service (QoS) voodoo to squeeze every last packet out of your existing uplinks, but the day has finally come when even that is no longer enough. To quote a famous network engineer of old, “ I’m givin’ her all she’s got, Cap’n! If I push the network any harder, the whole thing will blow!” So how can you solve this network bandwidth issue and make your way out the door before you miss your flight? Increasing network bandwidth is the obvious solution; however, that solution can sometimes be complicated or expensive; particularly if it requires the acquisition of new hardware or the installation of additional cable runs. Costly and time-consuming solutions definitely aren’t going to work when your CEO is breathing down your neck; your CEO doesn’t have time for that… “ain’t nobody got time for that.”
What if there was a simple and cost-effective solution to the problem? Let’s take a look at the network and see what we can find. Figure 1 gives us a nice overhead view of the network:
Looking at Figure 1, you can see that SwitchA and SwitchB share a redundant link. Excellent! Twice the link equals twice the bandwidth, amirite?!?! Sadly no. More likely than not, the redundant link in this scenario isn’t even being used and you can probably thank Spanning Tree Protocol (STP) for that. STP excels at preventing accidental loops in the network, but what if you intentionally put a loop in the network? What if you actually wanted more than one path between two switches and you wanted both of those paths to be available and usable at all times? In that case, STP isn’t going to be your friend. In fact, thanks to STP, the network actually looks more like the diagram in Figure 2:
“Inconceivable!” you say, “Why would a switch ignore a perfectly good uplink instead of using it to double its bandwidth?” Well, that’s kind of the point of STP. Without additional configuration, a redundant link could very well cause all sorts of nasty network issues, broadcast storms being among the nastiest. STP will shut down the redundant ports in an effort to save your network. You can see its handiwork in the partial command output from the show spanning-tree command:
SwitchA#show spanning-tree
VLAN0001
Spanning tree enabled protocol pvst
Root ID Priority 24576
Address 000C.1380.3538
Cost 19
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address 000C.1289.3959
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 15
Interface Role Sts Cost Prio.Nbr Type
--------- ---- --- ---- --- --- ----
Fa0/1 Root FWD 19 128.1 P2p
Fa0/2 Desg BLK 19 128.2 P2p
The command output above confirms that the FastEthernet 0/2 interface is blocked and not forwarding packets. If you can get this interface to forward packets at the same time as the FastEthernet 0/1 interface, you will have doubled the bandwidth between the switches. Fortunately, there’s something you can use to convince STP that you’d really like both of those ports forwarding packets at the same time, and that something is called EtherChannel.
EtherChannel is a form of port trunking that can use up to eight separate links together as a single logical link. That’s right, eight links that look like a single link. Brilliant! In this case, you only need two links, but the principal remains the same. With EtherChannel, you create something called a port channel interface, which is a virtual interface that functions in almost every sense like one of the physical interfaces on a switch. The port channel interface represents the bundle of physical interfaces that are assigned to a channel group. For example, if you assigned the FastEthernet 0/1 and FastEthernet 0/2 interfaces to channel group 1, you could use the PortChannel 1 interface to specify specific parameters, such as speed, duplex, and trunking mode. When you assign physical interfaces to a channel group, they are removed from the clutches of STP; the port channel interface in which these physical interfaces are bundled is all that STP can see. The following output shows that Fa0/1 and Fa0/2 are free of STP’s grubby little mitts:
SwitchA#show spanning-tree
VLAN0001
Spanning tree enabled protocol pvst
Root ID Priority 24576
Address 000C.1380.3538
Cost 19
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32768
Address 000C.1289.3959
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 15
Interface Role Sts Cost Prio.Nbr Type
--------- ---- --- ---- --- --- ----
Fa0/3 Desg FWD 19 128.3 P2p
Fa0/4 Desg FWD 19 128.4 P2p
…
Po1 Root FWD 19 128.16 P2p
Thanks to EtherChannel, the network now looks like the diagram in Figure 3:
Take that STP! A couple of clicks, a few crafty commands, and BOOM! You’ve doubled your bandwidth and satisfied your CEO. Don’t believe me? No worries, you can take a look at the output of the show interfaces command to verify that the PortChannel1 interface has twice the bandwidth of your typical lone Fast Ethernet interface:
SwitchA#show interfaces port-channel 1
Port-channel1 is up, line protocol is up
Hardware is EtherChannel, address is 000C.6873.9387 (bia 000C.6873.9387)
MTU 1500 bytes, BW 200000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Auto-duplex, Auto-speed
Encapsulation ARPA, loopback not set
ARP type: ARPA, ARP Timeout 04:00:00
Last input 02:29:44, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queuing strategy: fifo
Output queue :0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
269 packets input, 71059 bytes, 0 no buffer
Received 6 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
7290 packets output, 429075 bytes, 0 underruns
0 output errors, 3 interface resets
0 output buffer failures, 0 output buffers swapped out
Once again EtherChannel saves the day, and with just enough time for you to head out for the weekend. However, if you want to learn more about EtherChannel, hold tight for the second part of this blog post, in which we roll up our sleeves and get nerdy with all of the glorious details that are EtherChannel on Cisco hardware.
If you're studying for your CCENT, CCNA or CCNP certification exams, check out the NetSim demo.
