6 Multilayer Switching

The Bryant Advantage CCNP SWITCH Study Guide
Chris Bryant, CCIE #12933 www.thebryantadvantage.com

Back To Index
Multilayer Switching & High Availability
Services And Protocols
Overview
What Is Multilayer Switching?
Route Caching
Cisco Express Forwarding
Inter-VLAN Routing
Switched Virtual Interfaces (SVIs)
Fallback Bridging
ICMP Router Discovery Protocol (IRDP)
HSRP Basics
HSRP MAC Address Changing
HSRP Changing The Active Router
HSRP Load Balancing
HSRP Interface Tracking
Virtual Router Redundancy Protocol (VRRP)
Gateway Load Balancing Protocol (GLBP)

When you're learning basic routing and switching theory in your CCNA
studies, the two processes are taught as separate operations that happen
on two separate physical devices -- switches switch at Layer 2, routers
router at Layer 3, and never the two shall meet...

... until now.
While they are separate operations, devices that can perform both routing
and switching are more and more popular today. These devices are
Layer 3 switches, or multilayer switches.

What Is Multilayer Switching?
Multilayer switches are devices that switch and route packets in the switch
hardware itself. A good phrase to describe a multilayer switch is "pure
performance" - these switches can perform packet switching up to ten
times as fast as a pure L3 router.
Server Load Balancing (SLB)
Syslog And Logging
Cisco SLA
DHCP Server Config On Cisco Routers
IP Helper-Addresses
Multilayer switches make it possible to have inter-VLAN communication
without having to use a separate L3 device or configuring router-on-a-
stick. If two hosts in separate VLANs are connected to the same
multilayer switch, the correct configuration will allow that communication
without the data ever leaving that switch.
When it comes to Cisco Catalyst switches, this hardware switching is
performed by a router processor (or L3 engine). This processor must
download routing information to the hardware itself. To make this
hardware-based packet processing happen, Cat switches will run either
the older....um, I mean "legacy" Multilayer Switching (MLS), or the newer
Cisco Express Forwarding (CEF).
Application-Specific Integrated Circuits (ASICs) will perform the L2
rewriting operation of these packets. You know from your CCNA studies
that while the IP source and destination address of a packet will not
change during its travels through the network, the L2 source and
addresses may and probably will. With multilayer switching, it's the ASICs
that perform this L2 address overwriting.
The CAM And TCAM Tables
You learned early in your CCNA studies that we really like having more
than one name for something in networking - and that's particularly true of
the MAC address table, which is also known as the bridging table, the
switching table, and the Content Addressable Memory table - the CAM
table.
Multilayer switches still have a CAM table and it operates just as an L2
switch's CAM table does - but we have a lot more going on with our L3
switches, including routing, ACLs, and QoS.
A simple CAM table can't handle all of this, so in addition to the CAM table
we have a TCAM table - Ternary Content Addressable Memory.
Basically, the TCAM table stores everything the CAM table can't, including
info about ACLs and QoS.
Multilayer Switching Methods
The first multilayer switching (MLS) method is route caching. Route
caching devices have both a routing processor and a switching engine.
The routing processor routes a flow's first packet, the switching engine
snoops in on that packet and the destination, and the switching engine
takes over and forwards the rest of the packets in that flow.
Now, what exactly does a "flow" consist of? A flow is a unidirectional
stream of packets from a source to a destination, and packets on the
same flow will share the same protocol. That is, if a source is sending
both WWW and TFTP packets to the same destination, there are actually
two flows of traffic. The MLS cache entries support such unidirectional
flows.
Route Caching can be effective, but there's one slight drawback - the
first packet in any flow will be switched by software. Even though all other
packets in the flow will be hardware-switched, it is more effective for us to
have all of the packets switched by hardware - and that's what we get with
CEF.
Cisco Express Forwarding (CEF) is a highly popular method of multilayer
switching. Primarily designed for backbone switches, this topology-based
switching method requires special hardware, so it's not available on all L3
switches.
CEF can't be configured on 2950 switches, but you will see it on 3550s
and several other higher-numbered series. CEF is highly scalable, and is
also easier on a switch's CPU than route caching.
CEF has two major components - the Forwarding Information Base and
the Adjacency Table.
CEF-enabled devices the same routing information that a router would, but
it's not found in a typical routing table. CEF-enabled switches keep a
Forwarding Information Base (FIB) that contains the usual routing
information - the destination networks, their masks, the next-hop IP
addresses, etc - and CEF will use the FIB to make L3 prefix-based
decisions.
The FIB's contents will mirror that of the IP routing table - actually, the FIB
is really just the IP routing table in another format. You can view the FIB
with the show ip cef command.
SW2#show ip cef
Prefix Next Hop Interface
0.0.0.0/32 receive
224.0.0.0/4 drop
224.0.0.0/24 receive
255.255.255.255/32 receive
Not exactly the routing table we've come to know and love! However,
running CEF doesn't prevent us from configuring access-lists, QoS, or
other "regular" traffic filtering features that routers use every day.
The routing information in the FIB is updated dynamically as change
notifications are received from the L3 engine. Since the FIB is
prepopulated with the information from the routing table, the MLS can find
the routing information quickly.
Should the TCAM hit capacity, there's a wildcard entry that will redirect
traffic to the routing engine.
The FIB takes care of the L3 routing information, but what of the L2
information we need? That's found in the Adjacency Table (AT). As
adjacent hosts are discovered via ARP, that next-hop L2 information is
kept in this table for CEF switching. (A host is considered adjacent from
another if they're just one hop apart.)
Like the TCAM, if the AT hits capacity, there is a wildcard entry pointing to
the L3 engine.
To sum it up:
The FIB contains L3 information and is created via the IP routing
table.
The AT contains L2 information and is created via the ARP table.
There are some special cases when it comes to adjacencies:
Remember the Null0 route created by route summarization?
Basically, it's a route to nowhere. A null adjacency is said to be
formed for these packets, and they're dropped.
If we have packets that need some attention from the L3 engine
rather than being switched in hardware (or if they can't be switched
by hardware for some reason), that's a punt adjacency.
Ingress packets are dropped via a drop adjacency or a discard
adjacency.
Once the appropriate L3 and L2 next-hop addresses have been found, the
MLS is just about ready to forward the packet. The MLS will make the
same changes to the packet as a router normally would, and that includes
changing the L2 destination MAC address - that's going to be changed to
the next-hop destination, as I'm sure you remember from your CCNA
studies. The L3 destination will remain the same.
(The L2 source address will change as well, to the MAC address on the
MLS switch interface that transmits the packet.)
Enabling CEF is about as simple as it gets. CEF is on by default on any
and all CEF-enabled switches, and you can't turn it off. Remember, CEF
is hardware-based, not software-based, so it's not a situation where
running "no cef" on a switch will disable CEF. There's no such command!
A multilayer switch must have IP routing enabled for CEF to run,
however. Trying to view the FIB of a switch with IP routing not enabled
results in this console readout...
SW2#show ip cef
%IPv4 CEF not running
... and then after enabling IP routing.
SW2(config)#ip routing

SW2#show ip cef
Prefix Next Hop Interface
0.0.0.0/32 receive
224.0.0.0/4 drop
224.0.0.0/24 receive
255.255.255.255/32 receive
As with several advanced L3 switching capabilities, not every L3 switch
can run CEF. For instance, the 2900XL and 3500XL do not support CEF.
Keep in mind that switches that do support CEF do so by default, and
CEF can't be turned off on those switches!
CEF does support per-packet and per-destination load balancing, but the
capabilities differ between Cisco switch models. The default CEF load
balancing mode is per-destination, where packets for any particular
destination will take the same path from start to finish, even if other valid
paths are available.
The Control Plane And The Data Plane
These are both logical planes found in CEF multilayer switching, and I
know you won't be surprised to find they are also referred to by several
different names.
These all refer to the control plane:
"CEF control plane"
"control plane"
"Layer 3 engine" or "Layer 3 forwarding engine"
The control plane's job is to first build the ARP and IP routing tables, from
which the AT and FIB will be derived, respectively.
In turn, the data plane is also called by several different names:
"data plane"
"hardware engine"
"ASIC"
The control plane builds the tables necessary for L3 switching, but it's the
data plane that does the actual work! It's the data plane that places data
in the L3 switch's memory while the FIB and AT tables are consulted, and
then performs any necessary encapsulation before forwarding the data to
the next hop.
Exceptions To The Rule (Of L3 Switching, That Is)
Exception packets are packets that cannot be hardware switched, which
leaves us only one option - software switching! Comparing hardware
switching to software switching is much like comparing the hare to the
tortoise - but these tortoises are not going to win a race. Here are just a
few of the packet types that must be software switched:
Packets with IP header options
Packets that will be fragmented before transmission (because they're
exceeding the MTU)
NAT packets
Packets that came to the MLS with an invalid encap type
Note that packets with TCP header options are still switched in hardware;
it's the IP header options that cause trouble!
Is "Fast Switching" Really That Fast?
With so many switching options available today, it's hard to keep up with
which option is fastest, then next-fastest, and so on. According to Cisco's
website, here's the order;
1. Distributed CEF (DCEF). The name is the recipe - the CEF
workload is distributed over multiple CPUs.
2. CEF
3. Fast Switching
4. Process Switching (sometimes jokingly referred to as "slow
switching" - it's quite an involved process and is a real CPU hog)

Inter-VLAN Routing
Now that we have the (important) nuts and bolts out of the way, let's
configure an L3 switch!
Multilayer switches allow us to create a logical interface, the Switched
Virtual Interface (SVI), that represents the VLAN. Remember that the L2
switches you've worked with have an "interface VLAN1" by default?
interface Vlan1
no ip address
no ip route-cache
shutdown
That's actually a switched virtual interface (SVI). An SVI exists for VLAN 1
by default, but that's the only VLAN that has a "pre-created" SVI. As you
recall from your CCNA studies, this VLAN 1 SVI is for remote switch
administration.
On an MLS, such a logical interface can be configured for any VLAN, and
you configure it just as you would any other logical interface, such as a
loopback interface - just go into config mode, create the interface and
assign it an IP address, and you're on your way.

MLS(config)#interface vlan 10
MLS(config-if)#ip address 10.1.1.1 255.255.255.0
Let's put SVIs to work with a basic interVLAN routing configuration.

To allow these two hosts to communicate, you know that we've got to
have an L3 device - and now we have a different kind of L3 device than
you've used before. This L3 switch will allow interVLAN communication
without involving a router.
Before we begin configuring, we'll send pings between the two hosts. (In
this example, I'm using routers for hosts, but there are no routes of any
kind on them.)
HOST_1#ping 30.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 30.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
.....
As expected, neither host can ping the other. Let's fix that!
To get started, we'll put the port leading to Host 1 into VLAN 11, and the
port leading to Host 3 in VLAN 33.
SW1(config)#int fast 0/1
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 11

SW1(config-if)#int fast 0/3
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 33
We're going to create two SVIs on the switch, one representing VLAN 11
and the other representing VLAN 33. Note that both SVIs show as up/up
immediately after creation. Some Cisco and non-Cisco documentation
mentions that you should open the SVIs after creating them, but that's not
necessarily the case in the real world. Couldn't hurt, though. :)
SW1(config)#int vlan11
01:30:04: %LINK-3-UPDOWN: Interface Vlan11, changed state to up
01:30:05: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan11, changed
state to up
SW1(config-if)#ip address 20.1.1.11 255.255.255.0

SW1(config-if)#int vlan33
01:30:11: %LINK-3-UPDOWN: Interface Vlan33, changed state to up
01:30:12: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan33, changed
state to up
Only one VLAN per SVI, please.
If you don't see "up" for the interface itself and/or the line protocol, you
likely haven't created the VLAN yet or placed a port into that VLAN. Do
those two things and you should see the following result with show
interface vlan. I'll only show the top three rows of output for each SVI.
SW1#show int vlan11
Vlan11 is up, line protocol is up
Hardware is EtherSVI, address is 0012.7f02.4b41 (bia 0012.7f02.4b41)
Internet address is 20.1.1.11/24
SW1#show int vlan33
Vlan33 is up, line protocol is up
Hardware is EtherSVI, address is 0012.7f02.4b42 (bia 0012.7f02.4b42)
Now let's check that routing table...
SW1# show ip route
Default gateway is not set
Host Gateway Last Use Total Uses Interface
ICMP redirect cache is empty
Hmm, that's not good. We don't have one! There's a simple reason,
though - on L3 switches, we need to enable IP routing, because it's off by
default!
Step One In L3 Switching Troubleshooting: Make Sure IP Routing Is
On!
SW1(config)#ip routing
SW1(config)#^Z

SW1#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
20.0.0.0/24 is subnetted, 1 subnets
C 20.1.1.0 is directly connected, Vlan11
C 30.1.1.0 is directly connected, Vlan33
Now that looks like the routing table we've come to know and love! In this
particular case, there's no need to configuring a routing protocol.
Why? You recall from your CCNA studies that when router-on-a-stick is
configured, the IP address assigned to the router's subinterfaces should
be the default gateway setting on the hosts.
When SVIs are in use, the default gateway set on the hosts should be the
IP address assigned to the SVI that represents that host's VLAN. After
setting this default gateway on the hosts, the hosts can now successfully
communicate.
Since we're using routers for hosts, we'll use the ip route command to set
the default gateway.
HOST_1(config)#ip route 0.0.0.0 0.0.0.0 20.1.1.11
HOST_3(config)#ip route 0.0.0.0 0.0.0.0 30.1.1.11
Can the hosts now communicate, even though they're in different VLANs?
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
!!!!!
Routed Ports
We also have the option of configuring a physical port on a multilayer
switch as a routed port. A few things to note about these ports:
You assign an IP address to a routed port in the same manner in
which you would apply one to an SVI or to a port on a Cisco router.
There are some big differences between SVIs and routed ports,
though - for one, routed ports are physical L3 switch ports, as
opposed to SVIs, which are logical.
Another difference - routed ports don't represent a particular VLAN
as does as SVI.
You configure a routed port with a routing protocol such as OSPF or
EIGRP in the exact same manner as you would on a router. That
goes for protocol-specific commands as well as interface-specific.

If we add a router to our network as shown below, that's what we'll need
to do.

For many Cisco L3 switches, the ports will all be running in L2 mode by
default. To configure a port as a routed port, use the no switchport
command, followed by the appropriate IP address. Note that in the
following configuration, the line protocol on the switch port goes down and
comes back up in just a few seconds.
SW1(config)#interface fast 0/5
SW1(config-if)#no switchport
02:19:27: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/5,
changed state to down

02:19:30: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/5,
changed state to up
We verify the IP address assignment with show int fast 0/5.
SW1#show int fast 0/5
FastEthernet0/5 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 0012.7f02.4b43 (bia 0012.7f02.4b43)
The switch can now ping 210.1.1.1, the downstream router.
SW1#ping 210.1.1.1
!!!!!
Now let's take this just one step further - what if we wanted the hosts in
the VLANs to be able to communicate with the router? They can ping
210.1.1.11, the switch's interface in that subnet, but not 210.1.1.1, the
router's interface.
HOST_1#ping 210.1.1.1
.....
The router has no path to either 20.1.1.0 /24 or 30.1.1.0/24, so there's no
way for the pings to get back to Host 1 or Host 3.
ROUTER_TO_INTERNET#show ip route
< code table removed for clarity >
C 210.1.1.0/24 is directly connected, FastEthernet0/0
To remedy that, we'll now configure a dynamic routing protocol between
the L3 switch and the router. We'll use EIGRP in this case.
SW1(config)#router eigrp 100
SW1(config-router)#no auto-summary
SW1(config-router)#network 210.1.1.0 0.0.0.255
ROUTER_TO_INTERNET(config)#router eigrp 100
ROUTER_TO_INTERNET(config-router)#no auto-summary
ROUTER_TO_INTERNET(config-router)#network 210.1.1.0 0.0.0.255
The router now has the VLAN subnets in its routing table...
ROUTER_TO_INTERNET#show ip route
< code table removed for clarity >

D 20.1.1.0 [90/28416] via 210.1.1.11, 00:01:01, FastEthernet0/0
C 210.1.1.0/24 is directly connected, FastEthernet0/0
D 30.1.1.0 [90/28416] via 210.1.1.11, 00:01:01, FastEthernet0/0
... and the hosts now have two-way IP connectivity with the router's
210.1.1.1 interface.
HOST_1#ping 210.1.1.1
!!!!!
HOST_3#ping 210.1.1.1
!!!!!
It never hurts to make sure the pings can go the other way, too!
ROUTER_TO_INTERNET#ping 20.1.1.1
!!!!!

ROUTER_TO_INTERNET#ping 30.1.1.1
!!!!!
At first, the details of SVIs and routed ports might make you pine for the
good ol' days of ROAS!
Once you get a little experience and study in, though, you'll find that SVIs
and routed ports really are much more effective ways of getting the job
done on your network - and on your exam!
Here's a quick SVI checklist:
Create the VLAN before the SVI. The VLAN must be active when the SVI
is created - that VLAN will not be dynamically created at that time.
Theoretically, you need to open the SVI with no shutdown just as you
would open a physical interface after configuring an IP address
The SVI and VLAN have an association, but they're not the same thing,
and yes, I know you know that by now. Just a friendly reminder - creating
one does not dynamically create the other.
The IP address assigned to the SVI should be the default gateway
address configured on the VLAN's hosts.
The only SVI on the switch by default is the SVI for VLAN 1, intended to
allow remote switch administration and configuration. (Having to drive in
at 3 AM because there's no IP address on this interface really stinks.)
SVIs are a great way to allow interVLAN communication, but you must
have a routing protocol configured in addition to the SVIs. (Tshooting
note - if this inter-VLAN communication fails, check your SVI addresses
and make sure you have IP routing enabled on the switch. More SVI
tshooting notes later in this section.)
You need to create the VLAN before the SVI, and that VLAN must be
active at the time of SVI creation
Theoretically, you need to open the SVI with no shut just as you
would open a physical interface after configuring an IP address
Remember that the VLAN and SVI work together, but they're not the
same thing. Creating a VLAN doesn't create an SVI, and creating an
SVI doesn't create a VLAN.
Fallback Bridging
Odds are that you'll never need to configure fallback bridging, but it falls
under the category of "it couldn't hurt to know it". CEF has a limitation in
that IPX, SNA, LAT, and AppleTalk are either not supported by CEF or, in
the case of SNA and LAT, are nonroutable protocols. If you're running
any of these on an CEF-enabled switch, you'll need fallback bridging to
get this traffic from one VLAN to another.
Fallback bridging involves the creation of bridge groups, and the SVIs will
have to be added to these bridge groups.
To create a bridge group:
MLS(config)# bridge-group 1
To join a SVI to a bridge group:
MLS(config)#interface vlan 10
MLS(config-if)#bridge-group 1
Router-On-A-Stick vs. Switched Virtual Interfaces
Those of you who earned your CCNA working with me know that I love
configuring router-on-a-stick, and that they're also quite effective and quite
stable.
So what's the big deal about SVIs?
As much as I like 'em, ROAS configs do have a few drawbacks:
Not the most intuitive config in the world. I know that when you look
at a completed ROAS config, you'll wonder how you could make a
mistake with it - but I'll put it this way: In my CCNA ROAS material,
the troubleshooting section is larger than the configuration section.
We're sending a lot of traffic up and down a single trunk line from the
L2 switch to the router.
And the phrase "single trunk line" brings to mind another phrase that
we really hate - "single point of failure". If the port on either side of
the trunk goes out, or the cable itself goes down, we're SOL (Sure
Outof Luck).
Those drawbacks lead us to SVIs, which have advantages that neatly
map to ROAS's deficiencies:
No single point of failure
Faster than ROAS
Don't need to configure a trunk between the L2 switch and the router
Generally speaking, if you have an L3 switch, you're much better off using
SVIs for inter-VLAN communication rather than ROAS.
SVI "Up And Up" Checklist
We saw each of these in action during the lab, and I want you to have a
quick t-shooting list for your SVIs... so if you don't see your SVI interface
and line protocol up, check these points first:
Make sure you created the VLAN that the SVI represents. You know
how the switch creates a VLAN dynamically if you try to put a port
into a VLAN that doesn't exist yet? Well, the switch isn't doing this
for you. Creating an SVI for VLAN 11 does not dynamically create
VLAN 11 itself.
A valid port must be placed into the VLAN we just talked about - and
by "valid", I mean the port is physically up and has been placed into
forwarding mode by STP for that same VLAN.
Be sure you created the SVI you meant to create. Everybody
mistypes a number once in a while... say, "vlan 12" when you meant
"vlan 11".

Routed Port Checklist
On the L3 switch itself, be sure to enable ip routing.
On the port, be sure you've run the no switchport command as well
as applying an IP address and any protocol-specific commands you
need for your particular config (the OSPF commands neighbor or ip
ospf priority, for example).

An Etherchannel - SVI Similarity
We're not actually bundling ports with SVIs as we do with Etherchannels,
but there is an interesting similarity between the two:
SVIs remain "up/up" as long as the ports in the VLAN it represents
are up, even if there's only one.
Etherchannels remain "up/up" as long as the ports in the Portchannel
are up, even if there's only one. (The available bandwidth goes
down, though. And yes, I knew you know that.)
So what?
So this: If you have a port in a VLAN that's not actually handling data, but
is doing something else - like serving as a SPAN destination port
connected to a network monitor, for example - the SVI would stay up even
if all of the other ports in the VLAN went down, since this SPAN
destination port would stay up.
Having an SVI stay up in that situation isn't good - we can end up having a
black hole in our routing process. Here's Wikipedia's definition of a black
hole in space:
"According to the general theory of relativity, a black hole is a region
of space from which nothing, not even light, can escape. It is the
result of the deformation of spacetime caused by a very compact
mass."
A black hole in routing is the result of an SVI remaining up when there are
actually no "up/up" interfaces in that VLAN except for those connected to
network monitors or similar devices.
To avoid this, we can exclude such ports from the "up/up" calculation with
the switchport autostate exclude command. Using that interface-level
command on ports like the one previous described will exclude (get it?)
that port from the "up/up" determination.

