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
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 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) 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
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
SW1(config-if)#ip address 30.1.1.11 255.255.255.0
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) Internet address is 30.1.1.11/24
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
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 30.0.0.0/24 is subnetted, 1 subnets 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?
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.
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/2/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
SW1(config-if)#ip address 210.1.1.11 255.255.255.0
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) Internet address is 210.1.1.5/24
The switch can now ping 210.1.1.1, the downstream router.
SW1#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/8 ms
Now let's take this just one step further - what if we wanted the hosts in
Sending 5, 100-byte ICMP Echos to 210.1.1.1, timeout is 2 seconds:
...
Success rate is 0 percent (0/5)
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 >
Gateway of last resort is not set
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
The router now has the VLAN subnets in its routing table...
ROUTER_TO_INTERNET#show ip route
< code table removed for clarity >
Gateway of last resort is not set
20.0.0.0/24 is subnetted, 1 subnets
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
30.0.0.0/24 is subnetted, 1 subnets
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
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
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms