Home > Articles > Certification > Cisco Certification > CCNP

This chapter is from the book

Scenario 6-3: Upgrading from Hybrid Mode to Native Mode on the Catalyst 6000/6500

At the beginning of this chapter, you learned that there are two different modes in which you can operate a Cisco Catalyst 6000/6500 Layer 3 switch. The first mode is hybrid mode, where a separate and different operating system (CatOS and Cisco IOS) runs on the Supervisor engine and MSFC respectively; in the previous scenario, you learned how to configure a Catalyst 6000/6500 switch running in hybrid mode. The second mode is native mode, where a single operating system (Cisco IOS) controls and configures both the Supervisor engine and MSFC and is considered the way of the future for the Cisco Catalyst 6000/6500 switch. By default, all Cisco Catalyst 6000/6500 switches that include an MSFC ship in hybrid mode, so if you wish to run native mode, you must upgrade your switch to native mode yourself.

In this scenario, you learn how to upgrade a hybrid mode Catalyst 6000/6500 switch to native mode and also learn about some of the restrictions of running native mode. This scenario follows on from the previous scenario with the goal of ensuring the same level of functionality as the previous scenario; the only difference being that Switch-A is to operate in native mode as opposed to hybrid mode.

Understanding Native Mode

Before examining native mode, it is important to understand that the Supervisor module has its own processor, which is referred to as the switch processor. The switch processor is responsible for managing the Layer 2 components of the switch, as well as the PFC card that provides Layer 3/4 data plane operations. The MSFC also has its own processor, which is referred to as the route processor; this is responsible for managing Layer 3 control plane operations.

When a Cisco Catalyst 6000/6500 is installed with a MSFC, the switch can be described as operating in two modes:

  • Hybrid mode—In hybrid mode (or Hybrid mode), separate operating systems manage the Supervisor module and the MSFC. The Supervisor module operating system (CatOS) has control over the Layer 2 switching functions and hardware-based L3 switching (data plane) functions, while the MSFC operating system (Cisco IOS) has control over the Layer 3 routing control plane functions. Hybrid mode is the default mode of operation, and the Supervisor and MSFC require separate management.

  • Native mode—In native mode (or Native mode), a single operating system is used to manage both the Supervisor module and the MSFC. The operating system, which is Cisco IOS, has control over all Layer 2 and Layer 3 functions of the switch. Native mode represents the future direction of the Cisco Catalyst 6000/6500; however, it is important to note that at this time, native mode requires an MSFC to be installed alongside the Supervisor, and some line cards and features are not currently supported in native mode.

Hybrid mode represents the majority of Catalyst 6000/6500 installations today; this will remain so for the foreseeable future because there are some specific requirements and restrictions when using native mode.

Native Mode Requirements

To upgrade to native mode (if your Catalyst 6000/6500 switch has a Supervisor 1 module installed) it must meet the following prerequisites:

  • Policy feature card (PFC-1) installed.

  • Multilayer switching feature card (MSFC-1 or MSFC-2) installed.

  • Supervisor 1 must have at least 16 MB Flash (default) and 64 MB DRAM (default) installed.

  • MSFC-1 or MSFC-2 must have at least 16 MB Flash (default) and 128 MB DRAM (default for MSFC-2) installed. For larger and more complex networks, 256 MB or 512 MB of DRAM is recommended.

  • A 32 MB PCMCIA flash card is recommended at least temporarily for rollback purposes, as you must format the internal flash file system to a Cisco IOS format.

If your Catalyst 6000/6500 switch has a Supervisor 2 module installed, it must meet the following prerequisites:

  • Policy Feature Card (PFC-2) that is integrated into the Supervisor 2 module.

  • Multilayer Switching Feature Card (MSFC-2) installed (the Supervisor 2 does not support the MSFC-1).

  • Supervisor 2 must have at least 32 MB Flash and 128 MB DRAM (default) installed.

  • MSFC-2 must have at least 16 MB Flash (default) and 256 MB DRAM (default) installed.

  • A 32 MB PCMCIA Flash card is recommended at least temporarily for rollback purposes because you must format the internal Flash file system to a Cisco IOS format.

NOTE

If your Catalyst 6000/6500 switch has a Supervisor 720 engine installed, this engine in its default configuration meets the requirements for upgrading to native mode.

The main requirement for native mode (and also the main limiting factor for choosing to upgrade to native mode) is the MSFC. The MSFC certainly isn't cheap and is obviously not required for many LAN topologies where the switch is required to L2 switch packets and classify packets only at L3/L4 (the PFC is only required to classify packets at L3/L4).

Native Mode Limitations

It is important to understand that there are some restrictions on both the hardware and software features you can use with native mode. At the time of writing, hybrid mode supports more features than native mode, although at some stage in the not too distant future, Cisco has indicated native mode will become equal with hybrid mode in terms of features. From there native mode will be the primary development platform for the Catalyst 6000/6500.