Router Redundancy Techniques
In networking, we'll take as much redundancy as we can get. If a router
goes down, we've obviously got real problems. Hosts are relying on that
router as a gateway to send packets to remote networks. For true
network redundancy, we need two things:
A secondary router to handle the load when the primary goes down
A protocol to get the networks using that secondary router as quickly
as possible
Time is definitely of the essence here, in more ways than one - we need a
protocol to quickly detect the fact that the primary router's down in the first
place, and then we need a fast cutover to the secondary router.
Now you may be thinking, "Why is Chris talking about router redundancy
in a switching course?"
With the popularity of L3 switches, you'll often be configuring these
protocols on multilayer switches - so often that Cisco now tests your
knowledge of these protocols on the CCNP Switch exam rather than
Route.
Running router redundancy protocols on your multilayer switches actually
makes the cutover to a backup device a little faster than configuring them
on routers, since our end users are generally attached to the L3 switches
themselves, making this truly first-hop redundancy (or "1-hop redundancy"
in some documentation).
With the importance of these protocols in today's networks, we better be
ready for exam questions and real-world situations.
We have several different methods that allow us to achieve the goal of
redundancy, and a very popular choice is HSRP - the Hot Standby
Routing Protocol.
Please note: In the following section, I'm going to refer to routers rather
than L3 switches, since the HSRP terminology itself refers to "Active
routers", "Standby routers", and so forth. The commands and theory for
all of the following protocols will be the same on a multilayer switch as
they are on a router.
Hot Standby Routing Protocol
Defined in RFC 2281, HSRP is a Cisco-proprietary protocol in which
routers are put into an HSRP router group. Along with dynamic routing
protocols and STP, HSRP is considered a high-availability network
service, since all three have an almost immediate cutover to a secondary
path when the primary path is unavailable.
One of the routers in the HSRP router group will be selected as the Active
Router, and that router will handle the routing while the other routers are in
standby, ready to handle the load if the primary router becomes
unavailable.
In this fashion, HSRP ensures a high network uptime, since it routes IP
traffic without relying on a single router.
The terms "active" and "standby" do not refer to the actual operational
status of the routers - just to their status in the HSRP group.
The hosts using HSRP as a gateway don't know the actual IP or MAC
addresses of the routers in the group. They're communicating with a
pseudorouter, a "virtual router" created by the HSRP configuration. This
virtual router will have a virtual MAC and IP address as well, just like a
physical router.
The standby routers aren't just going to be sitting there, though! By
configuring multiple HSRP groups on a single interface, HSRP load
balancing can be achieved.
Before we get to the more advanced HSRP configuration, we better get a
basic one started! We'll be using a two-router topology here, and keep in
mind that one or both of these routers could be multilayer switches as
well. For ease of reading, I'm going to refer to them only as routers.

