"Building and Securing Networks for over 18 years."

Phone - Call Direct: 805-681-5071

NetXG - Network Exchange - Specializing in Cisco Systems Network Equipment. Switch Router Firewall wireless.

Cisco > Switch > Catalyst 6500 Series > Compare Cisco Catalyst and Cisco IOS

Compare Cisco Catalyst and Cisco IOS Operating Systems in the Cisco Catalyst 6500 Series Switch

Compare Cisco Cat OS and IOS in 6500 Series Switch

PURPOSE

This white paper compares the two software Operating Systems available for the Cisco Catalyst® 6500 Series switches: the Catalyst Operating System (CatOS) software and Cisco IOS® Software. It discusses the software architecture, operation, and configuration for CatOS and Cisco IOS Software (also known as "Native" model) on Cisco Catalyst 6500 Series switches.

This paper is not intended to cover all features available in the Cisco Catalyst 6500 software, but provides a review of the more frequently used features of both software models*. Additionally, this paper is a migration guide for readers familiar with CatOS and considering migration to Cisco IOS Software on the Supervisor Engine. This is the third version of this document.

* All features and support references are to Cisco CatOS Version 8.5.1 release and Cisco IOS Software Release 12.2(18)SXF; there may have been caveats or general lack of support in previous releases that this document does not account for; refer to the release notes for specific details.

INTRODUCTION

The proliferation of intranet and Internet-based applications is driving new business models such as e-commerce and e-learning. Delivered via intelligent Internet Protocol (IP) services, these applications are transforming corporate-intranet and service provider infrastructures into competitive tools which offer lower business costs, faster information flow, and scalable services. In its market leadership position, Cisco Systems offers various software options that enable services throughout a network infrastructure and give customers a choice of software to fulfill their specific networking needs and requirements. The Cisco Catalyst 6500 Series Switches provide two software operating system models:

• Cisco CatOS on the Cisco Catalyst 6500 Series with optional Cisco IOS Software on the Multilayer Switching Feature Card (MSFC) provides Layer 2/3/4 functionality for the Cisco Catalyst 6500 by integrating two operating systems. A switch running CatOS only on the Supervisor Engine is a Layer 2 forwarding device with Layer 2/3/4 functionality for QoS, security, multicast, and network management of the Policy Feature Card (PFC), but does not have any routing capabilities. Layer 3 routing functionality is provided via a Cisco IOS Software image on the MSFC routing engine (optional in Supervisor 1A and 2, and integrated within Supervisor 32 and 720.) In this paper, the combination of CatOS on the Supervisor Engine and Cisco IOS Software on the MSFC is referred to as the "hybrid" OS; two operating systems work together to provide complete Layer 2/3/4 system functionality.

The hybrid model operates based on two operating images, two configurations, and two command lines; one each for CatOS and Cisco IOS Software. The default operation of CatOS is as a switch (all ports bridging in VLAN 1). Additionally, the switch running Hybrid OS can be configured to operate as a router.

This operating model, as a Layer 2 forwarding device, targets wiring closets or access layer services with protocols such as IEEE 802.1x, inline power, and voice virtual LAN (VLAN) identification. With the MSFC daughter module installed, the chassis is suitable for distribution layers of a network. Because the Supervisor Engine 720, which ships by default with an MSFC3, and the Supervisor Engine 32, which ships by default with the MSFC2A, are supported under the Hybrid operating model, CatOS with Cisco IOS on the MSFC is suitable for Enterprise Cores. Combined with 10-Gigabit Ethernet modules, Hybrid operating system model serve as powerful solutions to bandwidth intensive, high throughput networks.

• Cisco IOS Software for the Supervisor Engine on the Catalyst 6500 Series provides a single Cisco IOS image, configuration, and command line to support all Layer 2, 3, and 4 functionality on the switch. Cisco IOS has historically been a Layer 3 operating system on routing platforms, and when installed on the Supervisor Engine of a Catalyst 6500 has expanded these capabilities to include true Layer 2 functionality as well. Cisco IOS requires an MSFC daughter card be present on the Supervisor Engine (default on the Supervisor Engine 32 and 720). In this paper, the term "Cisco IOS" refers to the Cisco IOS Software on the Supervisor Engine of the Catalyst 6500 Series switches.

The default operation of the Cisco IOS Software is as a router (all ports are Layer 3 and in the shutdown state), but the interfaces can also be configured to operate as a switch.

The Cisco IOS operating model targets service provider and enterprise data center backbones and distribution layer services. When combined with services modules, the software model is powerful for Integrated Data Centers. Cisco IOS Software combines the switching features of the Catalyst 6500 Series Switch with routing features of Cisco IOS Software to create a single, integrated operating system that performs all switching and routing functionality, providing operational ease of use. A Cisco IOS system has the capability to scale the throughput and bandwidth of a Catalyst 6500 Series to 400+ Mpps and 720 Gbps, respectively.

The software operating models described above can coexist in network environments to satisfy varying requirements. One model is recommended over another based solely on feature support, as both models are not at 100 percent feature parity. Figure 1 illustrates where both Hybrid and Cisco IOS operating models should be deployed in network architectures.

ARCHITECTURE COMPARISON

The Cisco Catalyst 6500 offers a high-performance blend of Layer 2/3/4+ technology. Independent of the software model chosen, the forwarding intelligence of the system is handled in the following hardware: the Supervisor Engine (with switch processor) baseboard, the PFC daughter card, and the MSFC (route processor) daughter card (Figure 2).

Figure 2. Cisco Catalyst 6500 Intelligence Components

Switch Processor Functions

The Switch Processor, which controls all chassis operations, runs a 250-Mhz R7000 CPU on Supervisor 2, 400-Mhz R7000 CPU on the Supervisor 32 and a 600-Mhz R7000 CPU on Supervisor 720. Chassis operations include the detection of Online Insertion and Removal (OIR) events, power management, environmental management and redundancy management. The Switch Processor also handles the download of the appropriate line card firmware to each line card, basic port management (setting of port configuration, detection of link state, etc.) and other Layer 2 functionality such as Spanning Tree, VLAN Trunking Protocol (VTP), Internet Group Management Protocol (IGMP) snooping, and Dynamic Trunking Protocol (DTP). Finally, the Switch Processor provides console connection for CatOS or Cisco IOS during initial system boot.

Route Processor Functions

The Route Processor (RP) runs a 300-Mhz R7000 CPU (MSFC2 and MSFC2A) or a 600-Mhz R7000 CPU (MSFC3) and provides Layer 3 functionality such as routing and Cisco Express Forwarding table creation. Cisco Express Forwarding is the default Layer 3 forwarding mechanism. The RP is responsible for creating and maintaining Cisco Express Forwarding and adjacency tables while pushing this information down to the PFC for hardware forwarding, QoS and security functionality. Other functions residing on the RP include IP address resolution (ARP) and routing table maintenance.

Policy Feature Card (PFC)

The PFC is the application-specific integrated circuit (ASIC) forwarding complex for the system. The PFC performs the hardware-based features and services at a high performance level (tens of millions of packets per second). Features such as Layer 2 bridging, Layer 3 routing, access control, Quality of Service (QoS) marking and policing, NetFlow statistics, and multicast are implemented within the PFC.

Software Implementation

Cisco IOS mode mandates that both CPUs (SP and RP) run the full Cisco IOS Software operating system. There is no hidden Catalyst software running in the switch and the executable images used by both CPUs run the complete IOS kernel. With both processors running Cisco IOS Software, overall system performance is enhanced. However, should the MSFC fail, all Layer 2/3/4 functionality is lost.

In contrast, CatOS operates on the SP and the PFC to provide Layer 2 forwarding and Layer 3/4 services. Should the user require Layer 3 forwarding/routing capabilities, the MSFC daughter card must be present and runs Cisco IOS Software (as part of the hybrid OS) on the RP. Thus, should the MSFC fail in hybrid configurations, Layer 2 and PFC functionality are not affected and remain operational.

Software Feature Support

The two software models, CatOS and Cisco IOS, on the Cisco Catalyst 6500 Series are not at feature parity. The following table presents the CatOS and Cisco IOS Software support for some of the more commonly used protocols. Note that many features in Cisco IOS Software are not platform specific (for example, the OSPF, BGP, or PIM protocols). In these cases, the Cisco IOS features in hybrid OS are identical to those in Cisco IOS Software.

Table 1 lists commonly used software features available in Cisco CatOS Version 8.3.1 and Cisco IOS Software Release 12.2(18)SXF (this includes all features available through 12.1(26)E3). Feature support is hardware dependent where noted.

Table 1. Software Comparison

Software Feature	CatOS	Cisco IOS
VLAN Ranges: up to 4096 VLAN SVIs (Layer 3 VLAN interfaces)	x	x
Inter VLAN Routing	x	x
4096 Layer 2 VLANs	x	x
Private VLANs	x	x
Dynamic VLANs	x
Trunking: IEEE 802.1q, ISL	x	x
DTP, VTP	x	x
VTPv3	x
IEEE 802.1q tunneling	x	x
Layer 2 Protocol tunneling	x	x
Spanning Tree: PortFast, UplinkFast, BackboneFast, BPDU Guard, PRRST+, PVRST	x	x
IEEE 802.1s and 802.1w	x	x
Jumbo Frames	x	x
EtherChannel, Port Aggregation Protocol (PAgP)	x	x
EtherChannel, IEEE 802.3ad (LACP)	x	x
Local and Remote Span (RSPAN)	x	x
Multicast Services: PIM, IGMP Snooping, RGMP, Bi-dir PIM	x	x
QoS Marking, Policing, Scheduling	x	x
QoS ACLs	x	x
Routing ACLs	x	x
VLAN ACLs	x	x
Port-Based ACLs (PACLs)	x
HSRP	x	x
VRRP	x	x
GLBP	x	x
IPv6		x
Any Transport over MPLS (AToM), (PFC3bXL only)		x
MPLS (PFC3b and PFC3bXL only)		x
Cisco IOS Server Load Balancing		x
Broadcast Suppression	x	x
Protocol Filtering, Cisco IOS Support on Supervisor Engine 1A Systems Only	x	x
Port Security	x	x
Secure Copy Protocol (SCP)	x	x
SSHv1 and SSHv2	x	x
Smart Ports Macros	x
IEEE 802.1x & VLAN Assignment	x	x
IEEE 802.1x Extensions Beyond VLAN Assignment	x
Time Domain Reflectometer (TDR)	x	x
AutoQoS	x
ARP Inspection	x	x
Dynamic ARP Inspection	x	x
DHCP Snooping	x	x
IP Source Guard	x
Network-Based Application Recognition (NBAR)	x	x
User-Based Rate Limiting		x
Cisco Discovery Protocol	x	x
NetFlow Data Export (NDE)	x	x
Unidirectional Link Detection (UDLD)	x	x
Voice VLAN ID (VVID) and Inline Power for Cisco IP Phones	x	x
Supervisor Redundancy and Failover	x	x
Stateful Supervisor Switchover	x	x
Multiprotocol Label Switching (MPLS), EoMPLS, MPLS VPN		x
Distributed Cisco Express Forwarding (dCEF)		x

Hardware and Line Card Support

Table 2 is a matrix of Cisco Catalyst 6500 Series line cards with operating system support.

Table 2. Hardware Modules

