Table Of Contents

Configuring MLS

Understanding How Layer 3 Switching Works

Understanding Layer 3-Switched Packet Rewrite

Understanding IP Unicast Rewrite

Understanding IPX Unicast Rewrite

Understanding IP Multicast Rewrite

Understanding MLS

Understanding MLS Flows

Understanding the MLS Cache

Understanding Flow Masks

Partially and Completely Switched Multicast Flows

MLS Examples

Default MLS Configuration

Configuration Guidelines and Restrictions

IP MLS

Maximum Transmission Unit Size

Restrictions on Using IP Routing Commands with IP MLS Enabled

IP MMLS

IP MMLS Supervisor Engine Guidelines and Restrictions

IP MMLS MSFC Configuration Restrictions

Unsupported IP MMLS Features

IPX MLS

IPX MLS Interaction with Other Features

IPX MLS and Maximum Transmission Unit Size

Configuring MLS on the Switch

Configuring Unicast MLS on the MSFC

Disabling and Enabling Unicast MLS on an MSFC Interface

Displaying MLS Information on the MSFC

Using Debug Commands on the MSFC

Using Debug Commands on the SCP

Configuring MLS on Supervisor Engine 1

Specifying MLS Aging-Time Value

Specifying IP MLS Long-Duration Aging Time, Fast Aging Time, and Packet Threshold Values

Setting the Minimum IP MLS Flow Mask

Displaying CAM Entries on the Supervisor Engine

Displaying MLS Information

Displaying IP MLS Cache Entries

Clearing MLS Cache Entries

Clearing IPX MLS Cache Entries

Displaying IP MLS Statistics

Clearing MLS Statistics

Displaying MLS Debug Information

Configuring IP MMLS

Configuring IP MMLS on the MSFC

Displaying Global IP MMLS Information on the Supervisor Engine

Configuring MLS

---

This chapter describes how to configure Multilayer Switching (MLS) for the Catalyst 6500 series switches. MLS provides IP and Internetwork Packet Exchange (IPX) unicast Layer 3 switching and IP multicast Layer 3 switching with Supervisor Engine 1, the Policy Feature Card (PFC), and the Multilayer Switch Feature Card (MSFC) or MSFC2.

---

Note For complete information on the syntax and usage information for the supervisor engine commands used in this chapter, refer to the Catalyst 6500 Series Switch Command Reference publication.

---

This chapter consists of these sections:

•Understanding How Layer 3 Switching Works

•Default MLS Configuration

•Configuration Guidelines and Restrictions

•Configuring MLS on the Switch

---

Note Supervisor Engine 2, PFC2, and MSFC2 provide Layer 3 switching with Cisco Express Forwarding for PFC2 (CEF for PFC2). See "Configuring CEF for PFC2," for more information.

---

Understanding How Layer 3 Switching Works

Layer 3 switching allows the switch, instead of a router, to forward IP and IPX unicast traffic and IP multicast traffic between VLANs. Layer 3 switching is implemented in hardware and provides wire-speed interVLAN forwarding on the switch, rather than on the MSFC. Layer 3 switching requires minimal support from the MSFC. The MSFC routes any traffic that cannot be Layer 3 switched.

---

Note Layer 3 switching supports the routing protocols that are configured on the MSFC. Layer 3 switching does not replace the routing protocols that are configured on the MSFC. Layer 3 switching uses IP Protocol Independent Multicast (IP PIM) for multicast route determination.

---

Layer 3 switching on Catalyst 6500 series switches provides traffic statistics that you can use to identify traffic characteristics for administration, planning, and troubleshooting. Layer 3 switching uses NetFlow Data Export (NDE) to export flow statistics (for more information about NDE, see "Configuring NDE").

These sections describe Layer 3 switching and MLS on the Catalyst 6500 series switches:

•Understanding Layer 3-Switched Packet Rewrite

•Understanding MLS

Understanding Layer 3-Switched Packet Rewrite

When a packet is Layer 3 switched from a source in one VLAN to a destination in another VLAN, the switch performs a packet rewrite at the egress port based on information learned from the MSFC so that the packets appear to have been routed by the MSFC.

---

Note Rather than just forwarding multicast packets, the switch replicates them as necessary on the appropriate VLANs.

---

Packet rewrite alters five fields:

•Layer 2 (MAC) destination address

•Layer 2 (MAC) source address

•Layer 3 IP Time to Live (TTL) or IPX Transport Control

•Layer 3 checksum

•Layer 2 (MAC) checksum (also called the frame checksum or FCS)