R2 and R3 will both be configured to be in standby group 5. The virtual
router will have an IP address of 172.12.23.10 /24. All hosts in VLAN 100
should use this address as their default gateway.
R2(config)#interface ethernet0
R2(config-if)#standby 5 ip 172.12.23.10
The show command for HSRP is show standby, and it's the first command
you should run while verifying and troubleshooting HSRP. Let's run it on
both routers and compare results.
R2#show standby
Ethernet0 - Group 5
Local state is Standby, priority 100
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 0.776
Virtual IP address is 172.12.23.10 configured
Active router is 172.12.23.3, priority 100 expires in 9.568
Standby router is local
1 state changes, last state change 00:00:22
R3#show standby
Ethernet0 - Group 5
Local state is Active, priority 100
Active router is local
Standby router is 172.12.23.2 expires in 8.020
Virtual mac address is 0000.0c07.ac05
R3 is in Active state, while R2 is in Standby. The hosts are using the
172.12.123.10 address as their gateway, but R3 is actually handling the
workload. R2 will take over if R3 becomes unavailable.
An IP address was assigned to the virtual router, but not a MAC address.
However, there is a MAC address under the show standby output on R3,
the active router. How did the HSRP process arrive at a MAC of 00-00-
0c-07-ac-05?
Well, most of the work is already done before the configuration is even
begun. The MAC address 00-00-0c-07-ac-xx is HSRP's well-known
virtual MAC address, and xx is the group number in hexadecimal. That's
a good skill to have for the exam, so make sure you're comfortable with
hex conversions.
In this example, the group number is 5, which is expressed as 05 with a
two-bit hex character. If the group number had been 17, we'd see 11 at
the end of the MAC address - one unit of 16, one unit of 1.
The output of the show standby command also tells us that the HSRP
speakers are sending Hellos every 3 seconds, with a 10-second holdtime.
These values can be changed with the standby command, but HSRP
speakers in the same group should have the same timers. You can even
tie down the hello time to the millisecond, but it's doubtful you'll ever need
to do that.
R3(config-if)#standby 5 timers ?
<1-254> Hello interval in seconds
msec Specify hello interval in milliseconds
R3(config-if)#standby 5 timers 4 ?
<5-255> Hold time in seconds
R3(config-if)#standby 5 timers 4 12
A key value in the show standby command is the priority. The default is
100, as shown in both of the above show standby outputs. The router
with the highest priority will be the primary HSRP router, the Active
Router.
The router with the highest IP address on an HSRP-enabled
interface becomes the Active Router if there is a tie on priority.
We'll raise the default priority on R2 and see the results.
R2(config-if)#standby 5 priority 150