Chassis, Supervisors, and PFC Daughter Cards	CatOS	Cisco IOS
WS-C6513, WS-C6509, WS-C6509-NEB, WS-C6509-NEB-A, WS-C6506, WS-C6503, OSR-7609-AC/DC, CISCO7603, CISCO7606, CISCO7609, WS-C6509	x	x
WS-SUP720	x	x
WS-SUP720-3B	x	x
WS-SUP720-3BXL	x	x
WS-SUP32-10GE-3B	x	x
WS-SUP32-GE-3B	x	x
WS-X6K-PFC3BXL	x	x
WS-X6K-S2U-MSFC2	x	x
WS-X6K-S2-MSFC2	x	x
WS-X6K-S2-PFC2	x	NS
WS-X6K-S1A-MSFC2	x	x
WS-X6K-SUP1A-MSFC	x	x
WS-X6K-SUP1A-PFC	x	NS**
WS-X6K-SUP1A-2GE	x	NS**
WS-X6K-SUP1-2GE	x	NS**
CEF720 Series Modules and XENPAKs
Chassis, Supervisors, and PFC Daughter Cards	CatOS	Cisco IOS
WS-X6748-SFP	x	x
WS-X6748-GE-TX	x	x
WS-X6724-SFP	x	x
WS-X6704-10GE	x	x
WS-X6748-GE-TX	x	x
WS-F6K-DFC3A		x
WS-X6700-DFC3		x
XENPAK-10GB-SR	x	x
XENPAK-10GB-LX4	x	x
XENPAK-10GB-CX4	x	x
XENPAK-10GB-LR	x	x
XENPAK-10GB-ER	x	x
Switching Fabric Modules
WS-C6500-SFM	x	x
WS-X6500-SFM 2	x	x
CEF256 and dCEF256 Series Modules
WS-F6K-DFC		x
WS-X6816-GBIC		x
WS-X6501-10GEX4	x	x
WS-X6502-10GE	x	x
WS-G6483	x	x
WS-G6488	x	x
WS-X6516-GBIC	x	x
WS-X6516A-GBIC	x	x
WS-X6516-GE-TX	x	x
WS-X6524-100FX-MM	x	x
WS-X6548-GE-TX/V	x	x
WS-X6548-RJ-21	x	x
WS-X6548-RJ-45	x	x
Classic Modules
WS-X6416-GBIC	x	x
WS-X6416-GE-MT	x	x
WS-X6316-GE-TX	x	x
WS-X6408A-GBIC	x	x
WS-X6408-GBIC	x	x
WS-X6324-100FX-SM/MM	x	x
WS-X6224-100FX-MT	x	x
WS-X6348-RJ-21/V	x	x
WS-X6348-RJ-45/V	x	x
WS-X6148X2-RJ-45	x	x
WS-X6148-GE-TX/V	x	x
WS-X6148-RJ-45V	x	x
WS-X6148-RJ21V	x	x
WS-X6248-RJ-45	x	x
WS-X6248A-TEL	x	x
WS-X6248-TEL	x	x
WS-X6024-10FL-MT	x	x
Voice Daughter Cards for Modules
WS-F6K-FE48X2-AF (for WS-X6148X2-RJ-45)	x	x
WS-F6K-FE48-AF (for WS-X6148-RJ-45 and WS-X6148-RJ-21)	x	x
WS-F6K-GE48-AF (for WS-X6548-GE-TX and WS-X6148-GE-TX)	x	x
Services Modules and Voice Modules
WS-X6624-FXS (EOS and EOL-May 15, 2005)	x
WS-X6608-T1/E1	x
WS-X6381-IDS (EOS and EOL-March 26, 2004)	x	x
WS-SVC-IDSM2-BUN-K9	x	x
WS-X6380-NAM (EOS External Announcement-June 24, 2002)	x	x
WS-X6066-SLB-APC	x	x
WS-SVC-CSG-1	x	x
WS-SVC-CMM-6T1/E1	x	x
WS-SVC-NAM-1	x	x
WS-SVC-NAM-2	x	x
WS-SVC-FWM-1-K9	x	x
WS-SVC-CMM	x	x
WS-SVC-MWAM-1		x
WS-SVC-CSG-1	x	x
WS-SVC-PSD-1 (Persistent Storage Device)		x
WS-SVC-IDSM2-K9	x	x
WS-SVC-SSL-1-K9	x	x
WS-SVC-IPSEC-1		x
WS-SVC-WLAN-1-K9		x
Miscellaneous Modules
WS-X6101-OC12-SMF/MMF	x
WS-X6302-MSM	x
WAN Modules
WS-X6582-2PA		x
WS-X6182-2PA	x	x
OSM-4GE-WAN		x
OSM-2+4GE-WAN+		x
OSM-4GE-WAN-GBIC	x	x
OSM-16OC3-POS-MM/SI/SL		x
OSM-2OC12-POS-MM/SI/SL	x	x
OSM-4OC12-POS-MM/SI/SL	x	x
OSM-4OC3-POS-SI	x	x
OSM-8OC3-POS-MM/SI/SL	x	x
OSM-16OC3-POS-MM/SI/SL	x	x
OSM-1OC48-POS-SS/SI/SL	x	x
OSM-1CHOC48/T3-SS/SI		x
OSM-4CHOC12/T3-MM/SI		x
OSM-2OC12-ATM-MM/SI		x
OSM-2OC12-POS-MM+/SI+		x
OSM-4OC12-POS-SI+		x
OSM-4OC3-POS-SI+/SL+		x
OSM-8OC3-POS-SI+		x
OSM-16OC3-POS-SI+		x
OSM-1OC48-POS-SS+/SI+/SL+		x
OSM-2OC12-ATM-MM+/SI+		x
OSM-2OC48/1DPT-SS/SI/SL		x
OSM-1CHOC12/T3-SI		x
OSM-12CT3/T1		x
OSM-2+4GE-WAN+		x

** IOS cannot be supported without an MSFC

Memory Requirements

The default memory requirements are the same for both the Cisco IOS Software and the CatOS software. The Supervisor Engine 2 ships with a default of 128 MB DRAM (upgradable to 512 MB) and 32 MB bootflash. The MSFC2 ships with 128 MB DRAM and can be upgraded to 512 MB, and has a 16 or 32 MB bootflash. The WS-X6K-S2U-MSFC2 is an orderable part number for 256 MB of DRAM on the Supervisor Engine 2 as well as 256 MB DRAM on the MSFC2. The Supervisor Engine 32 ships with 256 MB DRAM (upgradeable to 1Gb) and 512MB internal flash card on both the SP and the RP. Finally, the Supervisor Engine 720 ships with a default of 512 MB DRAM and 64 MB bootflash on both the SP and the RP.

Because the Cisco IOS Software images are combined Layer 2 and 3 images, they are larger than CatOS images. Some 12.1E Cisco IOS images are greater than 20 MB and require MEM-C6K-ATA-1-64M flash card to store more than one image per system equipped with Supervisor Engine 2.

For additional memory on the Supervisor Engine 720 and Supervisor 32, MEM-C6K-CPTFL64M/128M/256M/512M compact flash cards equipped with 64 MB, 128 MB and 256 MB, respectively, are available.

The Cisco IOS Software has specific memory guidelines for routing table capacity, which are documented in the release notes. Refer to the Cisco Catalyst 6500 Series release notes for these recommendations.

OPERATIONAL COMPARISON

Image Management

There are different image naming conventions for systems with hybrid operating systems and with Cisco IOS operating systems on the Supervisor Engines. Ensure the correct image is chosen for given hardware. The following sections describe the different image filenames for CatOS and Cisco IOS Software.

Operating System Files for the Hybrid OS

In the hybrid model, two separate image files are managed by the two different operating systems. The CatOS images are stored on the Supervisor bootflash or flash cards (PCMCIA for Supervisor 1A and Supervisor 2, and Compact Flash for both the Supervisor Engine 32 and Supervisor Engine 720). The Cisco IOS image for the MSFC is stored on the MSFC bootflash. The images can be moved between the active and standby supervisors using the copy command and uploaded to the switch via the TFTP application. Cisco Catalyst 6500 systems that run hybrid use the image names listed in Table 3.

Table 3. Hybrid OS Image Names

Image File	Description
cat6000-supx	CatOS image for Supervisor Engines where x is Sup2, Sup32 or Sup720. Stored on the Supervisor bootflash or flash cards.
c6msfcx-boot-mz	Layer 3 boot image where x is MSFC or MSFC2. Stored on the MSFCx bootflash: only. This image is required for running Cisco IOS Software on MSFC, recommended on MSFC2.
c6msfc-is-mz c6msfc2-is-mz c6msfc2a-ipbase_wan-mz c6msfc3-psv-mz	Layer 3 image for the MSFC, MSFC2, MSFC2A or MSFC3; works with the CatOS image on the Supervisor Engine. Stored on the MSFC bootflash: or sup-slot0 or sup-disk0 or sup-disk1:.

The same MSFC boot helper image (c6msfc-boot) is used for the hybrid OS and Cisco IOS Software. It is stored as the first file on the MSFC bootflash. The boot helper image is a limited function system image that has network interface code and end-host protocol code.

Note: The boot helper must never be erased on the MSFC(1) and should be the first image on the MSFC bootflash. The MSFC2, MSFC2A and MSFC3 hardware does not require the boot image as it has more sophisticated ROMMON*** functionality; however, keeping a boot image in the MSFC bootflash is still a good practice for last resort scenarios. Boot images are not available for the MSFC2A or MSFC3.

*** ROMMON is the low-level software used for fundamental hardware operation before CatOS or Cisco IOS Software take control of the system.

Operating System Files for Cisco IOS Software

Cisco IOS Software requires the single image be present on a device local to the Supervisor because it is a bundled image for two processors and the SP boots first. The image can reside either on the Supervisor bootflash (sup-bootflash:) or the flash card (slot0 or disk0); it cannot reside on the MSFC bootflash. Cisco IOS system files start with `c6supxy' where x is the supervisor model number and y is the MSFC model number or with the Supervisor Engine 32 and Supervisor Engine 720, s(SUP)vw where SUP is the Supervisor Engine, v is the MSFC version and w is the PFC version.

Table 4. Cisco IOS Image Names

Image File	Description
c6sup11	Bundled Layer 2-4 image for Supervisor 1, MSFC 1
c6sup12	Bundled Layer 2-4 image for Supervisor 1, MSFC 2
c6sup22	Bundled Layer 2-4 image for Supervisor 2, MSFC 2
s3223	Bundled Layer 2-4 image for Supervisor 32, MSFC 2A, PFC3x
s72033	Bundled Layer 2-4 image for Supervisor 720, MSFC 3, PFC3x

Note: Flash card formats vary between CatOS and Cisco IOS Software thus flash cards must be formatted when switching between operating system models.

Storage Devices

In Cisco IOS Software, the storage devices on the active Supervisor are as follows:

slot0	Active Supervisor Linear Flash Card
disk0, disk1	Active Supervisor ATA or Compact Flash Card
sup-bootflash:	Active Supervisor 16 MB, 32 MB, or 64 MB (Sup720) onboard flash
bootflash:	Active MSFC 16 or 32 MB or 64MB (Sup720) onboard flash
bootdisk:	Active onboard flash (Sup32)

New images can be copied into the standby supervisor: flash card, RP bootflash: or SP bootflash:/bootdisk: from the active supervisor. The standby storage devices are as follows:

slaveslot0	Standby Supervisor Flash Card
slavesup-bootflash:	Standby Supervisor 16 MB, 32 MB, or 64 MB (Sup720) onboard flash
slavesup-bootdisk:	Standby Supervisor 64MB (Sup32) onboard flash
slavedisk0	Standby Supervisor Flash Card (Sup32 Sup720)
slavebootflash:	Standby MSFC 16 MB or 64MB (Sup720) onboard flash

The following is an example of the command you use to copy from active supervisor flash card to standby supervisor flash:

IOS# copy disk0 s72033-jk9sv-mz.122-18.SXD slavesup-disk0

Destination filename [s72033-jk9sv-mz.122-18.SXD]?

Determining the Current Operating System on a Cisco Catalyst 6500

The Cisco IOS command line for both the Cisco IOS portion of hybrid and Cisco IOS systems look identical. To determine what operating system is running on the switch, you can use the show version command from the Cisco IOS command line. To access the IOS (Layer 3) functionality in hybrid OS, enter session 15 (or 16) or switch console from the command line. The console is then turned over to the MSFC, and this is where both Cisco IOS and hybrid OS systems look identical.

From a Hybrid System

Router#show version

Cisco Internetwork Operating System Software

IOS (tm) MSFC2 Software (C6MSFC2-PSV-M), Version 12.1(19)E, EARLY DEPLOYMENT RELEASE SOFTWARE
(fc1)

From a Cisco IOS System

Router#show version

Cisco Internetwork Operating System Software

IOS (tm) c6sup2_rp Software (c6sup2_rp-PSV-M), Version 12.1(19)E, EARLY DEPLYMENT RELEASE
SOFTWARE (fc1)

Cisco IOS and Hybrid OS Boot Process

The boot process in both the Cisco IOS and the hybrid operating system models is automatic and transparent to the user. In the hybrid model, the boot processes are separate for both the switch and the route processors, as they each boot independent operating systems.

In Cisco IOS Software, both processors (the SP and RP) load the Cisco IOS Software. Two processors working together yield two ROMMONs and two bootflash devices. First, the SP boots to ROMMON and loads its portion of the Cisco IOS Software. When the SP is booted, the software control is passed to the RP so that the second processor can successfully boot. From a console perspective, the RJ-45 console port on the Supervisor Engine initially shows information from the SP. During the boot cycle for the Cisco Catalyst 6500 with the Cisco IOS Software, control is passed to RP CPU as shown in the following statement on the console:

System Bootstrap, Version 7.1(1) (Catalyst Supervisor ROMMON)

c6k_sup2 processor with 262144 Kbytes of main memory

000003: %OIR-6-CONSOLE: Changing console ownership to route processor

System Bootstrap, Version 12.1(19)E, RELEASE SOFTWARE (fc1) (MSFC or RP ROMMON)

Cat6k-MSFC2 platform with 524288 Kbytes of main memory

After this point the Route Processor controls the system. From the software perspective, the RP acts as the primary CPU and the SP acts as the secondary CPU. This is transparent to the user, all configuration commands are entered directly through the Route Processor CPU in Cisco IOS Software. Commands entered that affect the SP functionality are passed internally from the RP to the SP.

Unlike CatOS, net booting a Cisco IOS image from a TFTP server is not supported because the Supervisor image is a bundled image for two processors. The runtime image location (c6sup<xy>-is-mz-<version>) must be stored on a device local to the SP (sup-bootflash) or the flash card (slot0, disk0, disk1:).

Logging into the Switch Processor in Cisco IOS Software

While the command line perspective is from the RP, you can log into the Switch Processor for any Layer 2-specific debugging. You can use the following commands to debug and to check the Switch Processor status during runtime. Note that all Layer 2 thru Layer 4 configurations are done from the main Cisco IOS command line:

• Remote Login-The remote login command (or remote login switch for the sup 2, Sup32 and Sup720) is equivalent to the session command in CatOS. The hostname becomes the `hostname-sp'. Use the exit command rather than Control-C to exit the SP.

