MSFC Native IOS Mode Layer 3 Switching

MSFC Native IOS Mode Layer 3 Switching

The MSFC Native IOS Mode approach to Layer 3 switching represents a unique and virtually ideal blend of Layer 2 and Layer 3 technology. It is the result of approximately six years of integration between Cisco routing and Catalyst switching (Cisco acquired Crescendo Communications, Inc. in the fall of 1993). Essentially, Native IOS Mode creates an environment where Catalyst 6000 switches can be completely configured and managed through the familiar and powerful IOS user interface.

The Benefits of Native IOS Mode

Chapters 11, 14, and 15 discussed the differences and unique benefits of the routing switch (MLS) and switching router (Catalyst 8500) approaches to Layer 3 switching. Table 18-1 summarizes the primary advantages and disadvantages of each.

Table 18-1. Primary Advantages and Disadvantages of MLS and 8500s

Technique Primary Advantages Primary Disadvantages
MLS Tight integration of Layer 2 and 3. Allows Layer 2 VLANs to transit the switch by default—can lead to excessively flat networks.

Requires the use of two separate user interfaces (IOS and XDI/CatOS).

Catalyst 8500s Uses the familiar IOS user interface. Integrating Layer 2 and Layer 3 generally requires the use of Integrated Routing and Bridging (IRB), a technique that can be difficult to manage in large networks.
Offers powerful integration features with ATM. Too Layer 3 oriented for some campus networks.

Doesn’t understand VLANs.

Although both approaches can be very effective in the appropriate design (MLS in Layer 2-oriented designs and 8500s in Layer 3-oriented designs), both suffer from some drawbacks (although some argue that most of these downsides are not a big deal).

Native IOS Mode is uniquely positioned in between the MLS and Catalyst 8500 approaches to Layer 3 switching. As such, it captures the Ethernet-based benefits of both while completely avoiding the downsides of both. As a result, the Native IOS Mode offers the following advantages:

  • It provides an extremely useful metaphor for configuring and integrating Layer 2 and Layer 3 technology. These capabilities are discussed in detail later in the chapter.
  • Because it uses a single user interface, organizations can avoid the confusion and training costs associated with supporting two interfaces.
  • Because it uses the IOS interface, most network personnel can use the Native IOS Mode technology with minimal training.
  • Because of the integrated user interface, organizations can more readily see and visualize their logical topology. Therefore, people are less likely to mistakenly create flat earth networks and campus-wide VLANs.
  • Although it is based internally on the same MLS technology used in the Hybrid Mode, the end user is insulated from having to configure MLS directly.
  • It understands and has full support for VLANs. (Although the Catalyst 6000 ASICs support Dynamic VLANs and VMPS, this feature is currently not supported on the platform because of its anticipated use as a backbone switch where all ports are hard-coded into each VLAN.)
  • It maintains almost all of the Layer 2 features of the XDI/CatOS Catalysts such as VTP, DTP/DISL, and PAgP.
  • These capabilities allow the Native IOS Mode MSFC to function as either a routing switch (as with MLS) or a switching router (as with 8500s). Although this can create confusion for those trying to discuss and explain such concepts, it creates an extremely powerful and flexible approach to Layer 3 switching.
  • Because the differences between the Hybrid Mode and Native IOS Mode consist only of software, it is easy to convert the box between the two as an organization’s needs change (it’s merely a matter of changing the images on flash).

Most importantly, the Native IOS Mode allows you to achieve all of these benefits while retaining the speed of the Hybrid Mode (first generation speeds will be approximately 15 mpps).

Note that the Catalyst 6000s and Native IOS Mode do not have the Catalyst 8500’s ATM switching and ATM-to-Ethernet integration capabilities.

MSFC Native IOS Mode Operating Concepts

As discussed earlier in the chapter, using an MSFC results in there being two CPUs onboard the Catalyst 6000’s Supervisor. One is the 150 Mhz R4700 used by the Layer 2-oriented Supervisor itself (when using a Catalyst 6000 Supervisor without an MSFC daughter card, this is the only CPU). This is referred to as the SP CPU. The second CPU is the 200 Mhz R5000 located on the RP (essentially an NPE-200 from a 7200 router).

