||A reader requests that the formatting and layout of this book be improved.
Good formatting makes a book easier to read and more interesting for readers. See Editing Wikitext for ideas, and WB:FB for examples of good books.
Please continue to edit this book and improve formatting, even after this message has been removed. See the discussion page for current progress.
Multi-layer Switching (MLS)Edit
Fundamentals of MLSEdit
You have undoubtedly heard of the term "router on a stick." Figure 7.1 depicts the router on a stick architecture.
As you can see from the diagram, there are multiple hosts using two separate VLAN assignments. One segment is running on VLAN10, and the other segment is running on VLAN50. Both VLANs or segments, are connected to the same switch. The switch is then connected to a router. Here we show an external router, but an RSM provides the same functionality, just internally.
By now you understand that for Host A on VLAN10 to communicate to Host D on VLAN50, packets must be routed through Router A. Because of the VLAN assignments, the switch must send the packet to the router on interface FE0/0.10. The router knows that the route to the network assigned to VLAN50 is through interface FE0/0.50. The packet is then sent back to the switch and forwarded to Host D.
Now back to our original question. Why use MLS? You can see from the diagram in Figure 7.1 that it very inefficient to have to use a router, or Route Switch Module (RSM), to move a packet from Host A to Host D when they are connected to the same device. MLS is used to bypass the router on subsequent packets of the same flow. A flow is created by using packet header information—Inter-Switch Link (ISL), layer 2, and layer 3 headers. There are several fields within a packet that make it unique:
- Source and destination IP addresses
- Source and destination MAC addresses
- Type of Service (TOS)
- Protocol type (i.e., HTTP, FTP, ICMP, etc.)
These are just some of the characteristics of a packet that can be used to establish a flow. A flow is defined by using a specified set of these attributes.
Cisco Catalyst switches require additional hardware to see the packet header information. Catalyst 5000 switches use the NetFlow Feature Card (NFFC) to gather this information and cache it. Catalyst 6000 series switches use the Multilayer Switch Feature Card (MSFC) and the Policy Feature Card (PFC) to gather and cache header information. There is a detailed process, which will be discussed later in the chapter, that allows switches to establish flows. MLS requires three components to function in any network Multilayer Switching Protocol (MLSP) is a protocol that runs on the router and allows it to communicate to the MLS-SE regarding topology or security changes. Multilayer Switching Route Processor (MLS-RP) can be an MLS-capable router or an RSM installed in the switch. Multilayer Switching Switching Engine (MLS-SE) is an MLS-capable switch (a 5000 with an NFFC or a 6000 with an MSFC and PFC).
Now that you have a basic understanding of what MLS does and what is required for MLS to function in a network, let's get into the nitty-gritty of how it works.
We discussed the three required components of MLS. It is important to understand how they work together to enable layer 3 switching. Let's look at a sample network topology that will support MLS. Figure 7.2 shows a simple architecture of a router and a switch with two connected hosts on the switch. Again, the hosts have different VLAN assignments, requiring the router's intervention to route packets. Notice that the figure depicts the main interface with two subinterfaces, FE0/0.2 and FE0/0.3. MLS follows a four-step process to establish the layer 3 switching functionality. These four steps can then be broken down into more detailed processes. The four steps required to enable MLS are as follows: MLSP discovery The MLS-RP uses MLSP to send hello packets out all interfaces to discover MLS-SE and establish MLS-RP/MLS-SE neighbor relationships. Identification of candidate packets The NFFC or PFC watches incoming packets and creates partial cache entries for them, thus identifying the packets as potential candidates for a flow, or candidate packets. Identification of enable packets The NFFC or PFC watches packets coming from the MLS-RP and tries to match them with candidate packet entries. If matches are made, the packets are tagged as enable packets and a shortcut forwarding entry is made in the CAM table. Subsequent flow packets are layer 3 switched Incoming packets are compared against CAM table entries. If the packets match the flow criteria, they are rewritten by the NFFC or PFC, then sent to the corresponding exit port for the flow. MLSP Discovery – Switches, NFFCs or PFCs specifically, need routers to perform the initial route table lookup and the packet rewrite. This dependency requires that MLS adjacencies are established between the switch and the router. This is accomplished using the MLSP protocol. Initially, the router, or MLS-RP, sends hello packets containing all of the MAC addresses and VLANs configured for use on the router. These messages are sent every 15 seconds to a layer 2 multicast address of 01-00-0C- DD-DD-DD. The intended recipients of these hello packets are the MLS-SE devices on the network. When an MLS-SE receives the information, it makes an entry in the CAM table of all the MLS-RP devices in the layer 2 network. Layer 2 is mentioned because MLS-SE devices are not concerned with devices that are not directly connected to layer 2 devices, such as switches. Figure 7.3 depicts the MLSP discovery process. Part of the information that is stored in the CAM table once an MLSP hello packet is received is an ID called an XTAG. The next section describes the significance and purpose of the XTAG. XTAGs Simply put, an XTAG is a unique identifier that MLS-SEs (switches) use to keep track of the MLS-RPs in the network. All of the MAC addresses and VLANs in use on the MLS-RP are associated to the XTAG value in the CAM table. You can clearly see that the MFSC has been assigned the XTAG value of 1. The MFSC receives the assignment because the MFSC acts as the MLS-RP. In this example, only one MAC address is associated with XTAG 1. How- ever, there are two VLANs associated with it.
Once MLS-SEs have established CAM entries for MLS-RPs, the switch is ready to start scanning packets and creating cache entries. This was described previously as identification of candidate and enable packets. The cache entries are made in order to maintain flow data. Flow data allows the MLS-SE to rewrite the packets with the new source and destination MAC address and then forward the packets. All this is done without sending the packets to the router for a route lookup and to be rewritten.
Cache entries happen in two steps:
- Candidate packet entries
- Enable packet entries
After these entries have been made in the MLS-SE, subsequent packets are matched against existing flow entries and dealt with accordingly.
Identifying Candidate PacketsEdit
The process of identifying candidate packets is quite simple. As has already been established, the MLS-SE has MAC address entries for any and all inter- faces that come from the MLS-RP. Using this information, the MLS-SE starts watching for incoming frames destined for any MLS-RP-related MAC addresses.
An incoming frame will match one of the following three criteria:
- Not destined for an MLS-RP MAC address
- Destined for an MLS-RP MAC address, but no cache entry exists for this flow
- Destined for an MLS-RP MAC address, but a cache entry already exists for this flow
Different actions will be taken by the MLS-SE, depending on which criteria match. We will discuss the first one right now. The others will be addressed in the following sections. If the incoming frame is not destined for a MAC address associated with the MLS-RP, no cache entry is made. No cache entry is made because MLS is used to avoid additional route lookups. If the frame is destined to another MAC address in the CAM table, the frame is layer 2 switched. Let's move on to discuss the processes for identifying and acting on the next two criteria. First we'll discuss what happens when an entry already exists. Then we'll cover the details of the cache entry process for a candidate packet. Figure depicts the occurrence of a candidate packet Cache Entry Exists When frames enter the switch destined for an MLS-RP MAC address, the MLS-SE checks to see if a cache entry has been made that matches the attributes of the current packet. As was mentioned briefly previously, each frame has distinguishing characteristics or attributes that allow the MLS-SE to categorize a packet into a flow. The MLS-SE uses these attributes to pattern match. If an incoming packet has the same attributes as an established flow cache entry, the packet is layer 3╜ or shortcut-switched. No Cache Entry When a qualified (destined for an MLS-RP MAC address) incoming frame is compared against the cache and fails (no match is found), a cache entry is made. At this point, the packet is tagged as a candidate packet. Once the cache entry is made, the packet is forwarded to the router (MLS-RP) for normal processing. Here the router performs the route lookup, rewrites the layer 2 header, and sends the packet out the next-hop interface, whichever it may be. The state of the MLS cache is only partial at this stage. A complete flow cache has not been established because the MLS-SE has only seen a packet come in and be forwarded to the router. It still needs to see something that it can tag as an enable packet come back from the router.
Identifying Enable PacketsEdit
Enable packets are the missing piece of the flow cache puzzle. Just as the MLS-SE watched all incoming frames destined for the MLS-RP MAC addresses, it also watches all of the packets coming from the MLS-RP. It watches these packets hoping for a match with the candidate packet cache entry. If it can make the match, the packet is tagged as an enable packet and the remaining elements of the flow cache are completed in the CAM table. Figure 7.5 depicts the occurrence of an enable packet. The match is made using the following criteria: The source MAC address is from an MLS-RP. The destination IP matches the destination IP of a candidate packet. The source MAC address is associated to the same XTAG value as the candidate packet's destination MAC address. If all three of these criteria are met, the MLS-SE completes the shortcut cache entry. Frame Modification It is important to understand that this shortcut switching occurs at layer 3. The layer 2 frame is rewritten by the switch. Normally, a router (layer 3 device) would rewrite the frame with the necessary information. A rewrite consists of changing the VLAN assignment, the source and destination MAC addresses, and the checksums. The MLS-SE can also modify the TTL, check- sums, TOS, and encapsulation Because MLS packets are no longer sent to the router, the MLS-SE must perform the rewrite function. When it changes the source and destination MAC address, the MLS-SE uses the MAC address of the MLS-RP for the source, and it changes the destination MAC to the MAC of the directly connected host. Through this procedure, the frame appears to the destination host as if it had come through the router. Figure 7.6 depicts the differences between the incoming frame and the exiting frame. Subsequent Packets Once the candidate and enable packets have been identified and a shortcut, or flow cache, has been established, subsequent packets are forwarded by the switch to the destination without the use of the router. Because the MLS-SE has the capability to rewrite the frames, it can make the necessary modifications and forward the frame directly to the destination host. The MLS-SE stores the necessary information in cache, such as the source and destination IP addresses, the source and destination MAC addresses, and the MLS-RP-related MAC addresses. Using this information, the MLS- SE is then capable of identifying packets belonging to a specific flow, rewriting the frame, and forwarding the packets to the proper destination. Disabling MLS There is a right way and a wrong way (not necessarily wrong, just unwanted) to disable MLS on a router or switch. Both methods will be discussed here. The Right Way The normal, and correct, way to disable MLS depends on the equipment you are using. Disabling MLS on a router can be paralleled with disabling MLS on an MSFC for a 6500 series switch. The command is even the same: no mls rp ip issued from the interface on either the router or the MSFC. To disable it completely, you can issue the same command from the global con- figuration mode. The consequences of this action vary depending on the sys- tem on which it is issued. When the command is issued on the router, the router alone disables MLS. When it's issued on an MSFC, MLS is disabled on the MSFC and the switch itself. That's why there is a difference when different switches are used. When you're using a 5000 series switch, MLS is disabled by default. However, on a 6000 series switch, MLS is enabled by default. To disable MLS on a 5000 series switch, use the set mls disable command. On a 6000 series, MLS should be disabled by issuing the no ip mls command on the MSFC. The Wrong Way There are several ways to inadvertently disable MLS on switches. Some are temporary, and others are permanent. Here is a list of MSFC/router com- mands that can disable MLS: no ip routing ip security ip tcp compression-connections ip tcp header-compression clear ip route By disabling IP routing on the MSFC or router, you automatically disable MLS. IP security disables MLS on the interface to which the command is applied. The same results occur with the IP TCP compression commands. Finally, the clear ip route command simply clears the MLS cache entries and the flow caches must be reestablished.