• Remote Command-If only one command's output is needed from the SP, use a remote command <command> (or remote command switch <command> for the Supervisor Engine 2, 32 and 720) as seen below.

Note: There is no help facility (i.e., remote command show ?) when using the remote command.

IOS#remote command sw show bootvar

IOS-sp#

BOOT variable = bootflash:c6sup22-psv-mz.121-11b.EX,1

CONFIG_FILE variable =

BOOTLDR variable does not exist

Configuration register is 0x2002

IOS#

Switch Management

While the direct console cable connection is a useful way for managing a Cisco Catalyst 6500, other methods of network-based management (such as telnet or SNMP) require a management interface with which to access the switch. In CatOS, two management interfaces, sc0 and sc1, are available for the system. An IP address and VLAN must be assigned to these interfaces, should both be in use. Any IP-based management of a CatOS system is then directed to the sc0 or sc1 interface address. With the hybrid OS, the sc0/sc1 interface is used in conjunction with any Layer 3 VLAN interfaces created for routing functionality.

CatOS> (enable) show interface

sl0 flags=51<UP,POINTOPOINT,RUNNING>

slip 0.0.0.0 dest 0.0.0.0

sc0 flags=63<UP,BROADCAST,RUNNING>

vlan 1 inet 10.1.1.54 netmask 255.255.255.0 broadcast 10.1.1.255

In the Cisco IOS Software, the concept of sc0/sc1 interface does not exist; network-based switch management is now accomplished with the use of Switch Virtual Interfaces (SVI, which is discussed further in the following section.) For every Layer 2 VLAN that is created, there can also be a corresponding SVI. Each SVI can have one or more IP addresses which are used for accessing the device on the particular VLAN via an SNMP or telnet client. The following command displays the VLAN SVIs and the associated IP addressing for managing the system.

IOS#show ip interface brief

Interface IP-Address OK? Method Status Protocol

Vlan1 192.168.1.1 YES manual up up

Vlan10 10.1.1.1 YES manual up down

Switch Configuration-Making Changes

Configuration changes in the Cat OS software are written to NVRAM immediately after a change is made-no intervention by the user is required. All configurations in Cat OS are done via a "set" command sequence, executed from the enabled-mode prompt. The clear command from the same prompt will erase a particular command.

In contrast, Cisco IOS Software does not save configuration changes to NVRAM unless the copy run start (or write memory) command is executed. If the configuration is not explicitly saved, any changes to the configuration will be lost should the system be reloaded. All command line configuration in Cisco IOS (whether on the Supervisor or the MSFC) is done from the configuration mode, commonly known as "config-t". Commands can be removed with the no form of the original command.

Port Behavior

The following section details the differences in port behavior between Cat OS and Cisco IOS software.

Hybrid Behavior: CatOS with Cisco IOS Software on the MSFC

The hybrid model offers a very tight integration of the Layer 2/4 CatOS features with the Layer 3 Cisco IOS on the MSFC feature set. Layer 2 ports (such as access and trunk ports) and VLANs are configured with the CatOS command set and Layer 3 SVIs are configured with the MSFC Cisco IOS command set. Ports are configured in Layer 2 VLANs with CatOS (set vlan x <slot/port>), thus corresponding Layer 3 SVIs must be created to enable inter-VLAN routing for the particular VLANs. You create SVIs using the interface vlan command. In the hybrid model, the MSFC operates on these logical interfaces (interface vlan 10) rather than on physical interfaces (interface gig 1/1). Figure 3 illustrates these concepts and the associated commands to use Layer 2 and/or Layer 3 functionality.

Figure 3. Port Concepts in the Hybrid Model

Cisco IOS Software

The port concepts in the Cisco IOS Software model are similar to the hybrid software model. In the Cisco IOS model, all system configurations are done from a single command line interface; there is no separation between the Layer 2 and Layer 3 configuration tasks. The Layer 2 port concepts, such as access and trunk ports and Layer 3 VLAN interfaces (SVIs), still apply, although with different syntax. Additionally, Cisco IOS Software offers the concept of a Layer 3 routed interface. Table 6 provides an overview of the different Cisco IOS port and interface types. More detailed descriptions follow.

Table 5. Cisco IOS Port Concepts

Interface Type	Purpose	Sample Configuration
Routed Interface	Traditional IOS routing example: each port with unique network	interface gigabitethernet 1/1 ip address 10.10.10.1 255.255.255.0 ipx network 1
Routed SVI	Single routed interface for all of the switch ports assigned to a VLAN	interface vlan 10 ip address 10.10.11.1 255.255.255.0 ipx network 2
Layer 2 VLAN	Single Layer 2 broadcast domain	vlan 10
Access Switch Port Interface	To group Layer 2 ports into a single VLAN	interface gigabitethernet 1/1 switchport switchport mode access switchport access vlan 10
Trunk Switch Port Interface	To configure Layer 2 port belonging to different VLANs	Interface Gigabit Ethernet 1/1 Switchport switchport trunk encap dot1q switchport mode dynamic desirable

Note: Although the terms interface and port are used interchangeably in this document, the Cisco IOS command line refers to ports as interfaces, while the CatOS command line refers to them strictly as ports.

Figure 4 illustrates the different Cisco IOS interface types and the commands to use the Layer 2 or Layer 3 functionality.

Figure 4. Port Concepts in the Cisco IOS Model

Cisco IOS numbers for interfaces start from 1, not 0, for a module; that is, the first interface on the line card in slot 2 is 2/1. This is the same port numbering convention that is used with CatOS.

More detailed descriptions of the three primary port types found in Cisco IOS Software are included below.

Routed Interfaces

Cisco IOS Software provides two means for creating Layer 3 interfaces: either at the physical port level (routed interfaces, described here) or at the virtual port level (SVIs, described in the following section). With Cisco IOS, each physical port is a routed interface (just like any Cisco router) by default. Every Ethernet port on the switch (Fast Ethernet, Gigabit Ethernet, or 10 Gigabit Ethernet) is shown as interface <interfacetype> <slot/port> and is shutdown by default. This operation differs from CatOS, which has all ports enabled, Layer 2 aware, and in VLAN 1 by default and does not support routed interfaces. The routed interface in Cisco IOS must be configured on a unique IP subnet or IPX network. No Layer 2 protocols such as the Spanning Tree Protocol (STP) and DTP are enabled on these interfaces.

For traditional LAN-based Ethernet ports, the routed interface does not support subinterface creation for separating dot1q encapsulations. Similar functionality to IEEE 802.1q subinterfaces is provided with trunk ports, described in the following sections.

Layer 2 VLAN

To place several interfaces in the same IP or IPX subnet, the port needs to be converted from a routed interface to a layer 2 port so that the port can be part of the Layer 2 domain or VLAN. The first step in this conversion of the routed interface is to create the Layer 2 VLAN entity.

The VLAN ID configuration creates an instance of a Layer 2 broadcast domain or VLAN. The configuration is done from global configuration mode via a vlan <vlan #> command. VLAN IDs from 1 through 4094 are supported, where VLAN IDs 1002 to 1005 are VTP default VLANs in both CatOS and Cisco IOS and are not user configurable.

The following example demonstrates the creation of vlan 8 in CatOS and Cisco IOS:

CatOS	Cisco IOS Software
set vlan 8	IOS#configure terminal IOS(config)#vlan 8 IOS(config-vlan)#exit

Because CatOS and Cisco IOS Software support the creation of 4094 Layer 2 VLANs, a MAC-address reduction feature must be enabled so that the system can allocate a limited number of system MAC addresses more efficiently. The following commands enable this feature:

CatOS	Cisco IOS Software
set spantree macreduction enable	IOS(config)# spanning-tree extend system-id

Routed SVI

When multiple ports on the same device belong to a single subnet, a VLAN is created to group these ports at Layer 2 (see Layer 2 VLAN, above). Generally, these ports need to send traffic to other subnets or VLANs. This requirement is accomplished by creating an SVI to provide the inter-VLAN routing functionality. Just as in the hybrid software model, SVIs in Cisco IOS are identified as interface VLAN 1, interface VLAN 2, etc. These interfaces are associated with Layer 3 information such as an IP subnet or IPX network number. If a particular Layer 2 VLAN does not have an associated SVI created, then traffic will be bridged in that VLAN but is not routable to or from that VLAN. As switch ports are added and removed from various VLANs, they automatically participate in the Layer 3 environment created by the appropriate SVI. For managing a device in Cisco IOS Software, the SVI requires an IP address for network reachability.

Access Switchport

An access switchport is a Layer 2 port that belongs to only one VLAN. For configuration, the switchport command is used to convert an interface from the default routed interface to a Layer 2 interface. In converting the port from a Layer 3 port to a Layer 2 port, Layer 2 features, such as DTP and STP, are enabled. This single switchport command must be enabled before any other switch port-related configuration is allowed. Like port operation in CatOS, Cisco IOS switchports automatically default to VLAN 1. To statically create an access port (one that will not attempt to negotiate a trunk), enter the switchport mode access command from the interface configuration. Then use the switchport access vlan <vlan-id> command to assign the access port to a particular VLAN. The following example defines port 5/1 as an access port in VLAN2:

IOS# configure terminal

IOS(Config)# interface fastethernet5/1

IOS(Config-if)# switchport

IOS(Config-if)# switchport mode access

IOS(Config-if)# switchport access vlan 2

IOS(Config-if)# no shut

IOS(Config-if)# end

Trunk Switchport

Trunk switchports in Cisco IOS Software are Layer 2 ports that carry multiple VLANs using ISL or IEEE 802.1q encapsulations. They are fully compatible with any other device supporting the ISL or IEEE 802.1q protocols.

After converting a routed interface to a Layer 2 switchport, the switchport will default to switchport mode dynamic desirable. The port is capable of forming a trunk with a neighboring Layer 2 device by using DTP for negotiating a trunk. If the neighboring interface supports trunking and is configured to allow trunking, the link becomes a Layer 2 trunk when you enter the switchport command (due to the dynamic/desirable default). By default, trunks negotiate encapsulation. If the neighboring interface supports both ISL and IEEE 802.1q encapsulation and both interfaces are set to negotiate the encapsulation type, the trunk will use ISL encapsulation. This is the same operation as in CatOS. The following example shows how to configure a trunk for IEEE 802.1q encapsulation:

IOS# configure terminal

IOS(Config)# interface fastethernet 5/1

IOS(Config-if)# switchport

IOS(Config-if)# switchport trunk encapsulation dot1q

IOS(Config-if)# end

Note: The recommended configuration for a dynamic trunk port would be desirable/auto between neighboring devices.

The switchport trunk native vlan <vlan-id> command sets the native VLAN for an IEEE 802.1q trunk port. The allowed parameter can be used to control the VLANs that are forwarded out that interface. In addition, the pruning parameter can be used to control VTP pruning on the link. VLAN1 cannot be pruned, either in CatOS or Cisco IOS Software. However, both the Cisco IOS Software and CatOS allow VLAN1 to be disabled from carrying traffic on trunks.

If a no switchport command is offered, all the commands related to that switchport will no longer show in configuration and the interface type will revert to a routed interface. However, if the switchport is re-enabled, then all the previous switchport-related commands will still be reinstated.****

**** This applies to a system that has not been rebooted since doing the "no switchport" command.

Cisco IOS Interface Configuration-Range Command

All interface types-whether routed interfaces, SVIs, or switchports-can be configured in groups. This means you can apply configuration parameters to a group of ports at once. The Cisco IOS range command allows you to configure multiple interfaces simultaneously by specifying interface range and then the range of ports. The ports in the range can be discontinuous across the same or different line cards. The following is a sample range configuration:

IOS(config)#int range fa3/1 - 48,gi1/1 - 2

IOS(config-if)#switchport

IOS(config-if)#switchport mode access

IOS(config-if)#switchport access vlan 2

IOS(config-if)#spanning-tree portfast

IOS(config-if)#no shut

Note: For IOS images before 12.2(18)SXE, the space before the dash is required, up to five comma-separated ranges are supported, and spaces are not required before or after the comma.

The range command works for Fast Ethernet, Gigabit Ethernet, and 10 Gigabit Ethernet interfaces as seen above. It also works with VLAN interfaces if the SVIs are created:

IOS(config)#int range vlan2 - 4

IOS(config-if)# description Floor 1 access VLANs

Interface Range Macros can be used to identify frequently grouped ports. A specific range of ports is defined in a macro and given a name. Once created, the macro name can be used to refer to the port grouping rather than explicitly typing in each port. This is useful when configuration changes frequently apply to the same group of ports (i.e., all 10/100 server ports). This feature is not available in CatOS. The following example defines an interface-range macro named "servers" that corresponds to ports 3/1 through 3/8.

IOS# configure terminal

IOS(config)#define interface-range servers fastethernet 3/1-8

IOS(config)#int range macro servers

IOS(config-if-range)#

To display the macro:

IOS# show running-config | include define

define interface-range servers fastethernet 3/1 - 8

