<PARA><DROPCAP>I</DROPCAP>n this chapter, we'll discuss <KEYTERM>Multi-Layer Switching (MLS)</KEYTERM>, which is part of the Bridging/Switching group of topics outlined by Cisco for the Switching exam (640-504).</PARA>
<PARA>Why MLS? Why do you need layer 3 switching when you have layer 3 routing? The answer to both of these questions is simple: enhanced performance. Why do you implement any features on any piece of Cisco equipment? To increase performance and take advantage of the robust feature set provided by Cisco.</PARA>
<SECTION ID="7.1"><TITLE>Fundamentals of MLS</TITLE>
<!-- <PARA><DROPCAP>Y</DROPCAP>ou have undoubtedly heard of the term "<KEYTERM>router on a stick</KEYTERM>". 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.</PARA> -->
<SLUG NUM="7.1">Figure 7.1: Router on a stick diagram [f0701.eps]</SLUG>
<!-- <PARA>By now you understand that for HostA on VLAN10 to communicate to HostD on VLAN50, packets must be routed through RouterA. 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.</PARA>
<PARA>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 <KEYTERM>Route Switch Module (RSM)</KEYTERM>, to move a packet from HostA to HostD when they are connected to the same device. MLS is used to bypass the router on subsequent packets of the same flow. A <KEYTERM>flow</KEYTERM> 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:</PARA>
<LIST MARK="bullet">
<LISTITEM><PARA>Source and destination IP addresses</PARA></LISTITEM>
<LISTITEM><PARA>Source and destination MAC addresses</PARA></LISTITEM>
<LISTITEM><PARA>Type of Service (TOS)</PARA></LISTITEM>
<LISTITEM><PARA>Protocol type (i.e., HTTP, FTP, ICMP, etc.)</PARA></LISTITEM>
</LIST>
<PARA>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. </PARA> -->
<!-- <PARA>Cisco Catalyst switches require additional hardware to see the packet header information. Catalyst 5000 switches use the <KEYTERM>NetFlow Feature Card (NFFC)</KEYTERM> to gather this information and cache it. Catalyst 6000 series switches use the <KEYTERM>Multilayer Switch Feature Card (MSFC)</KEYTERM> and the <KEYTERM>Policy Feature Card (PFC)</KEYTERM> 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.</PARA>
<PARA>MLS requires three components to function in any network (we have already briefly discussed two of them): </PARA>
<LIST MARK="bullet">
<LISTITEM><PARA><KEYTERM>Multilayer Switching Protocol (MLSP)</KEYTERM> is a protocol that runs on the router and allows it to communicate to the MLS-SE regarding topology or security changes.</PARA></LISTITEM>
<LISTITEM><PARA><KEYTERM>Multilayer Switching Route Processor (MLS-RP)</KEYTERM> can be an MLS-capable router or an RSM installed in the switch.</PARA></LISTITEM>
<LISTITEM><PARA><KEYTERM>Multilayer Switching Switching Engine (MLS-SE)</KEYTERM> is an MLS-capable switch (a 5000 with an NFFC or a 6000 with an MSFC and PFC).</PARA></LISTITEM>
</LIST> -->
<SLUG FLASH="g1"/>
<PARA>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.</PARA>
</SECTION>
<SECTION ID="7.1.2"><TITLE>MLS Procedures</TITLE>
<PARA>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. --></PARA>
<SLUG NUM="7.2">Figure 7.2: MLS example topology [f0702.eps]</SLUG>
<!-- <PARA>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:</PARA>
<RUNINBLOCK><RUNINHEAD>MLSP discovery</RUNINHEAD>
<RUNINPARA>The MLS-RP uses MLSP to send hello packets out all interfaces to discover MLS-SE and establish MLS-RP/MLS-SE neighbor relationships. </RUNINPARA></RUNINBLOCK>
<RUNINBLOCK><RUNINHEAD>Identification of candidate packets</RUNINHEAD>
<RUNINPARA>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.</RUNINPARA></RUNINBLOCK>
<RUNINBLOCK><RUNINHEAD>Identification of enable packets</RUNINHEAD>
<RUNINPARA>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.</RUNINPARA></RUNINBLOCK>
<RUNINBLOCK><RUNINHEAD>Subsequent flow packets are layer 3 switched</RUNINHEAD>
<RUNINPARA>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.</RUNINPARA></RUNINBLOCK> -->
<PARA><!-- The preceding list is an overview of the steps that must take place before packets can be switched at layer 3. --> We'll discuss each step in detail in the following sections.</PARA>
</SECTION>
<SECTION ID="7.1.3"><TITLE>MLSP Discovery</TITLE>
<!-- <PARA>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.</PARA>
<PARA>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.</PARA>
<PARA>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.</PARA> -->
<PARA><!-- 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.</PARA>
</SECTION>
<SECTION ID="7.1.4"><TITLE>XTAGs</TITLE>
<PARA>Simply put, an <KEYTERM>XTAG</KEYTERM> 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.</PARA>
<PARA>The following output is from a Catalyst 6509 with an MSFC and PFC card. The <INLINECODE>show mls</INLINECODE> command was issued to provide the output:</PARA>
<PARA>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. However, there are two VLANs associated with it.</PARA>
</SECTION>
<SECTION ID="7.1.5"><TITLE>MLS Cache</TITLE>
<PARA>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.</PARA>
<PARA>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. </PARA>
<PARACONTINUED>After these entries have been made in the MLS-SE, subsequent packets are matched against existing flow entries and dealt with accordingly.</PARACONTINUED>
<PARA>The process of identifying <KEYTERM>candidate packets</KEYTERM> is quite simple. As has already been established, the MLS-SE has MAC address entries for any and all interfaces 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.</PARA>
<PARA>An incoming frame will match one of the following three criteria:</PARA>
<LIST MARK="bullet">
<LISTITEM><PARA>Not destined for an MLS-RP MAC address</PARA></LISTITEM>
<LISTITEM><PARA>Destined for an MLS-RP MAC address, but no cache entry exists for this flow</PARA></LISTITEM>
<LISTITEM><PARA>Destined for an MLS-RP MAC address, but a cache entry already exists for this flow</PARA></LISTITEM>
</LIST>
<PARA>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.</PARA>
<PARA>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.</PARA>
<PARA>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 7.4 depicts the occurrence of a candidate packet.</PARA>
<PARA>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.</PARA>
<PARA>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.</PARA>
<PARA>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.</PARA>
<PARA>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.</PARA>
<PARA>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.</PARA>
<!-- <PARA><KEYTERM>Enable packets</KEYTERM> 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.</PARA>
<PARA>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.</PARA> -->
<PARA>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, checksums, TOS, and encapsulation.</PARA>
<PARA>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.</PARA>
<PARA>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.</PARA>
<PARA>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.</PARA>
</SECTION>
</SECTION>
<SECTION ID="7.1.6"><TITLE>Disabling MLS</TITLE>
<PARA>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.</PARA>
<SECTION ID="7.1.6.1"><TITLE>The Right Way</TITLE>
<PARA>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: <INLINECODE>no mls rp ip</INLINECODE> issued from the interface on either the router or the MSFC. To disable it completely, you can issue the same command from the global configuration mode. The consequences of this action vary depending on the system 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.</PARA>
<PARA>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 <INLINECODE>set mls disable</INLINECODE> command. On a 6000 series, MLS should be disabled by issuing the <INLINECODE>no ip mls</INLINECODE> command on the MSFC.</PARA>
<PARA>There are several ways to inadvertently disable MLS on switches. Some are temporary, and others are permanent. Here is a list of MSFC/router commands that can disable MLS:</PARA>
<LIST MARK="bullet">
<LISTITEM><PARA><INLINECODE>no ip routing </INLINECODE></PARA></LISTITEM>
<LISTITEM><PARA><INLINECODE>clear ip route </INLINECODE></PARA></LISTITEM>
</LIST>
<PARA>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 <INLINECODE>clear ip route</INLINECODE> command simply clears the MLS cache entries and the flow caches must be reestablished.</PARA>
<PARA><DROPCAP>T</DROPCAP>o fully enable MLS, you must properly configure all participating devices. This section covers the different configurations and settings that must be executed on the MLS-RP. Remember, the MLS-RP can be an external router, an RSM on a 5000 series switch, or an MSFC on a 6000 series switch.</PARA>
<PARA>We will start with the most basic and essential commands, then move on to management commands that can be used for verification and troubleshooting if necessary. </PARA>
<PARA>This is the first and foremost command that must be configured on the MLS-RP. It should be entered in as a global configuration. Because methods differ between external routers and the MSFC for the 6000 series switches, both will be discussed.</PARA>
<PARA>The command is still issued as a global command on the MSFC. However, the syntax is slightly different. MLS is on by default on the MFSC, but if you need to issue the command, the syntax is <INLINECODE>mls ip</INLINECODE>.</PARA>
<PARA>This command is required for MLS to operate on the MLS-RP. The following sections discuss optional configuration settings. These options will depend on the existing layer 2 network and configuration. All of the remaining sections, except "Verifying the MLS Configuration," apply only to external routers.</PARA>
<PARA>If a router interface is connected to a switch that is a VTP server or client, assigning the VLAN Trunk Protocol (VTP) domain is also a necessary step for MLS to work properly. It is very important to note that this step should be executed before any further MLS interface-specific commands are entered.</PARA>
<SECTION ID="7.2.2.1"><TITLE>Verifying the VTP Domain</TITLE>
<PARA>First you should verify which VTP domain the interface belongs to. This is done with the <INLINECODE>show vtp domain</INLINECODE> command from the switch. You can also obtain this information by looking at the switch configuration. Here are the two examples:</PARA>
<PARA>Once you have the VTP domain name, you are ready to assign the router interface to that VTP domain. This is done with the execution of the command <INLINECODE> mls rp vtp-domain [</INLINECODE><INLINECODEVARIABLE>domain-name</INLINECODEVARIABLE><INLINECODE>]</INLINECODE> on the specified interface.</PARA>
<PARA>This command is used only if an external router's interface is not using ISL or 802.1q encapsulation. (RSMs and MSFCs use logical VLAN interfaces.) An example may be when a router has two physical interfaces connected to the same switch, each to a different VLAN. This scenario doesn't require that the router be aware of VLAN assignments.</PARA>
<PARA>If you wish to enable MLS on interfaces that are not encapsulated, you can issue the <INLINECODE>mls rp vlan-id [</INLINECODE><INLINECODEVARIABLE>vlan-id-number</INLINECODEVARIABLE><INLINECODE>]</INLINECODE> command to assign a VLAN to the interface. Here is an example:</PARA>
<PARA>Once VTP and VLAN assignments have been made, you can finally enable MLS on the interface. This is done with the same command that was used to globally enable MLS, <INLINECODE>mls rp ip</INLINECODE>. Here is an example:</PARA>
<PARA>You may remember that we discussed that there were three components to MLS. The third component was MLSP. Well, in order for MLS to function between a switch and a router, MLSP must be able to communicate between both devices.</PARA>
<PARA>This requirement makes this next configuration step essential for MLS functionality. At least one interface on the router that is connected to the same switch must be enabled as the management interface. This indicates which interface is going to allow MLSP exchanges.</PARA>
<PARA>Another requirement is that there be at least one management interface per VLAN on the switch. To specify a router interface as a management interface, issue the <INLINECODE>mls rp management-interface</INLINECODE> command on the specified interface. Here is an example of the syntax for the command:</PARA>
<SECTION ID="7.2.6"><TITLE>Verifying the MLS Configuration</TITLE>
<PARA>Once all of the pieces have been configured, you may issue the <INLINECODE>show mls rp</INLINECODE> command to view the MLS status and information on the router. There are two options in correlation with the main command. All three commands are shown here:</PARA>
<CODELINE> keepalive timer expires in 4 seconds</CODELINE>
<CODELINE> retry timer not running</CODELINE>
<CODELINE> change timer not running</CODELINE>
<CODELINE> fcp subblock count = 1</CODELINE>
<CODELINE></CODELINE>
<CODELINE> 1 management interface(s) currently defined:</CODELINE>
<CODELINE> vlan 10 on FastEthernet4/0</CODELINE>
<CODELINE></CODELINE>
<CODELINE> 1 mac-vlan(s) configured for multi-layer switching:</CODELINE>
<CODELINE></CODELINE>
<CODELINE> mac 0010.a6a9.3470</CODELINE>
<CODELINE> vlan id(s)</CODELINE>
<CODELINE> 10 </CODELINE>
<CODELINE></CODELINE>
<CODELINE> router currently aware of following 1 switch(es):</CODELINE>
<CODELINE> switch id 00-e0-4e-2d-43-ef</CODELINE>
<CODELINE></CODELINE>
<CODELINE>RouterA#</CODELINE></CODESNIPPET>
<PARA>Here is an example of the interface option:</PARA>
<CODESNIPPET><CODELINE>RouterA#<EMPHASIS FORMAT="bold">show mls rp interface fastethernet 4/0</EMPHASIS></CODELINE>
<CODELINE>mls active on FastEthernet4/0, domain test</CODELINE>
<CODELINE>interface FastEthernet4/0 is a management interface</CODELINE>
<CODELINE>RouterA#</CODELINE></CODESNIPPET>
<PARA>These are the <INLINECODE>show</INLINECODE> commands, and as with any IOS, there are debugging opportunities. Table 7.1 provides a summary of the debug commands available for MLS troubleshooting.</PARA>
<TABLEENTRY><PARA>Displays information on all MLS verbose packets</PARA></TABLEENTRY>
</TABLEROW>
</TABLEBODY>
</TABLE>
</SECTION>
<SECTION ID="7.2.7"><TITLE>Access Lists</TITLE>
<PARA>Access control lists (ACLs) throw an interesting twist into MLS configuration and operation. There are some definite caveats when trying to use MLS and ACLs at the same time.</PARA>
<PARA>Until IOS release 12.0(2), inbound access lists were not supported. If a router interface had an inbound access list applied, MLS was disabled. With versions after 12.0(2), inbound access lists are supported.</PARA>
<PARA>Outbound ACLs are a little more problematic. Although they have always been supported, application thereof causes the MLS cache to clear and reestablish. Also, outbound lists utilizing the following functions will disable MLS on the interface to which they are applied:</PARA>
<LIST MARK="bullet">
<LISTITEM><PARA>TOS</PARA></LISTITEM>
<LISTITEM><PARA>Established</PARA></LISTITEM>
<LISTITEM><PARA>Log</PARA></LISTITEM>
<LISTITEM><PARA>Precedence</PARA></LISTITEM>
</LIST>
</SECTION>
</SECTION>
<SECTION ID="7.3"><TITLE>Configuring the MLS Engine</TITLE>
<PARA><DROPCAP>S</DROPCAP>witch configuration is very simple. MLS is on by default for both the 6000 and 2926G and for the 5000s with RSMs and NFFC cards in them. The only time that it is necessary to perform configuration tasks on the MLS-SE is when you want to change specific MLS attributes or when the device requires configuration. Here are some examples:</PARA>
<LIST MARK="bullet">
<LISTITEM><PARA>Using an external router</PARA></LISTITEM>
<LISTITEM><PARA>Changing the MLS cache aging timers</PARA></LISTITEM>
<LISTITEM><PARA>Enabling NDE (NetFlow Data Export)</PARA></LISTITEM>
</LIST>
<PARA>Each of these topics will be addressed in the following sections.</PARA>
<SECTION ID="7.3.1" POS="1"><TITLE>Enabling MLS on the MLS-SE</TITLE>
<PARA>As mentioned, the only time you need to actually enable MLS on the MLS-SE is when it has been disabled or on a system on which MLS is off by default.</PARA>
<PARA>To enable MLS on the MLS-SE, issue the command <INLINECODE>set mls enable</INLINECODE>. Here is an example:</PARA>
<CODESNIPPET><CODELINE>Switch2> (enable)<EMPHASIS FORMAT="bold"> set mls enable</EMPHASIS></CODELINE>
<CODELINE>Multilayer switching is enabled</CODELINE>
<PARA>MLS entry or shortcut cache exists on the NFFC for the 5000 series switches and on the PFC for 6000 series switches. The purpose for the cache is consistent across all platforms. The cache is a layer 3 switching table. It maintains the flow information that facilitates MLS.</PARA>
<PARA>Here is a sample of a layer 3 cache table:</PARA>
<PARA>Cache entries are kept while the flow is active. Once the flow no longer receives traffic, the cache entry gets aged out and removed from the layer 3 cache on the NFFC or PFC. This attribute can be modified and adjusted. The following sections describe how this can be done.</PARA>
<SECTION ID="7.3.2.1"><TITLE>Modifying the Cache Aging Time</TITLE>
<PARA>A layer 3 cache entry will remain in cache for 256 seconds after the last packet for the flow has passed through the switch. This is the default value. The value can be changed to different values depending on your needs as a network administrator.</PARA>
<PARA>The syntax is <INLINECODE>set mls agingtime </INLINECODE><INLINECODEVARIABLE>agingtime</INLINECODEVARIABLE><INLINECODE>,</INLINECODE> where <INLINECODEVARIABLE>agingtime</INLINECODEVARIABLE> is a value of seconds. The value is a multiple of 8. The valid range is from 8 to 2032. If the value specified is not a multiple of 8, the nearest multiple will be used. Here is an example:</PARA>
<SECTION ID="7.3.2.2"><TITLE>Modifying Fast Aging Time</TITLE>
<PARA>When the layer 3 cache grows greater than 32K in size, there is an increased possibility that the PFC or NFFC will not be able to perform all layer 3 switching, causing some packets to be forwarded to the router. To aid in maintaining a layer 3 cache smaller than 32K, you can enable and adjust fast aging times</PARA>
<PARA>Because some flows can be very short, you can enable packet thresholds that can be used in correlation with the fast aging time to quickly age out these entries. Both of these attributes are thresholds. When you set the fast aging time, you specify the amount of time for which <EMPHASIS FORMAT="italic">n </EMPHASIS>number of packets (defined by the packet threshold) must have used the cache entry.</PARA>
<PARA>When a flow is initialized, the switch must see a number of packets equal to or greater than the packet threshold set within the time specified by the fast aging time. If this criterion isn't met, the cache entry is aged out immediately.</PARA>
<PARA>Valid values for the fast aging time are 32, 64, 96, and 128. Valid values for the packet threshold are 0, 1, 3, 7, 15, 31, and 63. Let's do an example so we can understand how this works.</PARA>
<PARA>Say you configured a fast aging time of 64 seconds and the packet threshold to 31 packets using the <INLINECODE>set mls agingtime fast 64 31</INLINECODE> command on the switch. This is telling the MLS-SE that a layer 3 cache entry has 64 seconds in which 31 packets or more must utilize the entry. If this doesn't happen, the cache entry is removed.</PARA>
<PARA>The actual syntax for the command is <INLINECODE>set mls agingtime fast </INLINECODE><INLINECODEVARIABLE>fastagingtime pkt-threshold</INLINECODEVARIABLE>. An example configuration follows:</PARA>
<CODESNIPPET><CODELINE>Switch2> (enable) <EMPHASIS FORMAT="bold">set mls agingtime fast 64 31</EMPHASIS></CODELINE>
<CODELINE>Multilayer switching fast aging time set to 64 seconds for entries with no more than 31 packets switched.</CODELINE>
<SECTION ID="7.3.2.3"><TITLE>Verifying the Configuration</TITLE>
<PARA>MLS-SE configuration settings can be seen by using the <INLINECODE>show mls ip</INLINECODE> command. The command provides information regarding the aging time, fast aging time, and packet threshold values. In addition, it gives summary statistics for the type of flow mask and MLS entries. Finally, it provides details about the MLS-RP, including XTAG, MAC, and VLAN values. Here is an example:</PARA>
<SECTION ID="7.3.3"><TITLE>Displaying the MLS Cache Entries</TITLE>
<PARA>There are several different methods of viewing MLS cache entries. The base command is <INLINECODE>show mls entry</INLINECODE>. However, there are many options available to customize the output of this basic command.</PARA>
<PARA>If you are on a switch and issue the help command for <INLINECODE>show mls entry</INLINECODE>, this is what you get.</PARA>
<PARA>As you can see, there are quite a few different options. This command, with the options shown, allows the administrator to view very general information or very specific information. To get an idea of what can be generated from this command, let's review the options.</PARA>
<PARA>You can show MLS entries based on the module. The <INLINECODE>long</INLINECODE> and <INLINECODE>short</INLINECODE> options modify the output in different ways. <INLINECODE>Long</INLINECODE> displays the information all on one line, and <INLINECODE>short</INLINECODE> displays the information using carriage returns. It is impossible to give an example due to the formatting limitations in this course.</PARA>
<PARA>More specific information can be obtained by specifying an IP address or port information. By specifying options, you can refine your output. Instead of getting pages and pages of cache entries, you get entries that match your criteria.</PARA>
<PARA>If you do not want to wait for aging times to expire, or if you want to clear the cache immediately, you can issue the <INLINECODE>clear mls entry</INLINECODE> command. This command also has options that allow the network administrator to clear specific cache entries instead of the entire table.</PARA>
<PARA>The syntax of the command is as follows:</PARA>
<PARA>The use of the <INLINECODE>all</INLINECODE> option keyword causes all MLS cache entries to be removed. If you use specific IP addresses, ports, or protocols, specific cache entries can be removed.</PARA>
<!-- <PARA><DROPCAP>T</DROPCAP>here are few topologies that support MLS. Due to the nature of MLS, only certain system topologies will allow candidate and enable packets to transit the router and switch properly. If both candidate and enable packets cannot be identified, no complete flow cache entry can be made. Acceptable topologies include the following:</PARA>
<RUNINBLOCK><RUNINHEAD>Router on a stick</RUNINHEAD>
<RUNINPARA>This includes one router (internal RSM/MSFC or external) and one switch. See Figure 7.7.</RUNINPARA></RUNINBLOCK>
<RUNINBLOCK><RUNINHEAD>Multiple switches, one router</RUNINHEAD>
<RUNINPARA>This is acceptable if only one switch connects to the router and the switches are connected via an ISL trunk. See Figure 7.8</RUNINPARA></RUNINBLOCK>
<RUNINBLOCK><RUNINHEAD>Two routers, one switch</RUNINHEAD>
<RUNINPARA>This works, but it requires more work for the MLS-SE. The packet must be rewritten twice to account for the hops across two routers. It also requires the candidate and enable packets to be identified for each router. See Figure 7.9</RUNINPARA></RUNINBLOCK> -->
<SLUG NUM="7.7">Figure 7.7: Router on a stick [f0707.eps]</SLUG>
<!-- <SLUG NUM="7.8">Figure 7.8: Multiple switches, one router [f0708.eps]</SLUG> -->
<!-- <SLUG NUM="7.9">Figure 7.9: Single switch, two routers [f0709.eps]</SLUG> -->
</SECTION>
<SECTION ID="7.5"><TITLE>Summary</TITLE>
<PARA><DROPCAP>Y</DROPCAP>ou have learned a great deal in this chapter. It is important that you understand the fundamentals of MLS as well as the different platforms that support it. </PARA>
<PARA>The fact that MLS is supported on multiple platforms shouldn't be of much concern. However, implementation and configuration syntax depend greatly on the equipment and topology being deployed. </PARA>
<PARA>To summarize, in this chapter you learned the following:</PARA>
<LIST MARK="bullet">
<LISTITEM><PARA>The fundamentals of MLS: layer 3 switching</PARA></LISTITEM>
<LISTITEM><PARA>Components of MLS</PARA></LISTITEM>
<LISTITEM><PARA>System and topology requirements</PARA></LISTITEM>
<LISTITEM><PARA>Candidate and enable packet identification processes</PARA></LISTITEM>
<SECTION ID="7.5.2"><TITLE>Commands Used in This Chapter</TITLE>
<PARA>The following table provides a summary of the commands used in this chapter. There were no access layer switches used in this chapter, so the table is based on a distribution switch.</PARA>
<TABULARENTRY>Provides VTP domain information on the switch.</TABULARENTRY>
</TABULARROW>
<TABULARROW>
<TABULARENTRY><INLINECODE>mls rp vtp-domain [</INLINECODE><INLINECODEVARIABLE>domain-name</INLINECODEVARIABLE><INLINECODE>]</INLINECODE></TABULARENTRY>
<TABULARENTRY>Assigns the interface to the VTP domain.</TABULARENTRY>
</TABULARROW>
<TABULARROW>
<TABULARENTRY><INLINECODE>mls rp vlan-id [</INLINECODE><INLINECODEVARIABLE>vlan-id-number</INLINECODEVARIABLE><INLINECODE>]</INLINECODE></TABULARENTRY>
<TABULARENTRY>Assigns the interface the proper VLAN number. </TABULARENTRY>
</TABULARROW>
<TABULARROW>
<TABULARENTRY><INLINECODE>mls rp management-interface</INLINECODE></TABULARENTRY>
<TABULARENTRY>Assigns the interface to the MLS-RP. This allows MLSP updates to use this interface.</TABULARENTRY>
<TABULARENTRY>Allows all MLS entries to be cleared in addition to allowing specific entries to be terminated.</TABULARENTRY>
</TABULARROW>
</TABULARBODY>
</TABULARDATA>
</SECTION>
</SECTION>
<TESTSECTION ID="7.6"><TITLE>Written Lab</TITLE>
<!-- <PARA>Write out the answers to the following questions.</PARA>
<TESTDATA>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the command that enables MLS globally on an external router.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the command that will assign the VTP domain to the external router's interface. Use <EMPHASIS FORMAT="italic">cisco</EMPHASIS> as the VTP domain name</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the command that will assign VLAN 5 to the interface.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the command that will configure an external router interface to allow MLSP packets across it.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the command that will show you MLS information on a switch.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the command that will show you the XTAG information on a switch.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the command that will display all of the layer 3 cache entries.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the command that will display a layer 3 cache entry based on the destination IP address of 172.16.10.100.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the command to clear all MLS cache entries.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Write the command that sets the fast aging time to 64 and the packet threshold to 63.</QUESTION></QUESTIONBLOCK></TESTBLOCK>
</TESTDATA> -->
<SLUG NONUM="w1"/>
</TESTSECTION>
<TESTSECTION ID="7.7"><TITLE>Hands-On Lab</TITLE>
<PARA>Refer to Figure 7.10 for the topology of this lab. This lab will use the simplest architecture: router on a stick using a Catalyst 5000 and an external router (7200 series).</PARA>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Assume that RouterA does not have MLS enabled. You may assume that the subinterfaces are running ISL and have VLAN assignments. Switch1 is a VTP server for the sybex domain. Configure MLS to work on RouterA.</QUESTION></QUESTIONBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>The aging timers need to be adjusted to be shorter than the default of 256 seconds. Make the new value 128. In addition to changing the aging timers, add a command that will help keep the layer 3 cache size under 32K. To do this, use values of agingtimer = 64 and packet-threshold = 31.</QUESTION></QUESTIONBLOCK>
<TESTBLOCK><QUESTIONBLOCK><QUESTION>Verify MLS status on the switch and router. Provide samples of the MLS entries and XTAG values.</QUESTION></QUESTIONBLOCK>
<ANSWERBLOCK><ANSWER><EMPHASIS FORMAT="bold">Answer:</EMPHASIS> Results will vary on this answer; here are the commands that should be issued:<LIST MARK="bullet">
<LISTITEM>
<PARA><INLINECODE>show mls</INLINECODE> (executed on the switch)</PARA></LISTITEM>
<LISTITEM><PARA><INLINECODE>show mls rp</INLINECODE> (executed on the router)</PARA></LISTITEM>
<LISTITEM><PARA><INLINECODE>show mls entry</INLINECODE> (executed on the router) </PARA></LISTITEM>
</LIST></ANSWER></ANSWERBLOCK></TESTBLOCK>
</TESTDATA>
</TESTSECTION>
<TESTSECTION ID="7.8"><TITLE>Answers to Written Lab</TITLE>
<TESTDATA>
<TESTBLOCK><ANSWERBLOCK><ANSWER><INLINECODE>mls rp ip</INLINECODE></ANSWER></ANSWERBLOCK></TESTBLOCK>
<TESTBLOCK><ANSWERBLOCK><ANSWER><INLINECODE>mls rp vtp-domain cisco</INLINECODE></ANSWER></ANSWERBLOCK></TESTBLOCK>
<TESTBLOCK><ANSWERBLOCK><ANSWER><INLINECODE>mls rp vlan-id 5</INLINECODE></ANSWER></ANSWERBLOCK></TESTBLOCK>
<TESTBLOCK><ANSWERBLOCK><ANSWER><INLINECODE>mls rp management-interface</INLINECODE></ANSWER></ANSWERBLOCK></TESTBLOCK>