In terms of hardware limitations, the following modules are not supported in the latest Cisco IOS release at the time of writing (12.1(14)E):

  • Voice modules (WS-X6624-FXS, WS-X6608-T1, WS-X6608-E1)

  • ATM LANE modules (WS-X6101-OC12-MMF, WS-X6101-OC12-SMF)

  • Multilayer Switch Module (WS-X6302-MSM)

  • 2-port OC-12/STM-4 ATM OSM, MM (WS-X6101-OC12-MMF)

  • 2-port OC-12/STM-4 ATM OSM, SM-IR (WS-X6101-OC12-SMF)

If you have these modules installed in a native mode system, the modules remain powered down and do not interfere with the operation of the switch.

In terms of software limitations, quite a number of features are still not supported in native mode, although this list will grow smaller with each new release of Cisco IOS. Notable features that are not supported include:

  • High availability

  • Dynamic VLANs using VLAN Membership Policy Server (VMPS)

  • Multi-Instance Spanning Tree Protocol (MISTP)

  • MAC address filtering

  • Layer 2 traceroute

Probably the most important feature not available is high availability. A feature called Route Processor Redundancy Plus (RPR+) is supported; however, the failover time is in the order of 30 to 60 seconds. For many Catalyst 6000/6500 installations with redundant Supervisor configurations, this failover time is unacceptable and is definitely a limiting factor in the migration to native mode. Hybrid mode supports the high availability feature, which synchronizes the various state tables between each Supervisor (e.g., spanning tree, bridge table) and allows failover within three seconds.

NOTE

Other ways of implementing faster convergence for high availability networks exist, such as using Hot Standby Routing Protocol (HSRP), which can provide sub-second failover when operating redundant Layer 3 chassis. If you want a redundancy in a single chassis, however, native mode does not support the fast failover high availability brings to hybrid mode installations.

The Hybrid Mode versus Native Mode Boot Process

It is important to understand the differences in the boot process of both hybrid mode and native mode so that you can understand the file system and image requirements of upgrading to native mode. This information also helps you to revert back to hybrid mode if required.

The Hybrid Mode Boot Process

With hybrid mode, the following describes the files that the Supervisor and MSFC modules boot from:

  • Supervisor Image—The Supervisor CatOS image is normally installed in the bootflash: device (the onboard flash device) of the Supervisor and always begins with a prefix of cat6000-sup—e.g., cat6000-sup2k8.7-2-2.bin.

  • MSFC Boot Loader—The MSFC uses two files. The first is the boot loader file, which is required to initially boot the MSFC. This file is normally stored in the bootflash: device of the MSFC (not the Supervisor), and begins with a prefix of c6msfc-boot (for MSFC-1) or c6MSFC-2-boot (for MSFC-2)—e.g., c6MSFC-2-boot-mz.121-8a.E4.

  • MSFC Image—The MSFC Cisco IOS operating system image is normally stored in the bootflash: device of the MSFC and begins with a prefix of c6msfc (for MSFC-1) or c6MSFC-2 (for MSFC-2)—e.g., c6MSFC-2-jsv-mz.121-8a.E4.

When a hybrid mode switch first boots, the switch processor on the Supervisor module reads a boot environment variable, which specifies the full path to the operating system image that should be booted. This image is a CatOS-based image, which boots the Supervisor module. The Supervisor module initializes the various modules installed, runs systems diagnostics, and loads the CatOS operating system into Supervisor memory. If an MSFC is installed, once it has been initialized by the switch processor, the MSFC boot loader image is loaded, after which the main MSFC image is loaded by the route processor on the MSFC. This image is a Cisco IOS-based image which initializes the various hardware components on the MSFC, runs system diagnostics, and loads the Cisco IOS operating system into MSFC memory. Once the Supervisor and MSFC boot processes are complete, two separate operating systems exist, which each provide separate management interfaces to configure and manage each component.

The Native Mode Boot Process

With native mode, the following describes the files that each module boots from:

  • MSFC Boot Loader—The MSFC-1 still requires the boot loader file in native mode (the MSFC-2 does not require this file). This file is identical to the boot loader file used in hybrid mode. If you have an MSFC-2, you don't need this file; however, it is recommended to keep this file so that you can revert back to hybrid mode.

  • Combined Supervisor and MSFC Image—A single combined Supervisor and MSFC Cisco IOS operating system image is normally stored in the bootflash: device of the Supervisor and always begins with a prefix of c6sup, following by two digits that identify the Supervisor module and MSFC that the image is compatible for. For example, the file c6sup22-jsv-mz.121-11b.E4 is a native mode image for a Supervisor 2 module (indicated by the first number 2 digit) and MSFC-2 (indicated by the second number 2 digit).

When a native mode switch first boots, the switch processor on the Supervisor module reads a boot environment variable, which specifies the full path to the operating system image that should be booted. This image is a native mode (Cisco IOS) image, which boots the Supervisor module. The Supervisor module initializes the various modules installed, runs systems diagnostics, and loads the Cisco IOS operating system into Supervisor memory. Once complete, system control is then handed to the MSFC route processor, which boots from a portion of the native mode image. The MSFC hardware is initialized, system diagnostics are run and the Cisco IOS image is loaded into MSFC memory. At this point, both the switch processor and route processor have each loaded a separate Cisco IOS-based operating system that actually run independently of each other to some extent.