If Source A and Destination B are on different VLANs and Source A sends a packet to the MSFC to be routed to Destination B, the switch recognizes that the packet was sent to the Layer 2 (MAC) address of the MSFC.

To perform Layer 3 switching, the switch rewrites the Layer 2 frame header, changing the Layer 2 destination address to the Layer 2 address of Destination B and the Layer 2 source address to the Layer 2 address of the MSFC. The Layer 3 addresses remain the same.

In IP unicast and IP multicast traffic, the switch decrements the Layer 3 Time to Live (TTL) value by 1 and recomputes the Layer 3 packet checksum. In IPX traffic, the switch increments the Layer 3 Transport Control value by 1 and recomputes the Layer 3 packet checksum. The switch recomputes the Layer 2 frame checksum and forwards (or for multicast packets, replicates as necessary) the rewritten packet to Destination B's VLAN.

These sections describe how the packets are rewritten:

•Understanding IP Unicast Rewrite

•Understanding IPX Unicast Rewrite

•Understanding IP Multicast Rewrite

Understanding IP Unicast Rewrite

Received IP unicast packets are (conceptually) formatted as follows:

Layer 2 Frame Header		Layer 3 IP Header				Data	FCS
Destination	Source	Destination	Source	TTL	Checksum
MSFC MAC	Source A MAC	Destination B IP	Source A IP	n	calculation1

After the switch rewrites an IP unicast packet, it is (conceptually) formatted as follows:

Layer 2 Frame Header		Layer 3 IP Header				Data	FCS
Destination	Source	Destination	Source	TTL	Checksum
Destination B MAC	MSFC MAC	Destination B IP	Source A IP	n-1	calculation2

Understanding IPX Unicast Rewrite

Received IPX packets are (conceptually) formatted as follows:

Layer 2 Frame Header		Layer 3 IPX Header			Data	FCS
Destination	Source	Checksum/ IPX Length/ Transport Control	Destination Net/ Node/ Socket	Source Net/ Node/ Socket
MSFC MAC	Source A MAC	n	Destination B IPX	Source A IPX

After the switch rewrites an IPX packet, it is (conceptually) formatted as follows:

Layer 2 Frame Header		Layer 3 IPX Header			Data	FCS
Destination	Source	Checksum/ IPX Length/ Transport Control	Destination Net/ Node/ Socket	Source Net/ Node/ Socket
Destination B MAC	MSFC MAC	n+1	Destination B IPX	Source A IPX

Understanding IP Multicast Rewrite

Received IP multicast packets are (conceptually) formatted as follows:

Layer 2 Frame Header		Layer 3 IP Header				Data	FCS
Destination	Source	Destination	Source	TTL	Checksum
Group G1 MAC1	Source A MAC	Group G1 IP	Source A IP	n	calculation1

1 In this example, Destination B is a member of Group G1.

After the switch rewrites an IP multicast packet, it is (conceptually) formatted as follows:

Layer 2 Frame Header		Layer 3 IP Header				Data	FCS
Destination	Source	Destination	Source	TTL	Checksum
Group G1 MAC	MSFC MAC	Group G1 IP	Source A IP	n-1	calculation2

Understanding MLS

---

Note Supervisor Engine 1, PFC, and MSFC or MSFC2 can only do MLS internally with the MSFC or MSFC2 in the same chassis; an external MLS-RP cannot be used in place of the internal MLS-RP.

---

Supervisor Engine 1, PFC, and MSFC or MSFC2 provide Layer 3 switching with MLS. Layer 3 switching with MLS identifies flows on the switch after the first packet has been routed by the MSFC and transfers the process of forwarding the remaining traffic in the flow to the switch, which reduces the load on the MSFC.

These sections describe MLS:

•Understanding MLS Flows

•Understanding the MLS Cache

•Understanding Flow Masks

•Partially and Completely Switched Multicast Flows

•MLS Examples

Understanding MLS Flows

Layer 3 protocols, such as IP and IPX, are connectionless—they deliver every packet independently of every other packet. However, actual network traffic consists of many end-to-end conversations, or flows, between users or applications.

MLS supports unicast and multicast flows:

•A unicast flow can be any of the following:

–All traffic to a particular destination

–All traffic from a particular source to a particular destination

–All traffic from a particular source to a particular destination that shares the same protocol and transport-layer information.

•A multicast flow is all traffic with the same protocol and transport-layer information from a particular source to the members of a particular destination multicast group.

For example, communication from a client to a server and from the server to the client are separate flows. Telnet traffic that is transferred from a particular source to a particular destination comprises a separate flow from File Transfer Protocol (FTP) packets between the same source and destination.

---

