CCNP Practical Studies: Layer 3 Switching

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:

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:

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.

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.

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

¹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

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

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.

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 exist—destination, source-destination, and full flow. You normally don't need to modify the default flow mask of destination, as the configuration of features that require a higher resolution masks, such as implementing ACLs on the MLS-RP, is performed automatically. If you do wish to configure the minimum flow mask to a higher resolution flow mask, you can use the set mls flow command:

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

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

Example 6-73 Configuring the Minimum Flow Mask on CatOS

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

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.

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 entries—one for each direction packets are sent.

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

Verifying MLSP Operation

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

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

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

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

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

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

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

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

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

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

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

Switch-A> (enable) show mls entry ip
Destination IP Source IP    Prot DstPrt SrcPrt Destination Mac  Vlan Port
--------------- --------------- ---- ------ ------ ----------------- ---- -----
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

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.