The MSFC Cisco IOS operating system has control over the console port on the Supervisor module and provides a single management interface that you as the administrator see from the switch console port, which allows you to perform all system configuration tasks. In the background the route processor handling the commands executed by administrators actually passes the tasks that require handling by the switch processor to the switch processor for execution. This serves to give the look and feel of a unified switch management interface that manages all components of the switch.

Configuration Prerequisites

Before beginning this scenario, it is important that you have an appropriate operating system file required for native mode operation and that this file is somehow distributed to a local file system on Switch-A. The easiest way of distributing the new native mode operating system image to Switch-A is used the network, which requires a TFTP server to be accessible from Switch-A. This scenario assumes that the appropriate native mode image has been obtained (if you are a registered cisco.com user and have sufficient rights to download software, you can obtain a native mode operating system image from http://www.cisco.com/cgi-bin/tablebuild.pl/cat6000-sup-ios) and that this image has been installed to a PCMCIA Flash card in Switch-A via TFTP.

Configuration Tasks

It is important to ensure you fully understand the native mode upgrade process and that you follow the process correctly to ensure a smooth upgrade to native mode. Upgrading from hybrid mode to native mode requires the following configuration tasks:

  • Backing up existing configuration and operating system files

  • Obtaining the appropriate native mode operating system files

  • Upgrading to native mode operation

Backing up Existing Configuration and Operating System Files

The first thing that you must do before upgrading to native mode is to ensure that you have full backups of your current configuration and hybrid mode files. When upgrading to native mode a blank configuration is initially loaded, so you must manually reconfigure the switch to your previous configuration.

TIP

An automatic configuration converter is available on CCO at http://www.cisco.com/cgi-bin/Support/CatCfgConversion/catcfg_xlat.pl, which allows you to paste an existing CatOS hybrid mode configuration and outputs an equivalent native mode Cisco IOS configuration. This converter is available only for registered CCO users.

It is a good idea to also keep a copy of your hybrid mode files, just in case you need to revert back to hybrid mode. The ideal situation is to have enough flash so that you can leave the old hybrid mode image intact alongside the new native mode image. This makes it very quick and easy to revert back to hybrid mode if required.

At this stage, it is a good idea to have an understanding of the files that the Supervisor 2 engine and MSFC-2 on Switch-A are using for hybrid mode operation, so that you are aware of the files required to run hybrid mode if a roll back should be required. Example 6-25 demonstrates viewing the files used by the Supervisor engine on Switch-A and then establishing a console connection to the MSFC-2 on Switch-A by using the session command and viewing the files present on the MSFC-2 internal Flash file system.

Example 6-92 Viewing Hybrid Mode Files on an MSFC-2

Switch-A> (enable) dir bootflash:
-#- -length- -----date/time------ name
 1 6199068 Apr 26 2002 13:18:19 cat6000-sup2k8.7-2-2.bin 

25782500 bytes available (6199068 bytes used)
Switch-A> (enable) session 15
Trying Router-15...
Connected to Router-15.
Escape character is '^]'.

Switch-A-MSFC> enable
Password: ***** 
Switch-A-MSFC# dir bootflash:
Directory of bootflash:/

  1 -rw-   1686724  Jun 04 2002 13:32:23 c6MSFC-2-boot-mz.121-8a.E4
  2 -rw-  12263928  Jun 04 2002 13:37:19 c6MSFC-2-jsv-mz.121-8a.E4

15204352 bytes total (1253444 bytes free)

In Example 6-25, you initially can see the CatOS operating system file used for the Supervisor 2 engine (cat6000-sup2k8.7-2-2.bin) present in the bootflash: file system on Switch-A (the internal Supervisor engine Flash). On the MSFC-2, you can see two files present in the bootflash: file system (not to be confused with the bootflash: file system on the Supervisor), which represents the internal Flash on the MSFC-2. The first file is the boot image (c6MSFC-2-boot-mz.121-8a.E4), which is required to initially boot the MSFC-2 when operating in hybrid mode. The second file is the actual operating system file (c6MSFC-2-jsv-mz.121-8a.E4) for the MSFC-2, which is designed to operate in hybrid mode.

With Switch-A running in native mode, the CatOS operating system file on the Supervisor bootflash: device is replaced with a single native mode Cisco IOS operating system image, which manages both the Supervisor 2 engine and MSFC-2 without any additional files. This means you don't actually need the boot image and operating system image files located on the MSFC-2 bootflash: device. However, it is a good idea to maintain these files, at least during the upgrade process, just in case you need to revert to hybrid mode.

TIP

If you are upgrading a Supervisor 1 with MSFC-1 to native mode (instead of MSFC-2), you must keep the boot loader image in the MSFC flash file system, as it is used to boot the MSFC-1 in native mode.

Obtaining the Appropriate Native Mode Operating System Files

Before beginning the native mode upgrade process, you must ensure that you use the correct native mode image for your Catalyst 6000/6500 supervisor/MSFC configuration. A separate native mode image exists for the various combinations of Supervisor 1/2 modules and MSFC-1/MSFC-2 modules. For example, a different native mode image is required for a Supervisor 1 module with MSFC-2, compared with a Supervisor 2 module with MSFC-1. To determine which native mode image is suitable for your system, refer to the prefix of the native mode image filename. The first five characters of the filename should contain the text c6sup, which indicates the file is a native mode image. The next character (the sixth character of the filename) indicates the Supervisor engine that the native mode image is suitable for, while the following character (the seventh character of the filename) indicates the MSFC module that the native mode image is suitable for. For example, the prefix c6sup12 indicates the image is suitable for a Supervisor 1 with MSFC-2, while the prefix c6sup22 indicates the image is suitable for Supervisor 2 with MSFC-2.

If you have an MSFC-1 installed with the Supervisor 1, you must also ensure that the boot loader file used to initially boot the MSFC in hybrid mode is also present in native mode (i.e., the c6MSFC-2-boot-xxxx file). This file is already required for hybrid mode operation, so the correct boot loader file should already be in place.

After you have determined the appropriate files required for native mode, you must ensure the files are present on the Flash file system of the switch. Because the Supervisor module initially boots from the native mode image, the native mode image must be present on a file system that the Supervisor can initially read at system startup. This includes the following flash devices:

  • Supervisor internal Flash—This is the internal Flash included with every Supervisor 2 module. This device is referred to by the Supervisor module as bootflash: and by the MSFC as sup-bootflash:.

  • PCMCIA Flash—If your internal Flash does not have enough space to accommodate the native mode image, you must install PCMCIA-based Flash in the external PCMCIA slots on the Supervisor module. It is recommended that you have PCMCIA Flash available during the native mode upgrade, as you need to format all file systems after the upgrade to allow native mode to write to each file systems. PCMCIA Flash can be used as temporary storage whilst the internal Flash file system is being formatted.

In this scenario, assume that Switch-A has a PCMCIA flash card installed which allows for the native mode image to be stored here temporarily while the Supervisor Flash file system is formatted; this is required to ensure the file system is compatible with the native mode Cisco IOS operating system.

NOTE

A switch running in native mode can read a hybrid mode file system, but cannot write to the hybrid mode file system due to differences in the file system format. This is the reason why all file systems used by native mode must be reformatted.

Assuming a native mode image has been downloaded to the PCMCIA Flash card via TFTP or some other means, Example 6-26 demonstrates verifying a native mode image is present on the PCMCIA card.

Example 6-93 Verifying Native Mode Image is Available on File System

Switch-A> (enable) dir slot0:
-#- -length- -----date/time------ name
 1 21611516 Jun 03 2002 09:12:08 c6sup22-jsv-mz.121-11b.E4

10370052 bytes available (21611516 bytes used)

In Example 6-26, slot0: represents the Flash file system on the PCMCIA Flash card. An image called c6sup22-jsv-mz.121-11b.E4 is present. This is the new native mode image that you configure the switch to boot from. You can tell that the image is a native mode image for the Supervisor 2 with MSFC-2 because the filename prefix is c6sup22.

Upgrading to Native Mode Operation

Once the appropriate native mode files are in place within Flash, you are ready to begin the process of upgrading the switch to operate in native mode. Configuring the switch to operate in native mode requires the following configuration tasks:

  • Boot into ROMMON mode

  • Boot into native mode for the first time

  • Convert Flash file systems to native mode format

  • Set boot parameters

  • Reboot the switch

Booting into ROMMON Mode

When you upgrade to native mode, you must alter the BOOT environment variables that the switch processor reads (stored in the ROMMON configuration) so that the switch processor boots the native mode image, rather than a hybrid mode CatOS image. You need to specify the correct file system path, so it is important you understand the Flash device upon which the Native mode image is stored, and the full name of the image. The full path includes the Native mode image filename, preceded by the Flash device name (e.g., bootflash:c6sup22-jsv-mz.121-11b.E4 refers to a native mode image installed on the internal Flash of the Supervisor).

NOTE

It is important to understand that you cannot use any file system device that is attached to the MSFC to store the native mode image because the Supervisor module must have access to the image upon initialization (remember the MSFC is not initialized until after the Supervisor has initially booted from the native mode image).

To reconfigure the boot environment variables, you need to initially boot the switch into ROMMON mode and then modify the boot environment variables. This can be achieved by modifying the boot variables of the configuration register on the Supervisor engine using the set boot config-register command, so that the switch always boots to ROMMON mode and then physically rebooting the switch. Example 6-27 demonstrates configuring Switch-A to always boot into ROMMON mode and then rebooting the switch into ROMMON mode.

Example 6-94 Booting the Catalyst 6000/6500 into ROMMON Mode

Switch-A> (enable) set boot config-register 0x0
Configuration register is 0x0
ignore-config: disabled
auto-config: non-recurring, overwrite, sync disabled
console baud: 9600
boot: the ROM monitor
Switch-A> (enable) reset
This command will reset the system.
Do you want to continue (y/n) [n]? y
2002 Jul 01 11:48:47 %SYS-5-SYS_RESET:System reset from Console
Powering OFF all existing linecards
System Bootstrap, Version 6.1(4)
Copyright 1994-2001 by cisco Systems, Inc.
c6k_sup2 processor with 131072 Kbytes of main memory

rommon 1 >

In Example 6-27, notice that the configuration register is set to 0x0 (short for 0x0000), which configures the switch to boot to ROMMON mode as indicated by the shaded output of the command. The switch is then rebooted using the reset command, with the switch booting into ROMMON mode due to the new value of the configuration register.

Booting into Native mode for the First Time

Before you can boot into native mode, you must clear a boot variable called CONFIG_FILE, which is used by hybrid mode to locate the configuration file that contains the configuration of the switch. The reason for this is that although native mode does not use this variable, there have been some issues with leaving this variable set a value other than null. Example 6-28 demonstrates clearing this variable in ROMMON mode on Switch-A.

Example 6-95 Clearing the CONFIG_FILE Environment Variable

rommon 1 > set
PS1=rommon ! > 
BOOT=bootflash:cat6000-sup2k8.7-2-2.bin,1;
CONFIG_FILE=bootflash:switch.cfg
rommon 2 > CONFIG_FILE=
rommon 3 > sync

In Example 6-28, the set ROMMON command is used to display the various environment variables—notice the CONFIG_FILE variable is currently set to bootflash:switch.cfg, which represents a hidden CatOS binary configuration file stored in the internal flash file system (bootflash:) on Switch-A. This variable is then set to a null value using the command CONFIG_FILE=, after which the sync command must be used to write the environment variable changes permanently. At this point, for the environment variable change to take effect, the switch must once again be rebooted. The switch reboots back into ROMMON mode because the configuration register is still set to 0x0. Example 6-29 demonstrates rebooting Switch-A after clearing the CONFIG_FILE environment variable.

Example 6-96 Rebooting Switch-A To Clear the CONFIG_FILE Environment Variable

rommon 4 > reset

System Bootstrap, Version 6.1(4)
Copyright 1994-2001 by cisco Systems, Inc.
c6k_sup2 processor with 131072 Kbytes of main memory

rommon 1 > set
PS1=rommon ! > 
BOOT=bootflash:cat6000-sup2k8.7-2-2.bin,1;
CONFIG_FILE=

In Example 6-29, notice that the CONFIG_FILE variable now has a null value, which ensures the switch doesn't boot with a value for this variable.

After clearing the CONFIG_FILE variable, the switch can now be booted from the native mode operating system image file. This can be achieved by using the boot ROMMON command, specifying the full path to the native mode image, which in this scenario is stored in PCMCIA Flash and can be referenced by the path slot0:c6sup22-jsv-mz.121-11b.E4 (see Example 6-26). Example 6-30 demonstrates booting Switch-A in ROMMON mode from the native mode operating system image file.

Example 6-97 Booting Native Mode Manually from ROMMON Mode

rommon 2 > boot slot0:c6sup22-jsv-mz.121-11b.E4
Self decompressing the image : ################################################
###############################################################################
###############################################################################
###############################################################################
###############################################################################
[OK] 
Restricted Rights Legend 
Use, duplication, or disclosure by the Government is 
subject to restrictions as set forth in subparagraph 
 of the Commercial Computer Software - Restricted 
Rights clause at FAR sec. 52.227-19 and subparagraph 
 (1) (ii) of the Rights in Technical Data and Computer 
Software clause at DFARS sec. 252.227-7013. 
cisco Systems, Inc. 
170 West Tasman Drive 
San Jose, California 95134-1706 
Cisco Internetwork Operating System Software 
IOS (tm) c6sup2_sp Software (c6sup2_sp-SPV-M), Version 12.1(11b)E4,
   EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) 
