Implementing MLS for high performance packet switching

In this Daily Feature, Robert McIntire shows you how to implement and configure multilayer switching to help optimize your routing devices.

In the first installment of this series on Cisco multilayer switching (MLS), “Multilayer switching: Switching at the speed of wire”, I introduced the concept of Layer 3 switching. I discussed the basic components: the MLS SE (switching engine) and the MLS RP (route processor). I also described how the MLS process works with flows and when to employ the technology.

In this Daily Feature, I’ll be addressing how to configure the Cisco switching and routing devices to implement MLS for high-performance packet switching.

IOS version
The following configuration examples assume the use of IOS 12.x on the RP and CatOS 5.4 on the switch.

Configuring the MLS SE
Activating MLS on the switch only requires a single command:
MLS-switch (enable) set mls enable

If you are implementing MLS with an external RP, you’ll also need to designate which RP the switch should listen to:
MLS-switch (enable) set mls include {ip address of RP}

There are several other commands that can be configured on the SE that have an effect on MLS performance. They mostly affect how the MLS cache functions and how it ages out cache entries. Generally speaking, the defaults are more than adequate in most network environments. If your environment has erratic flows, however, you may find that the default values for cache aging can nullify any beneficial effect MLS could have on network performance. The key is to set the timers so that your cache doesn’t age out flow information too quickly or too slowly. If the timers are set too low, then flow entries will be purged out too quickly, and as a result you will reap no benefit from MLS. In this case, the first packet from the flow would cause an entry to be added to the cache, but this entry would be purged before the next packet in that flow would arrive. So basically, the cache just keeps churning entries without actually performing any Layer 3 switching.

Another less than optimal case would be if the timer were set to such a value that some of the packets in the flow were switched at Layer 3, but the cache entry was then purged before the flow completed. The perfect situation would be that one cache entry was made for each flow and that entry was not purged until the flow was complete. We have to face facts, though—it’s not a perfect world. In a high-traffic network, the cache may be filled too quickly if entries are aged too slowly. It’s always a trade-off between performance and cache memory management. Again, since the default values are usually adequate for most network environments, I don’t recommend modifying the aging timers unless you know what you’re doing or you have recognized a bona fide problem with the cache timing. To check the MLS cache for possible performance issues, use the following command:
MLS-switch (enable) show mls

This command will yield (among other things) MLS cache statistics. Another command will produce more detail:
MLS-switch (enable) show mls entry

If you do need to tune the aging timers, use the following commands:
MLS-switch (enable) set mls agingtime {aging time}

I suggest checking the current settings before changing this timer. Then make only incremental changes rather than wide sweeping changes. Another timer, the fast aging timer, handles flows of short duration.

These two parameters together specify how many packets (threshold) must be received within a period of time (fast aging time) if the flow entry is to remain cached. It is a tool that can help you tune the cache so that it does not become overly laden with entries for short flows.

VTP before MLS
Remember that VTP (VLAN Trunk Protocol) must be configured on the switch before implementing MLS. The VTP allows a trunk link between devices to carry traffic from different VLANs. Since the Multilayer Switching Protocol (MLSP) must often carry traffic across these trunks to and from the RP, VTP is a prerequisite to MLS. If it is not already configured, execute the following commands:
MLS-switch (enable) set vtp domain {domain name}
MLS-switch (enable) set vtp domain {domain name}mode client

Configuring the MLS RP
As you may remember, the RP can be implemented in two different manners: internal and external. To configure the RP for MLS, you first need to enable MLS:
MLS-rp (config)# mls rp ip

After this, we need to associate the MLS interface of the RP to the VTP domain of the SE:
MLS-rp (config)# interface ethernet0/1
MLS-rp (config)# mls rp vlan-id 10
MLS-rp (config-if)# mls rp vtp-domain {vtp domain name}

In this example, we assigned the Ethernet port 0/1 of an external router to the VTP domain. This interface handles VLAN 10. If this were an internal RP, the first command would look a little different since the interface is logical rather than physical. With an internal Layer 3 module as the MLS RP, the first command would look like this:
MLS-rp (config)# interface vlan10

There would be no need to identify the VLAN ID in this case. Next, we must activate MLS on the interface itself:
MLS-rp (config-if)# mls rp ip

You’ll notice that this command looks exactly like the one we used to activate MLS on the RP itself. It is issued once from global config mode and then from interface config mode. Finally, we need to designate the management interface for MLS. We also do this from interface config mode:
MLS-rp (config)# interface vlan10
MLS-rp (config-if)# mls rp management-interface

At this point, we’re configured for MLS. To verify this, you’ll want to use the following command:
MLS-rp (config)# show mls rp interface vlan10

The output will give you details about MLS configuration on the RP that will help you to determine proper setup.

So, how do we quantify MLS performance gains? Well, if you have a high-traffic network with an overworked router handling all inter-VLAN traffic, the positive effects of MLS should be obvious. You probably won’t hear as many user complaints about response time (for inter-VLAN traffic). In other networks, the results of MLS may seem a bit subtler. If you’re dead-set on measuring the gain, you can employ a traffic-analysis tool that measures network latency by generating packets bound to cross VLAN barriers and measuring the ensuing delay. You can compare throughput with MLS turned on and then off. But, chances are the point is moot. If you’ve come to the MLS table, then it’s likely that you’ve been suffering network throughput issues for some time. If that was the case, then rest assured that Layer 3 switching was the next logical choice.

Editor's Picks