Senior Acquisitions Editor: Kenyon Brown Development Editor: Kim Wimpsett

PortFast and BPDU Guard

If you have a server or other devices connected into your switch that

you’re totally sure won’t create a switching loop if STP is disabled, you

can use a Cisco proprietary extension to the 802.1d standard called

PortFast on these ports. With this tool, the port won’t spend the usual 50

seconds to come up into forwarding mode while STP is converging, which

is what makes it so cool.

Since ports will transition from blocking to forwarding state immediately,

PortFast can prevent our hosts from being potentially unable to receive a

DHCP address due to STP’s slow convergence. If the host’s DHCP request

times out, or if every time you plug a host in you’re just tired of looking at

the switch port being amber for almost a minute before it transitions to

forwarding state and turns green, PortFast can really help you out!

Figure 15.19

illustrates a network with three switches, each with a trunk

to each of the others and a host and server off the S1 switch.

FIGURE 15.19

PortFast

We can use PortFast on the ports on S1 to help them transition to the STP

forwarding state immediately upon connecting to the switch.

Here are the commands, first from global config mode—they’re pretty

simple:

S1(config)#

spanning-tree portfast ?

bpdufilter Enable portfast bdpu filter on this switch

bpduguard Enable portfast bpdu guard on this switch

default Enable portfast by default on all access ports

If you were to type

spanning-tree portfast default

, you would enable all

nontrunking ports with PortFast. From interface mode, you can be more

specific, which is the better way to go:

S1(config-if)#

spanning-tree portfast ?

disable Disable portfast for this interface

trunk Enable portfast on the interface even in trunk mode

From interface mode you can actually configure PortFast on a trunk port,

but you would do that only if the port connects to a server or router, not

to another switch, so we won’t use that here. So let’s take a look at the

message I get when I turn on PortFast on interface Gi0/1:

S1#

config t

S1#config)#

int range gi0/1 - 2

S1(config-if)#

spanning-tree portfast

%Warning: portfast should only be enabled on ports connected to a

single

host. Connecting hubs, concentrators, switches, bridges, etc... to

this

interface when portfast is enabled, can cause temporary bridging

loops.

Use with CAUTION

%Portfast has been configured on GigabitEthernet0/1 but will only

have effect when the interface is in a non-trunking mode.

PortFast is enabled on port Gi0/1 and Gi0/2, but notice that you get a

pretty long message that’s essentially telling you to be careful. This is

because when using PortFast, you definitely don’t want to create a

network loop by plugging another switch or hub into a port that’s also

configured with PortFast! Why? Because if you let this happen, even

though the network may still sort of work, data will pass super slowly,

and worse, it could take you a really long time to find the source of the

problem, making you very unpopular. So proceed with caution!

At this juncture, you would be happy to know that there are some

safeguard commands to have handy when using PortFast just in case

someone causes a loop in a port that’s configured with PortFast enabled.

Let’s talk about a really key safeguard command now.

BPDU Guard

If you turn on PortFast for a switch port, it’s a really good idea to turn on

BPDU Guard as well. In fact, it’s such a great idea, I personally feel that it

should be enabled by default whenever a port is configured with PortFast!

This is because if a switch port that has PortFast enabled receives a BPDU

on that port, it will place the port into error disabled (shutdown) state,

effectively preventing anyone from accidentally connecting another

switch or hub port into a switch port configured with PortFast. Basically,

you’re preventing (guarding) your network from being severely crippled

or even brought down. So let’s configure our S1 interface, which is already

configured with PortFast, with BPDU Guard now—it’s easy!

Here’s how to set it globally:

S1(config)#

spanning-tree portfast bpduguard default

And specifically on an interface:

S1(config-if)#

spanning-tree bpduguard enable

It’s important to know that you would only configure this command on

your access layer switches—switches where users are directly connected.

Hedging My Bets Created Bad Switch Ports during the

Super Bowl

A junior admin called me frantically telling me all switch ports had

just gone bad on the core switch, which was located at the data center

where I was lead consultant for a data center upgrade. Now these

things happen, but keep in mind that I just happened to be at a Super

Bowl party having a great time watching my favorite team play in the

“Big One” when I received this call! So I took a deep breath to refocus.

I needed to find out some key information to determine just how bad

the situation really was, and my client was in as big of a hurry as I was

to get to a solution!