Synced to mainline version: 12.1(11b) 
TAC:Home:Software:Ios General:CiscoIOSRoadmap:12.1 
Copyright 1986-2001 by cisco Systems, Inc. 
Compiled Wed 28-Mar-01 18:36 by hqluong 
Image text-base: 0x30020980, data-base: 0x306B8000 
Start as Primary processor 
00:00:05: %SYS-3-LOGGER_FLUSHING: System pausing to ensure console
   debugging output. 
00:00:03: Currently running ROMMON from S (Gold) region 
00:00:05: %OIR-6-CONSOLE: Changing console ownership to route processor 
System Bootstrap, Version 12.1(3r)E2, RELEASE SOFTWARE (fc1) 
Copyright 2000 by cisco Systems, Inc. 
Cat6k-MSFC2 platform with 131072 Kbytes of main memory 
rommon 1 > boot 
Self decompressing the image : ################################################
###############################################################################
## [OK] 
Restricted Rights Legend 
Use, duplication, or disclosure by the Government is 
subject to restrictions as set forth in subparagraph 
 of the Commercial Computer Software - Restricted 
Rights clause at FAR sec. 52.227-19 and subparagraph 
 (1) (ii) of the Rights in Technical Data and Computer 
Software clause at DFARS sec. 252.227-7013. 
cisco Systems, Inc. 
170 West Tasman Drive 
San Jose, California 95134-1706 
Cisco Internetwork Operating System Software 
IOS (tm) MSFC2 Software (C6MSFC2-BOOT-M), Version 12.1(8a)E4,
   EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