R2#show standby
Ethernet0 - Group 5
Local state is Standby, priority 150
R2 now has a higher priority, but R3 is still the Active Router. R2 will not
take over as the HSRP primary until R3 goes down - OR the preempt
option is configured on R2 with the standby command. In effect, the
preempt option resets the HSRP process for that group.
R2(config-if)#standby 5 priority 150 preempt

1d11h: %STANDBY-6-STATECHANGE: Ethernet0 Group 5 state Standby -> Active

R2#show standby
Ethernet0 - Group 5
Local state is Active, priority 150, may preempt
In just a few seconds, a message appears that the local state has
changed from standby to active. Show standby confirms that R2, the
local router, is now the Active Router - the primary. R3 is now the
standby. So if anyone tells you that you have to take a router down to
change the Active router, they're wrong - you just have to use the preempt
option on the standby priority command.
What you do not have to do is configure the preempt command if you
want the standby to take over as the Active Router if the current Active
Router goes down. That's the default behavior of HSRP. The preempt
command is strictly intended to allow a router to take over as the active
router without the current active router going down.
On rare occasions, you may have to change the MAC address assigned
to the virtual router. This is done with the standby mac-address
command. Just make sure you're not duplicating a MAC address that's
already on your network!
R2(config-if)#standby 5 mac-address 0000.1111.2222

1d12h: %STANDBY-6-STATECHANGE: Ethernet0 Group 5 state Active -> Learn

R2#show standby
Ethernet0 - Group 5
Virtual mac address is 0000.1111.2222 configured

1d12h: %STANDBY-6-STATECHANGE: Ethernet0 Group 5 state Listen -> Active
The MAC address will take a few seconds to change, and the HSRP
routers will go into Learn state for that time period.
A real-world HSRP troubleshooting note: If you see constant state
changes with your HSRP configuration, do what you should always do
when troubleshooting - check the physical layer first.
We can do some load balancing with HSRP, but it's not quite the load
balancing you've learned about with some dynamic protocols. Let's say
we have six hosts and two separate HSRP devices. For HSRP load
balancing, there will be two HSRP groups created for the one VLAN.
R2 will be the primary for Group 1 and R3 will be the primary for Group 2.
(In production networks, you'll need to check the documentation for your
software, because not all hardware platforms support multiple groups.)
R2 is the Active for Group 1, which has a Virtual IP address of
172.12.23.11 /24. R3 is the Active for Group 2, which has a Virtual IP
address of 172.12.23.12 /24. The key to load balancing with HSRP is to
configure half of the hosts to use .11 as their gateway, and the remaining
hosts should use .12.

This is not 50/50 load balancing, and if the hosts using .11 as their
gateway are sending much more traffic than the hosts using .12, HSRP
has no dynamic method of adapting. HSRP was really designed for
redundancy, not load balancing, but there's no use in letting the standby
router just sit there!
Some other HSRP notes:
HSRP updates can be authenticated by using the standby command
with the authentication option.
R2(config-if)#standby 5 ?
authentication Authentication
ip Enable HSRP and set the virtual IP address
mac-address Virtual MAC address
name Redundancy name string
preempt Overthrow lower priority designated routers
priority Priority level
timers Hello and hold timers
track Priority tracking
If you're configuring HSRP on a multilayer switch, you can configure
HSRP on routed ports, SVIs, and L3 Etherchannels.
HSRP requires the Enhanced Multilayer Software Image (EMI) to run
on an L3 switch. Gig Ethernet switches will have that image, but
Fast Ethernet switches will have either the EMI or Standard
Multilayer Image (SMI). Check your documentation. The SMI can
be upgraded to the EMI. (Hint: It'll cost ya.)
HSRP can run on Ethernet, Token Ring, and FDDI LANs. Some
HSRP documentation states that Token Ring interfaces can support
a maximum of three HSRP groups.
You saw several HSRP states in this example, but not all of them. Here
they are, presented in order and with a quick description.
Disabled - Some HSRP documentation lists this as a state, others do not.
I don't consider it one, but Cisco may. Disabled means that the interface
isn't running HSRP yet.
Initial (Init) -- The router goes into this state when an HSRP-enabled
interface first comes up. HSRP is not yet running on a router in Initial
state.
Learn -- At this point, the router has a lot to learn! A router in this state
has not yet heard from the active router, does not yet know which router is
the active router, and it doesn't know the IP address of that router, either.
Other than that, it's pretty bright. ;)
Listen -- The router now knows the virtual IP address, but is not the
primary or the standby router. It's listening for hello packets from those
routers.
Speak -- The router is now sending Hello messages and is active in the
election of the primary and standby routers.
Standby -- The router is now a candidate to become the active router, and
sends Hello messages.
Active -- The router is now forwarding packets sent to the group's virtual
IP address.
Note that an HSRP router doesn't send Hellos until it reaches the Speak
state. It will continue to send Hellos in the Standby and Active states as
well.
There's also no problem with configuring an interface to participate in
multiple HSRP groups on most Cisco routers. Some 2500, 3000, and
4000 routers do not have this capability. Always verify with show standby,
and note that this command indicates that there's a problem with one of
the virtual IP addresses!
R1#show standby
FastEthernet0/0 - Group 1
State is Listen
Virtual IP address is 172.12.23.10
Active virtual MAC address is unknown
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 3 sec, hold time 10 sec
Preemption disabled
Active router is unknown
Standby router is unknown
Priority 100 (default 100)
IP redundancy name is "hsrp-Fa0/0-1" (default)
State is Init (virtual IP in wrong subnet)
Virtual IP address is 172.12.34.10 (wrong subnet for this interface)
Preemption disabled

HSRP Interface Tracking
Using interface tracking can be a little tricky at first, but it's a feature that
can really come in handy. Basically, this feature enables the HSRP
process to monitor an additional interface; the status of this interface will
dynamically change the HSRP priority for a specified group.
When that interface's line protocol shows as "down", the HSRP priority of
the router is reduced. This can lead to another HSRP router on the
network becoming the active router - but that other router must be
configured with the preempt option.
In the following network, R2 is the primary due to its priority of 105. R3
has the default priority of 100. R2 will therefore be handling all the traffic
sent to the virtual router's IP address of 172.12.23.10. That's fine, but
there is a potential single point of failure.
If R2's Serial0 interface fails, the hosts will be unable to reach the server
farm. HSRP can be configured to drop R2's priority if the line protocol of
R2's Serial0 interface goes down, making R3 the primary router. (The
default decrement in the priority when the tracked interface goes down is
10.)

R2(config-if)#standby 1 track serial0
R2#show standby
Ethernet0 - Group 1
Priority tracking 1 interface, 1 up:
Interface Decrement State
Serial0 10 Up

R3#show standby
Ethernet0 - Group 1
Local state is Standby, priority 100, may preempt
The show standby output on R2 shows the tracked interface, the default
decrement of 10, and that the line protocol of the tracked interface is
currently up. We'll test the configuration by shutting the interface down
manually.
R2(config-if)#int s0
R2(config-if)#shutdown

1d14h: %STANDBY-6-STATECHANGE: Ethernet0 Group 1 state Active -> Speak

1d14h: %LINK-5-CHANGED: Interface Serial0, changed state to
administratively down

1d14h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed
state to down