First I asked the junior admin exactly what he did. Of course, he said,

“Nothing, I swear!” I figured that’s what he’d say, so I pressed him for

more info and finally asked for stats on the switch. The admin told me

that all the ports on the 10/100/1000 line card went amber at the

same time—finally some information I could use! I confirmed that, as

suspected, these ports trunked to uplink distribution switches. Wow—

this was not good!

At this point, though, I found it hard to believe that all 24 ports would

suddenly go bad, but it’s possible, so I asked if he had a spare card to

try. He told me that he had already put in the new card but the same

thing was still happening. Well, it’s not the card, or the ports, but

maybe something happened with the other switches. I knew there

were a lot of switches involved, so someone must have screwed

something up to make this catastrophe happen! Or, maybe the fiber

distribution closet went down somehow? If so, how? Was there a fire

in the closet or something? Some serious internal shenanigans would

be the only answer if that were the cause!

So remaining ever patient (because, to quote Dr. House, “Patients

lie”), I again had to ask the admin exactly what he did, and sure

enough, he finally admitted that he tried to plug his personal laptop

into the core switch so he could watch the Super Bowl, and he quickly

added, “…but that’s it, I didn’t do anything else!” I’ll skip over the fact

that this guy was about to have the ugliest Monday ever, but

something still didn’t make sense, and here’s why.

Knowing that the ports on that card would all connect to distribution

switches, I configured the ports with PortFast so they wouldn’t have

to transition through the STP process. And because I wanted to make

sure no one plugged a switch into any of those ports, I enabled BPDU

Guard on the entire line card.

But a host would not bring down those ports, so I asked him if he had

plugged in the laptop directly or used something in between. He

admitted that he had indeed used another switch because, turns out,

there were lots of people from the office who wanted to plug into the

core switch and watch the game too. Was he kidding me? The security

policy wouldn’t allow connecting from their offices, so wouldn’t you

think they’d consider the core even more off-limits? Some people!

But wait… This doesn’t explain all ports turning amber, because only

the one he plugged into should be doing that. It took me a second, but

I figured out what he did and finally got him to confess. When he

plugged the switch in, the port turned amber so he thought it went

bad. So what do think he did? Well, if at first you don’t succeed, try,

try again, and that’s just what he did—he actually kept trying ports—

all 24 of them to be exact! Now that’s what I call determined!

Sad to say, I got back to the party in time just to watch my team lose

in the last few minutes! A dark day, indeed!

EtherChannel

Know that almost all Ethernet networks today will typically have multiple

links between switches because this kind of design provides redundancy

and resiliency. On a physical design that includes multiple links between

switches, STP will do its job and put a port or ports into blocking mode.

In addition to that, routing protocols like OSPF and EIGRP could see all

these redundant links as individual ones, depending on the configuration,

which can mean an increase in routing overhead.

We can gain the benefits from multiple links between switches by using

port channeling. EtherChannel is a port channel technology that was

originally developed by Cisco as a switch-to-switch technique for

grouping several Fast Ethernet or Gigabit Ethernet ports into one logical

channel.

Also important to note is that once your port channel (EtherChannel) is

up and working, layer 2 STP and layer 3 routing protocols will treat those

bundled links as a single one, which would stop STP from performing

blocking. An additional nice result is that because the routing protocols

now only see this as a single link, a single adjacency across the link can be

formed—elegant!

Figure 15.20

shows how a network would look if we had four connections

between switches, before and after configuring port channels.

FIGURE 15.20

Before and after port channels

Now as usual, there’s the Cisco version and the IEEE version of port

channel negotiation protocols to choose from—take your pick. Cisco’s

version is called Port Aggregation Protocol (PAgP), and the IEEE 802.3ad

standard is called Link Aggregation Control Protocol (LACP). Both

versions work equally well, but the way you configure each is slightly

different. Keep in mind that both PAgP and LACP are negotiation

protocols and that EtherChannel can actually be statically configured

without PAgP or LACP. Still, it’s better to use one of these protocols to

help with compatibility issues as well as to manage link additions and

failures between two switches.

Cisco EtherChannel allows us to bundle up to eight ports active between

switches. The links must have the same speed, duplex setting, and VLAN

configuration—in other words, you can’t mix interface types and

configurations into the same bundle.

There are a few differences in configuring PAgP and LACP, but first, let’s