Monitoring Interfaces in CatOS and Cisco IOS

The following commands are commonly used for monitoring interfaces:

CatOS> (enable) show port

Port Name Status Vlan Duplex Speed Type

----- -------------------- ---------- ---------- ------ ----- ------------

1/1 connected 1 full 1000 1000BaseSX

1/2 notconnect 1 full 1000 No Connector

11/1 notconnect 1 auto auto 10/100/1000

11/2 notconnect 1 auto auto 10/100/1000

11/3 notconnect 1 auto auto 10/100/1000

11/4 notconnect 1 auto auto 10/100/1000

11/5 notconnect 1 auto auto 10/100/1000

11/6 notconnect 1 auto auto 10/100/1000

11/7 notconnect 1 auto auto 10/100/1000

11/8 notconnect 1 auto auto 10/100/1000

IOS#show interface status

Port Name Status Vlan Duplex Speed Type

Gi1/1 notconnect routed full 1000 No GBIC

Gi1/2 notconnect routed full 1000 No GBIC

Gi4/1 connected 1 full 1000 1000BaseSX

Gi4/2 disabled routed full 1000 1000BaseSX

Gi4/3 disabled routed full 1000 No GBIC

Gi4/4 disabled routed full 1000 1000BaseSX

Gi4/5 disabled routed full 1000 No GBIC

Gi4/6 disabled routed full 1000 No GBIC

Gi4/7 disabled routed full 1000 1000BaseSX

Gi4/8 disabled routed full 1000 1000BaseSX

FEATURE COMPARISON

The following sections describe some general feature differences between CatOS and Cisco IOS Software. This is not an exhaustive or detailed list of features and their operation, but simply a comparison between the implementation and CLI syntax of some commonly used features on the Cisco Catalyst 6500. For a more detailed feature description of all CatOS and Cisco IOS features, refer to the user documentation at: http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/index.htm

VLAN Trunking Protocol (VTP)

VTP is used to manage VLAN information among switches in a Layer 2 domain. VTP administration is handled between switches configured as VTP Servers and VTP clients to learn a common VLAN topology throughout the network. A device can alternatively be configured as a VTP transparent device, which does not participate in the VTP protocol but can forward VTP advertisements. The only difference in VTP functionality between CatOS and Cisco IOS Software is that CatOS allows VTP to be disabled completely (i.e., the device does not forward VTP advertisements in the "off" mode).

For Cisco IOS Software, VTP/VLAN configurations are executed in global configuration mode for VTP Transparent, VTP Client, and VTP Server systems.***** This example compares how to define the VTP domain, mode, and VLANs and then apply them to ports:

CatOS	Cisco IOS Software
set vtp domain ENG-CAMPUS set vtp mode server set vlan 8 name engineering set vlan 8 5/1 - 48	IOS#configure terminal IOS(config)#vtp mode server IOS(config)#vtp domain ENG_CAMPUS IOS(config)#vlan 8 IOS(config-vlan)#name engineering IOS(config)#interface range fastethernet 5/1-48 IOS(config-if-range)#switchport IOS(config-if-range)#switchport mode access IOS(config-if-range)#switchport access vlan 8

***** VLAN or VTP configuration does not have to be completed in VLAN database submode.

VTP Operation in Cisco IOS Software

Configuration changes in CatOS are written to NVRAM immediately after a change is made. In contrast, the Cisco IOS Software does not save configuration changes to NVRAM unless you issue the copy run start command. VTP Client and Server systems require that VTP updates from other VTP servers be immediately saved in NVRAM without user intervention. Thus, the VTP update requirements are met by the default CatOS operation; while the Cisco IOS update model requires an alternative update operation.

For this alteration, a VLAN database was introduced into Cisco IOS for the Catalyst 6500 as a method for immediately saving VTP updates for VTP Clients and Servers. This VLAN database is in the form of a separate file in NVRAM, called the vlan.dat file. Viewed with sh vtp status, the vlan.dat files stores VTP/VLAN information for VTP Client or VTP Server systems. The entire VTP/VLAN configuration is not backed up to the Startup Config file in NVRAM when a copy run start command is issued on these systems.

This does not apply to systems running as VTP transparent. VTP transparent systems back up the entire VTP/VLAN configuration to the Startup Config file in NVRAM when you issue a copy run start command.

VTPv3 for CatOS

CatOS supports a new version of VTP-VTP Version 3 (VTPv3). VTPv3 supports the advertisement of the extended range of VLANs (4094). Configuration changes for the entire 4K VLAN range can be made centrally on one switch and automatically communicated to all other switches in the network.

Additionally, VTPv3 removes the risk of losing or overwriting the domain configuration when introducing a misconfigured or unauthorized server. It does this by introducing the concept of both primary and secondary servers, and by allowing the partitioning of domains. Users must statically define what server will become a primary server. Below is a description of the VTP devices available for a domain:

• A VTPv3 Primary Server can create, modify, and delete VLANs and specify other configuration parameters for the domain. The primary servers advertise their VLAN configuration to the switches in the same VTP domain and synchronize their VLAN configuration with other switches based on advertisements received over trunk links (similar to existing VTP versions).

• A VTPv3 secondary server is a hybrid between the original client and server; it is able to store the configuration of the domain but cannot modify it.

• A VTPv3 client only receives the configuration from the network and cannot save or modify it (unchanged from existing VTP versions).

Figure 5.

Spanning Tree Protocol (STP)******

Spanning-Tree Protocol (STP) prevents loops from being formed when switches or bridges are interconnected via multiple paths. Spanning-Tree Protocol implements the 802.1D IEEE algorithm by exchanging BPDU messages with other switches to detect loops, and then removes the loop by shutting down selected bridge interfaces. This algorithm guarantees that there is one and only one active path between two network devices.

Common Spanning-Tree (CST) assumes one spanning-tree instance for the entire bridged network, regardless of the number of VLANs. This implementation reduces CPU load since only one Spanning Tree instance is maintained for the entire network. This implementation can be used when only one Layer 2 topology is needed in the network.

Multiple Instance STP (MISTP) (802.1s) is an IEEE standard which allows several VLANs to be mapped to a reduced number of spanning-tree instances. This is possible since most networks do not need more than a few logical topologies. Each instance handles multiple VLANs that have the same Layer 2 topology.

Per-VLAN Spanning Tree (PVST) maintains a spanning tree instance for each VLAN configured in the network. It uses ISL Trunking and allows a VLAN trunk to be forwarding for some VLANs while blocking for other VLANs. Since PVST treats each VLAN as a separate network, it has the ability to load balance traffic (at layer-2) by forwarding some VLANs on one trunk and other VLANs on another trunk without causing a Spanning Tree loop. PVST+ (additional advantages are described later) provides the same functionality with 802.1Q trunking technology and is only supported on Cisco Switches.

Rapid Spanning Tree Protocol (RSTP) is an evolution of the Spanning Tree Protocol (802.1D standard) and provides for faster spanning tree convergence after a topology change. The standard also includes features equivalent to Cisco PortFast, UplinkFast and BackboneFast for faster network reconvergence.

This section presents the configuration differences between CatOS and Cisco IOS for basic STP configuration, PVST+ (802.1d), IEEE 802.1s (MST), IEEE 802.1w (RSTP), and Rapid PVST+.

Basic STP Configuration

CatOS	Cisco IOS Software
set spantree root 10 dia 5 hello 2 set spantree root sec 11 dia 5 hello 2 set spantree priority 4096 10,11	IOS(config)# spanning-tree vlan 10 root primary dia 5 hello 2 IOS(config)# spanning-tree vlan 11 root sec dia 5 hello 2 IOS(config)# spanning-tree vlan 10 pri 4096 IOS(config)# spanning-tree vlan 11 pri 4096

PVST+ Enhancements

PVST+ enhances basic spanning tree algorithms by allowing for faster convergence times via the implementation and integration of Cisco proprietary protocols, including UplinkFast, BackboneFast, and PortFast, into the PVST+ protocol itself.

Spanning Tree UplinkFast allows for faster convergence in a Layer 2 network after a direct root link failure. If a link from one bridge to the root bridge goes down, then the bridge will move one blocking port to forwarding immediately rather than waiting for the normal spanning tree timers to expire. This brings the convergence time from 50 seconds to three to five seconds or even subsecond.

In the case of an indirect failure in a Layer 2 network, Spanning Tree BackboneFast reduces the convergence time by the "maximum age" timer value (which defaults to 20 seconds).

Finally, Spanning Tree PortFast causes an access port to enter the forwarding state immediately, bypassing the listening and learning states. The feature is used on switch ports connected to a single workstation, IP Phone, server, etc., and allows these devices to connect to the network immediately, rather than waiting for spanning tree to converge. Because access ports do not typically transmit or receive bridge protocol data units (BPDUs) from attached devices, PortFast mode is supported on both nontrunking access ports and trunk ports in both CatOS and Cisco IOS.

Below are the configuration tasks associated with the aforementioned enhancements to PVST+.

CatOS	Cisco IOS Software
set spantree uplinkfast enable set spantree backbonefast enable set spantree portfast 3/1 enable	IOS(config)# spanning-tree uplinkfast IOS(config)# spanning-tree backbonefast IOS(config)# int range fa3/1 IOS(config-if)# switchport IOS(config-if)# spanning-tree portfast

Rapid PVST+

Rapid PVST+ is based on the IEEE 802.1w standard and uses the existing configuration for PVST+ to provide for faster STP convergence times. With Rapid PVST+, entries are flushed immediately on a per-port basis on topology changes. UplinkFast and BackboneFast configurations are ignored in this mode, as both features are included in the Rapid Spanning Tree Protocol (IEEE 802.1w).

CatOS	Cisco IOS Software
Set spantree mode rapid-pvst+	IOS(config)#spanning-tree mode rapid-pvst

IEEE 802.1S (MST)

Multiple Spanning Tree (MST) is based on the IEEE 802.1s standard, and extends the IEEE 802.1w rapid spanning tree (RST) algorithm to multiple spanning trees. This provides both rapid convergence and load balancing in a VLAN environment while converging even faster than PVST+.

MST allows the formation of spanning trees over trunks, to provide multiple forwarding paths for data traffic. This improves fault tolerance, as a single failure does not directly affect other instances of spanning tree. Additionally, by grouping multiple VLANs into single instances of spanning trees, the overall CPU of the system decreases significantly.

One major difference between the configuration of MST on the operating systems is the MST configuration submode in Cisco IOS. This mode is used to both enter and to display the MST configuration:

CatOS	Cisco IOS Software
Set spantree mst config name MST revision 1 Set spantree mst instance vlan vlan Set spantree mst config commit Set spantree mode mst	IOS(config)#spanning-tree mode mst IOS(config)#spanning-tree mst configuration IOS(config-mst)#name MST revision 1 instance 1 vlan 3

IEEE 802.1W (Rapid PVST+)

RSTP reduces the reconvergence time of a network by selecting a single switch to act as the root of a spanning tree. It is based on the IEEE standard 802.1w rather than IEEE 802.1D. Rapid PVST+ is configured in the same manner as PVST+, but with the additional syntax:

CatOS	Cisco IOS Software
Set spantree mode rapid-pvst+ Set spantree link-type mod/port point-to-point	IOS(config)#spanning-tree mode rapid-pvst

Note: The command syntax in CatOS uses rapid-pvst+ and Cisco IOS uses rapid-pvst.

Root and BPDU Guard Configuration

Port-based BPDU Guard monitors BPDUs on ports. If BPDUs are detected on access ports, the configured interfaces are shut down. Reception of a BPDU by a PortFast-configured interface signals an invalid configuration, such as the connection of an unauthorized device. The BPDU guard feature provides a secure response to invalid configurations since the interface is re-enabled manually by the administrator or automatically via the error-disable feature.

The spanning-tree root guard feature forces an interface to become a designated port, and if any device accessible through the interface tries to become the root bridge, the root guard feature puts the interface into the root-inconsistent (blocked) state.

Cisco IOS Software supports BPDU Guard and Root Guard feature on switchports only. The configuration dialog below shows highlights configuration differences.

CatOS	Cisco IOS Software
set spantree bpdu-guard 3/1 enable set spanning-tree guard root 1/1 show spantree summary	IOS(config)# int range fast3/1 IOS(config-if)# switchport IOS(config-if)# spanning-tree portfast bpduguard IOS(config-if)# spanning-tree guard root IOS# show spanning-tree summary

EtherChannel

EtherChannels in CatOS and Cisco IOS Software bundle individual Ethernet links into a single logical link to provide bandwidth aggregation and link resilience in a network. Catalyst 6500 Ethernet interfaces support up to eight interfaces per EtherChannel with all interfaces at the same speed: 10,100, 1000 or 10,000 Mbps. EtherChannel groups can include ports on any combination of line cards.

EtherChannel Operation

Configuring EtherChannels in the Cisco IOS Software is a two-step process: first the ports are assigned to a channel-group and then the virtual interface port-channels are configured. The virtual interface port-channel behaves like a physical interface. In both CatOS and Cisco IOS, all configurations on the port channel interfaces are propagated to the physical interfaces of the port channel. For example, shutting the port channel interface will shut all physical ports on that port channel. To change parameters of all ports in an EtherChannel, the configuration should be applied to the port channel interface. Although the Cisco IOS Software allows configuration on physical interfaces, the configuration will not be propagated to the port channel bundle. If the interfaces within the bundle are not identical, the channel will not form.