Note The PFC uses the Layer 2 multicast forwarding table to identify the ports to which Layer 2 multicast traffic should be forwarded (if any). The multicast forwarding table entries are populated by whichever multicast constraint feature is enabled on the switch (IGMP snooping or Generic Attribute Registration Protocol [GARP] Multicast Registration Protocol [GMRP]). These entries map the destination multicast MAC address to the outgoing switch ports for a given VLAN.

---

Understanding the MLS Cache

These sections describe the MLS cache:

•MLS Cache

•Unicast Traffic

•Multicast Traffic

•MLS Cache Aging

•MLS Cache Size

MLS Cache

The PFC maintains a Layer 3 switching table called the MLS cache for Layer 3-switched flows. The cache also includes entries for traffic statistics that are updated in tandem with the switching of packets. After the PFC creates an MLS cache entry, packets that are identified as belonging to an existing flow can be Layer 3 switched based on the cached information. The MLS cache maintains flow information for all active flows.

Unicast Traffic

For unicast traffic, the PFC creates an MLS cache entry for the initial routed packet of each unicast flow. Upon receipt of a routed packet that does not match any unicast flow currently in the MLS cache, the PFC creates a new MLS entry.

Multicast Traffic

For multicast traffic, the PFC populates the MLS cache using information learned from the MSFC. Whenever the MSFC receives traffic for a new multicast flow, it updates its multicast routing table and forwards the new information to the PFC. In addition, if an entry in the multicast routing table ages out, the MSFC deletes the entry and forwards the updated information to the PFC.

For each multicast flow cache entry, the PFC maintains a list of outgoing interfaces for the destination IP multicast group. The PFC uses this list to identify the VLANs on which traffic to a given multicast flow should be replicated.

These Cisco IOS commands affect the multicast MLS cache entries on the switch:

•Using the clear ip mroute command to clear the multicast routing table on the MSFC clears all multicast MLS cache entries on the PFC.

•Using the no ip multicast-routing command to disable IP multicast routing on the MSFC purges all multicast MLS cache entries on the PFC.

MLS Cache Aging

The state and identity of flows are maintained while packet traffic is active; when traffic for a flow ceases, the entry ages out. You can configure the aging time for MLS entries that are kept in the MLS cache. If an entry is not used for the specified period of time, the entry ages out and statistics for that flow can be exported to a flow collector application.

MLS Cache Size

The maximum MLS cache size is 128K entries. The MLS cache is shared by all MLS processes on the switch (IP MLS, IP MMLS, and IPX MLS). An MLS cache that is larger than 32K entries increases the probability that a flow will not be Layer 3 switched but will instead be forwarded to the MSFC.

Understanding Flow Masks

The PFC uses flow masks to determine how MLS entries are created.

These sections describe the flow mask modes:

•Flow Mask Modes

•Flow Mask Mode and show mls entry Command Output

Flow Mask Modes

The PFC supports only one flow mask (the most specific one) for all MSFCs that are Layer 3 switched by that PFC. If the PFC detects different flow masks from different MSFCs for which it is performing Layer 3 switching, it changes its flow mask to the most specific flow mask detected.

When the PFC flow mask changes, the entire MLS cache is purged. When the PFC exports cached entries, flow records are created based on the current flow mask. Depending on the current flow mask, some fields in the flow record might not have values. Unsupported fields are filled with a zero (0).

The MLS flow masks are as follows:

•destination-ip—The least-specific flow mask. The PFC maintains one MLS entry for each Layer 3 destination address. All flows to a given Layer 3 destination address use this MLS entry.

•destination-ipx—The only flow mask mode for IPX MLS is destination mode. The PFC maintains one IPX MLS entry for each destination IPX address (network and node). All flows to a given destination IPX address use this IPX MLS entry.

•source-destination-ip—The PFC maintains one MLS entry for each source and destination IP address pair. All flows between a given source and destination use this MLS entry regardless of the IP protocol ports.

•source-destination-vlan—For IP MMLS. The PFC maintains one MMLS cache entry for each {source IP, destination group IP, source VLAN}. The multicast source-destination-vlan flow mask differs from the IP unicast MLS source-destination-ip flow mask in that, for IP MMLS, the source VLAN is included as part of the entry. The source VLAN is the multicast reverse path forwarding (RPF) interface for the multicast flow.

•full flow—The most-specific flow mask. The PFC creates and maintains a separate MLS cache entry for each IP flow. A full flow entry includes the source IP address, destination IP address, protocol, and protocol ports.

Flow Mask Mode and show mls entry Command Output

With the destination-ip flow mask, the source IP, protocol, and source and destination port fields show the details of the last packet that was Layer 3 switched using the MLS cache entry.