R2#show standby
Ethernet0 - Group 1
Local state is Standby, priority 95 (confgd 105), may preempt
Serial0 10 Down (administratively down)
Not only does the HSRP tracking work to perfection - R2 is now the
standby and R3 the primary - but the show standby command even
shows us that the line protocol is administratively down, rather than just
"down". Running show standby on R3 verifies that R3 now sees itself as
the Active router.
R3#show standby
Ethernet0 - Group 1
We'll now reopen the Serial0 interface on R2. Since we also put the
preempt option on that router's HSRP configuration, R2 should take over
as the Active router.
R2(config)#int s0
R2(config-if)#no shut

1d14h: %STANDBY-6-STATECHANGE: Ethernet0 Group 1 state Standby -> Active

1d14h: %LINK-3-UPDOWN: Interface Serial0, changed state to up
1d14h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed
state to up

R2#show standby
Ethernet0 - Group 1
Serial0 10 Up
Just that quickly, R2 is again the Active router. If you're running HSRP
interface tracking, it's a very good idea to configure the preempt option on
all routers in the HSRP group.
The #1 problem with an HSRP Interface Tracking configuration that is not
working properly is a priority / decrement value problem.
As I mentioned earlier, the default decrement is 10, and that's fine with the
example we just worked through. If R2 had a priority of 120, the
decrement of 10 would not be enough to make R3 the Active router.
You can change the default decrement at the end of the standby interface
command. The following configuration would result in a priority value
decrement of 25 when the tracked interface goes down.
R1(config)#int ethernet0
R1(config-if)#standby 5 track s0 ?
<1-255> Decrement value
<cr>
R1(config-if)#standby 5 track s0 25
That does not change the decrement value for all interfaces - just the one
we're tracking with that particular statement, serial0. If we configure a
second interface for tracking and do not supply a decrement value, that
interface will have a decrement value of 10.
I've configured interface tracking for S1 and verified with show standby -
here's the pertinent information:
Track interface Serial0 state Down decrement 25
Track interface Serial1 state Down decrement 10
Note that this interface's priority is now 65! It's using the HSRP priority
default of 100, then has 25 decremented from that because serial0 is
down, and then another 10 decremented because serial1 is down.

Troubleshooting HSRP
We've discussed several troubleshooting steps throughout the HSRP
section, but the show standby command can indicate other HSRP issues
as well. I've deliberately misconfigured HSRP on this router to illustrate a
few.
R1#show standby
State is Active
Virtual IP address is 172.12.23.10
Active virtual MAC address is 0000.0c07.ac01
Next hello sent in 2.872 secs
Preemption disabled
State is Init (virtual IP in wrong subnet)
Virtual IP address is 172.12.34.10 (wrong subnet for this interface)
Preemption disabled
Track interface Serial0/0 state Down decrement 25
We've got all sorts of problems here! In the Group 5 readout, we see a
message that the subnet is incorrect; naturally, both the active and
standby routers are going to be unknown.
In the Group 1 readout, the Active router is local but the Standby is
unknown. This is most likely a misconfiguration on our part as well, but
along with checking the HSRP config, always remember -
"Troubleshooting starts at the Physical layer!"
One Physical layer issue with HSRP I've run into in both practice labs and
production networks is an unusual number of state transitions. You can
spot this and most other HSRP issues with debug standby.
R1#debug standby

*Apr 9 20:15:10.542: HSRP: Fa0/0 API MAC address update
*Apr 9 20:15:10.546: HSRP: Fa0/0 API Software interface coming up
*Apr 9 20:15:10.550: HSRP: Fa0/0 API Add active HSRP addresses to ARP
table
table
R1#
*Apr 9 20:15:11.648: %SYS-5-CONFIG_I: Configured from console by console
*Apr 9 20:15:12.541: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed
state to up
R1#
*Apr 9 20:15:12.541: HSRP: API Hardware state change
*Apr 9 20:15:12.541: HSRP: Fa0/0 API Software interface coming up
table
*Apr 9 20:15:13.483: HSRP: Fa0/0 Interface up
*Apr 9 20:15:13.483: HSRP: Fa0/0 Starting minimum interface delay (1
secs)
*Apr 9 20:15:13.543: %LINEPROTO-5-UPDOWN: Line protocol on Interface
FastEthernet0/0, changed state to up
R1#
*Apr 9 20:15:14.485: HSRP: Fa0/0 Interface min delay expired
*Apr 9 20:15:14.485: HSRP: Fa0/0 Grp 1 Init: a/HSRP enabled
*Apr 9 20:15:14.485: HSRP: Fa0/0 Grp 1 Init -> Listen
*Apr 9 20:15:14.485: HSRP: Fa0/0 Grp 1 Redundancy "hsrp-Fa0/0-1" state
Init ->Backup
This is an extremely verbose command, and a very helpful one. If you
have the opportunity to run HSRP in a lab environment, run this one often
during your configuration to see the different states and values being
passed around the network. (Never practice debugs at work or in any
production environment.)
If you see HSRP states regularly transitioning, particularly between Speak
and Standby, check your cabling - you'd be surprised how often that
happens, especially in labs.
Frankly, most HSRP issues you run into fall into these categories:
The secondary router didn't become the Active router when it should
have.
The former Active router didn't take back over when it came back
online.
If either of those happens to you, check these values:
Is the preempt command properly configured? (I put this first in the
list for a reason.)
What are the priority values of each HSRP speaker?
Watch your decrement values with HSRP interface tracking. Don't
get cute with these. If you're having a problem with interface tracking
and you see decrements that don't end in 0 or 5, I can practically
guarantee they're misconfigured.
(I don't know exactly why, but this happens fairly often, especially in
lab environments when you get tired of using decrements that don't
end in 5 or 0.)
Whew! That's a lot of detail - and only one of our redundancy choices.
Great news, though - many of the HSRP concepts you're currently
mastering are the same or similar to what we're doing with VRRP - the
Virtual Router Redundancy Protocol.

Virtual Router Redundancy Protocol
Defined in RFC 2338, VRRP is the open-standard equivalent of the Cisco-
proprietary HSRP. VRRP works very much like HSRP, and is suited to a
multivendor environment. The operation of the two is so similar that you
basically learned VRRP while going through the HSRP section! There
are some differences, a few of which are:
VRRP's equivalent to HSRP's Active router is the Master router.
(Some VRRP documentation refers to this router as the IP Address
Owner.) This is the router that has the virtual router's IP address as
a real IP address on the interface it will receive packets on.
The physical routers in a VRRP Group combine to form a Virtual
Router. Note that the VRRP Virtual Router uses an IP
address already configured on a router in its group, as opposed to
how the HSRP router is assigned a separate IP address.
VRRP Advertisements are multicast to 224.0.0.18.
VRRP's equivalent to HSRP's Standby router state is the Backup
state.
The MAC address of VRRP virtual routers is 00-00-5e-00-01-xx, and
you guessed it - the xx is the group number in hexadecimal.
"preempt" is a default setting for VRRP routers.
As of IOS Version 12.3(2)T, VRRP now has an Object Tracking
feature. Similar to HSRP's Interface Tracking feature, a WAN
interface can be tracked and a router's VRRP priority dropped when
that interface goes down.
Gateway Load Balancing Protocol (GLBP)
HSRP and its open-standard relation VRRP have some great features,
but accurate load balancing is not among them. While both allow a form
of load sharing, it's not truly load balancing. The primary purpose of
the Gateway Load Balancing Protocol (GLPB) is just that - load
balancing! It's also suitable for use only on Cisco routers, because GLBP
is Cisco-proprietary.
As with HSRP and VRRP, GLBP routers will be placed into a router
group. However, GLBP allows every router in the group to handle some
of the load in a round-robin format, rather than having a primary router
handle all of it while the standby routers remain idle. With GLBP, the
hosts think they're sending all of their data to a single gateway,
but actually multiple gateways are in use at one time.
That's a major benefit of GLBP over HSRP and VRRP, since the latter two
aren't really built for load balancing. They don't perform any balancing by
default, and configuring it is both an inexact science and a pain in the
behind.
GLBP also allows standard configuration of the hosts, who will all have
their gateway address set to the virtual router's address - none of this
"some hosts point to gateway A, some hosts point to gateway B" business
we had with HSRP load balancing.
The key to GLBP is that when a host sends an ARP request for the MAC
of the virtual router, one of the physical routers will answer with its own
MAC address. The host will then have the IP address of the GLBP virtual
router and the MAC address of a physical router in the group.
In the following illustrations, the three hosts send an ARP request for the
MAC of the virtual router.