go over some terms so you don’t get confused:

Port channeling Refers to combining two to eight Fast Ethernet or two

Gigabit Ethernet ports together between two switches into one

aggregated logical link to achieve more bandwidth and resiliency.

EtherChannel Cisco’s proprietary term for port channeling.

PAgP This is a Cisco proprietary port channel negotiation protocol that

aids in the automatic creation for EtherChannel links. All links in the

bundle must match the same parameters (speed, duplex, VLAN info), and

when PAgP identifies matched links, it groups the links into an

EtherChannel. This is then added to STP as a single bridge port. At this

point, PAgP’s job is to send packets every 30 seconds to manage the link

for consistency, any link additions, and failures.

LACP (802.3ad) This has the exact same purpose as PAgP, but it’s

nonproprietary so it can work between multi-vendor networks.

channel-group

This is a command on Ethernet interfaces used to add the

specified interface to a single EtherChannel. The number following this

command is the port channel ID.

interface port-channel

Here’s a command that creates the bundled

interface. Ports can be added to this interface with the

channel-group

command. Keep in mind that the interface number must match the group

number.

Now let’s see if you can make some sense out of all these terms by

actually configuring something!

Configuring and Verifying Port Channels

Let’s use

Figure 15.21

for our simple example of how to configure port

channels.

FIGURE 15.21

EtherChannel example

You can enable your

channel-group

for each channel by setting the

channel mode for each interface to either

active

or

passive

if using

LACP. When a port is configured in

passive

mode, it will respond to the

LACP packets it receives, but it won’t initiate an LACP negotiation. When

a port is configured for

active

mode, the port initiates negotiations with

other ports by sending LACP packets.

Let me show you a simple example of configuring port channels and then

verifying them. First I’ll go to global configuration mode and create a port

channel interface, and then I’ll add this port channel to the physical

interfaces.

Remember, all parameters and configurations of the ports must be the

same, so I’ll start by trunking the interfaces before I configure

EtherChannel, like this:

S1(config)#

int range g0/1 - 2

S1(config-if-range)#

switchport trunk encapsulation dot1q

S1(config-if-range)#

switchport mode trunk

All ports in your bundles must be configured the same, so I’ll configure

both sides with the same trunking configuration. Now I can assign these

ports to a bundle:

S1(config-if-range)#

channel-group 1 mode ?

active Enable LACP unconditionally

auto Enable PAgP only if a PAgP device is detected

desirable Enable PAgP unconditionally

on Enable Etherchannel only

passive Enable LACP only if a LACP device is detected

S1(config-if-range)#

channel-group 1 mode active

S1(config-if-range)#

exit

To configure the IEEE nonproprietary LACP, I’ll use the

active

or

passive

command; if I wanted to use Cisco’s PAgP, I’d use the

auto

or

desirable

command. You can’t mix and match these on either end of the

bundle, and really, it doesn’t matter which one you use in a pure Cisco

environment, as long as you configure them the same on both ends

(setting the mode to

on

would be statically configuring your EtherChannel

bundle).

At this point in the configuration, I’d have to set the mode to

active

on

the S2 interfaces if I wanted the bundle to come up with LACP because,

again, all parameters must be the same on both ends of the link. Let’s

configure our port channel interface, which was created when we used

the channel-group command:

S1(config)#

int port-channel 1

S1(config-if)#

switchport trunk encapsulation dot1q

S1(config-if)#

switchport mode trunk

S1(config-if)#

switchport trunk allowed vlan 1,2,3

Notice that I set the same trunking method under the port channel

interface as I did the physical interfaces, as well as VLAN information

too. Nicely, all command performed under the port-channel are inherited

at the interface level, so you can just easily configure the port-channel

with all parameters.

Time to configure the interfaces, channel groups, and port channel

interface on the S2 switch:

S2(config)#

int range g0/13 - 14

S2(config-if-range)#

switchport trunk encapsulation dot1q

S2(config-if-range)#

switchport mode trunk

S2(config-if-range)#

channel-group 1 mode active

S2(config-if-range)#

exit

S2(config)#

int port-channel 1

S2(config-if)#

switchport trunk encapsulation dot1q

S2(config-if)#

switchport mode trunk

S2(config-if)#

switchport trunk allowed vlan 1,2,3

On each switch, I configured the ports I wanted to bundle with the same