Copyright 1986-2000 by cisco Systems, Inc. 
Compiled Sat 14-Oct-00 05:33 by eaarmas 
Image text-base: 0x30008980, data-base: 0x303B6000 
cisco Cat6k-MSFC2 (R7000) processor with 114688K/16384K bytes of memory. 
Processor board ID SAD04430J9K 
R7000 CPU at 300Mhz, Implementation 39, Rev 2.1, 256KB L2, 1024KB L3 Cache 
Last reset from power-on 
X.25 software, Version 3.0.0. 
509K bytes of non-volatile configuration memory. 
16384K bytes of Flash internal SIMM (Sector size 512K). 
Press RETURN to get started!

--- System Configuration Dialog --- 
Continue with configuration dialog? [yes/no]: n
Router> enable

In Example 6-30, you can see the native mode boot process. First of all, the Supervisor engine is booted, as indicated in the first shaded line by the text, c6sup2 sp Software (Catalyst 6000 Supervisor 2 switch processor software). After the supervisor engine boots, notice the next shaded line, which states that console ownership is being changed to the route processor (MSFC):

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

This message indicates that the switch processor (Supervisor) is handing management control of the system to the route processor (MSFC). When a Catalyst 6000/6500 switch running native mode boots, the Supervisor initially executes startup code and then hands off the boot process to the MSFC. The MSFC then boots. At this stage, the MSFC still boots from the hybrid mode files located on the MSFC internal Flash. Once boot up by the MSFC is complete, notice that the switch loads with a blank configuration, as indicated by the System Configuration Dialog prompt. After specifying n at the System Configuration Dialog prompt, notice that a normal Cisco IOS Router> prompt is presented, as per the default operation when booting up a Cisco IOS-based Catalyst switch with a blank configuration.