This example shows how the show mls entry command output appears in destination-ip mode:

Console> (enable) show mls entry ip short

Destination-IP  Source-IP       Prot  DstPrt SrcPrt Destination-Mac   Vlan 

--------------- --------------- ----- ------ ------ ----------------- ---- 

 ESrc EDst SPort DPort Stat-Pkts Stat-Byte    Uptime   Age

 ---- ---- ----- ----- --------- ------------ -------- --------

171.69.200.234  -               -     -      -      00-60-70-6c-fc-22 4    

 ARPA SNAP 5/8   11/1  3152      347854       09:01:19 09:08:20

171.69.1.133    -               -     -      -      00-60-70-6c-fc-23 2    

 SNAP ARPA 5/8   1/1   2345      123456       09:03:32 09:08:12

Total Entries: 2

* indicates TCP flow has ended

Console> (enable)

---

Note The short keyword exists for some show commands and displays the output by wrapping the text after 80 characters. The default is long (no text wrap).

---

With the source-destination-ip flow mask, the protocol, source port, and destination port fields display the details of the last packet that was Layer 3 switched using the MLS cache entry.

This example shows how the show mls entry command output appears in source-destination-ip mode:

Console> (enable) show mls entry ip short

Destination-IP  Source-IP       Prot  DstPrt SrcPrt Destination-Mac   Vlan 

--------------- --------------- ----- ------ ------ ----------------- ---- 

 ESrc EDst SPort DPort Stat-Pkts Stat-Byte    Uptime   Age

 ---- ---- ----- ----- --------- ------------ -------- --------

171.69.200.234  171.69.192.41   -     -      -      00-60-70-6c-fc-22 4 

 ARPA SNAP 5/8   11/1  3152      347854       09:01:19 09:08:20

171.69.1.133    171.69.192.42   -     -      -      00-60-70-6c-fc-23 2 

 SNAP ARPA 5/8   1/1   2345      123456       09:03:32 09:08:12

Total Entries: 2

* indicates TCP flow has ended

Console> (enable)

With the full-flow flow mask, because a separate MLS entry is created for every ip flow, details are shown for each flow.

This example shows how the show mls entry command output appears in full flow mode:

Console> (enable) show mls entry ip short

Destination-IP  Source-IP       Prot  DstPrt SrcPrt Destination-Mac   Vlan 

--------------- --------------- ----- ------ ------ ----------------- ---- 

 ESrc EDst SPort DPort Stat-Pkts Stat-Byte    Uptime   Age

 ---- ---- ----- ----- --------- ------------ -------- --------

171.69.200.234  171.69.192.41   TCP*  6000   59181  00-60-70-6c-fc-22 4 

 ARPA SNAP 5/8   11/1  3152      347854       09:01:19 09:08:20

171.69.1.133    171.69.192.42   UDP   2049   41636  00-60-70-6c-fc-23 2 

 SNAP ARPA 5/8   1/1   2345      123456       09:03:32 09:08:12

Total Entries: 2

* indicates TCP flow has ended

Console> (enable)

Partially and Completely Switched Multicast Flows

Some flows might be partially Layer 3 switched instead of completely Layer 3 switched in these situations:

•The MSFC is configured as a member of the IP multicast group (using the ip igmp join-group command) on the RPF interface of the multicast source.

•The MSFC is the first-hop router to the source in PIM sparse mode (in this case, the MSFC must send PIM-register messages to the rendezvous point).

•The multicast TTL threshold is configured on an egress interface for the flow.

•The extended access list deny condition on the RPF interface specifies anything other than the Layer 3 source, Layer 3 destination, or IP protocol (an example is Layer 4 port numbers).

•The multicast helper is configured on the RPF interface for the flow, and multicast to broadcast translation is required.

•Multicast tag switching is configured on an egress interface.

•Network address translation (NAT) is configured on an interface, and source address translation is required for the outgoing interface.

For partially switched flows, all multicast traffic belonging to the flow reaches the MSFC and is software switched for any interface that is not Layer 3 switched.

The PFC prevents multicast traffic in flows that are completely Layer 3 switched from reaching the MSFC, reducing the load on the MSFC. The show ip mroute and show mls ip multicast commands identify completely Layer 3-switched flows with the text string RPF-MFD. Multicast Fast Drop (MFD) indicates that from the perspective of the MSFC, the multicast packet is dropped because it is switched by the PFC.

For all completely Layer 3-switched flows, the PFC periodically sends multicast packet and byte count statistics to the MSFC, because the MSFC cannot record multicast statistics for completely switched flows, which it never sees. The MSFC uses the statistics to update the corresponding multicast routing table entries and to reset the appropriate expiration timers.

