Home > Articles > Cisco Certification > CCNP > CCNP Practical Studies: Layer 3 Switching

CCNP Practical Studies: Layer 3 Switching

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Nov 26, 2003.

Scenario 6-1: Configuring MLS on the Catalyst 6000

In this scenario, you learn how to configure Multilayer switching (MLS), which represents the first Layer 3 switching technology used by Cisco Catalyst switches to provide wire-speed routing of inter-VLAN traffic. Although MLS is no longer considered the ideal L3 switching architecture, many installations still use MLS, and hence, you as a Cisco engineer must be able to configure and troubleshoot MLS.

Figure 6-9 illustrates the topology used for this scenario. In Figure 6-9, an MLS configuration is to be used to provide the high-speed Layer 3 switching of inter-VLAN traffic on Switch-A. Router-A is required to provide routing control plane operation, initially routing the first packet of each flow sent through the Switch-A, allowing Switch-A to learn the required MAC address rewrite operations for Layer 3 switching.

Figure 9Figure 6-9 Scenario 6-1 Topology

The following describes the function of each component of the lab topology shown in Figure 6-9:

  • Switch-A is a Catalyst 5509 switch with a Supervisor 3G module installed. In this scenario, Switch-A acts as the MLS Switching Engine (MLS-SE), which is responsible for the data plane operations required for Layer 3 switching.

  • Router-A is a Cisco 3620 router with a physical FastEthernet interface that connects as an 802.1Q to Switch-A. Two virtual interfaces are required on the trunk to provide inter-VLAN routing between each VLAN. Router-A acts as an MLS Route Processor (MLS-RP), which is responsible for making routing decisions for the first packet associated with an MLS flow.

  • Host-X and Host-Y are workstations that are used to test that inter-VLAN routing works with MLS configured.

Understanding MLS

MLS represents the first hardware-based Layer 3 switching mechanism used by Cisco Catalyst switches, supported on switches such as the Catalyst 5000/5500 and Catalyst 6000/6500. This section explains the operation of MLS and how Layer 3 switches use MLS.

MLS Overview

MLS is designed to support a distributed L3 switching architecture, which means the various components of MLS do not need to be located on the same physical device. MLS consists of the following two main components:

  • MLS Route Processor (MLS-RP)—This component represents the control plane of the routing process. The MLS-RP maintains the route table and is responsible for updating the route table as changes in the network topology occur.

  • MLS Switching Engine (MLS-SE)—This component represents the data plane of the routing process. The MLS-SE is responsible for determining the next hop and egress interface information for each frame received that requires routing, and then rewriting the frame as required and forwarding the frame to the correct egress interface.

The route table is maintained on the MLS-RP, and this control plane information must somehow be communicated to the MLS-SE. The MLS-RP and MLS-SE communicate using the MLS protocol (MLSP), which is a Cisco proprietary protocol that uses multicast Ethernet frames to communicate.

Flows are used to represent routing information in the route cache located on the MLS-SE. A flow can be defined based upon a unique destination IP address, a unique combination of source and destination IP address, or a unique combination of source and destination IP address, as well as source and destination Layer 4 (i.e., TCP or UDP) ports. For example, all packets that are sent from any source IP address to a destination IP address of can be represented as a flow. All packets sent from a source IP address of to a destination IP address of can be represented by a flow, with the return packets represented as another flow.

For each flow, the MLS-SE builds the required frame rewrite information for Layer 3 switching (i.e., source and destination MAC address rewrite information) by allowing the MLS-RP to perform the normal routing process for the first frame of each new flow. This allows the MLS-SE to learn the required rewrites for the source and destination MAC address of a framed IP packet after it has been routed, with the appropriate information stored in an MLS cache. Figure 6-10 demonstrates the MLS architecture and how packets are routed using MLS using flows.

Figure 10Figure 6-10 MLS Architecture

The following describes the events that occur in Figure 6-10:

Step 1