Under the Hybrid Mode discussed in the previous section, the SP CPU runs an XDI/CatOS image and is used to control the Layer 2 side of the box, whereas the RP CPU runs the router IOS and is used to provide Layer 3 services. The key to the Native IOS Mode is that both CPUs run full IOS software. And no, this is not some warmed-over XDI/CatOS code made to look like IOS—the executable images used by both CPUs use the full-blown IOS kernel.

From a physical standpoint, the RJ-45 console port on the front of the Catalyst 6000 Supervisor is obviously connected to the SP CPUs hardware. However, during the 6000’s boot cycle, control is passed to the RP CPU. Therefore, in Native IOS Mode, the RP acts as the primary CPU, and the SP acts as the secondary. All human interaction is done directly through the RP CPU. As commands are entered that affect the Layer 2/SP side of the device, commands are passed over an internal bus from the RP to the SP.

Also notice that for performance reasons, both CPUs are fully functioning (the SP CPU is not sitting completely idle). The SP CPU concentrates on port-level management (such as link up/down) and Layer 2 protocols such as Spanning Tree, VTP, and DTP. The RP CPU performs duties such as routing the first packet in every IP or IPX flow (or all packets for protocols that are not supported by the NFFC/PFC), running routing protocols, CDP, and PAgP.

The two CPUs boot from two different binary image files. First, the SP CPU takes control and loads an image from flash memory. Then, it passes control to the RP image (along with passing control of the console port) so that it can boot another image and take over as the primary CPU for the entire device.

MSFC Native IOS Mode Configuration Concepts

The unique and unified user interface of the Native IOS Mode is what sets it apart. Before digging into specific commands, this section takes a look at several concepts that underlie the configuration process.

Nonvolatile RAM

As with all Cisco devices, there must be some place to store the configuration while the device is powered down. Almost all Cisco devices use Nonvolatile RAM (NVRAM) for this purpose. However, the Native IOS Mode MSFC is somewhat unique in that it maintains two sets of NVRAM configurations:

  • The VLAN database
  • The local switch configuration

Although it might appear strange at first to have two different sorts of NVRAM information, it makes complete sense upon closer inspection. Consider that each NVRAM repository is storing a different type of information. The VLAN database contains information that is global to the entire network. As information is added to this list, it should be immediately (or almost immediately) saved and shared through the entire VTP domain. (Assume that the current switch is a VTP server; for more information, see Chapter 12, “VLAN Trunking Protocol.”) Also, as VTP advertisements are received from other devices, they should immediately be saved (recall that the definition of a VTP server requires that all VLANs be saved to NVRAM).

On the other hand, the switch configuration is locally significant. Furthermore, these normal IOS configuration statements are only supposed to be saved when the user enters the copy run start or write memory commands. After all, one of the benefits to the IOS is that you can make all the changes you want and return to the exact place you started from by merely rebooting the box (assuming that you did not save the new configuration).

Therefore, rather than trying to interleave the two sets of data, two completely different stores are maintained. The VLAN database holds globally significant information that gets saved right away (as it would under the XDI/CatOS interface). The switch configuration stores locally significant information only when the user enters some form of a save command.

Configuration Modes

The split in NVRAM storage also corresponds to two different configuration modes:

  • VLAN database configuration mode
  • Normal IOS configuration mode

VLAN Database Configuration Mode

The VLAN database configuration mode is used to control VTP information. Not only can it be used to set the VTP mode to server, client, or transparent, it provides a mechanism to add, modify, and delete VLANs. Example 18-9 shows some basic VLAN database commands from the online help system.

Example 18-9 Using the VLAN Database Configuration Mode

To use the VLAN database configuration mode, enter the vlan database command from the EXEC prompt. This places you in the VLAN database mode and modifies the prompt to indicate this (the prompt now consists of the RP’s name and the word vlan in parentheses). As shown by the online help in Example 18-9, the vtp command can be used to control the VTP configuration of a device. For example, set vtp client and set vtp transparent change a Catalyst to client and transparent modes, respectively. The device can be returned to the default of server mode with the command set vtp server. The command set vtp domain Skinner changes the VTP domain name to Skinner. There are other commands to control VTP features such as passwords, pruning, and version 2 support.

