6 Multilayer Switching
6 Multilayer Switching
www.thebryantadvantage.com
Back To Index
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...
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
0.0.0.0/32
224.0.0.0/4
224.0.0.0/24
255.255.255.255/32
Next Hop
receive
drop
receive
receive
Interface
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
Next Hop
receive
drop
receive
receive
Interface
different names.
These all refer to the control plane:
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:
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
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
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)
HOST_3#ping 20.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.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
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
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
SW1(config-if)#ip address 30.1.1.11 255.255.255.0
Last Use
Total Uses
Interface
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
20.1.1.0 is directly connected, Vlan11
30.0.0.0/24 is subnetted, 1 subnets
C
30.1.1.0 is directly connected, Vlan33
C
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?
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 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
HOST_3#ping 20.1.1.1
Type escape sequence to abort.
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
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
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 210.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
The router now has the VLAN subnets in its routing table...
ROUTER_TO_INTERNET#show ip route
< code table removed for clarity >
D
C
D
... 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
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 210.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
HOST_3#ping 210.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 210.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
It never hurts to make sure the pings can go the other way, too!
ROUTER_TO_INTERNET#ping 20.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
ROUTER_TO_INTERNET#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 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
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
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
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
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)#interface ethernet0
R2(config-if)#standby 5 priority 150
R2#show standby
Ethernet0 - Group 5
Local state is Standby, priority 150
Hellotime 4 sec, holdtime 12 sec
Next hello sent in 0.896
Virtual IP address is 172.12.23.10 configured
Active router is 172.12.23.3, priority 100 expires in 8.072
Standby router is local
1 state changes, last state change 00:14:24
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
Hellotime 4 sec, holdtime 12 sec
Next hello sent in 1.844
Virtual IP address is 172.12.23.10 configured
Active router is local
Standby router is 172.12.23.3 expires in 10.204
Virtual mac address is 0000.0c07.ac05
2 state changes, last state change 00:00:13
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
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:
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
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.
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)#interface ethernet0
R2(config-if)#standby 1 priority 105 preempt
R2(config-if)#standby 1 ip 172.12.23.10
R2(config-if)#standby 1 track serial0
R3(config)#interface ethernet0
R3(config-if)#standby 1 priority 100 preempt
R3(config-if)#standby 1 ip 172.12.23.10
R2#show standby
Ethernet0 - Group 1
Local state is Active, priority 105, may preempt
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 1.424
Virtual IP address is 172.12.23.10 configured
Active router is local
Standby router is 172.12.23.3 expires in 9.600
Virtual mac address is 0000.0c07.ac01
Up
R3#show standby
Ethernet0 - Group 1
Local state is Standby, priority 100, may preempt
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 0.624
Virtual IP address is 172.12.23.10 configured
Active router is 172.12.23.2, priority 105 expires in 9.452
Standby router is local
1 state changes, last state change 00:01:33
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:
administratively down
Interface
Serial0,
changed
state
to
R2#show standby
Ethernet0 - Group 1
Local state is Standby, priority 95 (confgd 105), may preempt
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 0.446
Virtual IP address is 172.12.23.10 configured
Active router is 172.12.23.3, priority 100 expires in 9.148
Standby router is local
4 state changes, last state change 00:00:02
Priority tracking 1 interface, 0 up:
Interface
Decrement State
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
Local state is Active, priority 100, may preempt
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 0.706
Virtual IP address is 172.12.23.10 configured
Active router is local
Standby router is 172.12.23.2 expires in 8.816
Virtual mac address is 0000.0c07.ac01
2 state changes, last state change 00:02:34
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
Local state is Active, priority 105, may preempt
Hellotime 3 sec, holdtime 10 sec
Next hello sent in 0.852
Virtual IP address is 172.12.23.10 configured
Active router is local
Standby router is 172.12.23.3 expires in 9.276
Virtual mac address is 0000.0c07.ac01
5 state changes, last state change 00:00:16
Priority tracking 1 interface, 1 up:
Interface
Decrement State
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
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:
Priority 65 (default 100)
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
FastEthernet0/0 - Group 1
State is Active
2 state changes, last state change 01:08:58
Virtual IP address is 172.12.23.10
Active virtual MAC address is 0000.0c07.ac01
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 2.872 secs
Preemption disabled
Active router is local
Standby router is unknown
Priority 100 (default 100)
IP redundancy name is "hsrp-Fa0/0-1" (default)
FastEthernet0/0 - Group 5
State is Init (virtual IP in wrong subnet)
Virtual IP address is 172.12.34.10 (wrong subnet for this interface)
Active virtual MAC address is unknown
Local virtual MAC address is 0000.0c07.ac05 (v1 default)
Hello time 3 sec, hold time 10 sec
Preemption disabled
Active router is unknown
Standby router is unknown
Priority 75 (default 100)
Track interface Serial0/0 state Down decrement 25
IP redundancy name is "hsrp-Fa0/0-5" (default)
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
*Apr 9 20:15:10.554: HSRP: Fa0/0 API Add active HSRP addresses to ARP
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
*Apr 9 20:15:12.545: HSRP: Fa0/0 API Add active HSRP addresses to ARP
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
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-4444-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
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>
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.
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:
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
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 ?
Std IP accesslist allowing access with this community
<1-99>
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
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
buffered
console
exception
facility
history
host
monitor
on
rate-limit
source-interface
trap
(severity=1)
(severity=2)
(severity=7)
(severity=0)
(severity=3)
(severity=6)
(severity=5)
(severity=4)
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
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)#
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
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
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.
TIME, port 37
TACACS, port 49
DNS, port 53
BOOTP/DHCP Server, port 67
BOOTP/DHCP Client, port 68
TFTP, port 69
<cr>
R1(config)#ip forward-protocol udp 123
R1(config)#no ip forward-protocol udp 137
R1(config)#no ip forward-protocol udp 138