2009/05/04

管理Cisco IOS软件

第五章:管理Cisco IOS软件

5.1 路由器的启动顺序和验证
没有Cisco IOS,Cisco路由器就无法运行。每天Cisco路由器都有一个定位和加载IOS的预定义启动顺序。

5.1.1 路由器加电启动顺序的阶段
路由器的初始化是通过加载引导程序(boot-strap)、操作系统和一个配置文件来进行的。如果路由器找不到配置文件,它将进入设置模式。
Cisco IOS软件启动例程的目的是为了启动路由器的所有操作。路由器根据配置连接用户网络时,必须提供可靠的性能。为了达到这个目的,启动例程必须完成以下几个内容:
1. 确定路由器加载了ROM。
2. 找到并加载用于路由器操作系统的Cisco IOS软件映像。
3. 找到并应用包括协议功能和接口地址的配置语句。

更多信息:POST
一个Cisco路由器加电时,执行加电自检(POST)。在自检过程中,路由器执行ROM中的诊断程序,检查所有的硬件模块。这些诊断程序检查CPU、内存和网络接口的基本操作。检验硬件功能后,路由器进行软件初始化。

5.1.2 定位和加载Cisco IOS软件
Cisco IOS软件启动的默认来源取决于硬件平台。但是路由器通常会去查看存放在NVRAM中的boot system命令。
配置寄存器中的设置允许以下这些选择:
• 可以通过指定全局配置模式下的boot system命令,按后退顺序输入路由器所使用的来源。当路由器重启后,它会在必要时按顺序使用这些命令。
• 如果NVRAM总没有设置路由器可用的boot system命令,系统将缺省使用闪存(flash memory)中保存的Cisco IOS软件。
• 如果闪存flash为空,路由器接下来尝试使用TFTP从网络上加载IOS软件映像。此时,路由器使用配置寄存器的值构建一个文件名,该文件名可以用来引导一个存储在网络服务器上的缺省系统映像。
• 如果TFTP服务器无效,路由器将装载存储在ROM下的受限版本的Cisco IOS软件映像。

5.1.3 使用boot system命令
可以输入多个boot system命令来指定引导Cisco IOS软件的后退顺序。下例子中显示的boot system命令指定Cisco IOS软件映像首先从闪存中加载,其次是从网络服务器加载,最后是从ROM加载。
!
boot-start-marker
boot system flash unzip-c2691-advsecurityk9-mz.124-11.T2.bin
boot system tftp IOS-image 10.1.1.1
boot system flash rom
boot-end-marker
!

1,从闪存引导
从闪存引导包括从可电擦除可编程只读存储器EEPROM中加载一个系统映像。优点是存储在闪存中的信息不易受到网络故障的攻击,而那些完了过故障会从TFTP服务器加载系统映像时发生。
Router(config)#boot system flash IOS-image
2,从网络服务器引导
在闪存损坏的情况下,系统映像可以通过指定从TFTP服务器加载的方式提供一个备份。上面例子是指定从IP地址为10.1.1.1的TFTP服务器加载映像文件IOS-image。
3,从ROM引导
如果前两种方法加载系统映像失败,那么从ROM引导是软件中最后一个引导程序选项。但是,ROM中的系统映像是Cisco IOS软件的一个子集,这个子集缺少完整 Cisco IOS软件所拥有的协议、特性和配置。

5.1.4 配置寄存器
路由器加载Cisco IOS软件时,寻找Cisco IOS软件映像的顺序取决于配置寄存器中设置的引导字段。

更改配置寄存器的引导字段:
Router(config)#config-register ?
<0x0-0xffff> Config register number
Router(config)#config-register 0x2102
Router(config)#

配置寄存器的设置是让路由器为引导系统选项检查保存在NVRAM中的启动文件。配置寄存器是NVRAM中的一个16位寄存器。配置寄存器的低四位是引导字段。
0x2100 使用ROM监视器模式
0x2101 根据不同平台自动从ROM引导受限的IOS或启动闪存中第一个映像。
0x2102~0x210f 检查NVRAM中的boot system命令。如果没有,路由器将尝试从闪存中的第一个文件启动。

5.1.5 排除IOS启动故障