configuration, then created the port channel. After that, I added the ports

into the port channel with the

channel-group

command.

Remember, for LACP we’ll use either active/active on each side of the

bundle or active/passive, but you can’t use passive/passive. Same goes for

PAgP; you can use desirable/desirable or auto/desirable but not

auto/auto.

Let’s verify our EtherChannel with a few commands. We’ll start with the

show etherchannel port-channel

command to see information about a

specific port channel interface:

S2#

sh etherchannel port-channel

Channel-group listing:

----------------------

Group: 1

----------

Port-channels in the group:

---------------------------

Port-channel: Po1 (Primary Aggregator)

------------

Age of the Port-channel = 00d:00h:46m:49s

Logical slot/port = 2/1 Number of ports = 2

GC = 0x00000000 HotStandBy port = null

Port state = Port-channel

Protocol = LACP

Port Security = Disabled

Ports in the Port-channel:

Index

Load Port EC state No of bits

------+------+------+------------------+-----------

0 00 Gig0/2 Active 0

0 00 Gig0/1 Active 0

Time since last port bundled: 00d:00h:46m:47s Gig0/1

S2#

Notice that we have one group and that we’re running the IEEE LACP

version of port channeling. We’re in

Active

mode, and that

Port-channel:

Po1

interface has two physical interfaces. The heading

Load

is not the load

over the interfaces, it’s a hexadecimal value that decides which interface

will be chosen to specify the flow of traffic.

The

show etherchannel summary

command displays one line of

information per port channel:

S2#

sh etherchannel summary

Flags: D - down P - in port-channel

I - stand-alone s - suspended

H - Hot-standby (LACP only)

R - Layer3 S - Layer2

U - in use f - failed to allocate aggregator

u - unsuitable for bundling

w - waiting to be aggregated

d - default port

Number of channel-groups in use: 1

Number of aggregators: 1

Group Port-channel Protocol Ports

------+-------------+-----------+----------------------------------

------------

1 Po1(SU) LACP Gig0/1(P) Gig0/2(P)

This command shows that we have one group, that we’re running LACP,

and Gig0/1 and Gig0/2 or (P), which means these ports are

in port-

channel

mode. This command isn’t really all that helpful unless you have

multiple channel groups, but it does tell us our group is working well!

Layer 3 EtherChannel

One last item to discuss before we finish this chapter and that is layer 3

EtherChannel. You’d use layer 3 EtherChannel when connecting a switch

to multiple ports on a router, for example. It’s important to understand

that you wouldn’t put IP addresses under the physical interfaces of the

router, instead you’d actually add the IP address of the bundle under the

logical port-channel interface.

Here is an example on how to create the logical port channel 1 and assign

20.2.2.2 as its IP address:

Router#

config t

Router(config)#

int port-channel 1

Router(config-if)#

ip address 20.2.2.2 255.255.255.0

Now we need to add the physical ports into port channel 1:

Router(config-if)#

int range g0/0-1

Router(config-if-range)#

channel-group 1

GigabitEthernet0/0 added as member-1 to port-channel1

GigabitEthernet0/1 added as member-2 to port-channel1

Now let’s take a look at the running-config. Notice there are no IP

addresses under the physical interface of the router:

!

interface Port-channel1

ip address 20.2.2.2 255.255.255.0

load-interval 30

!

interface GigabitEthernet0/0

no ip address

load-interval 30

duplex auto

speed auto

channel-group 1

!

interface GigabitEthernet0/1

no ip address

load-interval 30

duplex auto

speed auto

channel-group 1

Summary

This chapter was all about switching technologies, with a particular focus

on the Spanning Tree Protocol (STP) and its evolution to newer versions

like RSTP and then Cisco’s PVST+.

You learned about the problems that can occur if you have multiple links

between bridges (switches) and the solutions attained with STP.

I also talked about and demonstrated issues that can occur if you have

multiple links between bridges (switches), plus how to solve these

problems by using the Spanning Tree Protocol (STP).

I covered a detailed configuration of Cisco’s Catalyst switches, including

verifying the configuration, setting the Cisco STP extensions, and

changing the root bridge by setting a bridge priority.

Finally, we discussed, configured, and verified the EtherChannel

technology that helps us bundle multiple links between switches.

Exam Essentials

Understand the main purpose of the Spanning Tree Protocol in