The vlan command shown in Example 18-9 can be used to add, delete, or modify VLANs. For example, the command vlan 2 name Marketing creates VLAN 2. Then, issuing the command vlan 2 name Finance changes the VLAN’s name from Marketing to Finance. Entering no vlan 2 removes VLAN 2 altogether. When creating or modifying VLANs, additional parameters can be specified to control attributes such as MTU and media type. Example 18-10 shows a list from the online help screen.

Example 18-10 Online Help Listing of Available VLAN Parameters

After making changes, you can apply them. At this point, the changes are saved to the VLAN database section of NVRAM (therefore, VLAN changes made under Native IOS Mode are not as immediate as those made under the XDI/CatOS interface). The exit command can be used to first apply the changes to the database and then return to the EXEC mode.

Normal IOS Configuration Mode

Contrary to VLAN database mode, the normal IOS configuration mode should be familiar to all users of traditional Cisco router platforms. To enter this mode, use the configure terminal command. From there, the usual interface interface-type interface-number, router protocol, and line line-type number submodes can be used to configure the routing characteristics of the device. To exit the normal IOS configuration mode, enter the exit command to move one level at a time up towards the EXEC mode. To jump straight from a submode to EXEC mode, use the end command or press Ctrl-Z. In Normal IOS configuration mode, commands are applied to the running configuration as soon as you press the Enter key. However, commands are only saved to NVRAM when you enter copy run start or write mem.

Native IOS Mode Interface Types

Much of the appeal of the Native IOS Mode centers around the way in which it handles the various types of ports that exist in the typical campus network. Rather than relying on IRB to mix Layer 2 and Layer 3 in the same device (as mentioned earlier, IRB can be confusing and difficult to configure and manage), Native IOS Mode has a unique approach that is powerful, flexible, and intuitive.

In all, there are two primary types of interfaces under the Native IOS Mode:

  • Routed interfaces
  • Switched interfaces (also called switchport interfaces)

These two primary types can be further subdivided into the following four interface types:

  • Routed Physical Interfaces
  • Routed SVI Interfaces
  • Access Switchport Interfaces
  • Trunk Switchport Interfaces

Each of these is discussed in the following sections.

Routed Physical Interfaces

Like all Cisco IOS devices, interfaces default to being routed. In this configuration, every port receives its own IP and/or IPX address. Notice that each of these must fall on a unique IP subnet or IPX network. For example, if you try to assign to interface 5/2 when interface 5/1 has already been assigned, you receive the following message:

  • Tip
    The Native IOS Mode and the XDI/CatOS user interfaces use the terms interface and port differently. In Native IOS Mode, Layer 3 external connections are called interfaces, and Layer 2 connections are referred to as ports (actually, switchports). Under XDI/CatOS, the term interface is used to only refer to the management entities such as SC0, SL0, and ME1 (in the case of SC0 and SL0, these are logical ports that you cannot see and touch; in the case of ME1, it is a physical port, but it cannot be used for end-user traffic). XDI/CatOS uses the term port to refer to all external points of connection (these are ports you can physically touch). This chapter uses the terms interface and port interchangeably.

Also notice that the Native IOS Mode software numbers interfaces starting from 1, not 0 (in other words, the first interface is 1/1, not 0/0). Although this is different than other IOS devices, it is consistent with the rest of the Catalyst platform.

In a similar fashion, you receive the following error message if you try to assign both interfaces to the same IPX network number:

Note that this behavior is the same throughout Cisco’s entire router product line. It is not some strange thing cooked up just for the Catalyst 6000 Native IOS Mode.

Access Switchport Interfaces

To place several interfaces in the same IP subnet or IPX network, a common practice in virtually all campus networks, you need to convert the port from a routed interface to a switched interface. To do so, simply enter the switchport command on the appropriate interface. For example, the code shown in Example 18-11 does this for interfaces 5/1 and 5/2.

