-
Catalyst 6500 Series Software Configuration Guide, 8.7
-
Catalyst 6500 Series Switch Software Configuration Guide (Full-book PDF)
-
Index
-
Preface
-
Product Overview
-
Command-Line Interfaces
-
Configuring the Switch IP Address and Default Gateway
-
Configuring Ethernet, Fast Ethernet, Gigabit Ethernet, and 10-Gigabit Ethernet Switching
-
Configuring Ethernet VLAN Trunks
-
Configuring EtherChannel
-
Configuring IEEE 802.1Q Tunneling and Layer 2 Protocol Tunneling
-
Configuring Spanning Tree
-
Configuring Spanning Tree PortFast, UplinkFast, BackboneFast, and Loop Guard
-
Configuring VTP
-
Configuring VLANs
-
Configuring InterVLAN Routing
-
Configuring CEF for PFC2/PFC3
-
Configuring MLS
-
Configuring Access Control
-
Configuring NDE
-
Configuring GVRP
-
Configuring MVRP
-
Configuring Dynamic Port VLAN Membership with VMPS
-
Checking Status and Connectivity
-
Configuring Online Diagnostics
-
Administering the Switch
-
Configuring Redundancy
-
Configuring NSF with SSO MSFC Redundancy
-
Modifying the Switch Boot Configuration
-
Working with the Flash File System
-
Working with System Software Images
-
Working with Configuration Files
-
Configuring System Message Logging
-
Configuring DNS
-
Configuring CDP
-
Configuring UDLD
-
Configuring DHCP Snooping and IP Source Guard
-
Configuring NTP
-
Configuring Broadcast Suppression
-
Configuring Layer 3 Protocol Filtering
-
Configuring the IP Permit List
-
Configuring Port Security
-
Configuring Switch Access Using AAA
-
Configuring 802.1x Authentication
-
Configuring MAC Authentication Bypass
-
Configuring Web-Based Proxy Authentication
-
Tracking Host Aging
-
Configuring Network Admission Control
-
Configuring Unicast Flood Blocking
-
Configuring SNMP
-
Configuring RMON
-
Configuring SPAN, RSPAN and the Mini Protocol Analyzer
-
Using Switch TopN Reports
-
Configuring Multicast Services
-
Configuring QoS
-
Configuring Automatic QoS
-
Configuring ASLB
-
Configuring the Switch Fabric Module
-
Configuring a VoIP Network
-
Configuring MSFC IOS Features
-
Acronyms
-
Table Of Contents
Understanding How Layer 3 Switching Works
Understanding Layer 3-Switched Packet Rewrite
Understanding IP Unicast Rewrite
Understanding IPX Unicast Rewrite
Understanding IP Multicast Rewrite
Partially and Completely Switched Multicast Flows
Configuration Guidelines and Restrictions
Maximum Transmission Unit Size
Restrictions on Using IP Routing Commands with IP MLS Enabled
IP MMLS Supervisor Engine Guidelines and Restrictions
IP MMLS MSFC Configuration Restrictions
IPX MLS Interaction with Other Features
IPX MLS and Maximum Transmission Unit Size
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 the 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 IP MLS Cache Entries
Clearing IPX MLS Cache Entries
Displaying MLS Debug Information
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 that are used in this chapter, refer to the Catalyst 6500 Series Switch Command Reference publication.
This chapter consists of these sections:
•
•
Note
Note
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 the 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 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 Chapter 16, "Configuring NDE").
These sections describe Layer 3 switching and MLS on the Catalyst 6500 series switches:
•
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
The packet rewrite alters these five fields:
•
•
•
•
•
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
Received IP unicast packets are (conceptually) formatted as follows:
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:
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:
After the switch rewrites an IPX packet, it is (conceptually) formatted as follows:
Understanding IP Multicast Rewrite
Received IP multicast packets are (conceptually) formatted as follows:
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:
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 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
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:
•
–
–
–
•
For example, communication from a client to a server and from the server to the client are separate flows. The 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
Understanding the MLS Cache
These sections describe the MLS cache:
MLS Cache
The PFC maintains a Layer 3 switching table called the MLS cache for the Layer 3-switched flows. The cache also includes the entries for the traffic statistics that are updated simultaneously with the switching of packets. After the PFC creates an MLS cache entry, the 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 the 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 that is 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:
•
•
MLS Cache Aging
The state and identity of flows are maintained while the packet traffic is active; when the traffic for a flow ceases, the entry ages out. You can configure the aging time for the 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 the statistics for that flow can be exported to a flow collector application.
MLS Cache Size
The maximum MLS cache size is 128,000 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 32,000 entries increases the probability that a flow will not be Layer 3 switched but will be forwarded to the MSFC.
Understanding Flow Masks
The PFC uses flow masks to determine how the MLS entries are created.
These sections describe the flow mask modes:
•
•
•
Flow Mask Modes—Prior to Software Release 8.5(1)
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 the 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 the cached entries, the 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. The unsupported fields are filled with a zero (0).
The MLS flow masks are as follows:
•
•
•
•
•
Flow Mask Modes—Software Release 8.5(1) and Later Releases
With software release 8.5(1) and later releases, the multiple flow mask feature is supported on Supervisor Engine 720. This feature results in some changes to the NetFlow Data Export (NDE) functionality.
A new value for the flow mask is null. Enter the set mls flow null command to set the flow mask to null (null is the new default flow mask). When the flow mask is set to null and no feature is driving a more specific flow mask, all the flows will match to the same null flow. The counters for the null flow are incremented each time a flow hits the null flow. When the flow masks are null and no other feature is driving a flow mask, when you enter the show mls statistics entry command, the command output displays the null flow as follows (in the example, flows are not being exported because NDE is disabled):
Console> (enable) show mls statistics entryFlowmask set to Null. Please set the flowmask to see the flowsLast UsedDestination IP Source IP Prot DstPrt SrcPrt Vlan Stat-Pkts Stat-Bytes---------------- --------------- ----- ------ ------ ----- --------- ------------ - - - - N/A 728915 33530090Console> (enable)To enable flow creation, specify the flow mask by entering the set mls flow {destination | destination-source | null | full} command and specify a keyword other than the null keyword. If NDE is enabled when the null flow mask is configured, NDE will not export any flows. An example follows:
Console> (enable) set mls nde enableNetflow export enabledConsole> (enable) 2005 Sep 18 18:04:43 %MLS-5-FLOWMASK_NULL:IP Flowmask set to Null:Flows will not be exportedConversely, if NDE is enabled and you set the flow mask to null, the following message displays:
Console> (enable) set mls flow null2000 Sep 18 18:04:02 %MLS-5-FLOWMASK_NULL:IP Flowmask set to Null:Flows will not be exportedConsole> (enable)When you upgrade from software release 8.4(x) to software release 8.5(1) and later releases, note the following:
•
–
–
•
–
–
–
Because multiple flow masks can now coexist on the switch, the show mls statistics entry command displays only the relevant fields per flow. Depending on the flow mask that is used to create a particular flow, the relevant fields are zeroed out. NDE is used by the flow collector software. NDE assumes that all flows are created with the same flow mask. Due to this restriction, NDE cannot be enabled with certain features requiring conflicting flow masks. One specific case is hardware-accelerated NAT. NDE and hardware-accelerated NAT are mutually exclusive.
Software release 8.5(1) introduces hardware acceleration for some MSFC features. When upgrading from software release 8.4(x) to software release 8.5(1), there are no issues with MSFC features that were already configured and running. In addition to NAT, such features as reflexive ACLs and Context Based Access Control (CBAC) can work in the hardware if there is no flow mask conflict. A feature will work in the hardware unless the feature needs a flow mask that is in conflict with another feature such as an NDE or QoS microflow policer.
Hardware acceleration is also introduced in software release 8.5(1) for WCCP and TCP intercept. These MSFC features can coexist with NDE if there is no flow mask conflict. The ACL manager attempts to merge the flow mask requirements of different features. The basic idea is to allocate a new flow mask only for a strict flow mask requirement that is incompatible with already allocated flow masks. NDE does not have a strict flow mask requirement, so the flow mask for NDE can be moved up.
To use the hardware acceleration functionality for NAT, if a flow mask has been configured for NDE (enter the show mls command to display flow masks), perform these steps:
Step 1
Step 2
NDE will fail if any of the following events occur:
•
•
Conversely, once NDE is successfully configured, NAT cannot be configured to work in the hardware and two different features with conflicting flow mask requirements cannot be configured on the switch.
Software release 8.5(1) introduces the show mls flowmask command that displays the flow masks used by the various features on the switch.
These examples show the output with various configurations when no features are configured on the MSFC:
Console> show mls flowmaskNetflow Data Export is enabledNDE Flowmask is configured to use at least Null flowmaskConsole>Console> show mls flowmaskNetflow Data Export is enabled and is using Full flowmaskNDE Flowmask is configured to use at least Full flowmaskConsole>Console> show mls flowmaskNetflow Data Export is disabledNDE Flowmask is configured to use at least Full flowmaskConsole>This example shows the output when NAT is configured on the MSFC:
Console> show mls flowmaskThe MSFC features are using NotVlanFullFlow and VlanFullFlowOnly flow mask on vlan(s)10-11,50-51,90-91.Netflow Data Export is disabledNDE Flowmask is configured to at least the Null flowmaskConsole>These examples show the output with various configurations when the reflexive ACL feature is configured on the MSFC:
Console> show mls flowmaskThe MSFC features are using VlanFullFlowOnly flow mask on vlan(s) 13.Netflow Data Export is disabledNDE Flowmask is configured to use at least Null flowmaskConsole>Console> show mls flowmaskThe MSFC features are using VlanFullFlowOnly flow mask on vlan(s) 13.Netflow Data Export is enabled and is using Full-Vlan flowmaskNDE Flowmask is configured to use at least Full-Vlan flowmaskConsole>Flow Mask Modes and show mls entry Command Outputs
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 shortDestination-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 4ARPA SNAP 5/8 11/1 3152 347854 09:01:19 09:08:20171.69.1.133 - - - - 00-60-70-6c-fc-23 2SNAP ARPA 5/8 1/1 2345 123456 09:03:32 09:08:12Total Entries: 2* indicates TCP flow has endedConsole> (enable)
Note
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 shortDestination-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 4ARPA SNAP 5/8 11/1 3152 347854 09:01:19 09:08:20171.69.1.133 171.69.192.42 - - - 00-60-70-6c-fc-23 2SNAP ARPA 5/8 1/1 2345 123456 09:03:32 09:08:12Total Entries: 2* indicates TCP flow has endedConsole> (enable)With the full-flow flow mask, because a separate MLS entry is created for every ip flow, the 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 shortDestination-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 4ARPA SNAP 5/8 11/1 3152 347854 09:01:19 09:08:20171.69.1.133 171.69.192.42 UDP 2049 41636 00-60-70-6c-fc-23 2SNAP ARPA 5/8 1/1 2345 123456 09:03:32 09:08:12Total Entries: 2* indicates TCP flow has endedConsole> (enable)Partially and Completely Switched Multicast Flows
Some flows might be partially Layer 3 switched instead of completely Layer 3 switched in these situations:
•
•
•
•
•
•
•
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 the multicast packet and byte count statistics to the MSFC, because the MSFC cannot record the 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 the 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 the 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 the trunk links.
Figure 14-2 IPX MLS Example Topology
Default MLS Configuration
Table 14-1 shows the default IP MLS configuration.
Table 14-2 shows the default IP MMLS switch configuration.
Table 14-2 Default IP MMLS Supervisor Engine Configuration
Multicast services (IGMP snooping or GMRP)
Disabled
IP MMLS
Enabled
Table 14-3 shows the default IP MMLS MSFC configuration.
Table 14-4 shows the default IPX MLS configuration.
Table 14-4 Default IPX MLS Configuration
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
These sections describe the IP MLS configuration guidelines:
•
•
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.
IP MMLS
These sections describe the IP MMLS configuration guidelines:
•
•
IP MMLS Supervisor Engine Guidelines and Restrictions
This section describes the guidelines and restrictions for configuring Supervisor Engine 1 for IP MMLS:
•
•
•
•
•
•
•
IP MMLS MSFC Configuration Restrictions
IP MMLS does not perform multilayer switching for an IP multicast flow in these situations:
•
224.0.0.* through 239.0.0.*
224.128.0.* through 239.128.0.*
Note
•
Note
•
•
•
•
•
Unsupported IP MMLS Features
If you enable IP MMLS, the IP accounting for the interface will not reflect accurate values.
IPX MLS
These sections describe the configuration guidelines that apply when configuring IPX MLS:
•
•
IPX MLS Interaction with Other Features
Other Cisco IOS software features affect IPX MLS as follows:
•
•
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
These sections describe how to configure MLS:
•
•
Configuring Unicast MLS on the MSFC
These sections describe how to configure MLS on the MSFC:
•
•
•
•
For information on configuring routing on the MSFC, see Chapter 12, "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
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 one of these tasks:
This example shows how to disable IP MLS on an MSFC interface:
Router(config)# interface vlan 100Router(config-if)# no mls ipRouter(config-if)#This example shows how to disable IPX MLS on an MSFC interface:
Router(config)# interface vlan 100Router(config-if)# no mls ipxRouter(config-if)#
Note
To enable unicast IP or IPX MLS on a specific MSFC interface, perform this task:
Step 1
Specify an MSFC interface.
Router(config)# interface vlan-id
Step 2
Enable IP or IPX MLS on an MSFC interface.
Router(config-if)# mls ip
or
Router(config-if)# mls ipx
This example shows how to enable IP MLS on an MSFC interface:
Router(config)# interface vlan 100Router(config-if)# mls ipRouter(config-if)#This example shows how to enable IPX MLS on an MSFC interface:
Router(config)# interface vlan 100Router(config-if)# mls ipxRouter(config-if)#Displaying MLS Information on the MSFC
The show mls status command displays the MLS details. To display the MLS information on the MSFC, perform this task:
This example shows how to display the MLS status on the MSFC:
Router# show mls statusMLS global configuration status:global mls ip: enabledglobal mls ipx: enabledglobal mls ip multicast: disabledcurrent ip flowmask for unicast: destination onlycurrent ipx flowmask for unicast: destination onlyRouter#Using Debug Commands on the MSFC
Table 14-6 describes the MLS-related debug commands that you can use to troubleshoot the MLS problems on the MSFC.
Table 14-7 describes the MLS-related debug commands that you can use to troubleshoot the MLS problems when using the MSFC as an external router for a Catalyst 5000 family switch.
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).