如果路由器无法正确启动,可能有几方面出了问题:
• 配置文件丢失或者 boot system语句不对。
• 不正确的配置寄存器值。
• 闪存映像损坏。
• 硬件故障。

路由器启动时,它会在启动配置文件中查找boot system语句。该boot system语句可以强制路由器从其他映像中启动,而不是闪存中的IOS。要识别出启动映像源,输入show version命令并查看标识映像启动源的行:
Router#sh version
Cisco IOS Software, 7200 Software (C7200-ADVIPSERVICESK9-M), Version 12.4(9)T1, RELEASE
SOFTWARE (fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2006 by Cisco Systems, Inc.
Compiled Wed 30-Aug-06 20:48 by prod_rel_team
ROM: ROMMON Emulation Microcode
BOOTLDR: 7200 Software (C7200-ADVIPSERVICESK9-M), Version 12.4(9)T1, RELEASE SOFTWARE (fc2)
Router uptime is 31 minutes
System returned to ROM by unknown reload cause - suspect boot_data[BOOT_COUNT] 0x0,
BOOT_COUNT 0, BOOTDATA 19
System image file is "tftp://255.255.255.255/unknown"

5.2 管理Cisco文件系统
Cisco互联网络设备运行时使用多个不同的文件,包括IOS映像和配置文件。系统网络能平稳可靠运行的网络管理员必须小心地管理这些文件,确保使用合适的版本并执行必需的备份。

5.2.3 使用TFTP管理配置文件
在TFTP服务器上备份启动配置:
Router#copy startup-config tftp:
Address or name of remote host []? 10.1.1.1

5.2.6 使用ROMmon管理IOS映像
如果闪存中的Cisco IOS软件映像已经被删除或者损坏,你也许需要从ROM监视器模式(ROMmon)下恢复 Cisco IOS软件映像。在很多的Cisco硬件系统结构中,ROMmon模式是通过提示符 rommon>来辨认。
这个过程的第一步是确认为什么 Cisco IOS软件映像没有从闪存中加载。这个问题可能是由于映像文件的丢失或损坏,或者闪存损坏造成的。可以通过命令dir flash:检查内存。
如果找到了一个看起来有效的映像,那么尝试从该映像进行引导。可以使用命令boot flash:来执行这个引导尝试。例如:
rommon> boot flash:c2600-is-mz.121-5

如果路由器完全启动了,你需要检查几个条款,因为需要确定为什么路由器启动进入了ROMmon模式,而不是直接使用闪存中的IOS软件。
• 首先,使用show version命令检查配置寄存器值。确保其配置为默认启动顺序。
• 如果配置寄存器值正确,使用show startup-config命令,该命令可以显示是否有一个boot system命令指示路由器使用Cisco IOS软件进入ROMmon。
如果路由器不能很好地从该映像启动,或者根本没有Cisco IOS映像,你需要下载一个新的Cisco IOS软件映像。要恢复 Cisco IOS软件文件,既可以通过控制台使用Xmodem恢复映像,也可以在ROMmon模式下使用TFTP下载映像。

在ROMmon下使用Xmodem下载Cisco IOS软件
恢复 Cisco IOS软件映像时,可以使用9600bitps的缺省控制台速率。你可以将波特率更改到115200bps来加速下载。可以在ROMmon模式下使用confreg命令更改控制台速率。在输入confreg命令之后,路由器将提示一系列可以修改的参数,当提示“change console baud rate? y/n[n]:”时,选择y将提示选择新的速率。在更改了控制台速率之后,重启路由器进入ROMmon模式。9600bps的终端会话被终止,一个新的会话以115200bps开始来匹配控制台速率。
你可以在ROMmon模式下使用xmodem命令从PC恢复 Cisco IOS软件映像。Xmodem命令的格式如下:
rommon>xmodem -c image_file_name
命令格式中的参数-c指示xmodem进程使用CRC检查下载过程中的错误。
现在需要从终端仿真器上开始Xmodem传输。在超级终端中,选择Transfer>Send。然后,在“发送文件”弹出窗口中指定映像文件的名称和位置。选择Xmodem协议,开始传输。
在传输结束后,将显示一个消息表是闪存已经被清除。该消息后紧跟着“Download Complete!”消息。在重新启动路由器之前,需要将控制台速率重新设置回 9600bps,将配置寄存器重新设置回 0x2102。
在重启路由器时,你需要结束 115200bps的终端会话,并开始一个9600bps的会话。

5.2.7 环境变量
也可以从一个TFTP会话恢复 Cisco IOS软件。在ROMmon模式下使用TFTP下载映像是将Cisco IOS软件映像恢复到路由器的一个最快捷的方法。可以通过设置环境变量和使用tftpdnld命令来执行该进程。
因为ROMmon模式的功能有限,在引导过程中没有加载配置文件。因此,路由器没有IP或接口配置。环境变量提供了一个最小化配置来允许从TFTP下载Cisco IOS软件映像。ROMmon模式下的TFTP传输仅仅工作在第一个LAN端口上,所以为该接口设置了一组简单的IP参数。设置一个ROMmon环境变量,你要输入变量名称,然后是等号(=),接着是该变量的值(变量名=值)。例如要设置IP地址为10.1.1.1,可在ROMmon提示符下输入 IP_ADDRESS=10.1.1.1。
注释:所有的环境变量名都是大小写敏感的。
使用tftpdnld所需的最少变量如下:
• IP_ADDRESS
• IP_SUBNET_MASK
• DEFALUT_GATEWAY
• TFTP_SERVER
• TFTP_FILE 服务器上的Cisco IOS软件文件名
要检查ROMmon环境变量,可以使用set命令。
例如:
rommon>set
IP_ADDRESS=10.0.0.1
IP_SUBNET_MASK=255.255.255.0
DEFAULT_GATEWAY=10.0.0.254
TFTP_SERVER=192.168.1.1
TFTP_FILE=GAD/IOS_image/c2600-i-mz.121-5
一旦为Cisco IOS软件的下载设定了变量,就可以输入tftpdnld命令。不带任何参数,ROMmon回显这些变量,随后显示一个确认提示和警告该进程将清除闪存。
当新的映像被写入闪存并且出现 ROMmon提示符后,你可以输入reset命令或 i来重启路由器。此时,路由器将从闪存中的Cisco IOS软件映像引导。

5.2.8 检验文件系统
可以使用几个命令来检验文件系统:
Router#show version
Router#show flash:

2009/05/01

双机双引擎冗余配置这回事

Cisco双机双引擎解析:

双机冗余备份使用的协议有Cisco的HSRP和标准的VRRP,具体配置都很简单。
双引擎配置使用的是RPR和SSO:

4500系列:
Catalyst 4500 series switches allow a redundant supervisor engine to take over if the active supervisor engine fails. In software, supervisor engine redundancy is enabled by running the redundant supervisor engine in route processor redundancy (RPR) or stateful switchover (SSO) operating mode.

With supervisor engine redundancy enabled, if the active supervisor engine fails or if a manual
switchover is performed, the redundant supervisor engine becomes the active supervisor engine. The redundant supervisor engine has been automatically initialized with the startup configuration of the active supervisor engine, shortening the switchover time (30 seconds or longer in RPR mode, depending on the configuration; subseconds in SSO mode).

When power is first applied to a switch, the supervisor engine that boots first becomes the active
supervisor engine and remains active until a switchover occurs.
A switchover will occur when one or more of the following events take place:
1,The active supervisor engine fails (due to either hardware or software function) or is removed.
2,A user forces a switchover.
3,A user reloads the active supervisor engine.

Supervisor Engine Redundancy Guidelines and Restrictions:
1,The Catalyst 4507R switch and the 4510R switch are the only Catalyst 4500 series switches that support supervisor engine redundancy.
2,The Catalyst 4510R switch supports the WS-X4516 supervisor engine only. The Catalyst 4507R supports supervisor engines WS-X4013+, WS-X4515, and WS-X4516.
3,Redundancy requires both supervisor engines in the chassis to be of the same supervisor engine model and to use the same Cisco IOS software image.
4,Router ports are not supported when SSO redundancy mode is configured.
5,When you use the WS-X4013+ and WS-X4515 supervisor engines in RPR or SSO mode, only the Gig1/1 and Gig2/1 Gigabit Ethernet interfaces are available, but the Gig1/2 and Gig2/2 uplink ports are unavailable.
6,When the WS-X4516 active and redundant supervisor engines are installed in the same chassis, the four uplink ports (Gig1/1, Gig2/1, Gig 1/2, and Gig2/2) are available.
7,The active and redundant supervisor engines in the chassis must be in slots 1 and 2.
8,Supervisor engine redundancy does not provide supervisor engine load balancing.
9,The Cisco Express Forwarding (CEF) table is cleared on a switchover. As a result, routed traffic is interrupted until route tables reconverge. This reconvergence time is minimal because the SSO feature reduces the supervisor engine redundancy switchover time from 30+ seconds to subseconds, so Layer 3 also has a faster failover time if the switch is configured for SSO.
10,Static IP routes are maintained across a switchover because they are configured from entries in the configuration file.
11,Information about Layer 3 dynamic states that is maintained on the active supervisor engine is not synchronized to the redundant supervisor engine and is lost on switchover.
12,If you are running (or upgrading to) Release 12.2(20)EWA or Release 12.2(25)EW and are using a single supervisor engine in a redundant chassis (Catalyst 4507R or Catalyst 4510R series switch), and you intend to use routed ports, do one of the following:
-Use SVI’s instead of routed ports.
-Change the redundancy mode from SSO to RPR.

Configuring Supervisor Engine Redundancy:

Switch(config)# redundancy
Switch(config-red)# mode {sso rpr}
Switch# show running-config
Switch# show redundancy [clients counters history states]

Switch(config-red)# mode {sso rpr}--->Configures SSO or RPR. When this command is entered, the redundant supervisor engine is reloaded and begins to work in SSO or RPR mode.


Switch> enable
Switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# redundancy
Switch(config-red)# mode sso
Switch(config-red)# end
Switch# show redundancy

This example shows how to display redundancy facility state information:
Switch# show redundancy states

Synchronizing the Supervisor Engine Configurations:

Switch(config)# redundancy
Switch(config-red)# main-cpu ---Enters main-cpu configuration submode.
Switch(config-r-mc)# auto-sync {startup-config config-register bootvar standard}
Switch(config-r-mc)# end
Switch# copy running-config startup-config

In SSO mode, the running-config is always synchronized.

This example shows how to reenable the default automatic synchronization feature using the auto-sync standard command to synchronize the startup-config and config-register configuration of the active supervisor engine with the redundant supervisor engine. Updates for the boot variables are automatic and cannot be disabled.
Switch(config)# redundancy
Switch(config-red)# main-cpu
Switch(config-r-mc)# [no] auto-sync standard
Switch(config-r-mc)# end
Switch# copy running-config startup-config

Performing a Manual Switchover: 手动切换引擎
Switch# show redundancy
Switch# redundancy force-switchover

Be aware of these usage guidelines:
1,To force a switchover, the redundant supervisor engine must be in a standby hot state. You can verify the state with the show redundancy command. If the state is not standby hot, the
redundancy force-switchover command will not execute.
2,Use the redundancy force-switchover command, rather than the reload command, to initiate a switchover. The redundancy force-switchover command will first check that the redundant
supervisor engine is in the correct state. If you issue the reload command and the status is not
standby hot, the reload command will reset the current supervisor engine only.

6500系列: Supervisor Engine 720

The redundant supervisor engines must be the same type with the same model PFC and MSFC.

During the startup of the standby MSFC, image version information is exchanged between MSFCs and one of the following occurs:
1,If the image version information matches and both MSFCs are configured as SSO or have the default (SSO) configuration, the system runs in SSO mode.
2,If the image version information does not match or if one of the MSFCs is configured for route processor redundancy (RPR), the system runs in RPR mode.

In NSF/SSO mode, one MSFC is active and the other MSFC is in a hot-standby mode. The hot-standby MSFC maintains a constant readiness state by receiving state information from the active MSFC. At any given moment, the standby MSFC may be called on by the supervisor engine to take over the responsibilities held by the active MSFC. The supervisor engine monitors the active MSFC and if the MSFC does not respond, the supervisor engine declares the MSFC as lost or down and proceeds to reset the MSFC. The standby MSFC has the up-to-date state information necessary to resume processing (the standby MSFC is fully initialized, but the VLANs are kept in an administrative down state until a switchover occurs).

With NSF, the switching modules and switch fabric continue to forward packets while the MSFC switchover is in progress.


Note :
High availability on the supervisor engine operates independent of the MSFC high-availability feature. However, you must enable high availability on the supervisor engine must be enabled to ensure the correct operation of the MSFC SSO feature.
If you run the MSFC in SSO mode and fail to run the high-availability feature on the supervisor engine, any switchover that may occur will result in a nonstateful switchover and the standby MSFC will reset itself and reload at the time of the switchover. This reset/reload of the standby MSFC occurs because there is insufficient state information on the supervisor engine to support a stateful switchover of the MSFC. This reset/reload of the standby MSFC interrupts service.

RPR is a cold standby mode. When a switchover occurs, the standby MSFC must go completely through its initialization. RPR mode is used primarily for the fast software upgrade (FSU). In RPR mode, the startup configuration is synchronized to the standby MSFC, however, it is not processed in any way until the switchover occurs. The running configuration is not synchronized to the standby MSFC.

When the active MSFC boots completely, no state information is exchanged between the MSFCs. If the active MSFC fails, the standby MSFC processes its startup configuration file and begins its initialization.

If there is an image compatibility problem, the active MSFC boots fully, but the standby MSFC suspends its startup before processing the startup configuration file. If the active MSFC fails, a switchover is triggered and the suspended standby MSFC begins to initialize and become the active MSFC.

Configuration Guidelines and Restrictions :
1, During a switchover, there will be traffic loss for traffic that is routed by the MSFC. NSF only applies to traffic that is hardware switched by modules and the switch fabric. New flows are not allowed until the switchover is complete.
2, In cases where the MSFC has failed and is unable to notify the supervisor engine of the failure, the supervisor engine may take 30 to 40 seconds before it realizes that the MSFC has failed and a switchover is triggered. If the supervisor engine receives the failure notification, the switchover is triggered immediately.
3, The Frame Relay, ATM, and PPP protocols that are not supported in SSO mode.
4, Standby supervisor engine/MSFC insertion—With NSF/SSO redundancy, you can hot swap the standby supervisor engine/MSFC for maintenance. When you hot insert the standby MSFC, the active MSFC detects the presence of the standby MSFC and starts to drive the standby MSFC state transition to hot-standby. When you remove the standby MSFC, the synchronization between the active and standby MSFC is stopped, any pending updates to the standby MSFC are discarded, and the system enters simplex mode. The standby MSFC state is displayed by entering the show redundancy states command.

Configuring SSO

SSO is the default mode. By default, even if you do not configure the system explicitly as SSO, the system comes up in SSO mode. However, we recommend that you explicitly configure SSO mode.
Router(config)# redundancy
Router(config-red)# mode sso
Router(config-red)# end
Router# show redundancy states


Configuring CEF NSF
CEF NSF operates by default while the networking device is running in SSO mode. No configuration is necessary.

This example shows how to verify that CEF is NSF-capable:
router# show cef state

以下是《学习指南》中的摘抄:

因为仅当主组件出现故障时,他们才会激活,所以设备内的冗余子系统通常是以热备用模式维护的,它们不能提供性能。然而在高端和未来的Catalyst交换中,可以通过合适的配置克服这种缺点。

组件高可用性网络的一种折衷方法是:通过在网络拓扑中提供冗余,而不仅仅是在网络设备中提供冗余,来确保可靠性。

NSF(SSO)在Catalyst 4500和Catalyst 6500系列交换机中提供最高级别的可用性。

在Supervisor Engine发生切换之后,RPR和PRP+将在大约1分钟之内恢复交换机的流量转发。在SSO模式中,冗余Supervisor Engine以完全初始化状态进行启动,并且与活跃Supervisor Engine的启动配置和运行配置进行同步。对于SSO支持特性的软硬件状态发生变化的情况,备用Supervisor Engine (SSO模式)将与活跃Supervisor Engine保持同步。如果活跃Supervisor Engine上的SSO支持特性发生中断的情况,那么将无缝地切换到冗余Supervisor Engine。

SSO模式因为没有发生链路状态变更的情况,所以也就不会发生生成树拓扑的变更。

对于Catalyst 6500系列交换机,在Supervisor发生故障之后,第2层流量将在0~3s之内恢复正常工作状态。当SSO结合SRM(Single Router Mode单路由器模式),在发生Supervisor Engine切换之后,第2层和第3层流量将几乎不存在中断。

Catalyst 6500 系列交换机中使用单路由器模式的路由器冗余:
虽然在任何时候都只有一个Supervisor Engine处于活跃状态,而另一个Supervisor Engine处于冗余状态,但默认情况下,两个Supervisor Engine中的MSFC都处于活跃状态。
在典型的网络中,设计中包含冗余路径,使用两台交换机来提供机箱冗余。这样将有4台活跃路由器,难以诊断网络故障。Cisco引入了单路由器模式SRM冗余,用于替代内部冗余(双)MSFC配置(在这种配置下,两个MSFC同时处于活跃状态),从而将活跃路由器从4台减少到2台。

配置SRM:
1, 在指定路由器上启用SRM,然后在非指定路由器上启用SRM,如下所示。
MSFC_1(config)#redundancy
MSFC_1(config-r)#high-availability
MSFC_1(config-r-ha)#single-router-mode
MSFC_2(config)#redundancy
MSFC_2(config-r)#high-availability
MSFC_2(config-r-ha)#single-router-mode
2,通过在指定路由器上使用命令wr,将可以把运行配置保存到启动配置中,同时确保非指定路由器的启动配置也包含这些SRM命令。
3,重新启动非指定路由器。当系统提示时候保存配置时,输入no。如下所示:
MSFC_2#reload
System configuration has been modified. Save? [yes/no]: no
Proceed with reload?[confirm]
4,非指定路由器启动后将进入备用状态。
验证:show redundancy


经典案例:
请教6509+双720引擎该如何配置?
模块状态:
show module all
Mod Ports Card Type Model Serial No.
--- ----- -------------------------------------- ------------------ -----------
1 6 Firewall Module WS-SVC-FWM-1 SAD122300FB
2 48 48-port 10/100/1000 RJ45 EtherModule WS-X6148A-GE-TX SAL1226UW54
3 24 CEF720 24 port 1000mb SFP WS-X6724-SFP SAL1226VBVP
5 2 Supervisor Engine 720 (Active) WS-SUP720-3B SAL1226UYHE
6 2 Supervisor Engine 720 (Cold) WS-SUP720-3B SAL1230Y9ZJ
Mod MAC addresses Hw Fw Sw Status
--- ---------------------------------- ------ ------------ ------------ -------
1 0021.5517.aecc to 0021.5517.aed3 4.2 7.2(1) 2.3(4) Ok
2 001d.70c5.e380 to 001d.70c5.e3af 1.6 8.4(1) 8.7(0.22)H2A Ok
3 0021.d874.4eb0 to 0021.d874.4ec7 3.1 12.2(18r)S1 12.2(33)SXH2 Ok
5 001c.58d0.b098 to 001c.58d0.b09b 5.6 8.5(2) 12.2(33)SXH2 Ok
6 0016.9de6.ab68 to 0016.9de6.ab6b 5.6 8.5(2) 12.2(18)SXF1 Ok
Mod Sub-Module Model Serial Hw Status
---- --------------------------- ------------------ ----------- ------- -------
3 Centralized Forwarding Card WS-F6700-CFC SAL1226V63Q 4.1 Ok
5 Policy Feature Card 3 WS-F6K-PFC3B SAL1225UERJ 2.3 Ok
5 MSFC3 Daughterboard WS-SUP720 SAL1226UWA7 3.1 Ok
6 Policy Feature Card 3 WS-F6K-PFC3B SAL1230YE06 2.3 Ok
6 MSFC3 Daughterboard WS-SUP720 SAL1230YD9R 3.1 Ok

Mod Online Diag Status
---- -------------------
1 Pass
2 Pass
3 Pass
5 Pass
6 Pass

相关配置:
#show run begin redu
redundancy
keepalive-enable
mode sso
main-cpu
auto-sync running-config

出现的问题是将主引擎复位测试了一下,第二个引擎好像是需要很长的时间才能切换过来。正常情况下SSO模式1-2秒就可以切换。

请问:该配置那些内容才能实现引擎的快速冗余切换?出现上述切换时间过长的原因是什么?

解决:因为两块引擎里灌的IOS版本不一致。虽然你配置了SSO,但是交换机检测两块引擎IOS版本不一致,自动变为RPR模式,这个cold一般只在RPR模式中出现。