The Active Virtual Gateway (AVG) will be the router with the highest
GLBP priority, and this router will send back ARP responses containing
different virtual MAC addresses.
The three hosts will have the same Layer 3 address for their gateway, but
a different L2 address, accomplishing the desired load balancing while
allowing standard configuration on the hosts. (If the routers all have the
same GLBP priority, the router with the highest IP address will become
the AVG.)
In the following illustration, R3 is the AVG and has assigned a virtual MAC
of 22-22-22-22-22-22 to R2, 33-33-33-33-33-33 to itself, and 44-44-44-44-
44-44 to R4. The routers receiving and forwarding traffic received on this
virtual MAC address are Active Virtual Forwarders (AVFs).

If the AVG fails, the router serving as the standby AVG will take over. If
any of the AVFs fails, another router will handle the load destined for a
MAC on the downed router. GLBP routers use Hellos to detect whether
other routers in their group are available or not.
GLBP groups can have up to four members.
GLBP's load balancing also offers the opportunity to fine-tune it to your
network's needs. GLBP offers three different forms of MAC address
assignment, the default being round-robin. With round-robin assignments,
a host that sends an ARP request will receive a response containing the
next virtual MAC address in line.
If a host or hosts need the same MAC gateway address every time it
sends an ARP request, host-dependent load balancing is the way to go.
Weighted MAC assignments affect the percentage of traffic that will be
sent to a given AVF. The higher the assigned weight, the more often that
particular router's virtual MAC will be sent to a requesting host.
GLBP is enabled just as VRRP and HSRP are - by assigning an IP
address to the virtual router. The following command will assign the
address 172.1.1.10 to GLBP group 5.
MLS(config-if)# glbp 5 ip 172.1.1.10
To change the interface priority, use the glbp priority command. To allow
the local router to preempt the current AVG, use the glbp preempt
command.
MLS(config-if)# glbp 5 priority 150
MLS(config-if)# glbp 5 preempt
GLBP Weighting
A router can be configured to give up its role as the AVF if its overall
weight drops below a configured value. The default weight of a GLBP
AVF is 100. The router is configured with upper and lower weight
thresholds, and should the router's weight fall below its lower threshold, it
gives up the role of AVF.
When the router's GLBP weight exceeds the higher threshold, it resumes
the role of GLBP AVF.
Before configuring the GLBP-specific commands, we configure track
statements to number and name the interfaces being tracked. IOS Help
shows us our options:
R1(config)#track ?
<1-500> Tracked object
resolution Tracking resolution parameters
timer Polling interval timers
R1(config)#track 1 ?
interface Select an interface to track
ip IP protocol
list Group objects in a list
rtr Response Time Reporter (RTR) entry
R1(config)#track 1 interface ?
Async Async interface
BVI Bridge-Group Virtual Interface
CDMA-Ix CDMA Ix interface
CTunnel CTunnel interface
Dialer Dialer interface
FastEthernet FastEthernet IEEE 802.3
Lex Lex interface
Loopback Loopback interface
MFR Multilink Frame Relay bundle interface
Multilink Multilink-group interface
Port-channel Ethernet Channel of interfaces
Serial Serial
Tunnel Tunnel interface
Vif PGM Multicast Host interface
Virtual-PPP Virtual PPP interface
Virtual-TokenRing Virtual TokenRing
XTagATM Extended Tag ATM interface
R1(config)#track 1 interface serial 0/0 ?
ip IP parameters
line-protocol Track interface line-protocol
R1(config)#track 1 interface serial 0/0 line-protocol ?
<cr>
The choices at the end, ip and line-protocol, determine what is being
tracked. The line-protocol option does just what you think it would - it
tracks the line protocol to see whether it's up or not.
The ip option is followed only by routing, as shown in the next track
statement.
R1(config)#track 2 interface serial 0/1 ip ?
routing Track interface IP routing capability
R1(config)#track 2 interface serial 0/1 ip routing ?
<cr>
R1(config)#track 2 interface serial 0/1 ip routing
After taking a look at our options with IOS Help, I'll configure a GLBP
weight of 105 on the fast 0/0 interface, a lower threshold of 90, and an
upper threshold of 100. I'll set a decrement of 10 for both tracking
statements created earlier.
R1(config)#int fast 0/0
R1(config-if)#glbp ?
<0-1023> Group number
R1(config-if)#glbp 1 ?
authentication Authentication method
forwarder Forwarder configuration
ip Enable group and set virtual IP address
load-balancing Load balancing method
name Redundancy name
preempt Overthrow lower priority designated routers
priority Priority level
timers Adjust GLBP timers
weighting Gateway weighting and tracking
R1(config-if)#glbp 1 weighting ?
<1-254> Weighting maximum value
track Interface tracking
R1(config-if)#glbp 1 weighting 105 ?
lower Weighting lower threshold
upper Weighting upper threshold
<cr>
R1(config-if)#glbp 1 weighting 105 lower 90 upper 100
R1(config-if)#glbp 1 weighting track 1 decrement 10
R1(config-if)#glbp 1 weighting track 2 decrement 10

Server Load Balancing
We've talked at length about how Cisco routers and multilayer switches
can work to provide router redundancy - but there's another helpful
service, Server Load Balancing, that does the same for servers. While
HSRP, VRRP, and CLBP all represent multiple physical routers to hosts
as a single virtual router, SLB represents multiple physical servers to
hosts as a single virtual server.
In the following illustration, three physical servers have been placed into
the SRB group ServFarm. They're represented to the hosts as the virtual
server 210.1.1.14.

The hosts will seek to communicate with the server at 210.1.1.14, not
knowing that they're actually communicating with the routers in ServFarm.
This allows quick cutover if one of the physical servers goes down, and
also serves to hide the actual IP addresses of the servers in ServFarm.
The basic operations of SLB involves creating the server farm, followed
by creating the virtual server. We'll first add 210.1.1.11 to the server farm:
MLS(config)# ip slb serverfarm ServFarm
MLS(config-slb-sfarm)# real 210.1.1.11
MLS(config-slb-real)# inservice
The first command creates the server farm, with the real command
specifying the IP address of the real server. The inservice command is
required by SLB to consider the server as ready to handle the server
farm's workload. The real and inservice commands should be repeated
for each server in the server farm.
To create the virtual server:
MLS(config)# ip slb vserver VIRTUAL_SERVER
MLS(config-slb-vserver)# serverfarm ServFarm
MLS(config-slb-vserver)# virtual 210.1.1.14
MLS(config-slb-vserver)# inservice
From the top down, the vserver was named VIRTUAL_SERVER, which
represents the server farm ServFarm. The virtual server is assigned the
IP address 210.1.1.14, and connections are allowed once the inservice
command is applied.
You may also want to control which of your network hosts can connect to
the virtual server. If hosts or subnets are named with the client command,
those will be the only clients that can connect to the virtual server. Note
that this command uses wildcard masks. The following configuration
would allow only the hosts on the subnet 210.1.1.0 /24 to connect to the
virtual server.
MLS(config-slb-vserver)# client 210.1.1.0 0.0.0.255

Network Monitoring Tools
Actively monitoring your network is another part of a high-availability
design -- and the following tools and protocols play an important role in
that monitoring.
SNMP
The Simple Network Management Protocol is used to carry network
management information between network devices, and you're going to
find it in just about any network that uses anyone's network management
tools -- particularly Cisco's.
An SNMP deployment basically consists of three parts:
A monitoring device, the SNMP Manager
The SNMP instance running on the monitored devices, officially
called the SNMP Agents
A database containing all of this info, the Management Information
Bases (MIB)
The Manager will question the Agents at a configurable interval, basically
asking if there are any problems the Manager needs to know about
("polling").

This is a proactive approach (sorry for the buzzword), but the only way to
get near-immediate notification of critical events through polling alone is to
poll the Agents quite often - and that can be a big use of bandwidth along
with increasing the hit on the managed device's CPU.
To work around those issues, we can configure SNMP managed devices
to send traps when certain events occur.

There are some serious security considerations with SNMP and the
different versions available to us.
There are three versions of SNMP; v1, v2c, and v3. Version 3 has both
authentication and encryption capabilities, where the earlier version do
not. Use version 3 whenever possible; use of the other versions should be
restricted to allowing read-only access.
How do you do that? When you configure SNMP community strings - a
kind of combination of password and authority level - you'll have the
option to configure the string as read-only or read-write.
R1(config)#snmp-server community ?
WORD SNMP community string
R1(config)#snmp-server community CCNP ?
<1-99> Std IP accesslist allowing access with this community
string
<1300-1999> Expanded IP accesslist allowing access with this community
string
WORD Access-list name
ipv6 Specify IPv6 Named Access-List
ro Read-only access with this community string
rw Read-write access with this community string
view Restrict this community to a named MIB view
<cr>
R1(config)#snmp-server community CCNP ro ?
<1-99> Std IP accesslist allowing access with this community
string
<1300-1999> Expanded IP accesslist allowing access with this community
string
WORD Access-list name
ipv6 Specify IPv6 Named Access-List
<cr>
R1(config)#snmp-server community CCNP ro 15
That command allows hosts identified by access-list 15 to have read-only
access to all SNMP objects specified by this community string. Restrict
read-write access to your SNMP objects as much as is practical with your
network and network personnel.
To configure the location of the SNMP server on the monitored device so
the local device knows where to send the traps, use this command:
R1(config)#snmp-server trap < IP address of SNMP server >