CatOS	Cisco IOS Software
set port channel 3/1-8 1 desirable	interface range gigabit 3/1 - 8 switchport channel-group 1 mode desirable no shut interface port-channel 1 switchport trunk encapsulation dot1q no shut

CatOS supports a maximum of 128 EtherChannel groups and the Cisco IOS Software supports a maximum of 64 EtherChannel groups (128 Etherchannel groups are supported in Cisco IOS 12.2(18)SXE and later).

EtherChannel Negotiation

Cisco IOS and CatOS EtherChannels support both PAgP and LACP, which allows for automatic creation of port channels with other devices. PAgP is a Cisco proprietary protocol for channel negotiation and LACP is a standard for channel negotiation (IEEE 802.3ad). The negotiation modes of both protocols are nearly identical. Note that the negotiation keywords are the same for both CatOS and Cisco IOS Software. For more detail on PAgP and LACP configuration, refer to the following configuration guides:

• http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/12_1e/swconfig/channel.htm

• http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_7_3/confg_gd/channel.htm

PAgP Configuration Example:

CatOS	Cisco IOS Software
set channelprotocol pagp set port channel 3/1-8 1 desirable	interface range gigabit 3/1-8 switchport channel-protocol pagp channel-group 1 mode desirable interface port-channel 1 switchport trunk encapsulation dot1q no shut

LACP Configuration Example:

CatOS	Cisco IOS Software
set channelprotocol lacp set port channel 3/1-8 1 desirable	interface range gigabit 3/1 - 8 switchport channel-protocol lacp channel-group 1 mode active interface port-channel 1 switchport trunk encapsulation dot1q no shut

In CatOS, the channel protocol is configured on a per-module basis. That is, all channel ports on a module must use the same negotiation protocol. In the Cisco IOS Software, the channel protocol can be configured on a per-port basis.

EtherChannel Load Sharing

Several load-balancing algorithms are available for distributing traffic across the ports in an EtherChannel. This is regardless of the whether an EtherChannel contains Layer 2 or Layer 3 ports and interfaces. The options are the same in both CatOS and Cisco IOS Software and are shown below.

CatOS	Cisco IOS Software
set port channel all distribution ? ip Channel distribution ip mac Channel distribution mac session Channel distribution session set port channel all distribution ip ? source Channel distribution source destination Channel distribution dest both Channel distribution both	port-channel load-balance ? dst-ip Dst IP Addr dst-mac Dst Mac Addr dst-port Dst TCP/UDP Port src-dst-ip Src XOR Dst IP Addr src-dst-mac Src XOR Dst Mac Addr src-dst-port Src-Dst TCP/UDP Port src-ip Src IP Addr src-mac Src Mac Addr src-port Src TCP/UDP Port

EtherChannel Types

The Cisco IOS Software can do both Layer 2 and Layer 3 EtherChannels. In the context of the Cisco IOS Software, a Layer 2 EtherChannel includes ports that are configured as switch ports; a Layer 3 EtherChannel can include only switchport in combination with SVIs or it could include only routed interfaces. CatOS has only one type of Layer 3 EtherChannel because it does not support true routed ports, only SVIs.

Layer 2 EtherChannels

All interfaces are grouped together in a common channel-group and the subsequent interface port-channel is configured as a switchport. The channel protocol (PAgP or LACP) automatically creates the Port-Channel 1 interface when the channel-group command is enabled on the physical interface.

CatOS	Cisco IOS Software
set port channel 3/1 - 8 1 desirable set trunk 3/1 - 8 dot1q	interface range fa3/1 - 8 no shut channel-group 1 mode desirable interface port-channel 1 switchport switchport trunk encap dot1q no shut

Note: Defaults to PAgP for negotiation

Layer 3 EtherChannels with SVIs

Layer 3 EtherChannels with SVIs are formed like the Layer 2 EtherChannels with the addition of a Layer 3 SVI for routing functionality. This is the method for configuring Layer 3 EtherChannels with Layer 2 VLANs providing the transport and SVIs providing the VLAN termination and routing.

CatOS	Cisco IOS Software
Catalyst OS config: set port channel 3/1-8 2 desirable set spantree portfast 3/1-8 set vlan 10 3/1-8 MSFC config: int vlan 10 ip address 10.10.10.1 255.255.255.0	interface range fa3/1 - 8 no shut channel-group 1 mode desirable interface port-channel 1 switchport switchport mode access no shut int vlan 10 ip address 10.10.10.1 255.255.255.0

Layer 3 EtherChannels

True Layer 3 EtherChannels are only specific to an IP subnet, not to a Layer 2 VLAN. As with the previously described routed interface, this is a concept only available in Cisco IOS Software. The following is an example of the command line syntax for configuring a Layer 3 EtherChannel.

CatOS	Cisco IOS Software
No Catalyst OS equivalent	int range fa3/1 - 8 channel-group 1 mode desirable interface port-channel 1 ip address 10.10.10.1 255.255.255.0

The following are some helpful show commands for EtherChannels on a Cisco IOS system:

• show etherchannel summary to view all EtherChannels states and ports on a Cisco IOS system:

cat6k#show etherchannel summary

Flags: D - down P - in port-channel

I - stand-alone s - suspended

H - Hot-standby (LACP only)

R - Layer3 S - Layer2

U - in use f - failed to allocate aggregator

u - unsuitable for bundling

Number of channel-groups in use: 2

Number of aggregators: 2

Group Port-channel Protocol Ports

------+--------+--------+---------------------

1 Po1(SD) LACP Fa3/13(P) Fa3/14(P) Fa3/15(P) Fa3/16(P)

273 Po273(SD) -

cat6k#

• show interfaces etherchannel displays all the interfaces that have been a channel-group associated with it, regardless of their channel status. If only one interface status is needed, show interfaces <mod>/<port> etherchannel states the channel status of a specific interface without having to scroll through multiple screens of output.

IOS1#sh int gi8/15 etherchannel

Port state = Up Mstr In-Bndl

Channel group = 2 Mode = Desirable-Sl Gcchange = 0

Port-channel = Po2 GC = 0x00020001 Pseudo port-channel = Po2

Port index = 1 Load = 0x55

Flags: S - Device is sending Slow hello. C - Device is in Consistent state.

A - Device is in Auto mode. P - Device learns on physical port.

Timers: H - Hello timer is running. Q - Quit timer is running.

S - Switching timer is running. I - Interface timer is running.

Local information:

Hello Partner PagP Learning Group

Port Flags State Timers Interval Count Priority Method Ifindex

Gi8/15 SC U6/S7 30s 1 128 Any 33

Partner's information:
          Partner              Partner         Partner        Partner  Group
Port      Name                 Device ID       Port      Age  Flags    Cap.
Gi8/15    cat6k-3-ios          0050.808a.a200  Gi4/3     11s  SC       20001

Age of the port in the current state: 00h:00m:42s

Identity Based Networking Services (IBNS)-IEEE 802.1x Authentication

IEEE 802.1x is a client-server-based access control and authentication protocol that restricts unauthorized devices from connecting to a LAN via publicly accessible ports. 802.1x authenticates users connected to switch ports prior to making services available offered by the switch or LAN. Until the device is authenticated, 802.1x only permits Extensible Authentication Protocol over LAN (EAPOL) traffic through the port to which the device is connected. Following successful authentication, all traffic can pass through the port.

Both CatOS and Cisco IOS support IEEE 802.1x port-based authentication, 802.1x multiple host mode as defined in the specification, and IEEE 802.1x VLAN Assignment using a RADIUS Server. Additionally, CatOS only supports the following 802.1x extensions:

• 802.1x Authentication on Ports Configured for Auxiliary VLAN Traffic

• 802.1x Authentication for Guest VLANs-this enables non-802.1x capable hosts to access networks that use 802.1x authentication.

• 802.1x Authentication with Port Security-802.1x is compatible with the port security feature to define the number of MAC addresses to authenticate on a specific port. Users connected through all other MAC addresses are denied access.

• 802.1x Multi-Authentication Mode-administrators can specify multiple authentications to ensure that more than one host can gain access to an 802.1x port; every host is authenticated separately.

Example: Set port dot1x mod/port multiple-authentication enable

• 802.1x Unidirectional Controlled Port-administrators have the capability to perform Wake-on LAN functionality on 802.1x-enabled ports for scheduled system backups or software upgrades of hosts. This 802.1x enhancement allows traffic to only flow outbound on an 802.1x port.

• 802.1x with ACL Assignment-This extension allows an ACL policy to be dynamically applied to a port based on the user and his successful authentication to the RADIUS server.

• 802.1x User Distribution-This allows the even distribution of authenticated users within the same `group name' to be assigned into different VLANs for load-balancing.

• 802.1x RADIUS Accounting and Tracking-Allows the transfer of accounting information from the switch to the RADIUS server. Also, from the RADIUS Server, the administrator can set knobs to control user access, such as the time of day users have access to the network, and the maximum number of users authenticated at any time within a given user group.

• 802.1x Authenticated Identity-to-Port Description Mapping-By enabling this feature, the administrator can assign a port description to the port that a user is authenticated to. The description is seen once `sh port' is executed. This is configured on the RADIUS server.

• DNS Resolution for RADIUS-Allows the administrator to configure a server DNS name in addition to or instead of an IP address. In the event of a RADIUS server moving subnets, there is no reconfiguration required for the switches-they'll re-resolve immediately.

A RADIUS server must be specified prior to enabling 802.1x on the switch. 802.1x is then enabled globally, and finally enabled from the console for individual ports, as seen below. Also described below is the syntax for multiple host configurations:

CatOS	Cisco IOS Software
Globally: Set dot1x system-auth-control enable Per Port: Set port dot1x mod/port port-control auto Multiple Host: Set port dot1x mod/port multiple-host enable	Globally: Router(config)# dot1x system-auth-control Router(config)# interface type1 <slot/port> Interface Commands: Router(config-if)# dot1x port-control auto Router(config-if)# dot1x host-mode multi-host

For more information relating to the configuration of IEEE 802.1x on the Catalyst 6500, see: http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122sx/swcg/dot1x.htm

Cisco Security Toolkit Features

Supported in CatOS IOS since 12.2(18)SXE, the Cisco Security toolkit features assist in mitigating Denial-of-Service (DoS) and Man-in-the-Middle (MiM) attacks. The Security Toolkit consists of three features: DHCP Snooping, and Dynamic ARP Inspection.

DHCP Snooping provides security against certain DoS attacks, namely, DHCP rogue server attacks. In such attacks, rogue servers are able to insert themselves into the network and respond to DHCP discovers and requests for IP addresses. DHCP Snooping prevents this kind of attack by setting ports as trusted or untrusted. All untrusted ports can only send discovers and requests for DHCP. On the other hand, trusted ports allow all DHCP traffic to traverse the port, including requests and offers for IP addresses.

For ports attached to all hosts, or all ports connected to unknown devices, the port should be set to DHCP untrusted. In this case, should a server attach itself to an untrusted port, it cannot issue an IP address to requesting hosts.

DHCP Snooping also maintains a DHCP Snooping Table which contains the MAC address, IP Address, lease time of the client and the VLAN of the untrusted host on the port. This table is used for other features, including Dynamic ARP Inspection, to ensure users attaching to ports are not attempting to attack the network. It does this by validating the IP address and MAC address binding of all hosts. The example below enables dhcp-snooping on VLAN 20, and all ports on that VLAN are by default, untrusted:

CatOS

Console>(enable)set security acl ip snoopname permit dhcp-snooping

Console>(enable)set security acl ip snoopname permit ip any any

Console>(enable)commit security acl snoopname

Console>(enable)set security acl map snoopname 20

Cisco IOS Software

Router(config)# ip dhcp snooping

Router(config)# ip dhcp snooping vlan 20

Dynamic ARP Inspection (DAI) validates ARP packets in a network. It allows a network administrator to intercept, log, and discard ARP packets with invalid MAC address to IP bindings (set forth in the DHCP Snooping binding tables). It prevents certain MIM attacks from occurring. The example below enables DAI on all ARP traffic from port 4/2 (because 4/2 is set to untrusted) on VLAN 20

CatOS

Console>(enable)set security acl arp-inspection dynamic enable 20

Console>(enable)set port arp-inspection 4/2 trust disable

Cisco IOS Software

Router(config)# ip arp inspection vlan 20

Router(config)# interface FastEthernet 4/2

Router(config-if)# no ip arp inspection trust

A CatOS feature only (and supported only on the Sup720 and Sup32), IP Source Guard prevents IP spoofing by allowing only the IP addresses that are logged in the DHCP Snooping binding table on a particular port. Initially, all traffic on the port is blocked except for DHCP packets that are captured by DHCP snooping. When the client receives a DHCP IP address, a Port-based Access Control List is installed on the port which permits traffic from the IP address. Any IP address with a source IP address other than that in the PACL permit list will be filtered out. This prevents the possibility of users attempting to spoof their neighbor's IP address.