At this point, it is a good idea to issue a show version command so that you can verify the switch has booted from the image you think it has booted from and to also verify that native mode has recognized each of the physical interfaces installed in the switch. Example 6-31 demonstrates using show version to verify the hardware configuration and operating system version on Switch-A.

Example 6-98 Verifying a Native Mode Catalyst 6000/6500 Switch

Router# show version
Cisco Internetwork Operating System Software 
IOS (tm) c6sup2_rp Software (c6sup2_rp-JSV-M), Version 12.1(11b)E4,
   EARLY DEPLOYMENT 
Synced to mainline version: 12.1(11b) 
TAC:Home:Software:Ios General:CiscoIOSRoadmap:12.1 
Copyright 1986-2001 by cisco Systems, Inc. 
Compiled Wed 28-Mar-01 17:52 by hqluong 
Image text-base: 0x30008980, data-base: 0x315D0000 
ROM: System Bootstrap, Version 12.1(3r)E2, RELEASE SOFTWARE (fc1) 
BOOTFLASH: c6sup2_rp Software (c6sup2_rp-JSV-M), Version 12.1(8a)EX,
   EARLY DEPLOYMENT 
Router uptime is 2 hours, 33 minutes 
System returned to ROM by power-on (SP by power-on) 
Running default software 
cisco Catalyst 6000 (R7000) processor with 114688K/16384K bytes of memory. 
Processor board ID SAD04430J9K 
R7000 CPU at 300Mhz, Implementation 39, Rev 2.1, 256KB L2, 1024KB L3 Cache 
Last reset from power-on 
Bridging software. 
X.25 software, Version 3.0.0. 
SuperLAT software (copyright 1990 by Meridian Technology Corp). 
TN3270 Emulation software. 
1 Virtual Ethernet/IEEE 802.3 interface(s) 
48 FastEthernet/IEEE 802.3 interface(s) 
2 Gigabit Ethernet/IEEE 802.3 interface(s) 
381K bytes of non-volatile configuration memory. 
16384K bytes of Flash internal SIMM (Sector size 512K). 
Configuration register is 0x0

In Example 6-31, notice that the switch is running Cisco IOS 12.1(11b)E4 and that the switch has recognized 1 virtual Ethernet interface (the VLAN 1 interface), 48 FastEthernet interfaces (located in slot 2 of Switch-A), and 2 gigabit Ethernet interfaces, which are onboard the Supervisor 2 engine.