Example 18-11 Placing Two Interfaces in the Same VLAN (Default = VLAN 1)

Switchports automatically dfault to VLAN 1 (although this assignment is not made until after the switchport command has been entered). To alter this assignment, you can use additional switchport commands. First, decide if you want the interface to be an access port (one VLAN) or a trunk port (multiple VLANs using ISL or 802.1Q). This section looks at access ports (trunk ports are discussed later). To create an access port, first enter the switchport mode access command on the interface. Then enter switchport access vlan vlan-identifier to assign a VLAN. For example, Example 18-12 assigns 5/1 and 5/2 to VLAN 2.

Example 18-12 Creating Access Port in VLAN 2

However, trying to assign an IP address to 5/1 or 5/2 at this point does not work. If you try this, the RP outputs the following message:

If you think about it, this makes complete sense—these two interfaces have been converted to Layer 2 ports that do not directly receive Layer 3 IP and IPX addresses. This is the same restriction placed on other Layer 2 ports. For example, you cannot apply IP addresses to ports in the XDI/CatOS Catalyst configuration. Also, when using bridging on IOS-based Cisco routers, you cannot assign Layer 3 addresses to the same interface that contains a bridge-group (the software lets you make the assignment, but the interface is now routing that protocol, not bridging it; see Chapter 11 for more information on bridge-groups).

Routed SVI Interfaces

To assign an IP address to 5/1 and 5/2, you need a separate interface that can act as the routed interface on behalf of both switchports. This is where the Switch Virtual Interface (SVI) comes in. SVIs use names like interface VLAN 1 and interface VLAN 2. These interfaces receive the Layer 3 information for each VLAN. As switchports are added and removed from various VLANs, they automatically participate in the Layer 3 environment created by the appropriate SVI.

Notice that this is the same as the RSM. In fact, it is this automatic linkage between Layer 3 SVI VLAN interfaces and Layer 2 switchports that makes the Native IOS Mode such an attractive vehicle for configuring campus networks.

To create an SVI, simply enter the interface VLAN vlan-identifier command. This places you in interface mode for that VLAN (the prompt changes to RP_Name(Config-if)#) where you can configure the appropriate Layer 3 information. For example, Example 18-13 creates and configures VLANs 1 and 2 with IP and IPX addresses.

Example 18-13 Creating Two SVI Interfaces

Although all ports are assigned to VLAN 1 by default, the VLAN 1 SVI does not exist by default. To assign Layer 3 attributes to VLAN 1, you must create this SVI.

Trunk Switchport Interfaces

Finally, trunk interfaces can be created to carry multiple VLANs using ISL or 802.1Q encapsulations. To apply trunking to a switchport, simply enter the switchport trunk encapsulation [ dot1q | isl | negotiate ] command. Several other switchport trunk parameters can be used to tune the behavior of the trunk. The native parameter can be used to set the 802.1Q native VLAN (this VLAN is sent untagged). The allowed parameter can be used to control the VLANs that are forwarded out that interface. Similarly, the pruning parameter can be used to control VTP pruning on the link.

For example, the code in Example 18-14 makes Port 5/10 an ISL trunk for VLANs 1—10.

Example 18-14 Creating a Trunk

Therefore, in total, the MSFC Native IOS Mode uses four port/interface types as summarized in Table 18-2.

Table 18-2. MSFC Native IOS Mode Port/Interface Types

Port/Interface Type Use Sample Configuration Commands
Routed Physical Interface Used to configure interfaces functioning as fully routed port. Conceptually, these interfaces are similar to ones found on traditional Cisco router platforms. interface GigabitEthernet1/1 ip address ipx network FEEDFACE
Routed SVI Interface Acts as the single routed interface for the collection of all switchports assigned to a given VLAN. interface Vlan1 ip address ipx network FEEDFACE
Access Switchport Interface Used to configure a Layer 2 port that belongs to one VLAN. interface GigabitEthernet1/1 switchport switchport access vlan 1 switchport mode access
Trunk Switchport Interface Used to configure a Layer 2 port that belongs to multiple VLANs. interface GigabitEthernet1/1 switchport switchport trunk


About the author


Leave a Comment