Configuring IP Source Guard requires the port security-acl be placed in port-based mode, and requires DHCP Snooping be enabled. The example below enables IP Source Guard on port 4/2, and enables the security-acl "dhcpsnoop", which enables dhcp-snooping, on the VLAN 10

CatOS

Console>(enable)set port security-acl 4/2 port-based

Console>(enable)set port dhcp-snooping 4/2 source-guard enable

Console>(enable)set security-acl ip dhcpsnoop permit dhcp-snooping

Console>(enable)set security-acl ip dhcpsnoop permit any any

Console>(enable)commit security-acl dhcpsnoop

Console>(enable)set security acl map dhcpsnoop 10

Secure Copy Protocol (SCP)

Currently supported in CatOS and IOS, The Secure Copy Protocol provides a secure method for copying crypto image files. SCP relies on Secure Shell (SSH) and allows the network administrator to copy a SCP to and from the system through an encrypted channel.

Time Domain Reflectometer (TDR)

Time Domain Reflectometer (TDR) enables the troubleshooting of cable plants, easing the operational support of the switch. Built into the port interfaces of 48-port 10/100/1000 RJ-45 and the 6148A 10/100 modules, TDR enables network managers to remotely identify the location of cable breaks and faults. The TDR test sends a signal along a cable. Using intelligent DSPs built into the port interfaces, it measures the time it takes for the echo to return, and computes the distance to the break.

TDR is an online test which, when completed, displays the port's connected wire pairs and distances to their breaks (if present). Execution commands are as follows:

CatOS	Cisco IOS Software
Console>(enable)test cable-diagnostics tdr 3/1 Console>(enable)show port tdr 3/1	IOS#test cable-diagnostics tdr interface g3/1 IOS#show cable-diagnostics tdr interface g3/1

Access Control Lists (ACLs)

Catalyst 6500 Series running Hybrid OS support the following types of ACLs:

• IOS Routing ACLs (RACLs) provide access control for routed traffic between VLANs. Standard and extended IOS ACLs are configured on the input and output of router interfaces and, as such, are applied to routed packets. The use of IOS ACLs requires both a PFCx and a MSFCx on the Catalyst 6500 Series.

• VLAN ACLs (VACLs) provide access control based on Layer 3 or Layer 4 information for IP or IPX protocols. A VACL is applied to all packets (bridged and routed) on a VLAN and can be configured on any VLAN interface. VACLs are used for security packet filtering and redirecting traffic to specific physical switch ports. They are not defined by direction (input or output). VACL functionality requires a PFCx.

• QoS ACLs are used to identify ingress traffic which is should be marked or policed upon entering a port or VLAN. QoS ACL functionality requires a PFCx.

• Port-based ACLs (PACL)******* are access lists mapped to a physical port (rather than to a VLAN, which is typically comprised of multiple ports). Like VACLs, PACLs are applied to both Layer 2 and Layer 3 forwarded packets. Only ingress PACLs are supported on the Catalyst 6500.

IOS RACLs have the same implementation in Hybrid as in Cisco IOS (whether on the Catalyst 6500 or any other IOS router). QoS ACLs for both operating systems are covered in the QOS section of this white paper. This section describes the differences between the VACL implementation in CatOS and Cisco IOS Software and also covers PACL implementation in CatOS.

VLAN Access Control Lists (VACLs)

For CatOS, configuring a security ACL statement creates a VACL. This statement is used to configure all match and action parameters for the security policy.

The VACL configuration in Cisco IOS is based on the traditional IOS ACL implementation. That is, it relies on the IOS access-list command to define the traffic matching parameters. From there, all configuration (including ACL reference and action) is done from the "vlan access-map" configuration mode. Although the Cisco IOS action is a CLI concept which is not present in CatOS, it provides similar capture, log, and redirect functionality. Refer to the user documentation for specifics on these options. The following provides a general comparison between VACL configuration between CatOS and Cisco IOS.

******* PACLs are supported only on Sup 720 with PFC3a and later with CatOS version 8.3 and later.

CatOS	Cisco IOS Software
set vlan 10 set security acl ip sample permit ip any any commit security acl sample set security acl map sample 10	vlan 10 access-list 101 permit ip any any vlan access-map sample match ip address 101 action forward vlan filter sample vlan-list 10

Note: When creating a VACL in IOS, an SVI for that VLAN interface is created automatically. While this interface is required, it is not necessary for the interface to be configured or even in an "up" state for the VACL to operate properly.

In CatOS, when an ACL is created, modified, or deleted, the changes exist temporarily in an edit buffer in memory. CatOS requires that the ACL be committed for it to take effect. In contrast, Cisco IOS Software does not utilize the edit buffer concept. Once a policy has been built in IOS, it must then be mapped to a VLAN or interface for that ACL to take effect.

VACL Capture

The VACL Capture feature is a useful extension to VACLs. This feature is essentially a port-mirroring function where packets that match the specified flows are captured and transmitted out of capture ports. You can create a VACL to identify traffic that you would like to make a copy of and send to a destination port for analysis (via a network analyzer or otherwise). This does not affect the performance of the captured traffic; the original data will move through the box as it is intended. It provides a very granular tool for network troubleshooting and analysis as well as a scalable alternative to the traditional Switch Port ANalyzer (SPAN) feature.

CatOS	Cisco IOS Software
set vlan 10 set security acl ip cap_acl permit ip any any capture commit security acl cap_acl set security acl map cap_acl 10 set security acl capture-ports 1/1	vlan 10 access-list 101 permit ip any any vlan access-map cap_acl match ip address 101 action forward capture vlan filter sample vlan-list 10 int gigabitethernet 1/1 switchport capture

Port-Based Access Control Lists (PACLs)

Supported only in CatOS on the Sup720 and Sup32, PACLs are access lists mapped to physical ports. PACLs have three modes of operation configurable on a per-port basis: port-based, VLAN-based, and merge modes. In port-based mode, the PACL overrides the existing VACL and Cisco IOS ACL. In VLAN-based mode, the VACL and IOS ACLs override the PACL. In merge mode, the ingress PACL, VACL and IOS ACL are merged together (VLAN-based mode is the default mode).

To configure PACLs, the mode must be specified. The example below sets a PACL on port 2/1 in port-based mode and maps the ACL "pacl_acl" to port 2/2:

CatOS

set port security-acl 2/1 port-based

set security acl ip pacl_acl permit ip any any

commit security acl pacl_acl

set security acl map pacl_acl 2/2

Quality of Service (QoS)

Quality of Service is the use of several different features which all work to differentiate and prioritize network traffic. These features include the classification, marking, policing, congestion avoidance, and scheduling of traffic. In the Catalyst 6500 Series, QoS functionality resides on the PFC (for Layer 3 marking, policing, and some classification functions) and on line cards (for congestion avoidance, scheduling, and other classification functions). With CatOS, a Supervisor without a PFC can be used for Layer 2-only QoS classification and marking. With the PFC and the MSFC installed, Cisco IOS and hybrid OS support full Layer 2/3/4 QoS capabilities.

This section is not intended to provide a general overview of QoS functionality. Rather, it discusses configuration differences between CatOS and Cisco IOS Software for the following scenarios:

• Configuring interface QoS

• Configuring QoS policies

By default, QoS is disabled on both operating systems. The first step to implement QoS functionality on the Catalyst 6500 is to enable QoS globally:

CatOS	Cisco IOS Software
set qos enable	Router(config)# mls qos

Configuring Interface QoS

Trust State

Ports can be set to trust certain fields such as COS, IP-precedence, or DSCP in the incoming frames. The following is a sample configuration:

CatOS	Cisco IOS Software
set port qos 3/1 trust trust-cos	Router(config)# interface gigabitethernet 3/1 Router(config-if)# mls qos trust cos

Both CatOS and Cisco support the Extended Trust feature for differentiating IP Phone voice traffic and workstation data traffic.

Default Port CoS

The switch offers the capability to set a CoS value for all traffic entering a particular port. This is supported in both operating systems:

CatOS

Cisco IOS Software

set port qos 3/1 cos 3

Router(config)# interface gigabitethernet 3/1

Router(config-if)# mls qos cos 3

Port- and VLAN-Based QoS Mode

QoS policies can be applied either per- port or per-VLAN. By default, QoS functionality is port-based. In this case, all QoS policies are applied to a particular port. Policies that are applied to a VLAN will not affect traffic that is ingress on a port which is configured as port-based. If a policy is mapped to a VLAN, you must inform the interface that QoS is VLAN based for each port in the VLAN to which the VLAN policy is applicable. The following command when executed on the intended interfaces alters the default QoS from port-based to VLAN-based:

CatOS	Cisco IOS Software
set port qos 3/1 vlan-based	Router(config)#interface gigabitethernet 3/1 Router(config-if)# mls qos vlan-based

CoS-to-Queue Mapping

This section describes the mapping of CoS values to queues/thresholds in the standard receive and transmit queues. In Cisco IOS, the rcv-queue keyword is used for standard receive queue configuration, the wrr-queue keyword is used for round-robin transmit queues, and the priority-queue keyword is used for priority queues.

In the CatOS implementation, the CoS-to-queue mapping is configured per queue type (i.e. all 1p2q2t ports will have the same configuration). In Cisco IOS implementation, the CoS-to-queue mapping is configured per interface and the configuration changes are implemented on all ports that are managed by the same port ASIC. (ASIC to port layout varies by line card, but the CLI will issue a warning of the changes made.) The following example maps 802.1p value of 5 to the strict priority queue (rx and tx) and 802.1p values of 0 and 1 to the first threshold of the low priority queue.

CatOS	Cisco IOS Software
set qos map 1p1q4t rx 2 1 cos 5 set qos map 1p2q2t tx 1 1 cos 0,1 set qos map 1p2q2t tx 3 1 cos 5	interface gigabitethernet 3/1 rcv-queue cos-map 2 1 5 wrr-queue cos-map 1 1 0 1 priority-queue cos-map 1 5

Queue Sizes

The total amount of buffer per port is a fixed quantity. However, the allocation of that packet buffer per queue can be configured on most Ethernet ports. Specifically, the transmit buffer allocation can be changed on the classic Fast Ethernet, any Gigabit Ethernet, and any 10 Gigabit Ethernet line card. The receive buffer allocation is configurable on the fabric-enabled Fast Ethernet ports (6548, 6524 line cards) and on the 10 Gigabit Ethernet ports (6501, 6502 line cards).

CatOS	Cisco IOS Software
set qos txq-ratio 1p2q2t 10 90 set qos rxq-ratio 1p1q0t 10 90	interface gigabitethernet 3/1 wrr-queue queue-limit 10 90 interface fastethernet 4/1 rcv-queue queue-limit 10 90

WRR Scheduling

The Weighted Round Robin (WRR) scheduling mechanism is used to prioritize traffic as it exits an egress port. The prioritization is based on the relative weighting of each of the participating queues-so that traffic in a higher priority queue will be serviced before traffic in a low priority queue. The WRR scheduling feature is supported on the transmit queues for all Ethernet line cards. An example (for Gigabit Ethernet ports) is shown below. As with the CoS-to-queue mapping, the WRR scheduling is configured on a per-ASIC basis.

CatOS	Cisco IOS Software
set qos wrr 1p2q2t 30 70	interface gigabitethernet 3/1 wrr-queue bandwidth 30 70

Configuring QoS Policies

The configuration of QoS policies differs significantly between the Cisco IOS Software and CatOS. For CatOS, a QoS ACL statement is used to configure all match and action parameters for marking and policing. Cisco IOS QoS supports classification, marking, and policing using the Modular QoS CLI (MQC) syntax.

A Cisco IOS policy uses traffic classes (with the class-map statement) to identify interesting traffic. These traffic classes can be defined for different types of traffic flows-for example, a user could have a different class for IP traffic, IPX traffic, and MAC traffic. Each traffic class uses IOS based access control lists and/or class match statements to identify traffic. The policy-map includes the desired action for the matched traffic (mark, police, trust, etc). The policy defined by a policy-map is mapped to an interface using the service-policy command.

Examples of both are included below.

Trust with an ACL

As an alternative to setting the trust state for all traffic on a port (as described above), a QoS policy can be created to trust traffic that matches a specific QoS ACL. This functionality is available in both CatOS and the Cisco IOS Software. As such, it is a straightforward example of the configuration differences between the CatOS QoS ACL syntax and the Cisco IOS MQC syntax described above. In this example, the function of using an ACL for trusting the CoS on all traffic coming into port gigabit 3/1 is compared.

CatOS	Cisco IOS Software
set qos acl ip CatOS trust-cos any commit qos acl CatOS set qos acl map CatOS 3/1	access-list 101 permit ip any any policy-map IOS class IOS access-group 101 trust cos interface gigabitethernet 3/1 service-policy input IOS

When a CatOS ACL is created, modified, or deleted, the changes exist temporarily in an edit buffer in memory. CatOS requires that the ACL be committed for it to take effect. Cisco IOS Software does not utilize the edit buffer concept. Once a policy has been built in IOS, it must then be mapped to either a port or a VLAN for that policy to take effect. When a policy is mapped to an "up" interface, the ASIC hardware is programmed with the necessary information and that policy is in effect.

Policers