Converting the Flash File Systems to Native mode Format

Assuming the switch has booted correctly as shown in Example 6-30 and verified in Example 6-31, the switch is now operating in native mode which confirms the switch is compatible with the native mode image. The next step is to convert the existing Flash file systems to native mode format, so that native mode can write to these file systems. This involves the following tasks:

  • Formatting existing hybrid mode file systems

  • Copying native mode image to new native mode file systems

To format the Flash file systems, you use the format command which takes a single parameter indicated the Flash device that you wish to format. At a minimum, you must format the Flash from which the switch normally boots. This is normally the internal Flash on the Supervisor engine; however, it could also be a PCMCIA Flash card. In this scenario, although Switch-A is currently booted from the slot0: Flash device (i.e., a PCMCIA Flash card), this is only temporary with the intention of Switch-A normally booting from the internal Flash on the Supervisor engine. It is important to understand that in native mode, the MSFC refers to the internal Flash device on the Supervisor engine as sup-bootflash: (as the MSFC already has its own bootflash: internal flash device).

NOTE

It is recommended that all Flash file systems on the switch be formatted so that the switch can both read and write to all file systems.

Example 6-32 demonstrates formatting the onboard Flash file system of the Supervisor module and then verifying that the file system has been formatted.

Example 6-99 Formatting Supervisor Flash from Native Mode

Router# format sup-bootflash:
Format operation may take a while. Continue? [confirm] y
Format operation will destroy all data in "sup-bootflash:".
  Continue? [confirm] y
Formatting sector 1  
Format of sup-bootflash complete
Router# dir sup-bootflash:
Directory of sup-bootflash:/

No files in directory

31981568 bytes total (31981568 bytes free)

In Example 6-32, after the format of the Supervisor internal Flash is complete, the dir command is used to verify that the file system is accessible.

NOTE

If you have an MSFC-2 installed, the native mode image will be larger than 16 MB. This means that your Supervisor Flash must be 32 MB to store the native mode image for the MSFC-2. If the onboard Flash is only 16 MB, you must store the native mode image on a 32-MB PCMCIA card permanently installed into the Supervisor engine.

After formatting the appropriate Flash file system that is used for booting the switch, you must next copy the native mode image to the newly formatted file system so that the switch boots. In this scenario, the Supervisor Flash (sup-bootflash:) is to be used to boot the switch, and the native mode image is currently stored on PCMCIA flash (slot0:). Example 6-33 demonstrates copying the native mode image on slot0: of Switch-A to the sup-bootflash: Flash device.

Example 6-100 Copying Native Mode Image to Onboard Flash

Router# copy slot0:c6sup22-jsv-mz.121-11b.E4 sup-bootflash:
c6sup22-jsv-mz.121-11b.E4
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
21611516 bytes copied in 371.077 secs (58340 bytes/sec)
Router# dir sup-bootflash:
Directory of sup-bootflash:/

  1 -rw-   21611516  July 01 2001 16:15:11 c6sup22-jsv-mz.121-11b.E4
31981568 bytes total (10370052 bytes free)

In Example 6-33, after the copy command is used for copying the native mode image, the dir command is then used to verify the image has been successfully copied to Flash.

NOTE

You can also copy the native mode image via other means such as over the network using TFTP or FTP; however, this requires some configuration of the switch because the switch loads with a blank configuration the first time you boot native IOS. Using the network is required when you have only a single Flash file system to boot the switch from initially (i.e., sup-bootflash:) because you must erase the native mode image when formatting the sup-bootflash: device in this situation.

At this stage, the native mode image is located in the appropriate Flash device, with the switch able to read and write from the file system because it is now formatted for native mode. It is a good idea at this point to also format all other Flash file systems for native mode operation, although you might want to leave this until such time that you are confident that the switch is operating correctly in native mode. If you format all other Flash file systems immediately, you lose the ability to rollback quickly to hybrid mode (you can still rollback; it just takes longer to do).

Set Boot Parameters

Finally, you need to modify the boot parameters so that the switch automatically boots from Flash and boots from the native mode image. At present, the configuration register of the Supervisor engine is set to boot to ROMMON mode, and the boot environment variable is set to the previous CatOS image file.

When working with boot variables in native mode, it is important to understand that just as in hybrid mode, the supervisor engine and MSFC each possess their own bootstrap code and associated boot variables. Although the MSFC controls the switch during normal operation, the switch initially boots from the Supervisor engine first, and then control is handed over to the MSFC. This means that you must ensure you modify the boot variables of both the Supervisor engine and MSFC.

To view the current boot environments on the MSFC, you can use the show bootvar command, as shown in Example 6-34.

Example 6-101 Verifying Boot Parameters on the MSFC in Native Mode

Router# show bootvar
BOOT variable = bootflash:c6MSFC-2-jsv-mz.121-8a.E4,1;
CONFIG_FILE variable does not exist
BOOTLDR variable = bootflash:c6MSFC-2-mz.121-8a.E4
Configuration register is 0x2102

