Chapter 11: Multilayer Switching

In Depth

Earlier in this book, I told you that switches were Layer 2 devices and routers were Layer 3 devices, which fit nicely into those well−known seven layers. You know the seven—the Open System Interconnection (OSI) Reference Model layers. Oh, did I forget to mention the Multilayer Switching Engine, multilayer switches, and Layer 3 switches?

Do you recall when it was easy to remember that Layer 2 devices use physical addresses and Layer 3 devices use logical addresses? These distinctions will seem much blurrier after you read this chapter.

For now, let’s define what Multilayer Switching (MLS) does. MLS is a method for increasing the performance of IP routing. Whereas routers provide routing functionality with a central processing unit (CPU), MLS injects certain advanced modules—either available separately or built into switches—with Application−Specific Integrated Circuit (ASIC) silicon chips to handle Layers 3 and 4 routing. As a result, the switching hardware can handle the routing functions previously performed by routers at Layer 3. MLS combines the functions of switching and the functions of routing to increase the level of performance in the device.

Why Not Call Them Routers?

If MLS switches offer the same benefits as routers, why not just call them routers with a lot of interfaces? Although most multilayer switches are much faster and considerably less per port cost than routers, some MLS devices are simple, stackable workgroup switches that fall well short of the flexibility, protocol support, port density, and WAN features you find on most enterprise edition routers (with the exception of the Catalyst 6000, which now offers a FlexWAN Card).

Until the Cisco IOS version 12.1 was released, the only protocol supported by MLS was Internet Protocol (IP). Even now, MLS supports only IP and Internetwork Packet Exchange (IPX).

Let’s examine how MLS works and the components used in MLS.

How MLS Works

Before we can analyze how MLS works, we need to understand how a network sends traffic from point A to point B. Cisco’s implementation of MLS supports every Cisco routing protocol used in its product line, including the following:

∙Border Gateway Protocol (BGP)

∙Distance Vector Multicast Routing Protocol (DVMRP)

∙Internet Group Multicast Protocol (IGMP)

∙Open Shortest Path First (OSPF)

∙Protocol−Independent Multicast (PIM)

∙Routing Information Protocol (RIP)

However, Cisco’s implementation of MLS supports only two Layer 3 routable protocols: IP and IPX.

IP and IPX are connectionless protocols. This means they attempt to deliver every packet in a best−effort

227

manner. This method is similar to sending a piece of mail: You put it in the mailbox, but you have no guarantee that it will arrive—just the likelihood it will reach its destination.

Using other protocols, including those at Layer 2 and Layer 4, the network traffic is made up of a series of end−to−end conversations also known as flows. These flows are connection−oriented in nature. Connection−oriented data traffic is similar to a certified letter. You put the letter in the mailbox, and you receive a signed notice saying the letter reached its destination.

MLS identifies network flows from a network source to a network destination by using the Network and Transport layer information in the packet headers; it then forwards the packets. This sequence of packets is sent in one direction between a particular source and destination and uses the same protocol and Layer 4 header information.

Let’s take a look at multiple flows. Suppose I am looking at Coriolis’s Web site to determine when the last book I wrote will be released. At the same time, I am using FTP to send the latest chapter I have written for review. Both data flows are traversing back and forth from the same source to the same destination and vice versa—two flows of data are traveling at the same time between my PC and a server at Coriolis. How does my host, a router, or even the switch know which conversation I want on my screen? Why don’t parts of the

Coriolis Web site get mixed into the chapter I am uploading? The reason it works is that each flow is assigned an individual port number.

MLS should not be confused with NetFlow switching provided by the NetFlow Feature Card (NFFC) or the NFFC II, even though the NFFCs are used to provide MLS with the Catalyst 5000 and 6000 families of switches. MLS must use an external router or an internal route processor such as the Route Switch Module (RSM) to provide the routing resolution for the initial packet that is routed in an MLS flow (the connection−oriented session). Each subsequent packet in the flow is processed by the switch, not the router.

Prioritizing Traffic Flows

MLS identifies the unique flows between hosts by identifying the user application and classifying data traffic with the appropriate priority level. These flows can be either unicast or multicast traffic.

MLS identifies individual network traffic flows to provide predictable network services. It does this by supplying dedicated bandwidth to those applications that need it most. As an example, enterprise resource planning (ERP) application traffic (which can be mission−critical) can be identified as needing a higher priority and thus receive more network bandwidth than, say, Web or FTP traffic.

Before we go into more detail on packet flows, let’s take a more detailed look at the hardware and software used by MLS.

MLS Components

You should understand three components in the MLS process to resolve the destination path for the initial packet flow. These components are required in order to use MLS and send routing updates to Catalyst switches. The components are as follows:

∙MLS Switching Engine (MLS−SE)—The switch supporting MLS

∙MLS Route Processor (MLS−RP)—The internal route processor in the switch or external router that supports MLS