MLS Examples

Figure 14-1 shows a simple IP MLS network topology. In this example, Host A is on the Sales VLAN (IP subnet 171.59.1.0), Host B is on the Marketing VLAN (IP subnet 171.59.3.0), and Host C is on the Engineering VLAN (IP subnet 171.59.2.0).

When Host A initiates an HTTP file transfer to Host C, an MLS entry for this flow is created (this entry is the second item in the MLS cache shown in Figure 14-1). The PFC stores the MAC addresses of the MSFC and Host C in the MLS entry when the MSFC forwards the first packet from Host A through the switch to Host C. The PFC uses this information to rewrite subsequent packets from Host A to Host C.

Figure 14-1 IP MLS Example Topology

Figure 14-2 shows a simple IPX MLS network topology. In this example, Host A is on the Sales VLAN (IPX address 01.Aa), Host B is on the Marketing VLAN (IPX address 03.Bb), and Host C is on the Engineering VLAN (IPX address 02.Cc).

When Host A initiates a file transfer to Host B, an IPX MLS entry for this flow is created (this entry is the first item in the table shown in Figure 14-1). The PFC stores the MAC addresses of the MSFC and Host B in the IPX MLS entry when the MSFC forwards the first packet from Host A through the switch to Host B. The PFC uses this information to rewrite subsequent packets from Host A to Host B.

Similarly, a separate IPX MLS entry is created in the MLS cache for the traffic from Host A to Host C, and for the traffic from Host C to Host A. The destination VLAN is stored as part of each IPX MLS entry so that the correct VLAN identifier is used when encapsulating traffic on trunk links.

Figure 14-2 IPX MLS Example Topology

Default MLS Configuration

Table 14-1 shows the default IP MLS configuration.

Table 14-1 Default IP MLS Configuration

Feature	Default Value
IP MLS enable state	Enabled
IP MLS aging time	256 seconds
IP MLS fast aging time	0 seconds (no fast aging)
IP MLS fast aging-time packet threshold	0 packets

Table 14-2 shows the default IP MMLS switch configuration.

Table 14-2 Default IP MMLS Supervisor Engine Configuration 

Feature	Default Value
Multicast services (IGMP snooping or GMRP)	Disabled
IP MMLS	Enabled

Table 14-3 shows the default IP MMLS MSFC configuration.

Table 14-3 Default IP MMLS MSFC Configuration 

Feature	Default Value
Multicast routing	Disabled globally
IP PIM routing	Disabled on all interfaces
IP MMLS Threshold	Unconfigured—no default value
IP MMLS	Enabled when multicast routing is enabled and IP PIM is enabled on the interface

Table 14-4 shows the default IPX MLS configuration.

Table 14-4 Default IPX MLS Configuration

Feature	Default Value
IPX MLS enable state	Enabled
IPX MLS aging time	256 seconds

Configuration Guidelines and Restrictions

These sections describe the configuration guidelines and restrictions for IP MLS, IP MMLS, and IPX MLS:

•IP MLS

•IP MMLS

•IPX MLS

IP MLS

These sections describe the IP MLS configuration guidelines:

•Maximum Transmission Unit Size

•Restrictions on Using IP Routing Commands with IP MLS Enabled

Maximum Transmission Unit Size

The default maximum transmission unit (MTU) for IP MLS is 1500. To change the MTU on an IP MLS-enabled interface, enter the ip mtu mtu command.

Restrictions on Using IP Routing Commands with IP MLS Enabled

Enabling certain IP processes on an interface will affect IP MLS on the interface. Table 14-5 shows the affected commands and the resulting behavior.

Table 14-5 IP Routing Command Restrictions 

Command	Behavior
clear ip route	Clears all MLS cache entries for all switches performing Layer 3 switching for this MSFC.
ip routing	The no form purges all MLS cache entries and disables IP MLS on this MSFC.
ip security (all forms of this command)	Disables IP MLS on the interface.
ip tcp compression-connections	Disables IP MLS on the interface.
ip tcp header-compression	Disables IP MLS on the interface.

IP MMLS

These sections describe the IP MMLS configuration guidelines:

•IP MMLS Supervisor Engine Guidelines and Restrictions

•IP MMLS MSFC Configuration Restrictions

•Unsupported IP MMLS Features

IP MMLS Supervisor Engine Guidelines and Restrictions

These guidelines and restrictions apply when configuring Supervisor Engine 1 for IP MMLS:

•Only ARPA rewrites are supported for IP multicast packets.

•Subnetwork Address Protocol (SNAP) rewrites are not supported.