Syslog
Syslog delivers messages about network events in what a friend once
called "kinda readable format". These messages can be really helpful in
figuring out what just happened in both your home lab and production
network - you just have to remain calm and read the message.
That sounds flip, but I've seen and heard plenty of network admins panic
because something's gone wrong in their network, and they don't know
what it is, and they totally miss the Syslog message on their screen.
True, that message can be hidden in a batch of other output, but I bet it's
there - and as we've seen a few times in this course, the message may
well spell out exactly what the problem is.
While part of the Syslog message will be in easily understood text, part of
it's going to have some numbers and dashes in it. After we take a look at
the different severity levels and some sample configurations, we'll
"decipher" the "kinda readable" part of a Syslog message.
Logging To A Host
The basic command for sending logging messages to a specific host is
straightforward, but I've found the level command that goes with it
sometimes trips Cisco network admins up. Let's take a look at the
different logging options with IOS Help. The commands we're focusing on
are at the very top and very bottom of the IOS Help options.
R1(config)#logging ?
Hostname or A.B.C.D IP address of the logging host
buffered Set buffered logging parameters
console Set console logging level
exception Limit size of exception flush output
facility Facility parameter for syslog messages
history Configure syslog history table
host Set syslog server host name or IP address
monitor Set terminal line (monitor) logging level
on Enable logging to all supported destinations
rate-limit Set messages per second limit
source-interface Specify interface for source address in logging
transactions
trap Set syslog server logging level
Identifying the logging host is easy enough - we just need to follow
logging with the hostname or IP address of that host. It's the trap
command you have to watch, since that sets the logging level itself.
R1(config)#logging 172.12.123.1
R1(config)#logging trap ?
<0-7> Logging severity level
alerts Immediate action needed (severity=1)
critical Critical conditions (severity=2)
debugging Debugging messages (severity=7)
emergencies System is unusable (severity=0)
errors Error conditions (severity=3)
informational Informational messages (severity=6)
notifications Normal but significant conditions (severity=5)
warnings Warning conditions (severity=4)
<cr>
Selecting a trap level means that all log messages of the severity you
configure and all those with a lower numeric value are sent to the logging
server. If you want all log messages to be sent, you don't have to enter
every number - just number 7, the debug level, which is the highest
numeric level.
I've occasionally seen instances where the desired log messages were
not being sent to the server. The first thing you should check is the
logging trap level. If you want debug logs sent to the server, you must
specify that level.
R1(config)#logging trap 7
You can use the actual name or the level behind logging trap. Just make
sure to set the level high enough to get the desired results!
Let's take a "kinda typical" Syslog message that you've seen quite often
by this point in your studies and examine it closely.
5d05h: %SYS-5-CONFIG_I: Configured from console by console
About as commonplace as it gets, right? Those are some odd characters
at the beginning, though. The very beginning of that is the timestamp,
which you can set to different formats with the service timestamps
command. Right now it's set to uptime, showing that this router's been up
for five days and five hours.
I prefer the datetime option, which I'll show you here along with the syntax
of the command via IOS Help:
R3(config)#service timestamps ?
debug Timestamp debug messages
log Timestamp log messages
<cr>
R3(config)#service timestamps log ?
datetime Timestamp with date and time
uptime Timestamp with system uptime
<cr>
R3(config)#service timestamps log datetime
R3(config)#^Z
R3#
*Mar 6 05:42:35: %SYS-5-CONFIG_I: Configured from console by console
Note the immediate change of the timestamp format.
The "SYS" in that message is the facility; "SYS" indicates a System
message. When you're configuring routing protocols, you'll see
messages with "OSPF", "EIGRP", or "RIP" there.
The "5" is the severity, which in this case is the "Notifications" level. That's
followed by the mnemonic ("CONFIG_I", for Config Interface in this case)
and the message-text, which is the final part of the Syslog message.
Cisco SLA
In your Frame Relay studies, you were introduced to the Committed
Information Rate (CIR). The CIR is basically a guarantee given to the
customer by the Frame Relay service provider where the provider says..
"For X dollars, we guarantee you'll get "Y" amount of bandwidth. You may
get more, but we guarantee you won't get less."
Given that guarantee of minimum performance, the customer can then
plan the WAN appropriately.
The SLA is much the same, only this agreement (the Service Level
Agreement, to be precise) can be between different groups..
.. it can be much like the CIR, where a service provider guarantees a
certain level of overall network uptime and performance...
... or it can be between the internal clients of a company and the
network team at the same company.
The SLA can involve bandwidth minimums, but it can involved just about
any quality-related value in your network, including acceptable levels of
jitter in voice networks. From Cisco's "IOS IP Service Level Agreements"
website:
"With Cisco IOS IP SLAs, users can verify service guarantees,
increase network reliability by validating network performance,
proactively identify network issues, and increase Return on
Investment (ROI) by easing the deployment of new IP services."
"Cisco IOS IP SLAs use active monitoring to generate traffic in a
continuous, reliable, and predictable manner, thus enabling the
measurement of network performance and health."
Now that's quite an agreement.
According to the same site, a typical SLA contains the following
assurances:
Network availability percentage
Network performance (often measured by round-trip delay)
Latency, jitter, packet loss, DNS lookup time
Trouble notification response time
Resolution time
Reimbursement schedule when above assurances are not met
Cisco IOS IP SLA usage includes:
Performance visibility
SLA monitoring
IP service network health readiness
Edge-to-edge network availability monitoring
Business-critical app performance monitoring
Network operation troubleshooting
There are two parties involved in the overall SLA process, the self-
explanatory Source and Responder. Once we configure SLA, the source
kicks off the process...
Control packets are sent to the Responder on UDP port 1967 in an
attempt to create a control connection similar to that of FTP - it's
basically an agreement on the rules of communication. In this case,
the rules sent to the Responder are the protocol and port number it
should listen for and a time value indication how long it should listen.
If the Responder agrees to the rules, it will send a message back to
the Source indicating its agreement, and will then start listening! (If
the Responder doesn't agree, it will indicate that as well, and our
story ends here.)
We now go from controlling to probing, as the Source sends some
test packets to the Responder. What's the Source testing? The
approximate length of time it take the Responder to - you guessed it
- respond!
The Responder adds timestamps both as the packets are accepted
and returned to the Sender. This gives the Sender a better idea of
the overall time it took the Responder to process the packets.
Some notes regarding the time measurements going on here...
It bears repeating that the Responder places two timestamps on the
returned packets - one indicating when the packet arrived and
another indicating when it left. This allows the Sender to determine
how long it took the Responder to process the packets.
This dual timestamping allows the Sender to determine if there were
any delays either as the packet went from Sender to Receiver or vice
versa. (Similar to our old friends BECN and FECN from Frame
Relay.)
All of this time measurement and timestamping only works if the
involved devices have the same time set - and that's what NTP is all
about. The Network Time Protocol is not a part of your CCNP
SWITCH exam studies, but it is important to know for working in real-
world networks. I have an idea it might show up on other exams,
too!
There's some excellent information on Cisco's SLA white paper site:
http://bit.ly/ahY5dh
Configuring SLA can be a bit tricky - I've seen the IOS commands vary
more than usual between IOS version. While the basic process is the
same..
Config the probe and send it
Config the object to be probed
... the commands to get you there vary. Here's a Cisco PDF on the
subject:
http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsicmp.html
I certainly wouldn't memorize every single step, but knowing the basic
commands ("ip sla monitor" and "show ip sla statistics", for example)
certainly couldn't hurt.
Configuring A Cisco Multilayer Switch As A DHCP Server
As a CCNA and future CCNP, you're familiar with the basic purpose of
DHCP and the basic process a host goes through in order to get an IP
address from a DHCP server... but let's review it anyway!
The initial step has the DHCP client sending a broadcast packet, a
DHCPDiscover packet, that allows the host to discover where the
DHCP servers are.
The DHCP servers that receive that DHCPDiscover packet will
respond with a DHCPOffer packet. This packet contains an IP
address, the time the host can keep the address (the "lease"), a
default gateway, and other information as configured by the DHCP
server admin.
If the host receives DHCPOffer packets from multiple DHCP servers,
the first DHCPOffer packet received is the one accepted. The host
accepts this offer with a DHCPRequest packet, which is also a
broadcast packet.
The DHCP server whose offered IP address is being accepted sends
a unicast DHCPAck (for "acknowledgement") back to the host.
Note that two broadcast packets are involved in the DHCP address
assignment process. You remember from your CCNA studies that there
is a certain circumstance where broadcasts may not reach their intended
destination. I'll remind you what that is and show you how we're going to
get around it later in this section.
The commands to configure a Cisco router and a multilayer switch as a
DHCP server are the same. There's one "gotcha" involving using an L3
switch as a DHCP Server that I'll point out as we dive into the config.
Careful planning is the first step to success when working with Cisco
routers, and that's particularly true of a DHCP deployment. We may have
a situation where we want to exclude a certain range of addresses from
the DHCP pool, and oddly enough, we need to do that in global
configuration mode.
Actually, let me point out that "gotcha" right here - when you use an L3
switch as a DHCP Server, the switch must have an IP address from any
subnet that it's offering addresses from.
Let's say we are going to assign addresses to DHCP clients from the
11.0.0.0 /8 range, but we don't want to assign the addresses 11.1.1.1 -
11.1.1.255. We need to use the ip dhcp excluded-address command to
do that, and again, that's a global command. (I mention that twice
because that drives everyone crazy - it's very easy to forget!)
R1(config)#ip dhcp excluded-address ?
A.B.C.D Low IP address
R1(config)#ip dhcp excluded-address 11.1.1.1 ?
A.B.C.D High IP address
<cr>
R1(config)#ip dhcp excluded-address 11.1.1.1 11.1.1.255 ?
<cr>
R1(config)#ip dhcp excluded-address 11.1.1.1 11.1.1.255
Note that there are no masks used in this command - just the numerically
lowest and highest IP addresses in the excluded range.
Finally, we're ready to create the DHCP pool! We enter DHCP config
mode with the ip dhcp pool command, followed by the name we want the
pool to have.
R1(config)#ip dhcp pool ?
WORD Pool name
R1(config)#ip dhcp pool NETWORK11
R1(dhcp-config)#
The range of addresses to be assigned to the clients is defined with the
network command. Note that for the mask, we're given the option of
entering the value in either prefix notation or the more familiar dotted
decimal.
R1(dhcp-config)#network ?
A.B.C.D Network number in dotted-decimal notation
R1(dhcp-config)#network 11.0.0.0 ?
/nn or A.B.C.D Network mask or prefix length
<cr>
R1(dhcp-config)#network 11.0.0.0 /8
We can specify a domain name with the domain-name command, and
give the clients the location of DNS servers with the dns-server
command. The DNS servers can be referred to by either their hostname
or IP address.
R1(dhcp-config)#domain-name ?
WORD Domain name
R1(dhcp-config)#domain-name bryantadvantage.com