∙Multilayer Switch Protocol (MLSP)—The protocol that runs between the MLS−SE and MLS−RP to enable MLS

228

Figure 11.1 shows the three MLS components contained in a single switch chassis, such as that of a Cisco Catalyst 5000 or 6000 family switch.

Figure 11.1: The MLS components using an internal route processor in an MLS switch.

The Cisco 5000 and 6000 families of switches can use multiple internal route processors, such as the following:

∙NetFlow Feature Card (NFFC)

∙NetFlow Feature Card II (NFFC II)

∙Route Switch Module (RSM)

∙Route Switch Feature Card (RSFC)

∙Multilayer Switch Feature Card (MSFC)

∙Multilayer Switching Module (MSM)

Note The NFFC or NFFC II must be used as a daughtercard of the Supervisor Engine III. You can also use the Supervisor IIG or IIIG card with Supervisor Engine software release 4.1 or later, which provides the functionality of the NFFC without using an NFFC card. Newer Catalyst models have the MLS functionality built into the switch. These switches—known as Layer 3 (L3) switches—are the Cisco Catalyst 4908G−L3, the Cisco Catalyst 2926G−L3, and the Cisco Catalyst 2948G−L3. The RSM or RSFC can be used in the Catalyst 5000 family, and an MSM or MSFC can be used in the Catalyst 6000 family.

You can use an external router instead of an internal route processor to resolve the initial packet routing information. You must use an external router that supports MLS. Figure 11.2 shows an external router providing MLS route resolution functionality for the MLS−SE (switch). MLS support is included in enterprise routers with the Cisco IOS version 11.3(2)WA4(4) or later. These routers include the following:

Figure 11.2: The MLS switch using an external router.

∙Cisco 3600 series

∙Cisco 4500 series

∙Cisco 4700 series

∙Cisco 7200 series

∙Cisco 7500 series

∙Cisco 8500 Gigabit Switch Router series

In order to understand the MLS process better, we need to examine how the data packets are forwarded in an MLS environment.

229

MLS Flows

When a flow process begins, the MLS−RP starts sending out multicast hello messages every 15 seconds to all switches in the network that accept MLS−RP messages. These messages inform each switch that the MLS−RP (router or internal route processor) is available to provide routing information to the MLS switches, allowing them to cache learned routes.

MLSP is the protocol used between the MLS−SE and the MLS−RP. It uses a Cisco Group Management Protocol (CGMP) multicast address, so each MLS−SE (switch) enabled for CGMP will hear the hello message. To distinguish between normal CGMP messages and the MLS messages, the MLS−RP uses a special protocol type in the hello message itself.

The MLSP hello message (which is also known as an MLS−RP advertisement) can contain the following information:

∙The Media Access Control (MAC) addresses of the router interfaces participating in MLS

∙The router’s known virtual LAN (VLAN) information

∙The MLS−RP’s access lists

∙Any known or updated routing information

A switch participating in MLS has an MLS−SE component. This component processes the hello message and records the MAC address of the MLS−RP interfaces into its Content Addressable Memory (CAM) table. If multiple MLS−RPs exist in the network, the MLS−SE assigns a unique 1−byte identifier called an XTAG, as shown in Figure 11.3. The XTAG is a number that distinguishes the network flows of each MLS−RP.

Figure 11.3: An individual XTAG number is assigned to each MLS router in the network.

When a host from one VLAN on the network begins a network flow that is destined for a host on another VLAN, the MLS switch that received the first packet in the flow extracts the Layer 3 information for the flow. This information includes the destination address, source address, and protocol port numbers. The MLS−SE then forwards the first packet to the MLS−RP for a routing resolution. MLSP is used to inform the MLS−SE of the path to the destination hosts communicating in the flow. Because this is the first packet, no cache entry exists; a partial MLS entry for this Layer 3 flow is created in the MLS cache.

When the MLS−RP receives the packet, it looks at its route table to determine the destination of the packet and applies any applicable policies, such as an inbound or outbound access list. The MLS−RP will then rewrite the MAC header, adding the MAC address of the destination host and using its own MAC address as the source address. The MLS−RP then sends the packet back to the MLS−SE.

At this point, an MLS router has resolved the first packet with either a VLAN or Layer 3 logical address to a Layer 2 MAC address. The MLS−SE can now use this address to make a forwarding decision and send the packet out the correct port connected to the destination node based on the entries the switch has in its CAM table. The MLS−SE also determines that the MAC address of the MLS router is the source address in the packet and that the packet’s flow information matches a candidate entry in its MLS cache.

Now that the entry for the flow has been added to the MLS cache, any further packets that are identified as belonging to the same flow are handled by MLS−SE and switched based on the cached information. The MLS−SE rewrites the headers, reconditions the checksums, and forwards the packets without their having to

230