•You must enable one of the multicast services (IGMP snooping or GMRP) on the switch in order to use IP MMLS.

•IP multicast flows are not multilayer switched if there is no entry in the Layer 2 multicast forwarding table (for example, if no Layer 2 multicast services are enabled or the forwarding table is full). Enter the show multicast group command to check for a Layer 2 entry for a particular IP multicast destination.

•If a Layer 2 entry is cleared, the corresponding Layer 3 flow information is purged.

•When using two MSFCs that have one or more interfaces in the same VLAN, the switch uses two reserved VLANs (VLANs 1012 and 1013) internally to forward multicast flows properly.

•The MSFC will not act as an external router for a Catalyst 5000 family switch that has Layer 3 switching hardware.

IP MMLS MSFC Configuration Restrictions

IP MMLS does not perform multilayer switching for an IP multicast flow in the following situations:

•For IP multicast groups that fall into these ranges (where * is in the range 0-255):

224.0.0.* through 239.0.0.*
224.128.0.* through 239.128.0.*

---

Note Groups in the 224.0.0.* range are reserved for routing control packets and must be flooded to all forwarding ports of the VLAN. These addresses map to the multicast MAC address range 01-00-5E-00-00-xx, where xx is in the range 0-0xFF.

---

•For IP PIM auto-RP multicast groups (IP multicast group addresses 224.0.1.39 and 224.0.1.40).

---

Note In systems with redundant MSFCs, the IP PIM interface configuration must be the same on both the active and redundant MSFCs.

---

•For flows that are forwarded on the multicast-shared tree (that is, {*,G,*} forwarding) when the interface or group is running IP PIM sparse mode.

•If the shortest-path tree (SPT) bit for the flow is cleared when running IP PIM sparse mode for the interface or group.

•For fragmented IP packets and packets with IP options. However, packets in the flow that are not fragmented or that do not specify IP options are multilayer switched.

•For source traffic received on tunnel interfaces (such as MBONE traffic).

•For any RPF interface with multicast tag switching enabled.

Unsupported IP MMLS Features

If you enable IP MMLS, IP accounting for the interface will not reflect accurate values.

IPX MLS

These sections describe configuration guidelines that apply when configuring IPX MLS:

•IPX MLS Interaction with Other Features

•IPX MLS and Maximum Transmission Unit Size

IPX MLS Interaction with Other Features

Other Cisco IOS software features affect IPX MLS as follows:

•IPX accounting—IPX accounting cannot be enabled on an IPX MLS-enabled interface.

•IPX EIGRP—To support MLS on EIGRP interfaces, you must set the Transport Control (TC) maximum to a value greater than the default (16). Enter the ipx maximum-hop tc_value global configuration command on the MSFC with the tc_value greater than 16.

IPX MLS and Maximum Transmission Unit Size

In IPX, the two end points of communication negotiate the maximum transmission unit (MTU) to be used. The MTU size is limited by the media type.

Configuring MLS on the Switch

These sections describe how to configure MLS:

•Configuring Unicast MLS on the MSFC

•Configuring MLS on Supervisor Engine 1

•Configuring IP MMLS

Configuring Unicast MLS on the MSFC

These sections describe how to configure MLS on the MSFC:

•Disabling and Enabling Unicast MLS on an MSFC Interface

•Displaying MLS Information on the MSFC

•Using Debug Commands on the MSFC

•Using Debug Commands on the SCP

For information on configuring routing on the MSFC, see "Configuring InterVLAN Routing." For information on configuring unicast Layer 3 switching on Supervisor Engine 1, see the "Configuring MLS on Supervisor Engine 1" section.

---

Note The MSFC can be specified as the MLS route processor (MLS-RP) for Catalyst 5000 family switches using MLS. Refer to the Layer 3 Switching Configuration Guide—Catalyst 5000 Family, 2926G Series, 2926 Series Switches, for MLS configuration procedures.

---

Disabling and Enabling Unicast MLS on an MSFC Interface

Unicast MLS for IP and IPX is enabled globally by default, but can be disabled and enabled on a specified interface.

To disable unicast IP or IPX MLS on a specific MSFC interface, perform these tasks:

Task	Command
Specify an MSFC interface.	Router(config)# interface vlan-id
Disable IP MLS on an MSFC interface.	Router(config-if)# no mls ip
Disable IPX MLS on an MSFC interface.	Router(config-if)# no mls ipx

This example shows how to disable IP MLS on an MSFC interface:

Router(config)# interface vlan 100

Router(config-if)# no mls ip

Router(config-if)# 

This example shows how to disable IPX MLS on an MSFC interface:

Router(config)# interface vlan 100

Router(config-if)# no mls ipx

Router(config-if)# 

---

Note Unicast MLS is enabled by default; you only need to enable (or reenable) it if you have previously disabled it.

---

To enable unicast IP or IPX MLS on a specific MSFC interface, perform these tasks:

Task	Command
Specify an MSFC interface.	Router(config)# interface vlan-id
Enable IP MLS on an MSFC interface.	Router(config-if)# mls ip
Enable IPX MLS on an MSFC interface.	Router(config-if)# mls ipx

This example shows how to enable IP MLS on an MSFC interface:

Router(config)# interface vlan 100

Router(config-if)# mls ip

Router(config-if)# 

This example shows how to enable IPX MLS on an MSFC interface:

Router(config)# interface vlan 100

Router(config-if)# mls ipx

Router(config-if)# 

Displaying MLS Information on the MSFC

The show mls status command displays MLS details.

To display MLS information on the MSFC, perform this task:

Task	Command
Display MLS status.	show mls status

This example shows how to display MLS status on the MSFC:

Router# show mls status 

MLS global configuration status:

global mls ip:                     enabled

global mls ipx:                    enabled

global mls ip multicast:           disabled

current ip flowmask for unicast:   destination only

current ipx flowmask for unicast:  destination only

Router#

Using Debug Commands on the MSFC

Table 14-6 describes the MLS-related debug commands that you can use to troubleshoot MLS problems on the MSFC.

Table 14-6 MLS Debug Commands 

Command	Description
[no] debug l3-mgr events	Displays Layer 3 manager-related events.
[no] debug l3-mgr packets	Displays Layer 3 manager packets.
[no] debug l3-mgr global	Displays the bugtrace of ip global purge events.
[no] debug l3-mgr all	Turns on all Layer 3 manager debugging messages.

Table 14-7 describes the MLS-related debug commands that you can use to troubleshoot MLS problems when using the MSFC as an external router for a Catalyst 5000 family switch.

Table 14-7 MLS Debug Commands—External Router Function 

Command	Description
[no] debug mls ip	Turns on IP-related events for MLS including route purging and changes of access lists and flow masks.
[no] debug mls ipx	Turns on IPX-related events for MLS including route purging and changes of access lists and flow masks.
[no] debug mls rp	Turns on route processor-related events.
[no] debug mls locator	Identifies which switch is switching a particular flow by using MLS explorer packets.
[no] debug mls all	Turns on all MLS debugging events.

Using Debug Commands on the SCP

Table 14-8 describes the Serial Control Protocol (SCP)-related debug commands to troubleshoot the SCP that runs over the Ethernet out-of-band channel (EOBC).

Table 14-8 SCP Debug Commands 

Command	Description
[no] debug scp async	Displays trace for asynchronous data in and out of the SCP system.
[no] debug scp data	Displays packet data trace.
[no] debug scp errors	Displays errors and warnings in the SCP.
[no] debug scp packets	Displays packet data in and out of the SCP system.
[no] debug scp timeouts	Reports timeouts.
[no] debug scp all	Turns on all SCP debugging messages.

Configuring MLS on Supervisor Engine 1

MLS is enabled by default on Catalyst 6500 series switches. You only need to configure Supervisor Engine 1 in these circumstances:

•You want to change the MLS aging time

•You want to enable NDE

These sections describe how to configure MLS on Supervisor Engine 1:

•Specifying MLS Aging-Time Value

•Specifying IP MLS Long-Duration Aging Time, Fast Aging Time, and Packet Threshold Values

•Setting the Minimum IP MLS Flow Mask

•Displaying CAM Entries on the Supervisor Engine

•Displaying MLS Information

•Displaying IP MLS Cache Entries

•Clearing MLS Cache Entries

•Clearing IPX MLS Cache Entries

•Displaying IP MLS Statistics

•Clearing MLS Statistics

•Displaying MLS Debug Information

For information on configuring VLANs on the switch, see "Configuring VLANs." For information on configuring MLS on the MSFC, see the "Configuring Unicast MLS on the MSFC" section.

---

Note When you disable IP or IPX MLS on the MSFC, IP or IPX MLS is automatically disabled on Supervisor Engine 1. All existing protocol-specific MLS cache entries are purged. To disable MLS on the MSFC, see the "Disabling and Enabling Unicast MLS on an MSFC Interface" section.

---

---

Note If NDE is enabled and you disable MLS, you will lose the statistics for existing cache entries—they are not exported.

---

Specifying MLS Aging-Time Value