The policing function is primarily used for rate limiting traffic to a configured speed. If traffic exceeds the configured speed, then it can either be dropped or marked down to a lower priority. This is useful to ensure compliance to service level agreements or for security protection. The policer can either be an aggregate or a microflow policer. An aggregate policer will rate limit all traffic in a class or group of classes to one combined (or aggregate) rate. A microflow policer will rate limit each flow (a unique SA/DA MAC address, SA/DA IP address, TCP/UDP port numbers, and with UBRL, a unique SA or DA) in a traffic class to an individual rate. A total of 63 microflows and 1023 aggregates can be configured per chassis (independent of the operating system).

In CatOS, the policing parameters, such as rate, burst, and related actions, are defined first in a policer statement. A QoS ACL is configured which identifies both the traffic to-be-policed and references the appropriate policer. Then, the QoS ACL needs to be committed and applied to a port or VLAN, as with normal ACL configuration.

In Cisco IOS Software, the ACL is defined first. The policing parameters are defined in one of two configuration modes. This depends on the type of policer being implemented; differences are discussed in the following sections.

Aggregate Policers

There are two forms of aggregate policers that can be defined in the Catalyst Software: Shared Aggregate Policers and Per-Interface Aggregate Policers.

Shared Aggregate Policers (sometimes referred to as Named Aggregate Policers) are applied to a group of interfaces/VLANs and provide the function of policing traffic across all interfaces and/or classes cumulatively. As an example, use the shared aggregate policer when a 100-Mbps rate limit should be applied to four different interfaces combined. These policers are supported in both CatOS and Cisco IOS Software. The following table shows a configuration comparison of both implementations:

CatOS	Cisco IOS Software
set qos policer aggregate ag1 rate 1000000 burst 32 drop set qos acl ip ag_acl trust-dscp aggregate ag1 any set qos acl map ag_acl 3/5	access-list 101 permit ip any any mls qos aggregate-policer ag1 10000000 4625 conform-action transmit exceed- action drop policy-map limit-named class class-ag1 access-group 101 police aggregate ag1 interface fastethernet 3/5 service-policy input limit-named

Note: In CatOS, the rate is measured in Kbps and the burst is specified in Kb. In the Cisco IOS Software, the rate is measured in bps and the burst is specified in bytes. These differences are true for all policer types.

Per-Interface Aggregate Policers are applied to an interface and traffic class, individually. These policies can be applied to multiple interfaces, but the policer polices each interface separately. As an example, use the Per Interface Aggregate policer when a 100-Mbps rate limit should be applied individually to four different interfaces. These policers are only supported in Cisco IOS Software********.

CatOS	Cisco IOS Software
No Catalyst OS equivalent	access-list 101 permit ip any any policy-map limit-interface class class-ag1 access-group 101 police 10000000 4625 conform-action transmit exceed-action drop interface fastethernet 3/5 service-policy input limit-interface

******** Similar functionality can be achieved in CatOS, but it requires configuring a unique policer for each interface in question. The Cisco IOS implementation of per-interface policers requires that the policer is defined only once, but applied separately.

Cisco IOS Software running on the Supervisor Engine 2 and 720 supports per-port policing in a distributed forwarding system (a system with one or more Distributed Forwarding Cards present). In a distributed system, aggregate policing per-VLAN is not supported.

Microflow Policers

Enabling Microflow policing in Cisco IOS Software must be done globally on the switch. This is not required in CatOS. The police flow command denotes the Microflow policing configuration for the Cisco IOS Software. The rest of the configuration follows a syntax similar to configuring a Per-Interface Aggregate Policer in the Cisco IOS Software.

CatOS	Cisco IOS Software
set qos policer microflow mf1 rate 1000000 burst 32 drop set qos acl ip mf_acl trust-dscp microflow mf1 any commit qos acl mf_acl set qos acl map mf_acl 3/5	mls qos flow-policing access-list 101 permit ip any any Policy-map limit-flow class limit-flow access-group 101 police flow 200 15 confirm-action transmit exceed-action drop interface fastethernet 3/5 service-policy input limit-flow

User-Based Rate Limiting (UBRL) on the Sup 32 and Sup 720 with Cisco IOS Only

User-Based Rate Limiting functionality is supported only on the Supervisor Engine 32 and Supervisor Engine 720 and is a Microflow policing function which provides a means to rate limit many source or destination IP addresses to an individual rate. This configuration requires only two ACLs and can support a large number of users. Only supported in Cisco IOS, the example below demonstrates UBRL by rate limiting traffic from each user in a user-group to 1Mbps each, going to the subnet 192.168.0.0/16:

CatOS	Cisco IOS Software
Not Supported	Access-list 101 permit ip any 192.168.0.0 0.0.255.255 Class-map 1Mbps-rate Match access-group 101 Policy-map Outbound Class 1Mbps-rate Police flow mask src-only 1000000 ... Int gig 3/1 Service-policy input Outbound

Marking with an ACL

You can set the priority fields in a frame (CoS, DSCP, or ToS) for specific traffic classes that match an ACL. This gives the user more granularity and functionality than what is provided by marking with default port CoS values.