Host-X sends an IP packet to Host-Y ( Because the packet is on a different IP subnet from Host-X, Host-X addresses the Ethernet frame containing the IP packet to the configured default gateway (MLS-RP) for routing, meaning the frame has a destination MAC address of 0010.7be2.aba0.

Step 2

The frame is received by the MLS-SE, which initially examines the destination MAC address of the frame. Because the destination MAC address is the MAC address of the MLS-RP (0010.7be2.aba0), the MLS-SE immediately marks the frame as a candidate frame for L3 switching (as any L3 switched frame always has a destination MAC address of a routing device). The MLS-SE inspects the destination IP address in the packet and checks the MLS cache for a flow. Because this is the first packet sent to Host-Y, no entry is present so the packet is sent to the MLS-RP for routing. An incomplete flow entry is written in the MLS cache, which includes only information that identifies the flow at this stage (e.g., destination IP address).

Step 3

The MLS-RP receives the frame and performs normal IP routing, inspecting the destination IP address and determining from the local route table that the destination is locally attached. The MLS-RP determines the MAC address of Host-Y by checking the ARP cache (and sending an ARP request if the ARP cache does not contain the entry) and generates a new Ethernet frame to transport the IP packet to its intended destination.

Step 4

The MLS-SE receives the routed frame and writes the destination MAC address of the routed frame into the incomplete flow entry that was initially created in Step 2. The switch also consults the local bridge table to determine the egress port associated with the destination MAC address and writes this information into the flow entry as well. The flow entry information is used for future rewriting and forwarding of packets sent to Host-Y without having to forward the packets to the MLS-RP.

Step 5

The frame is switched out the appropriate egress port (2/3) to Host-Y.

Step 6

Host-X sends another IP packet to Host-Y. The MLS-SE sees from the destination MAC address that the frame is destined to the MLS-RP and is therefore a candidate for L3 switching. The MLS-SE inspects the destination IP address ( and matches it against the flow entry completed in Step 4. The MLS-SE rewrites the destination MAC address of the frame and performs other necessary L3 switching operations (such as decrementing the IP TTL and computing the IP and Ethernet checksums).

Step 7

The rewritten frame is switched out the correct egress port (2/3) to Host-Y. All subsequent IP packets from Host-X to Host-Y are L3 switched as described in Step 6 and Step 7 as long as the flow entry created in Step 4 is valid.

As you can see from Figure 6-10, MLS requires the first packet in a flow to be routed through the MLS-RP, which allows the MLS-SE to determine the appropriate information that must be rewritten by the MLS-SE for the subsequent L3 switching of packets to Host-Y.

The MLS-RP and MLS-SE also communicate regularly, so that if the MLS-SE can detect if an MLS-RP goes down, the MLS-SE can flush the appropriate flow entries in the MLS cache. This is important in a redundant topology where two or more MLS-RPs provide inter-VLAN routing, because it ensures the redundant MLS-RP can be used if the primary MLS-RP fails.

MLS Flows

Because the MLS architecture is based on flows, it is important to understand the different type of flows that exist. Each flow can be categorized as belonging to a particular flow mask. A flow in MLS terms represents one of the following (the name of the flow mask that categorizes the flow is indicated in parentheses):

  • Destination IP address (destination-only)—A single destination IP address can represent a flow. All traffic sent to the destination IP address is part of a single flow. In Figure 6-10, flows were represented by destination IP address.

  • Source and Destination IP address (source-destination)—All traffic sent between a specific source and destination IP address is part of a single flow. This means that several flows might exist for the same destination IP address; each flow is differentiated by the source IP address.

  • Full flow (full)—A full flow represents all traffic associated with a specific source IP address, destination IP address, source TCP/UDP port, and destination TCP/UDP port. For example, a Telnet connection between and would be represented by a separate flow from an HTTP connection between the same two hosts.

Flows are important because the route cache used by MLS uses flows to store the information for the hardware-based rewrites required for Layer 3 switching process. The flow you use depends on the requirements of your network. For example, if you are using simple routing (where routing decisions only need to be made based solely upon the destination IP address of each packet), destination IP address flows are only required. However, if you are using access control lists (ACLs) on a routed interface through which a packet would normally travel, you need to use source and destination IP address or full flows depending on the granularity of the ACLs. For example, Figure 6-11 shows the topology of Figure 6-10 with an extended ACL configured on an interface on the MLS-RP.

Figure 11Figure 6-11 MLS Architecture and ACLs

The following describes the events that occur in Figure 6-11:

Step 1

Host-X attempts to establish an HTTP connection to Host-Y, sending an IP packet with a source IP address of, destination IP address of, protocol number of 6 (TCP), destination TCP port of 80, and a random source TCP port of 1111. The frame for the IP packet is addressed to the MLS-RP, because Host-Y is not on the local subnet. The MLS-SE receives the frame, marks it as a candidate frame, and routes the frame to the MLS-RP, because no flow entry exists that matches the packet. When the MLS-RP receives the packet, it is inspected against the ACL and is permitted because the packet is a TCP packet with a destination port of 80. The MLS-SE receives the routed packet, allowing it to write a complete flow entry in the MLS cache.

Step 2

Host-X next attempts to establish an FTP connection to Host-Y. Because the flow cache on the MLS-SE is now using a full flow mask, the FTP packet sent does not match the flow entry created in Step 1 and hence is forwarded to the MLS-RP. The MLS-RP inspects the packet against the ACL and drops the packet because it is not an HTTP packet. This means that the MLS-SE never sees the return routed frame come back from the MLS-RP that includes the required information to complete the entry for the flow, meaning the MLS-SE can never complete the incomplete flow entry created when the packet was first received by the MLS-SE. Any subsequent FTP connection requests (or any other non-HTTP traffic) is always forwarded to the MLS-RP (because no complete flow entries ever exist on the MLS-SE), at which point the traffic is dropped.

Step 3

All traffic associated with the HTTP connection established in Step 1 is Layer 3 switched by the MLS-SE. If a new HTTP connection is established between Host-X and Host-Y, a new flow entry must be built (as per Step 1), because the source TCP port is different for each connection. In Figure 6-11, you can see two flow entries, which each represent separate HTTP connections established from Host-X to Host-Y.

In Figure 6-11, a full flow must be used because the MLS-RP must be able to permit traffic based on specific combinations of source and destination IP address and source and destination TCP/UDP ports. If a destination or destination-source flow were used in Figure 6-11, the MLS-SE would not differentiate HTTP packets from FTP packets and FTP packets would be incorrectly L3 switched (permitted) to Host-Y.


The MLS-RP can communicate the required flow mask to the MLS-SE, which ensures that if an ACL is applied in an existing MLS configuration, the appropriate flow mask is immediately used on the MLS-SE ensuring packets are not incorrectly permitted if they have been denied in the ACL.

MLS Communications

MLS requires some internal communications between the MLS-RP and MLS-SE to ensure L3 switching on the MLS-SE is performed accurately and correctly. Two major events that can cause the MLS cache to become invalid:

  • Routing topology changes

  • ACL configuration

If a routing topology change occurs, it is possible that flow information in the MLS cache needs to be updated. This is also the case if an ACL is applied to an interface (or modified) on the MLS-RP. The MLS-RP and MLS-SE use MLSP messages to communicate with each other. The MLS-RP sends MLSP messages to the MLS-SE if either of the above events occur, which indicate to the MLS-SE that it should flush the MLS cache and possibly modify the flow mask used. An example of when the flow mask would be changed is when an extended ACL is applied to a previously unfiltered interface. As you saw in Figure 6-11, a full flow mask is required when extended ACLs are used, so the MLS-RP sends an MLSP message to the MLS-SE to flush its MLS cache and update the flow mask.


MLSP communications are also used to verify that MLS components are still alive via the exchange of hello packets. These messages are sent every 15 seconds by default.

In an environment where multiple MLS-RPs are present, the MLS-SE must be able to differentiate between each MLS-RP. This can be done based upon the MAC address of each MLS-RP; however, if there are thousands of flow entries in the MLS cache and if each of the entries associated with an MLS-RP that has just gone down need to be flushed, searching through the cache based upon a 48-bit MAC address value can take some time. To facilitate faster cache purges, an 8-bit XTAG value is assigned to MLS-RP, which acts like an index for each MLS-RP, allowing the MLS-SE to differentiate between the flow entries associated with each MLS-RP much more quickly.

Cisco Platform Support for MLS

It is important to understand that MLS is now considered a legacy technology and as such is not supported on many newer Cisco Catalyst switches. Table 6-2 lists the Cisco Catalyst switch platforms that the MLS-SE component is supported on.

Table 6-2 MLS-SE Supported Platforms


Hardware Requirements

Software Requirements

Catalyst 5000/5500

Supervisor 2G/3G/3/3F

NetFlow Feature Card

CatOS 4.1(1)

Catalyst 6000/65001

Policy Feature Card


1The Catalyst 6000/6500 MLS-SE supports only operation with a locally installed MSFC as the MLS-RP. No support for an external MLS-RP is currently provided.

Table 6-3 lists the router platforms that the MLS-RP component is supported on.

Table 6-3 MLS-RP Supported Platforms


Software Requirements






Catalyst 5000 RSM/RSFC


Catalyst 6000 MSFC

All software trains


It is important to note that the Catalyst 6000/6500 Supervisor 1A with PFC can act only as an MLS-SE in conjunction with the Catalyst 6000/6500 MSFC; in this configuration, the MLS-SE (the PFC) and MLS-RP (the MSFC) do not communicate over IP, instead communicating via an internal bus. However, the MSFC can act as an MLS-RP with other MLS-SEs such as a Catalyst 5000 with NetFlow Feature Card (NFFC).

Scenario Prerequisites

To successfully commence the configuration tasks required to complete this scenario, Table 6-4 describes the prerequisite configurations required on each device in the scenario topology. Any configurations not listed can be assumed as being the default configuration.

Table 6-4 Scenario 6-1 Requirements


Required Configuration









sc0 IP Address (VLAN) (VLAN 1)


Enable/Telnet Password



VTP Mode



VTP Domain Name



VLANs (Name)



VLAN Assignments

VLAN 2: port 2/3


ISL Trunks (DTP Mode)

2/1 (nonegotiate)





Enable/Telnet Password



ISL Trunks



ISL Trunk Subinterfaces

FastEthernet0/0.1 (VLAN 1)


IP Address

FastEthernet0/0.2 (VLAN 2)


(Interface) (fa0/0.1) (fa0/0.2)


Operating System

Windows 2000 Professional or Windows XP


IP Address


Default Gateway


Operating System

Windows 2000 Professional or Windows XP


IP Address


Default Gateway



Telnet server (e.g. Microsoft Telnet Server)

Example 6-1 and Example 6-2 shows the configuration required on Switch-A and Router-A before you can begin this scenario.

Example 6-68 Scenario 6-1 Prerequisite Configuration for Switch-A

Console> (enable) set system name Switch-A
System name set.
Switch-A> (enable) set password
Enter old password: _
Enter new password: *****
Reenter new password: *****
Switch-A> (enable) set enablepass
Enter old password: _
Enter new password: *****
Retype new password: *****
Switch-A> (enable) set interface sc0
Interface sc0 IP address and netmask set.
Switch-A> (enable) set vtp mode transparent
VTP domain modified
Switch-A> (enable) set vtp domain lanps
VTP domain lanps modified
Switch-A> (enable) set vlan 2 name VLAN2
Vlan 2 configuration successful
Switch-A> (enable) set trunk 2/1 nonegotiate isl
Port(s) 2/1 trunk mode set to nonegotiate.
Port(s) 2/1 trunk type set to isl.
Switch-A> (enable) set vlan 2 2/3
VLAN 2 modified.
VLAN 1 modified.
VLAN Mod/Ports
---- -----------------------
2   2/3

Example 6-69 Scenario 6-1 Prerequisite Configuration for Router-A

Router# configure terminal
Router(config)# hostname Router-A
Router-A(config)# enable secret cisco
Router-A(config)# line vty 0 4
Router-A(config-line)# password cisco 
Router-A(config-line)# exit 
Router-A(config)# interface FastEthernet0/0
Router-A(config-if)# no shutdown
Router-A(config-if)# exit
Router-A(config)# interface FastEthernet0/0.1
Router-A(config-if)# encapsulation isl 1
Router-A(config-if)# ip address
Router-A(config-if)# exit
Router-A(config)# interface FastEthernet0/0.2
Router-A(config-if)# encapsulation isl 2
Router-A(config-if)# ip address

After the prerequisite configuration is implemented, you should attach each device as indicated in Figure 6-9 and verify PING connectivity between devices in the network before proceeding.

Configuration Tasks

As you have learned, MLS consists of an MLS-SE and MLS-RP, which must each be configured separately. Configuring MLS requires the following configuration tasks:

  • Configuring the MLS-RP

  • Configuring the MLS-SE

  • Verifying MLS operation

Configuring the MLS-RP

When configuring MLS on the MLS-RP, you must configure MLS globally on the router, which then enables you to configure global MLS parameters as well as specific interfaces for MLS. Before you can enable any MLS interface, you must configure the same VTP domain used by the MLS-SE on each MLS-enabled interface. This is because MLSP communications between MLS components cannot cross VTP domain boundaries. You must also configure an MLS management interface, which is the interface used to send and receive MLSP messages. Once you have completed all these tasks, you can then enable MLS on the required interfaces. In summary, this requires the following configuration tasks:

  • Enabling MLS globally

  • Configuring MLS on interfaces

Enabling MLS Globally

The first configuration task for configuring MLS on an MLS-RP is to enable MLS globally, which enables further configuration of specific MLS parameters. To enable MLS globally, the mls rp ip global configuration command is used, as demonstrated in Example 6-3 on Router-A.

Example 6-70 Enabling IP MLS on Router-A

Router-A# configure terminal
Router-A(config)# mls rp ip

Configuring MLS on Interfaces

After enabling MLS globally on the MLS-RP, you next configure MLS on each interface that needs to communicate with MLS-SEs. Each interface that needs to communicate with an MLS-SE requires the following configuration:

  • The VTP domain of the MLS-SE switches that the MLS-RP communicates with via the interface must be configured.

  • MLS must be explicitly enabled on the interface.

An MLS-RP also requires a single interface to be designated as a management interface, which defines the interface used for MLS-RP λν MLS-SE communications. Without a management interface, the MLS-RP does not function.

To configure MLS on an interface, the mls interface configuration command is used, which has the following syntaxes:

Switch(config-if)# mls rp vtp-domain vtp-domain-name
Switch(config-if)# mls management-interface
Switch(config-if)# mls rp ip

The following describes each of the command syntaxes listed above:

  • mls rp vtp-domain—Defines the VTP domain of the MLS-SEs connected to the interface. The configured VTP domain must match the VTP domain configured on MLS-SEs; otherwise, MLS communications fail.

  • mls management-interface—Defines the interface as the MLS management interface. Only one interface can be configured as a management interface.

  • mls rp ip—Enables MLS operation on the interface.


Always configure the VTP domain first, before configuring any other MLS commands on an interface. If you do not specify the VTP domain first, as soon as you configure another MLS command (e.g., enable MLS or configure a management interface), a null VTP domain will be assumed and configured. To change the VTP domain, all MLS interface configuration must be removed. Hence, to save time and frustration, always configure the appropriate VTP domain first.

In this scenario, Router-A has two subinterfaces configured (fastEthernet0/0.1 and fastEthernet0/0.2) over a physical trunk to Switch-A, which belong in VLAN 1 and VLAN 2 respectively. MLS must be enabled on both these interfaces, and a management interface must also be configured. Example 6-4 demonstrates enabling MLS on both interfaces and configuring fastEthernet0/0.1 as the management interface.

Example 6-71 Enabling IP MLS on MLS-RP Interfaces

Router-A# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router-A(config)# interface fastEthernet0/0.1
Router-A(config-if)# mls rp vtp-domain lanps
Router-A(config-if)# mls management-interface
Router-A(config-if)# mls rp ip
Router-A(config-if)# exit
Router-A(config)# interface fastEthernet0/0.2
Router-A(config-if)# mls rp vtp-domain lanps
Router-A(config-if)# mls rp ip

In Example 6-4, notice that the VTP domain is configured first with a value of lanps, which matches the VTP domain configured on Switch-A in the "Configuration Prerequisites" section earlier in this chapter. The fastEthernet0/0.1 interface is specified as the management interface, meaning Router-A must be configured as an MLS-RP with an IP address of on the MLS-SE.

Configuring the MLS-SE

After you have configured the MLS-RP, you can then configure the MLS-SE. Configuring the MLS-SE requires the following configuration tasks:

  • Configuring VTP

  • Enabling MLS

  • Configuring optional MLS parameters

Configuring VTP

As indicated in the previous section on configuring the MLS-RP, the VTP domains configured on the MLS-RP and MLS-SE must match. In the configuration prerequisites section of this scenario, VTP was configured on Switch-A with a VTP domain name of lanps, which matches the VTP domain configured on the MLS-RP earlier, ensuring MLS communications succeed.

Enabling MLS

After ensuring VTP is configured correctly, you can begin to configure MLS. The first MLS configuration task is to enable MLS globally on the switch, which enables MLS-SE functionality. If the MLS-RP is integrated with the Catalyst switch (i.e., the RSM/RSFC on the Catalyst 5000/5500 or the MSFC on the Catalyst 6000/6500), MLS is already enabled automatically and you do not need to configure MLS, unless you wish to modify certain MLS parameters. If the MLS-RP is external (as is the case for this scenario), you must explicitly enable MLS and also define at least one MLS-RP.

To enable MLS, the set mls enable command is used without any other parameters. After enabling MLS, you can then define up to 16 external MLS-RPs using the set mls include command:

Console> (enable) set mls include mls-rp-address

The mls-rp-address parameter must be the IP address of the MLS management interface configured on the MLS-RP. Example 6-5 demonstrates enabling MLS on Switch-A and then defining Router-A as an MLS-RP.

Example 6-72 Enabling IP MLS and Configuring an MLS-RP on CatOS

Switch-A> (enable) set mls enable
IP Multilayer switching is enabled.
Switch-A> (enable) set mls include
Multilayer switching is enabled for router

In Example 6-5, notice that after MLS is enabled, the VLAN 1 interface IP address on Router-A is defined as an MLS-RP, which is the management interface on Router-A (see Example 6-4).

Configuring Optional MLS Parameters

At this stage, Switch-A has been configured as a fully functional MLS-SE and begins to use MLS as Router-A is operational as an MLS-RP. You can also configure other optional MLS parameters, which mainly affect the how the flow cache is operated and maintained. Some of these optional parameters include the following:

  • Configuring the minimum flow mask

  • Configuring MLS timers

Configuring the Minimum Flow Mask

The first optional parameter defines the minimum flow mask for the flow cache. By default, a flow mask of destination is used, which means flow entries are generated on a per-destination IP address basis. As you have already learned, three different flow masks exist—destination, source-destination, and full flow. You normally don't need to modify the default flow mask of destination, as the configuration of features that require a higher resolution masks, such as implementing ACLs on the MLS-RP, is performed automatically. If you do wish to configure the minimum flow mask to a higher resolution flow mask, you can use the set mls flow command:

Console> (enable) set mls flow {destination | destination-source | full]

Example 6-6 demonstrates configuring the minimum flow mask as source and destination IP address on Switch-B, which means a new flow entry is generated for each unique source and destination pair of IP addresses.

Example 6-73 Configuring the Minimum Flow Mask on CatOS

Switch-A> (enable) set mls flow destination-source
Configured flow mask is set to destination-source flow.


The full flow mask generates a lot of entries in the MLS cache and should be used with caution. For example, in this scenario, an HTTP connection between Host-X and Host-Y is represented by a separate flow from an FTP connection between Host-X and Host-Y.

Configuring MLS Timers

The flow cache is a finite resource that only can maintain a certain amount of flow entries before the cache becomes full. If the cache becomes full, the MLS-SE can no longer write new entries for new flows, meaning any new flows that require routing cannot be Layer 3 switched. Instead they are routed normally via the router-on-stick topology of the MLS-RP. The MLS cache can accommodate 128 K (128 * 1024) entries; however, when the number of entries is above 32 K, there is a chance that the MLS-SE forwards some flows to the MLS-RP for forwarding. To avoid the flow cache from exceeding 32 K entries, the MLS-SE operates two timers, which are both used to age out idle flow entries after a configurable period of time:

  • MLS fast aging timer—Used to age out flows that have not exceeded sending a configurable number of packets (the packet threshold) within the fast aging timer. By default, the fast aging timer is set to 0 (not used) and is normally configured only to reduce the size of the MLS cache when it is consistently exceeding 32K entries. You can configure the fast aging timer as 32, 64, 96, or 128 seconds; you can configure a packet threshold of 0, 1, 3, 7, 15, 31, or 63 packets. For example, if you configured a fast aging timer of 32 seconds and a packet threshold of 15, any flow that does not send more than 15 packets within 32 seconds is aged out. If the MLS cache exceeds 32 K, reduce the fast aging timer; if the MLS cache continues to exceed 32 K, you should decrease the MLS aging timer (described next).

  • MLS aging timer—Used to age out idle flows that have not sent a single packet (if one or more packets is sent, the aging timer is reset) during the aging timer interval. The MLS aging timer is 256 seconds by default and the aging time can be configured in 8-second increments between 8 and 2032 seconds.


You should only ever modify the MLS aging time after you have first tuned the IP MLS fast aging timer.

To configure the MLS fast aging timer and aging timer, the set mls agingtime command is used:

Console> (enable) set mls agingtime {aging-timer | fast
 fast-aging-timer packet-threshold}

You configure the MLS aging timer by just specifying an aging timer value, while you configure the MLS fast aging timer by specifying the fast keyword and then configuring the fast aging timer and packet threshold. Example 6-7 demonstrates configuring the MLS fast aging timer and aging timer on Switch-A.

Example 6-74 Configuring the MLS Aging Timer and MLS Fast Aging Timer on CatOS

Switch-A> (enable) set mls agingtime 480
Multilayer switching aging time set to 480
Switch-A> (enable) set mls agingtime fast 128 7
Multilayer switching fast aging time set to 128 seconds for entries
  with no more than 7 
packets switched.

In Example 6-7, the MLS aging timer is set to 480 seconds, meaning any flow entry that is idle for 480 seconds is aged out. The MLS fast aging timer is also configured, aging out any flow entry that does not send more than 7 packets within a 128 second period.

Verifying MLS Operation

At this stage, you have configured an MLS-RP and MLS-SE, configured a minimum flow mask on the MLS-SE so that the MLS cache on the MLS-SE contains flows that represent unique source and destination IP address combinations and also configured MLS timers on the MLS-SE. To verify the MLS configuration on the MLS-RP and MLS-SE, Host-X and Host-Y need to communicate so that MLS operation can be observed and verified.

Before testing inter-VLAN communications, it is a good idea to verify the MLS configuration on the MLS-RP and MLS-SE. On the MLS-RP (Cisco IOS-based), the show mls rp command can be used to verify MLS configuration. Example 6-8 demonstrates using this command on Router-A after both the MLS-RP and MLS-SE have been configured.

Example 6-75 Verifying MLS Configuration on the MLS-RP

Router-A# show mls rp
ip multilayer switching is globally enabled
ipx multilayer switching is globally disabled
ipx mls inbound acl override is globally disabled
mls id is 0010.7be2.aba0
mls ip address
mls ip flow mask is destination
mls ipx flow mask is unknown
number of domains configured for mls 1

vlan domain name: lanps
  current ip flow mask: destination-source
  ip current/next global purge: false/false
  ip current/next purge count: 0/0
  current ipx flow mask: destination
  ipx current/next global purge: false/false
  ipx current/next purge count: 0/0
  current sequence number: 4280145038
  current/maximum retry count: 0/10
  current domain state: no-change
  domain uptime: 00:14:43
  keepalive timer expires in 9 seconds
  retry timer not running
  change timer not running
  fcp subblock count = 2

  1 management interface(s) currently defined:
   vlan 1 on fastEthernet0/0.1

  2 mac-vlan(s) configured for multi-layer switching

  2 mac-vlan(s) enabled for ip multi-layer switching:
   mac 0010.7be2.aba0
     vlan id(s)
     1  2  

  0 mac-vlan(s) enabled for ipx multi-layer switching:

  router currently aware of following 1 switch(es):
   switch id 0030.f2b8.3fff

Notice in Example 6-8 that IP MLS is enabled on Router-A, and that the IP address of the MLS-RP is You can see that interface fastEthernet0/0.1 is the management interface and that two VLANs are enabled for MLS (VLAN 1 and VLAN 2, which are provided physically by fastEthernet0/0.1 and fastEthernet0/0.2, respectively). You can also see that a single VTP domain called lanps is configured and that Router-A is aware of Switch-A as an MLS-SE. Notice that the flow mask is indicated as being destination, as opposed to destination-source as has been configured on Switch-A. This is because Router-A has no knowledge of the flow mask on Switch-A and, therefore, has a flow mask that is independent of the switch.

You can also you the show mls ip command on the MLS-SE (CatOS). Example 6-9 demonstrates using this command on Switch-A after both the MLS-RP and MLS-SE have been configured.

Example 6-76 Verifying MLS Configuration on the MLS-SE

Switch-A> (console) show mls ip
IP Multilayer switching enabled
IP Multilayer switching aging time = 480 seconds
IP Multilayer switching fast aging time = 128 seconds, packet threshold = 7
IP Current flow mask is Destination-source flow
Configured flow mask is Destination-source flow
Active IP MLS entries = 1
Netflow Data Export disabled
Netflow Data Export port/host is not configured.
Total packets exported = 0

---------------- ------------ ---- ---------------------------------   00107be2aba0  2 00-10-7b-e2-ab-a0 1-2

In Example 6-9, you can see that MLS is enabled and can also see the aging timers configured for MLS. Notice that the flow mask on the MLS-SE is destination-source, because this has been configured as the minimum flow mask. The last line in the output of Example 6-9 shows the IP address, MAC address, XTAG, and VLANs for which each interface of the MLS-RP is configured.

Now that the MLS configuration on both the MLS-RP and MLS-SE has been verified, it is time to actually test that inter-VLAN is routing and that MLS is being performed as it should. Before testing inter-VLAN routing, it is a good idea to clear any current flow entries from the MLS cache using the clear mls entry ip all command so that you can easily see when entries are generated in response to various events. Example 6-10 demonstrates clearing all current entries from the MLS cache on the MLS-SE.

Example 6-77 Clearing the MLS Cache on Switch-A

Switch-A> (enable) clear mls entry ip all
Multilayer switching entries cleared.
Switch-A> (enable) show mls entry ip
                 Last  Used
Destination IP Source IP    Prot DstPrt SrcPrt Destination Mac  Vlan Port
--------------- --------------- ---- ------ ------ ----------------- ---- -----
No entries

In Example 6-10, after all entries in the MLS cache are cleared, the show mls entry ip command is used to verify no entries exist in the cache.

After the MLS cache is emptied, the process of testing inter-VLAN routing can now begin. To simulate traffic that requires inter-VLAN routing, Host-X (in VLAN 1) can be used to ping Host-Y (in VLAN 2), which causes inter-VLAN routing between VLAN 1 and VLAN 2 to occur. Example 6-11 demonstrates pinging Host-Y from Host-X.

Example 6-78 Generating Inter-VLAN on Host-X

C:\> ping

Pinging with 32 bytes of data:

Reply from bytes=32 time=4ms TTL=128
Reply from bytes=32 time<1ms TTL=128
Reply from bytes=32 time<1ms TTL=128
Reply from bytes=32 time<1ms TTL=128

Ping statistics for
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 1ms, Maximum = 4ms, Average = 2ms

In Example 6-11, the first packet sent by Host-X is routed through the MLS-RP, with the MLS-SE learning the information required for Layer 3 switching based upon the routed Ethernet frame that is sent from the MLS-RP to Host-Y in VLAN 2. Each subsequent packet is then Layer 3 switched in hardware on the MLS-SE, ensuring high performance inter-VLAN routing. Example 6-12 demonstrates verifying that a flow entry has indeed been generated on the MLS-SE (Switch-A) using the show mls entry ip command, after traffic has been generated in Example 6-11 between Host-X and Host-Y.

Example 6-79 Viewing the MLS Cache on Switch-A

Switch-A> (enable) show mls entry ip
                 Last  Used
Destination IP Source IP    Prot DstPrt SrcPrt Destination Mac  Vlan Port
--------------- --------------- ---- ------ ------ ----------------- ---- -----
 No entries
MLS-RP  -  -   -   00-10-a4-e0-1e-d3 1  2/2  -  -   -   00-06-53-fe-84-20 2  2/3

Notice in Example 6-12 that two new entries are in the MLS cache for the MLS-RP at (Router-A). The first entry indicates that any IP packet with a source IP address of (Host-Y) and a destination IP address of (Host-X) should be L3 switched by rewriting the destination MAC address of the frame to 00-10-a4-e0-1e-d3 (the MAC address of Host-X) and then switching the frame out port 2/2 (which is attached to Host-X). Similarly, the second entry describes the information required to L3 switch traffic from Host-X ( to Host-Y ( Example 6-12 demonstrates that a bidirectional communications session between two devices generates two flow entries—one for each direction packets are sent.

You can see that the flow entries generated on the MLS-SE in Example 6-12 have a flow mask of destination-source, which means only a single pair of flow entries are generated for any communications between Host-X and Host-Y. If on Host-X you attempt to establish another form of connectivity to Host-Y (e.g., access a file share or establish a Telnet connection), no new flow entries are generated.

Verifying MLSP Operation

MLSP is used to communicate information between the MLS-RP and MLS-SE. Events such as routing topology changes and access control list configuration changes are communicated to the MLS-SE by the MLS-RP via MLSP messages. In the event of a routing topology change, the MLS-SE flushes the MLS cache to ensure that packets are not L3 switched in error. In the event of an access control list (ACL) being applied to an interface on the MLS-RP, the MLS-SE adjusts the flow mask to that specified by the MLS-RP to ensure traffic cannot bypass the ACL.

Example 6-13 demonstrates configuring an extended ACL on Router-A and then applying it to interface fastEthernet0/0.1, which is attached to VLAN 1 on Switch-B. After this configuration is implemented, Router-A (as the MLS-RP) should immediately notify Switch-A (the MLS-SE) that the flow mask needs to be modified.

Example 6-80 Configuring an Extended Access Control List on Switch-A

Router-A# configure terminal
Router-A(config)# access-list 100 permit tcp any any eq telnet
Router-A(config)# access-list 100 deny ip any any log
Router-A(config)# interface fastEthernet0/0.1
Router-A(config-if)# ip access-group 100 in 

In Example 6-13, the ACL configured permits only Telnet traffic, denying all other traffic. After applying the ACL to interface fastEthernet0/0.1, Router-A communicates via MLSP to the MLS-SE that the flow mask needs to be modified to a full flow mask to ensure the MLS-SE does not permit other types of traffic. Example 6-14 demonstrates checking the MLS configuration on Switch-A after the ACL is applied on Router-A in Example 6-13.

Example 6-81 Checking the MLS Cache on Switch-A

Switch-A> (console) show mls ip
Total packets switched = 1748724
Total Active MLS entries = 0
IP Multilayer switching enabled
IP Multilayer switching aging time = 480 seconds
IP Multilayer switching fast aging time = 128 seconds, packet threshold = 7
IP Current flow mask is Full flow
Configured flow mask is Destination-source flow
Active IP MLS entries = 0

In Example 6-14, notice that the configured flow mask is destination-source; however, the current flow mask is full, which is due to the ACL configuration on Router-A causing Router-A to indicate to Switch-A that the flow mask needs to be changed to a full flow mask.

At this point, Host-X is able to establish only Telnet connections to Host-Y based upon the ACL configured in Example 6-13 (ping requests should fail). Because a full flow mask is now configured on Switch-A, a new flow entry should be generated for each connection routed through the Layer 3 switching engine of Switch-A. Figure 6-12 demonstrates establishing two Telnet connections to Host-Y from Host-X, and then Example 6-15 demonstrates checking the MLS cache after the connections have been established.

Figure 12Figure 6-12 Establishing Two Telnet Connections From Host-X to Host-Y

Example 6-82 Viewing the MLS Cache on Switch-A

Switch-A> (enable) show mls entry ip
Destination IP Source IP    Prot DstPrt SrcPrt Destination Mac  Vlan Port
--------------- --------------- ---- ------ ------ ----------------- ---- -----
 No entries
MLS-RP  TCP Telnet 3779  00-06-53-fe-84-20 2  2/3  TCP Telnet 3780  00-06-53-fe-84-20 2  2/3  TCP 3780  Telnet 00-10-a4-e0-1e-d3 1  2/2  TCP 3779  Telnet 00-10-a4-e0-1e-d3 1  2/2

Notice in Example 6-15 that four new flows are cached in the MLS cache, one for each direction of traffic for each connection. Because the source TCP port (on Host-X) of each connection is different, separate pairs of flow entries in the MLS cache are present due to the flow mask being now configured as full (see Example 6-14). With the ACL configured, you should never see any completed flow entries for traffic other than Telnet traffic. Because the access list on Router-A drops all non-Telnet traffic, Switch-A never sees any traffic associated with non-Telnet packets return from Router-A and thus never completes a flow entry for the non-Telnet traffic in the MLS cache.

4. Scenario 6-2: Configuring CEF-based Layer 3 Switching on the Catalyst 6000/6500 Operating in Hybrid Mode | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020