The MLS aging time for each protocol (IP and IPX) applies to all protocol-specific MLS cache entries. Any MLS entry that has not been used for agingtime seconds is aged out. The default is 256 seconds.

You can configure the aging time in the range of 8 to 2032 seconds in 8-second increments. Any aging-time value that is not a multiple of 8 seconds is adjusted to the closest multiple of 8 seconds. For example, a value of 65 is adjusted to 64 and a value of 127 is adjusted to 128.

---

Note We recommend that you keep the size of the MLS cache below 32K entries. If the number of MLS entries exceeds 32K, some flows are sent to the MSFC. To keep the size of the MLS cache down, for IP, enable IP MLS fast aging as described in the "Specifying IP MLS Long-Duration Aging Time, Fast Aging Time, and Packet Threshold Values" section.

---

To specify the MLS aging time for both IP and IPX, perform this task in privileged mode:

Task	Command
Specify the MLS aging time for MLS cache entries.	set mls agingtime [agingtime]

This example shows how to specify the MLS aging time:

Console> (enable) set mls agingtime 512

Multilayer switching agingtime IP and IPX set to 512

Console> (enable) 

To specify the IP MLS aging time, perform this task in privileged mode:

Task	Command
Specify the IP MLS aging time for an MLS cache entry.	set mls agingtime ip [agingtime]

This example shows how to specify the IP MLS aging time:

Console> (enable) set mls agingtime ip 512

Multilayer switching aging time IP set to 512

Console> (enable) 

To specify the IPX MLS aging time, perform this task in privileged mode:

Task	Command
Specify the IPX MLS aging time for an MLS cache entry.	set mls agingtime ipx [agingtime]

This example shows how to specify the IPX MLS aging time:

Console> (enable) set mls agingtime ipx 512

Multilayer switching aging time IPX set to 512

Console> (enable)

Specifying IP MLS Long-Duration Aging Time, Fast Aging Time, and Packet Threshold Values

---

Note IPX MLS does not use fast aging. IPX MLS only operates in destination-source and destination flow modes; therefore, the number of IPX MLS entries in the MLS table is low relative to IP MLS entries in full-flow mode.

---

To keep the MLS cache size below 32K entries, enable IP MLS fast aging time. The IP MLS fast aging time applies to MLS entries that have no more than pkt_threshold packets switched within fastagingtime seconds after they are created. A typical cache entry that is removed is the entry for flows to and from a Domain Name Server (DNS) or TFTP server; the entry might never be used again after it is created. Detecting and aging out these entries saves space in the MLS cache for other data traffic.

The default fastagingtime value is 0 (no fast aging). You can configure the fastagingtime value to 32, 64, 96, or 128 seconds. Any fastagingtime value that is not configured exactly as the indicated values is adjusted to the closest one. You can configure the pkt_threshold value to 0, 1, 3, 7, 15, 31, or 63 packets.

If you need to enable IP MLS fast aging time, initially set the value to 128 seconds. If the size of the MLS cache continues to grow over 32K entries, decrease the setting until the cache size stays below 32K. If the cache continues to grow over 32K entries, decrease the normal IP MLS aging time.

Typical values for fastagingtime and pkt_threshold are 32 seconds and 0 packets (no packets switched within 32 seconds after the entry is created).

To specify the IP MLS fast aging time and packet threshold, perform this task in privileged mode:

Task	Command
Specify the IP MLS fast aging time and packet threshold for an MLS cache entry.	set mls agingtime fast [fastagingtime] [pkt_threshold]

This example shows how to set the IP MLS fast aging time to 32 seconds with a packet threshold of 0 packets:

Console> (enable) set mls agingtime fast 32 0

Multilayer switching fast aging time set to 32 seconds for entries with no more than 0 
packets switched.

Console> (enable)

To specify that an active flow gets aged out, perform this task in privileged mode:

Task	Command
Specify that an active flow gets aged out.	set mls agingtime long-duration agingtime

This example shows how to force an active flow to age out. You can specify the aging time of the active flow in the range of 64 to 1920 seconds in increments of 64.

Console> (enable) set mls agingtime long-duration 128

Multilayer switching agingtime set to 128 seconds for long duration flows 

Console> (enable)

Setting the Minimum IP MLS Flow Mask

You can set the minimum granularity of the flow mask for the MLS cache on the PFC. The actual flow mask used will be at least of the granularity that is specified by this command. For information on how the different flow masks work, see the "Understanding Flow Masks" section.

For example, if you do not configure access lists on any MSFC, then the IP MLS flow mask on the PFC is destination-ip by default. However, you can force the PFC to use the source-destination-ip flow mask by setting the minimum IP MLS flow mask using the set mls flow destination-source command.