R1(dhcp-config)#dns-server ?
Hostname or A.B.C.D Server's name or IP address
R1(dhcp-config)#dns-server 11.1.1.255
To specify a default router for the clients, use the default-router
command.
R1(dhcp-config)#default-router ?
Hostname or A.B.C.D Router's name or IP address
R1(dhcp-config)#default-router 11.1.1.100

Not only can you specify the length of the DHCP address lease, you can
be really specific about that value - down to the minute! The lease can
also be made indefinite with the infinite option.
R1(dhcp-config)#lease ?
<0-365> Days
infinite Infinite lease
R1(dhcp-config)#lease 30 ?
<0-23> Hours
<cr>
R1(dhcp-config)#lease 30 23 ?
<0-59> Minutes
<cr>
R1(dhcp-config)#lease 30 23 59 ?
<cr>
R1(dhcp-config)#lease 30 23 59
At the beginning of this section, I mentioned that a Cisco router acting as
a DHCP server will check for IP address conflicts before assigning an IP
address. This check consists of the router sending two ping packets to an
IP address before assigning that address; those pings will time out in 500
milliseconds.
If the ping times out, the address will be assigned. If an echo returns,
obviously that address should not and will not be assigned!
If you want to change either the number of pings sent or the ping timeout
value during this process, use the ip dhcp ping packets and ip dhcp ping
timeout commands. Note that these are global commands as well. You
can also disable this pinging by entering zero for the ping packets value.
R1(config)#ip dhcp ping packets ?
<0-10> Number of ping packets (0 disables ping)
<cr>
R1(config)#ip dhcp ping packets 5

R1(config)#ip dhcp ping timeout ?
<100-10000> Ping timeout in milliseconds
R1(config)#ip dhcp ping timeout 1000
R1(config)#
Finally, if you need to disable the DHCP service on this router, run the no
service dhcp command. It can be reenabled at any time with the service
dhcp command. (DHCP capabilities should be enabled by default, but it
never hurts to make sure.)
Now, about those broadcasts ....
IP Helper Addresses
While routers accept and generate broadcasts, they do not forward them.
That can present quite a problem with DHCP requests when a router is
between the requesting host and the DHCP server. The initial step in the
DHCP process has the host generating a DHCPDiscover packet - and
that packet is a broadcast.

If this PC attempts to locate a DHCP server with a broadcast, the
broadcast will be stopped by the router and will never get to the DHCP
server. By configuring the ip helper-address command on the router,
UDP broadcasts such as this will be translated into a unicast by the
router, making the communication possible.
The command should be configured on the interface that will be receiving
the broadcasts -- not the interface closest to the destination device.
R1(config)#int e0
R1(config-if)#ip helper-address ?
A.B.C.D IP destination address
R1(config-if)#ip helper-address 100.1.1.2
A Cisco router running the ip helper-address command is said to be
acting as a DHCP Relay Agent, but DHCP messages are not the only
broadcasts being relayed to the correct destination. Nine common UDP
service broadcasts are "helped" by default:
TIME, port 37
TACACS, port 49
DNS, port 53
BOOTP/DHCP Server, port 67
BOOTP/DHCP Client, port 68
TFTP, port 69
NetBIOS name service, port 137
NetBIOS datagram service, port 138
IEN-116 name service, port 42
That's going to cover most scenarios where the ip helper-address
command will be useful, but what about those situations where the
broadcast you need forwarded is not on this list? You can use the ip
forward-protocol command to add any UDP port number to the list.
To remove protocols from the default list, use the no ip forward-protocol
command. In the following example, we'll add the Network Time Protocol
port to the forwarding list while removing the NetBIOS ports. Remember,
you can use IOS Help to get a list of commonly filtered ports!
R1(config)#ip forward-protocol udp ?
<0-65535> Port number
biff Biff (mail notification, comsat, 512)
bootpc Bootstrap Protocol (BOOTP) client (68)
bootps Bootstrap Protocol (BOOTP) server (67)
discard Discard (9)
dnsix DNSIX security protocol auditing (195)
domain Domain Name Service (DNS, 53)
echo Echo (7)
isakmp Internet Security Association and Key Management Protocol
(500)
mobile-ip Mobile IP registration (434)
nameserver IEN116 name service (obsolete, 42)
netbios-dgm NetBios datagram service (138)
netbios-ns NetBios name service (137)
netbios-ss NetBios session service (139)
ntp Network Time Protocol (123)
pim-auto-rp PIM Auto-RP (496)
rip Routing Information Protocol (router, in.routed, 520)
snmp Simple Network Management Protocol (161)
snmptrap SNMP Traps (162)
sunrpc Sun Remote Procedure Call (111)
syslog System Logger (514)
tacacs TAC Access Control System (49)
talk Talk (517)
tftp Trivial File Transfer Protocol (69)
time Time (37)
who Who service (rwho, 513)
xdmcp X Display Manager Control Protocol (177)
<cr>
R1(config)#ip forward-protocol udp 123
R1(config)#no ip forward-protocol udp 137
R1(config)#no ip forward-protocol udp 138
The DHCP Relay Agent And "Option 82"
In many cases, simply configuring the appropriate ip helper-address
command on a Cisco router is enough to get the desired results when it
comes to DHCP. In some networks, particularly larger ones, you may find
it necessary for the DHCP Relay Agent - in this case, the Cisco router - to
insert information about itself in the DHCP packets being forwarded to the
server.
On Cisco routers, this is done by enabling the Relay Agent Information
Option, also known as Option 82. (No word on what happened to the first
81 options.)
This is enabled with the ip dhcp relay information option command.
R1(config)#ip dhcp relay information ?
check Validate relay information in BOOTREPLY
option Insert relay information in BOOTREQUEST
policy Define reforwarding policy
R1(config)#ip dhcp relay information option

Copyright 2010 The Bryant Advantage. All Rights Reserved.

6 Multilayer Switching

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

6 Multilayer Switching

Diunggah oleh

Hak Cipta:

Format Tersedia

The Bryant Advantage CCNP SWITCH Study Guide

Chris Bryant, CCIE #12933 www.thebryantadvantage.com

Anda mungkin juga menyukai