PFC QoS (IOS release 12.1(12c)E1 supports policy map class marking for untrusted traffic with the set ip dscp and set ip precedence policy map class commands.

The following table provides a comparison of the different configuration parameters for each operating system.

CatOS	Cisco IOS Software
set qos acl ip CatOS dscp 24 any commit qos acl CatOS set qos acl map CatOS 3/1	access-list 101 permit ip any any policy-map IOS class IOS access-group 101 set ip dscp 24 interface gigabitethernet 3/1 service-policy input IOS

AutoQoS

Supported in CatOS only, AutoQoS is a macro which simplifies QoS configuration required for implementing recommended AVVID settings on a voice port. The macro is divided into two separate components:

• Global Automatic QoS Command (set qos auto)-deals with all switch-wide QoS-related settings, not specific to an interface.

• Port-Specific Automatic QoS Command (set port qos mod/port autoqos)-configures all inbound QoS parameters for a particular port to reflect desired traffic type.

In the examples below, AutoQoS is enabled and is configured to trust all incoming CoS and DSCP marking. The third example configures port 3/1 for ingress QoS for a Cisco IP Phone:

CatOS

set qos autoqos

set port qos 3/1 autoqos trust cos

set port qos 3/1 autoqos trust dscp

set port qos 3/1 autoqos voip ciscoipphone

Note: For further information on AutoQoS macro command inclusion, see: http://www.cisco.com/en/US/partner/products/hw/switches/ps708/products_configuration_guide_chapter09186a0080121d11.html - 22805

Switch Port Analyzer (SPAN)

SPAN is a troubleshooting analysis feature used to mirror the traffic coming to and from physical and logical interfaces on the switch. A SPAN session is an association of a set of SPAN source ports or VLANs that need to be monitored and a SPAN destination port is where the mirrored traffic is sent. The SPAN destination port does not belong to any VLAN and does not participate in spanning tree. Any 10M 100M 1G or 10G port can be configured as a SPAN source or destination port (including fabric-enabled and DFC-enabled line cards).

SPAN has been implemented differently between the two operating systems. CatOS can support up to two ingress-only or ingress/egress SPAN sessions and four egress-only SPAN sessions. Cisco IOS Software supports two SPAN sessions that can include traffic from both directions on the source interfaces. Different SPAN sessions can contain overlapping or distinct sets of source interfaces. Both switchports and routed ports can be configured as SPAN sources. Different SPAN sessions must contain distinct, nonoverlapping sets of destination interfaces.

Ingress SPAN (Rx) copies network traffic received by the source ports for analysis at the destination port. Egress SPAN (Tx) copies network traffic transmitted from the source ports. Configuration option "both" copies network traffic received and transmitted by the source ports to the destination port. The Cisco IOS Software can monitor 128 Egress or "both" sources and up to 128 ingress ports as source ports.********* Up to 64 SPAN destination interfaces are supported.

********* With IOS 12.2(18)SXE and above

The following example configures ports 5/1-2 as SPAN Sources and port 5/3 as the SPAN destination.

CatOS	Cisco IOS Software
set span 5/1,5/2 5/3 rx create	monitor session 1 source int f5/1-2 rx monitor session 1 dest int f5/3

Remote SPAN (RSPAN)

Remote SPAN retains most of the functionality of SPAN and adds support for source and destination ports distributed across multiple switches in a network. Traffic for RSPAN is carried over a user-specified RSPAN VLAN dedicated for that RSPAN session in all participating switches.

RSPAN sessions can coexist with SPAN sessions with a maximum of 30 SPAN/RSPAN sessions per switch. In the following example configurations, VLAN 10 is configured as an RSPAN VLAN and VLAN 5 is configured as the RSPAN source port to monitor both incoming and outgoing traffic:

CatOS	Cisco IOS Software
Set vlan 10 rspan Set rspan source 5 10 both Set rspan destination 3/1 10 Show rspan	IOS(config)#vlan 10 IOS(config-vlan)#remote-span IOS(config)#monitor session 1 source vlan 5 both IOS(config)#monitor session 1 destination remote-vlan 10 IOS#sh monitor session 1

Encapsulated Remote SPAN (RSPAN)

Introduced with 12.2(18)SXE, the Catalyst 6500 leverages the hardware acceleration of GRE on the Supervisro Engine 32 and Supervisor Engine 720 to allow network monitoring to extend beyond a layer 3 boundary. ERSPAN is used to monitor a remote network's layer 2 traffic and conserve resources by removing the requirement of the duplication of network probes across all layer 2 networks.

Figure 6.

ERSPAN and SPAN can monitor all traffic, including multicast and bridge protocol data unit (BPDU) frames, where RSPAN does not support BPDU monitoring. The following is a configuration example of ERSPAN.

CatOS	Cisco IOS Software
Not Applicable	IOS(config)# monitor session 3 type erspan-source IOS(config-mon-erspan-src)# source interface gigabitethernet 4/1 IOS(config-mon-erspan-src)# destination IOS(config-mon-erspan-src-dst)# ip address 10.1.1.1 IOS(config-mon-erspan-src-dst)# origin ip address 10.10.1.1 IOS(config-mon-erspan-src-dst)# erspan-id 101

Jumbo Frames

The jumbo frame feature supports a single larger-than-default Ethernet MTU size (1500 bytes) on the switch. The MTU can be configured between 1500 to 10240 bytes with default (recommended) MTU of 9216 bytes. Jumbo frames are switched in hardware with no performance impact for Ethernet, Fast Ethernet, Gigabit Ethernet and Ten Gigabit Ethernet interfaces. These interfaces can be routed interfaces, access switchports, trunk switchports, or EtherChannels (observe any restrictions imposed by the neighboring device). Jumbo frames are supported on VLAN interfaces (SVIs), but this would only be applicable for software switched traffic. As a general rule (not OS specific), jumbo frames should be enabled on all or none of the ports in a particular VLAN.

The configurations below show the jumbo frame configuration in both CatOS and Cisco IOS Software.

CatOS	Cisco IOS Software
Set port jumbo gi1/1-2 enable Show port jumbo (to show)	int range gi1/1-2 mtu 9216 show interface gi1/1 (to show)

The above commands enable MTU 9216 bytes on the gigabit interfaces. This will automatically change the ip mtu size also. The reverse is not true. Increasing ip mtu 9216 does not increase the interface MTU size.

High Availability

High availability on the Catalyst 6500 is one of the primary differentiators of the platform, allowing for fault avoidance and maximum uptime. With features like Non Stop Forwarding (NSF) and Stateful Switchover (SSO) combined with Generic Online Diagnostics (GOLD), the Catalyst 6500 can maintain packet processing combined with intersystem fault detection giving unmatched reliability and uptime.

Generic Online Diagnostics

The GOLD implementation checks the health of hardware components and verifies proper operation of the system data and control planes. Some tests take effect when the system is booting up, whereas other tests take effect when the system is operational. As shown in the Figure 6, tests are categorized into two categories: boot-up diagnostics and runtime diagnostics. Multiple tests can run in parallel.

Figure 7. Boot-Up Diagnostics and Runtime Diagnostics

The complete guide to GOLD can be found on CCO at: http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122sx/swcg/diags.htm

The comparison of implementing the GOLD features in IOS and CatOS are done below.

CatOS	Cisco IOS Software
set diagnostic bootup level ? bypass Bypass level complete Complete level minimal Minimal level	diagnostic bootup level ? complete Complete level minimal Minimal level
set diagnostic ondemand iterations 2	diagnostic ondemand iterations 2
set diagnostic ondemand action-on-failure stop	diagnostic ondemand action-on-failure stop
diagnostic start module 2 test 2	diagnostic start module 2 test 12
CatOS
Console> (enable) set diagnostic schedule module 2 test 1 weekly MON 03:00
Cisco IOS Software
Router(config)#diagnostic schedule module 2 test 1 weekly MON 03:00

Supervisor Redundancy

Both the Cisco IOS Software and CatOS support the deployment of redundant supervisor engines for component level redundancy within a Catalyst 6500 chassis. However, the operational model for supervisor engine redundancy differs between Cisco IOS Software and CatOS.

In CatOS, the foundation for supervisor redundancy is the High Availability feature. This feature allows systems with dual supervisors to synchronize the protocol states between the active and standby supervisor engines. If an active supervisor failure were to take place, the standby supervisor would then be able to take over system operation with accurate and up-to-date state information of the protocols running on the switch. This allows a supervisor failover to take place in one to three seconds and requires no network reconvergence for Layer 2, 3, and 4 protocols. From a router perspective, the MSFC engines can be configured for redundancy as well with hybrid software. For more information on hybrid High Availability, refer to the following white paper: http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/tech/hafc6_wp.pdf

Cisco IOS Software on the Catalyst 6500 supports Route Processor Redundancy (RPR, also known as Enhanced High System Availability [EHSA]), Route Processor Redundancy Plus (RPR+), and Non Stop Forwarding with Stateful Switchover (NSF/SSO). In this operational model, one supervisor/MSFC pair is fully operational and the other pair is in standby mode. The show module command lists the current and standby Supervisors. There are heartbeat messages between two pairs to ensure rapid failure detection. The RPR and RPR+ implementations do not synchronize protocol state between the two supervisor engines, however the SSO implementation synchronizes protocol state. The following section provides an overview of supervisor redundancy characteristics that are equivalent between RPR, RPR+, and SSO.

In the Cisco IOS Software, the supervisor and MSFC are each responsible for different functions and protocols (Layer 2 vs. Layer 3). However, the system is dependent on both engines being available for proper operation. Failure of either the supervisor or the MSFC in RPR/RPR+/SSO mode will cause a switchover from the active supervisor to the standby supervisor/MSFC. Note that in CatOS, the supervisor can remain fully operational if one MSFC fails; a MSFC failure does not necessarily cause a supervisor switchover, but may cause an MSFC failover only, allowing a cross model where the active PFC and the Switch Processor (SP) running Catalyst OS is fully functional in slot 1 whereas the Route Processor (RP)/MSFC is fully functional in slot 2.

Hybrid systems with redundant supervisor/MSFC combinations can optionally have two active MSFCs in the same chassis (referred to as Dual Router Mode). In this configuration, HSRP is configured internally between both active MSFCs. With Cisco IOS Software, the standby MSFC is not fully operational. Thus, it is not possible to run internal HSRP between the two MSFCs. External HSRP from the Cisco Catalyst 6500 to other routers in the network is supported in either RPR, RPR+, or NSF/SSO mode with the Cisco IOS Software.

There is no stateful protocol redundancy between supervisor engines with RPR or RPR+. The SSO redundancy mode provides the stateful protocol redundancy between supervisor engines in IOS and is equivalent in terms of functionality to the Cisco Catalyst OS High Availability redundancy mode.

The following section provides an overview of supervisor redundancy characteristics with RPR, RPR+, and NSF/SSO.

Route Processor Redundancy (RPR)

With RPR enabled, the active supervisor and MSFC are operational and responsible for all packet forwarding and features. The standby supervisor and MSFC are out of reset but not all subsystems are booted. The standby supervisor is booted to the point where the gigabit uplink ports are operational, but no protocols are running on the supervisor or MSFC.

Upon an active Supervisor failure, RPR detects the loss of the active supervisor and causes a switchover. The line cards are power-cycled, the supervisor and MSFC finish booting, and all Layer 2 and Layer 3 protocols are initialized. The fail-over time for the system to start forwarding traffic in EHSA is approximately 90 seconds. The actual failover time is dependent on the size and complexity of the configuration.

With RPR, the startup configuration and boot variables are synchronized between the active and standby supervisor.

Route Processor Redundancy Plus (RPR+)

With RPR+ enabled, the active supervisor and MSFC are operational and responsible for all packet forwarding and features. The standby supervisor and MSFC are fully booted and running on standby. RPR+ is an enhancement to RPR. Since the standby supervisor is further along in the boot process, RPR+ provides a faster supervisor failover than RPR. In addition, the line card state is maintained during a supervisor failover. This helps to reduce the failover time. However, the port states are not maintained, so connections to other devices will flap.

The failover time for the system to start forwarding traffic in RPR+ is approximately 30 seconds. The actual failover time is dependent on the size and complexity of the configuration.

Nonstop Forwarding with Stateful Switchover (NSF/SSO)

Both the Cisco IOS software and the CatOS support NSF with SSO. The key differentiators apply in where and how these features are applied with the more advanced forms of these features being deployed first in IOS. SSO expands the RPR+ capabilities to provide transparent failover of layer 2 protocols when a supervisor failure occurs. SSO is stateful for layer 2 protocols. Policy Feature Card (PFC) and Distributed Forwarding Card (DFC) hardware tables are maintained across a switchover. This allows for transparent failover at layer 2 and layer 4. NSF works in conjunction with SSO to ensure Layer 3 integrity following a switchover. It allows a router experiencing the failure of an active supervisor to continue forwarding data packets along known routes while the routing protocol information is recovered and validated. This forwarding can continue to take place by leveraging graceful restart mechanisms that allow peering arrangements to recover upon failover, thus avoiding unnecessary route flaps and network instability.

The failover time is 0 to 3 seconds with NSF/SSO. More information on NSF/SSO can be found at: http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper0900aecd801c5cd7.shtml

Hot Standby Router Protocol (HSRP)

The Hot Standby Router Protocol (HSRP) provides network redundancy for IP networks, ensuring that user traffic immediately and transparently recovers from first hop failures in network edge devices or access circuits. HSRP provides a layer 2 and layer 3 virtual address that is shared between 2 or more Cisco routing devices to ensure network resiliency. Using an election algorithm, combined with statically assigned virtual IP address and layer 2 MAC address for transparent fault recovery.

http://www.cisco.com/en/US/partner/tech/tk648/tk362/tk321/tsd_technology_support_sub-protocol_home.html

Virtual Router Redundancy Protocol (VRRP)

The Virtual Router Redundancy Protocol (VRRP) provides a function very similar to the Cisco-proprietary Hot Standby Router Protocol (HSRP). VRRP is designed to eliminate the single point of failure inherent in a static default routed environment. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail-over in the forwarding responsibility should the Master become unavailable. Any of the virtual router's IP addresses on a LAN can then be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host.

Gateway Load Balancing Protocol (GLBP)

The Gateway Load Balancing Protocol (GLBP) provides load-balancing over multiple gateways through a single virtual IP address and multiple virtual MAC addresses. This protocol is similar to Host Standby Router Protocol (HSRP) and Virtual Router Redundancy Protocol (VRRP). GLBP protects data traffic from a failed router or circuit, while allowing packet load sharing between a group of redundant routers (via the virtual MAC addresses on each router).

APPENDIX A: CISCO IOS SOFTWARE AND CATOS CONFIGURATION SAMPLE COMPARISON

This section walks you through a complete Cisco IOS mode configuration versus a CatOS configuration for a sample topology (Figure 8):

Figure 8. Sample Network Topology for Configuration Example

Step 1. Assign a name to the switch/router, configure prompt, time, and password.

CatOS	Cisco IOS Software
enable set system name cat6k-switch set enablepass set ip dns domain example.com set ip dns server a.b.c.d	Enable configure terminal hostname cat6k-switch enable password <> ip domain-name example.com ip name-server a.b.c.d end

Step 2. Configure VTP as transparent and check the status.

CatOS	Cisco IOS Software
set vtp mode transparent show vtp domain	configure terminal vtp mode transparent end write memory show vtp status

Step 3. Create VLANs and check the status.

CatOS	Cisco IOS Software
set vlan 2 name Marketing set vlan 3 name Finance show vlan	configure terminal vlan 2 name Marketing vlan 3 name Finance end write memory show vlan

Step 4. Configure the Gigabit Ethernet uplinks as routed interfaces. The Gigabit Ethernet uplinks 1/1 and 1/2 are used to connect to the remainder of the network. Because these ports only require Layer 3 routing functionality, the Cisco IOS Software can use the straightforward routed interface command structure below:

CatOS	Cisco IOS Software
Catalyst OS config: set vlan 89 1/1 set vlan 90 1/2 MSFC config: int vlan 89 ip address 10.1.1.1 255.255.255.0 no shut int vlan 90 ip address 10.1.2.1 255.255.255.0 no shut end write memory	configure terminal interface gigabitethernet 1/1 ip address 10.1.1.1 255.255.255.0 no shut interface gigabitethernet1/2 ip address 10.1.2.1 255.255.255.0 no shut end write memory

Note: VLANs 89 and 90 are randomly chosen for this example

Step 5. Configure ports 2/1-3 to be used as access ports for client connections in VLAN 2, ports 2/4-5 in VLAN 3, and configure all the ports for full-duplex mode and speed 100.

CatOS	Cisco IOS Software
set vlan 2 2/1 - 3 set vlan 3 2/4 - 5 set port speed 2/1 - 5 100 set port duplex 2/1 - 5 full show port	Configure terminal interface range fastethernet 2/1 - 3 switchport switchport mode access switchport access vlan 2 speed 100 duplex full interface range fastethernet 2/4 - 5 switchport switchport mode access switchport access vlan 3 speed 100 duplex full end write memory show interface status

Step 6. Configure trunk switchports: port 2/6 is used to carry all three VLANs to Catalyst B, a Layer 2 Catalyst. The trunk uses IEEE 802.1q encapsulation and defaults to VLAN 1.

CatOS	Cisco IOS Software
set trunk 2/6 dot1q set trunk 2/6 desirable	interface fastethernet 2/6 switchport switchport mode dynamic desirable switchport trunk encapsulation dot1q

Step 7. Optional Configuration: By default, the Catalyst 6500 switch allows all VLANs on the trunk. Configure the list VLAN 50-100 to be pruned from trunk.

CatOS	Cisco IOS Software
clear trunk 2/6 50-100	switchport trunk allowed vlan remove 50-100

Step 8. Configure the Routed SVI: Step 4 configured the Gigabit Ethernet interfaces as routed uplinks. This step shows the configuration for two SVI interfaces which provide routing services for both VLANs (inter-VLAN routing). This configuration uses HSRP on VLAN 2 and 3 and also includes IPX network numbers.

CatOS	Cisco IOS Software
Routing is done on MSFC: interface vlan2 ip address 10.10.2.2 255.255.255.0 standby 1 timers 1 3 standby 1 priority 200 preempt standby 1 ip 10.10.2.6 ipx network 20 interface vlan3 ip address 10.10.3.2 255.255.255.0 standby 1 timers 1 3 standby 1 priority 200 preempt standby 1 ip 10.10.3.6 ipx network 30	The Logical SVI interfaces are exactly the same as on MSFC. The configuration on the left can be copied.

APPENDIX B: CATOS AND CISCO IOS SOFTWARE COMMAND MATRIX

CatOS	Cisco IOS Software
reset system	Reload
session	Remote login
Set system name	Hostname
Set test diaglevel	Diagnostic level
Set boot config-register	Config-register
Set boot system flash	Boot system flash
Set module power down/up	Power enable module
Set port disable	Shutdown (interface mode)
set port duplex	Duplex
set port flowcontrol send [desired \| off \|on]	flowcontrol send [desired \| off \| on]
set port flowcontrol receive [desired \| off \|on]	flowcontrol receive [desired \| off \| on]
set port negotiation <mod/port> enable/disable	speed nonegotiate
set port speed	speed
set cam	mac-address-table
Set port jumbo	Mtu 9216
set port channel	channel-group <group> mode (interface mode)
set trunk (default mode is auto)	switchport mode trunk (vlan database command)
set udld	Udld
set vlan <vlan id> port	1) switchport 2) switchport mode access 3) switchport access vlan <>
set vtp	vtp
Set spantree backbonefast	Spanning-tree backbonefast
Set spantree enable/disable	Spanning-tree vlan
Set spantree portfast	Spanning-tree portfast
set qos enable	mls qos
Set port dot1qtunnel	Switchport mode dot1qtunnel
show cam dynamic	show mac-address-table dynamic
show channel info or show port channel	show etherchannel summary
show mac	show interface counters
show port <slot/port>	show interface <type slot/port>
show mls cef	show mls cef
show port	show interface status
Show port capabilities	Show interface capabilities
show span	show monitor
show spantree	show spanning-tree
show qos	show mls qos
show trace	show debugging
show trunk or show port trunk	show interfaces trunk
show udld	show udld
show vlan	show vlan
show vtp domain	show vtp status
clear cam	clear mac-address-table

APPENDIX C: CONVERSION PROCEDURES

Software conversion from Hybrid to Native IOS on a Cisco Catalyst 6000 Series Switch http://www.cisco.com/en/US/partner/products/hw/switches/ps708/products_tech_note09186a008015bfa6.shtml

Software conversion from Native IOS to Hybrid on a Cisco Catalyst 6000 Series Switch http://www.cisco.com/en/US/partner/products/hw/switches/ps700/products_tech_note09186a00801350b8.shtml

NetXG stocks, and specializes in Cisco Systems network equipment. All network equipment we sell is completely Tested, Cleaned, and Guaranteed. We make sure everything we sell works and you are 100% satisfied with the Network Equipment you purchase from us. NetXG buys and sells all Cisco routers, switches, firewall, and modules.

If you have any questions about the Cisco 6500 Series call us. Phone 805-681-5071. We have a knowledgeable support staff and complete documentation on the Cisco 6500 Series.