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 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 192.168.2.1 can be represented as a flow. All packets sent from a source IP address of 192.168.2.1 to a destination IP address of 192.168.2.2 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 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 (192.168.2.100). 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 (192.168.1.200) 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 192.168.1.1 and 192.168.2.1 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 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 192.168.1.100, destination IP address of 192.168.2.100, 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.

NOTE

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.

NOTE

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

Platform

Hardware Requirements

Software Requirements

Catalyst 5000/5500

Supervisor 2G/3G/3/3F

NetFlow Feature Card

CatOS 4.1(1)

Catalyst 6000/6500[1]

Policy Feature Card

5.1(1)


[1] The 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

Platform

Software Requirements

3600

12.0(2)

4500/4700

7200/7500

11.3(2)WA4(4)

Catalyst 5000 RSM/RSFC

12.0(3c)W5(8a)

Catalyst 6000 MSFC

All software trains


NOTE

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

Device

Required Configuration

 

Parameter

Value

Switch-A

Hostname

Switch-A

sc0 IP Address (VLAN)

192.168.1.10/24 (VLAN 1)

Enable/Telnet Password

cisco

VTP Mode

Transparent

VTP Domain Name

lanps

VLANs (Name)

VLAN 2 (VLAN02)

VLAN Assignments

VLAN 2: port 2/3

ISL Trunks (DTP Mode)

2/1 (nonegotiate)

Router-A

Hostname

Router-A

Enable/Telnet Password

cisco

ISL Trunks

FastEthernet0/0

ISL Trunk Subinterfaces

FastEthernet0/0.1 (VLAN 1)

IP Address

FastEthernet0/0.2 (VLAN 2)

(Interface)

192.168.1.1/24 (fa0/0.1)

192.168.2.1/24 (fa0/0.2)

Host-X

Operating System

Windows 2000 Professional or Windows XP

IP Address

192.168.1.100/24

Default Gateway

192.168.1.1

Host-Y

Operating System

Windows 2000 Professional or Windows XP

IP Address

192.168.2.100/24

Default Gateway

192.168.2.1

Applications

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 192.168.1.10 255.255.255.0 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 192.168.1.1 255.255.255.0 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 192.168.2.1 255.255.255.0 

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.

WARNING

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 192.168.1.1 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 192.168.1.1 Multilayer switching is enabled for router 192.168.1.1 

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 existdestination, 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. 

WARNING

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.

NOTE

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 192.168.1.1 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 192.168.1.1. 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 IP MLS-RP IP     MLS-RP ID    XTAG MLS-RP MAC-Vlans ---------------- ------------ ---- --------------------------------- 192.168.1.1      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 --------------- --------------- ---- ------ ------ ----------------- ---- ----- MLS-RP 192.168.1.1: 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 192.168.2.100 Pinging 192.168.2.100 with 32 bytes of data: Reply from 192.168.2.100: bytes=32 time=4ms TTL=128 Reply from 192.168.2.100: bytes=32 time<1ms TTL=128 Reply from 192.168.2.100: bytes=32 time<1ms TTL=128 Reply from 192.168.2.100: bytes=32 time<1ms TTL=128 Ping statistics for 192.168.2.100:     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 --------------- --------------- ---- ------ ------ ----------------- ---- ----- MLS-RP 192.168.2.2:  No entries MLS-RP 192.168.1.1: 192.168.1.100   192.168.2.100   -    -      -      00-10-a4-e0-1e-d3 1    2/2 192.168.2.100   192.168.1.100   -    -      -      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 192.168.1.1 (Router-A). The first entry indicates that any IP packet with a source IP address of 192.168.2.100 (Host-Y) and a destination IP address of 192.168.1.100 (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 (192.168.1.100) to Host-Y (192.168.2.100). Example 6-12 demonstrates that a bidirectional communications session between two devices generates two flow entriesone 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.

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 --------------- --------------- ---- ------ ------ ----------------- ---- ----- MLS-RP 192.168.2.2:  No entries MLS-RP 192.168.1.1: 192.168.2.100   192.168.1.100   TCP  Telnet 3779   00-06-53-fe-84-20 2    2/3 192.168.2.100   192.168.1.100   TCP  Telnet 3780   00-06-53-fe-84-20 2    2/3 192.168.1.100   192.168.2.100   TCP  3780   Telnet 00-10-a4-e0-1e-d3 1    2/2 192.168.1.100   192.168.2.100   TCP  3779   Telnet 00-10-a4-e0-1e-d3 1    2/2 

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


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.




CCNP Self-Study CCNP Practical Studies. Switching
CCNP(R) Practical Studies: Switching (CCNP Self-Study)
ISBN: 1587200600
EAN: 2147483647
Year: 2002
Pages: 135
Authors: Justin Menga

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net