In Example 6-34, the boot variables of the MSFC are actually the old boot variables of the MSFC in hybrid mode. This is quite reasonable because no modification of the MSFC environment variables has so far taken place. Also notice that the configuration register is 0x2102. This is a normal configuration register value that indicates the MSFC should boot normally from flash. The point of Example 6-34 is to show that the MSFC has separate boot environment variables from the Supervisor engine. For example, the configuration register of the Supervisor engine is currently 0x0 (boot to ROMMON mode), which is different from the configuration register on the MSFC.

To ensure both the Supervisor engine and MSFC boot correctly, you can set the boot environment variable from native mode using the boot system global configuration command. When executed, this command not only modifies the boot environment variables on the MSFC, it also modifies the boot environment variables on the Supervisor, as a single file is now used to boot both the Supervisor and MSFC. You must also modify the configuration register on the Supervisor engine so that the switch boots from Flash. This can be achieved by executing the config-register global configuration command in native mode. Example 6-35 demonstrates configuring the switch to boot from the new native mode image.

Example 6-102 Setting Native Mode Boot Parameters

Router# configure terminal
Router(config)# boot system sup-bootflash:c6sup22-jsv-mz.121-11b.E4
Router(config)# end
Router# copy running-config startup-config
Building configuration...
[OK]
Router# show bootvar
BOOT variable = sup-bootflash:c6sup22-jsv-mz.121-11b.E4,1;
CONFIG_FILE variable does not exist
BOOTLDR variable = bootflash:c6MSFC-2-mz.121-8a.E4
Configuration register is 0x2102

In Example 6-35, the boot system global configuration command is used to modify the BOOT environment variable to the native mode image path. The configuration is then saved, which ensures the environment variables are saved permanently. If you are using the MSFC-2 with native mode, the BOOTLDR variable is ignored. This is required only on the MSFC-1.

The configuration of Example 6-35 sets the boot environment variable for both the MSFC and the supervisor engine. To prove this, you can actually access the Supervisor engine switch processor from native mode and then view the boot environment variables for the Supervisor. To access the switch processor and view environment variables, you use the remote login switch command to access the switch processor and then use the show bootvar command to view the current boot parameters for the Supervisor engine itself, as shown in Example 6-36.

Example 6-103 Viewing the Supervisor Engine Boot Environment Variables

Router# remote login switch
Trying Switch ...
Entering CONSOLE for Switch
Type "^C^C^C" to end this session


Switch-sp# show bootvar
BOOT variable = bootflash:c6sup22-jsv-mz.121-11b.E4,12
CONFIG_FILE variable = 
BOOTLDR variable does not exist
Configuration register is 0x0 (will be 0x2102 at next reload)
Switch-sp# exit

[Connection to Switch closed by foreign host]
Router# 

You can see from Example 6-36 that native mode allows you to run Cisco IOS commands (not CatOS commands) from the Supervisor processor (switch processor). You shouldn't need to do this often, as commands executed on the MSFC in native mode are automatically passed to the appropriate switch processor or MSFC processor for handling. In Example 6-34, you need to use the switch processor to read the boot environment variables for the Supervisor engine rather than the MSFC. Notice that the BOOT variable is correctly set. This is because when you modify boot parameters in native mode, both the MSFC and Supervisor boot parameters are updated. The last shaded line indicates that the configuration register value on the Supervisor is 0x0, which means the switch still boots into ROMMON mode. You need to change this to ensure that the switch boots from Flash and loads the native mode image.

NOTE

The remote command switch privileged command can be used to execute commands on the switch processor from native mode, without having to first log in to the switch processor (see Example 6-37 for a demonstration).

To configure the switch to ensure it boots from Flash rather than into ROMMON mode as is currently the case, you can use the config-register global configuration mode command to modify the configuration register on both the MSFC and supervisor engine. Example 6-37 demonstrates modifying the configuration register and then using the remote command switch command to verify the new configuration register value on the Supervisor engine.

Example 6-104 Modifying the Supervisor Engine Configuration Register

Router# configure terminal
Router(config)# config-register 0x2102
Router(config)# end
Router# copy running-config startup-config
Building configuration...
[OK]
Router# remote command switch show bootvar

Switch-sp#
BOOT variable = bootflash:c6sup22-jsv-mz.121-11b.E4,1;
CONFIG_FILE variable = 
BOOTLDR variable does not exist
Configuration register is 0x0 (will be 0x2102 at next reload)

Router# 

In Example 6-37, after the configuration register is modified, the remote command switch command is used to execute the show bootvar command on the switch processor. Notice that the configuration register has been modified so that the Supervisor boots from Flash at the next reload (i.e., 0x2102).

Rebooting the Switch

Congratulations, you have successfully completed upgrading a Catalyst 6000/6500 switch with MSFC to native mode. At this stage, it is a good idea to reboot the switch to verify that the switch does boot automatically into native mode with no problems. After rebooting the switch, you can then configure the switch for native mode operation, which is discussed in the next scenario.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020