第五章：管理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/04
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模式中出现。
双机冗余备份使用的协议有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模式中出现。
2009/04/27
华为系列交换机VRRP双机冗余配置
基于 IPv4 的 VRRP 典型配置举例：
一： VRRP 单备份组配置举例
组网需求
1，Host需要访问 Internet，Host的缺省网关为202.38.160.111/24；
2，Switch A 和 Switch B 属于虚拟 IP 地址为 202.38.160.111/24 的备份组 1；
3，当 Switch A 正常工作时，Host A 发送给 Host B 的报文通过 Switch A 转发；
当 Switch A 出现故障时，Host A 发送给 Host B 的报文通过 Switch B 转发。
配置步骤：
(1) 配置 Switch A
# 配置 VLAN2。
system-view
[SwitchA] vlan 2
[SwitchA-vlan2] port GigabitEthernet 2/0/5
[SwitchA-vlan2] quit
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 202.38.160.1 255.255.255.0
# 创建备份组 1，并配置备份组 1 的虚拟 IP 地址为 202.38.160.111。
[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111
# 设置 Switch A 在备份组 1 中的优先级为 110。默认优先级为100。
[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110
# 设置 Switch A 工作在抢占方式，抢占延迟时间为 5 秒。
[SwitchA-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5
(2) 配置 Switch B
# 配置 VLAN2。
system-view
[SwitchB] vlan 2
[SwitchB-Vlan2] port GigabitEthernet 2/0/5
[SwitchB-vlan2] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ip address 202.38.160.2 255.255.255.0
# 创建备份组 1，并配置备份组 1 的虚拟 IP 地址为 202.38.160.111。
[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111
# 设置 Switch B 工作在抢占方式，抢占延迟时间为 5 秒。
[SwitchB-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5
(3) 验证配置结果
配置完成后，在 Host A 上可以 ping 通 Host B。通过 display vrrp verbose 命令查看配置后的结果。
# 显示 Switch A 上备份组 1 的详细信息。
[SwitchA-Vlan-interface2] display vrrp verbose
VRRP 监视接口配置举例：
当 Switch A 连接 Internet 的 VLAN 接口 3 不可用时，Host A 发送给 Host B 的报文通过 Switch B 转发。
# 设置备份组的认证方式为 SIMPLE 认证，认证字为 hello。
[SwitchA-Vlan-interface2] vrrp vrid 1 authentication-mode simple hello
# 设置 Master 发送 VRRP 报文的间隔时间为 5 秒。
[SwitchA-Vlan-interface2] vrrp vrid 1 timer advertise 5
# 设置监视接口。
[SwitchA-Vlan-interface2] vrrp vrid 1 track interface vlan-interface 3 reduced 30
VRRP 多备份组配置举例：
组网需求
1，202.38.160.0/24 网段内部分主机的缺省网关为 202.38.160.111/24，部分主机的缺省网关为 202.38.160.112/24；
2，利用 VRRP 备份组实现缺省网关间的负载分担和相互备份。
配置 Switch A
# 配置 VLAN2。
system-view
[SwitchA] vlan 2
[SwitchA-vlan2] port GigabitEthernet 2/0/5
[SwitchA-vlan2] quit
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 202.38.160.1 255.255.255.0
# 创建备份组 1，并配置备份组 1 的虚拟 IP 地址为 202.38.160.111。
[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111
# 设置 Switch A 在备份组 1 中的优先级为 110。
[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110
# 创建备份组 2，并配置备份组 2 的虚拟 IP 地址为 202.38.160.112。
[SwitchA-Vlan-interface2] vrrp vrid 2 virtual-ip 202.38.160.112
配置 Switch B
# 配置 VLAN2。
system-view
[SwitchB] vlan 2
[SwitchB-vlan2] port GigabitEthernet 2/0/5
[SwitchB-vlan2] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ip address 202.38.160.2 255.255.255.0
# 创建备份组 1，并配置备份组 1 的虚拟 IP 地址为 202.38.160.111。
[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111
# 创建备份组 2，并配置备份组 2 的虚拟 IP 地址为 202.38.160.112。
[SwitchB-Vlan-interface2] vrrp vrid 2 virtual-ip 202.38.160.112
# 设置 Switch B 在备份组 2 中的优先级为 110。
[SwitchB-Vlan-interface2] vrrp vrid 2 priority 110
验证配置结果
可以通过 display vrrp 命令查看配置后的结果。
# 显示 Switch A 上备份组的详细信息。
[SwitchA-Vlan-interface2] display vrrp verbose
VRRP 常见错误配置举例：
一：控制台上频频出现配置错误的提示
原因分析：
1，可能是备份组内的另一台交换机配置不一致造成的。
2，可能是有的机器试图发送非法的 VRRP 报文。
解决方法：
1，对于第一种情况，可以通过修改配置来解决。
2，对于第二种情况，则是有些机器有不良企图，应当通过非技术手段来解决。
二：同一个备份组内出现多个 Master 交换机
原因分析：
1，若短时间内存在多个Master 交换机，属于正常情况，无需进行人工干预。
2，若多个Master 交换机长时间共存，这很有可能是由于Master 交换机之间收不到VRRP报文，或者收到的报文不合法造成的。
解决方法：先在多个Master 交换机之间执行ping 操作。如果ping 不通，则检查网络连接是否正确；如果能ping 通，则检查VRRP 的配置是否一致。对于同一个VRRP 备份组的配置，必须要保证虚拟IP 地址个数、每个虚拟IP 地址、通告报文的发送时间间隔和认证方式完全一样。
三：VRRP 的状态频繁转换
原因分析：这种情况一般是由于 VRRP 通告报文发送时间间隔太短造成的。
解决方法：增加通告报文的发送时间间隔或者设置抢占延迟都可以解决这种故障。
一： VRRP 单备份组配置举例
组网需求
1，Host需要访问 Internet，Host的缺省网关为202.38.160.111/24；
2，Switch A 和 Switch B 属于虚拟 IP 地址为 202.38.160.111/24 的备份组 1；
3，当 Switch A 正常工作时，Host A 发送给 Host B 的报文通过 Switch A 转发；
当 Switch A 出现故障时，Host A 发送给 Host B 的报文通过 Switch B 转发。
配置步骤：
(1) 配置 Switch A
# 配置 VLAN2。
[SwitchA] vlan 2
[SwitchA-vlan2] port GigabitEthernet 2/0/5
[SwitchA-vlan2] quit
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 202.38.160.1 255.255.255.0
# 创建备份组 1，并配置备份组 1 的虚拟 IP 地址为 202.38.160.111。
[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111
# 设置 Switch A 在备份组 1 中的优先级为 110。默认优先级为100。
[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110
# 设置 Switch A 工作在抢占方式，抢占延迟时间为 5 秒。
[SwitchA-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5
(2) 配置 Switch B
# 配置 VLAN2。
[SwitchB] vlan 2
[SwitchB-Vlan2] port GigabitEthernet 2/0/5
[SwitchB-vlan2] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ip address 202.38.160.2 255.255.255.0
# 创建备份组 1，并配置备份组 1 的虚拟 IP 地址为 202.38.160.111。
[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111
# 设置 Switch B 工作在抢占方式，抢占延迟时间为 5 秒。
[SwitchB-Vlan-interface2] vrrp vrid 1 preempt-mode timer delay 5
(3) 验证配置结果
配置完成后，在 Host A 上可以 ping 通 Host B。通过 display vrrp verbose 命令查看配置后的结果。
# 显示 Switch A 上备份组 1 的详细信息。
[SwitchA-Vlan-interface2] display vrrp verbose
VRRP 监视接口配置举例：
当 Switch A 连接 Internet 的 VLAN 接口 3 不可用时，Host A 发送给 Host B 的报文通过 Switch B 转发。
# 设置备份组的认证方式为 SIMPLE 认证，认证字为 hello。
[SwitchA-Vlan-interface2] vrrp vrid 1 authentication-mode simple hello
# 设置 Master 发送 VRRP 报文的间隔时间为 5 秒。
[SwitchA-Vlan-interface2] vrrp vrid 1 timer advertise 5
# 设置监视接口。
[SwitchA-Vlan-interface2] vrrp vrid 1 track interface vlan-interface 3 reduced 30
VRRP 多备份组配置举例：
组网需求
1，202.38.160.0/24 网段内部分主机的缺省网关为 202.38.160.111/24，部分主机的缺省网关为 202.38.160.112/24；
2，利用 VRRP 备份组实现缺省网关间的负载分担和相互备份。
配置 Switch A
# 配置 VLAN2。
[SwitchA] vlan 2
[SwitchA-vlan2] port GigabitEthernet 2/0/5
[SwitchA-vlan2] quit
[SwitchA] interface vlan-interface 2
[SwitchA-Vlan-interface2] ip address 202.38.160.1 255.255.255.0
# 创建备份组 1，并配置备份组 1 的虚拟 IP 地址为 202.38.160.111。
[SwitchA-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111
# 设置 Switch A 在备份组 1 中的优先级为 110。
[SwitchA-Vlan-interface2] vrrp vrid 1 priority 110
# 创建备份组 2，并配置备份组 2 的虚拟 IP 地址为 202.38.160.112。
[SwitchA-Vlan-interface2] vrrp vrid 2 virtual-ip 202.38.160.112
配置 Switch B
# 配置 VLAN2。
[SwitchB] vlan 2
[SwitchB-vlan2] port GigabitEthernet 2/0/5
[SwitchB-vlan2] quit
[SwitchB] interface vlan-interface 2
[SwitchB-Vlan-interface2] ip address 202.38.160.2 255.255.255.0
# 创建备份组 1，并配置备份组 1 的虚拟 IP 地址为 202.38.160.111。
[SwitchB-Vlan-interface2] vrrp vrid 1 virtual-ip 202.38.160.111
# 创建备份组 2，并配置备份组 2 的虚拟 IP 地址为 202.38.160.112。
[SwitchB-Vlan-interface2] vrrp vrid 2 virtual-ip 202.38.160.112
# 设置 Switch B 在备份组 2 中的优先级为 110。
[SwitchB-Vlan-interface2] vrrp vrid 2 priority 110
验证配置结果
可以通过 display vrrp 命令查看配置后的结果。
# 显示 Switch A 上备份组的详细信息。
[SwitchA-Vlan-interface2] display vrrp verbose
VRRP 常见错误配置举例：
一：控制台上频频出现配置错误的提示
原因分析：
1，可能是备份组内的另一台交换机配置不一致造成的。
2，可能是有的机器试图发送非法的 VRRP 报文。
解决方法：
1，对于第一种情况，可以通过修改配置来解决。
2，对于第二种情况，则是有些机器有不良企图，应当通过非技术手段来解决。
二：同一个备份组内出现多个 Master 交换机
原因分析：
1，若短时间内存在多个Master 交换机，属于正常情况，无需进行人工干预。
2，若多个Master 交换机长时间共存，这很有可能是由于Master 交换机之间收不到VRRP报文，或者收到的报文不合法造成的。
解决方法：先在多个Master 交换机之间执行ping 操作。如果ping 不通，则检查网络连接是否正确；如果能ping 通，则检查VRRP 的配置是否一致。对于同一个VRRP 备份组的配置，必须要保证虚拟IP 地址个数、每个虚拟IP 地址、通告报文的发送时间间隔和认证方式完全一样。
三：VRRP 的状态频繁转换
原因分析：这种情况一般是由于 VRRP 通告报文发送时间间隔太短造成的。
解决方法：增加通告报文的发送时间间隔或者设置抢占延迟都可以解决这种故障。
转: VLAN划分，GVRP还是VTP
GVRP协议简介
GVRP是GARP的一种应用，它基于GARP的工作机制，维护交换机中的VLSN动态注册信息，并传播该信息到其它的交换机中。所有支持GVRP特性的交换机能够接收来自其它交换机的VLAN信息，并动态更新本地的VLAN注册信息，包括当前的VLAN成员、这些VLAN成员可以通过哪个端口到达等。而且所支持GVRP特性的交换机能够将本地的VLAN注册注册信息向其它交换机传播，以使同一交换网内所有支持GVRP特性的设备的VLAN信息达成一致。GVRP传播的VLAN注册信息既包括本地手工配置的静态注册信息，也包括来自其它交换机的动态注册信息。
VTP协议简介
VTP的功能与GVRP相似，也是用来使VLAN配置信息在交换网内其它交换机上进行动态注册的一种二层协议。在一台VTPServer上配置一个新的VLAN信息，则该信息将自动传播到本域内的所有交换机，从而减少在多台设备上配置同一信息的工作量，且方便了管理。VTP信息只能在Trunk端口上传播。
GVRP和VTP两个协议有何异同点
相同点：
二者都是对跨以太网交换机的VLAN进行动态注册和删除的二层协议，交换机之间的协议报文交互都必须在VLANTrunk链路上进行。
不同点：
a、GVRP是IEEE制定的基于GARP的协议；而VTP是CISCO公司开发的私有协议，目前华为等交换机也支持VTP协议；
b、GVRP协议就是通过属性的声明－注册机制将本地的VLAN信息通告给其他交换机；而VTP协议是通过检查通告报文中的配置版本号信息，版本号低的交换机向版本号高的交换机进行学习，从而实现VLAN信息的共享；
c、支持VLAN数目不同，GVRP协议所支持的VLANID范围为1-4094，而VTP协议只支持1-1001号的VLAN。
GVRP和VTP两个协议在实践中的应用比较
在具体应用上，VTP支持的是服务器－客户端模式，即在主交换机建立VTP域，并将主交换机设置成VTPServer，然后在分交换机设置为VTPClient，这样只需在主交换机上建立VLAN，就会通知到局域网中的任何一台交换机，这样便于集中管理。
GVRP相对繁琐些，它需要在每一台交换机上建立VLAN，并且在每一个交换机（无论是主交换机还是分交换机）首先全局运行gvrp命令，开启gvrp功能，然后在干道汇聚连接上运行gvrp命令，开启GVRP功能，这样才会将本交换机上建立的VLAN通知注册到局域网中的其它交换机上。
由此可见，GVRP是IEEE制定的基于GVRP的协议，VTP是厂家开发的协议，因此GVRP的适用面比较宽泛，但VTP的设置要便捷些，并且有利于设备的集中管理，在VLAN的划分中得到广泛应用。但由于VTP模式本质上是把在核心交换机上划分的VLAN复制到局域网中的所有分交换机上，这样整个网络中的VLAN广播还是会在汇聚连接上传播，会加重核心交换机的负担。GVRP本质上是在各交换机上分别划分VLAN，并且通过GVRP裁减机制限制不必要的VLAN广播，使得主交换机和分交换机的VLAN广播相对均衡，减少了主交换机的CPU占用率，因此在大型网络中GVRP有较好的表现。
现在的交换机在支持GVRP协议的同时，一般也都支持VTP协议，但是要记住这两个协议可不允许同时开启的。
GVRP是GARP的一种应用，它基于GARP的工作机制，维护交换机中的VLSN动态注册信息，并传播该信息到其它的交换机中。所有支持GVRP特性的交换机能够接收来自其它交换机的VLAN信息，并动态更新本地的VLAN注册信息，包括当前的VLAN成员、这些VLAN成员可以通过哪个端口到达等。而且所支持GVRP特性的交换机能够将本地的VLAN注册注册信息向其它交换机传播，以使同一交换网内所有支持GVRP特性的设备的VLAN信息达成一致。GVRP传播的VLAN注册信息既包括本地手工配置的静态注册信息，也包括来自其它交换机的动态注册信息。
VTP协议简介
VTP的功能与GVRP相似，也是用来使VLAN配置信息在交换网内其它交换机上进行动态注册的一种二层协议。在一台VTPServer上配置一个新的VLAN信息，则该信息将自动传播到本域内的所有交换机，从而减少在多台设备上配置同一信息的工作量，且方便了管理。VTP信息只能在Trunk端口上传播。
GVRP和VTP两个协议有何异同点
相同点：
二者都是对跨以太网交换机的VLAN进行动态注册和删除的二层协议，交换机之间的协议报文交互都必须在VLANTrunk链路上进行。
不同点：
a、GVRP是IEEE制定的基于GARP的协议；而VTP是CISCO公司开发的私有协议，目前华为等交换机也支持VTP协议；
b、GVRP协议就是通过属性的声明－注册机制将本地的VLAN信息通告给其他交换机；而VTP协议是通过检查通告报文中的配置版本号信息，版本号低的交换机向版本号高的交换机进行学习，从而实现VLAN信息的共享；
c、支持VLAN数目不同，GVRP协议所支持的VLANID范围为1-4094，而VTP协议只支持1-1001号的VLAN。
GVRP和VTP两个协议在实践中的应用比较
在具体应用上，VTP支持的是服务器－客户端模式，即在主交换机建立VTP域，并将主交换机设置成VTPServer，然后在分交换机设置为VTPClient，这样只需在主交换机上建立VLAN，就会通知到局域网中的任何一台交换机，这样便于集中管理。
GVRP相对繁琐些，它需要在每一台交换机上建立VLAN，并且在每一个交换机（无论是主交换机还是分交换机）首先全局运行gvrp命令，开启gvrp功能，然后在干道汇聚连接上运行gvrp命令，开启GVRP功能，这样才会将本交换机上建立的VLAN通知注册到局域网中的其它交换机上。
由此可见，GVRP是IEEE制定的基于GVRP的协议，VTP是厂家开发的协议，因此GVRP的适用面比较宽泛，但VTP的设置要便捷些，并且有利于设备的集中管理，在VLAN的划分中得到广泛应用。但由于VTP模式本质上是把在核心交换机上划分的VLAN复制到局域网中的所有分交换机上，这样整个网络中的VLAN广播还是会在汇聚连接上传播，会加重核心交换机的负担。GVRP本质上是在各交换机上分别划分VLAN，并且通过GVRP裁减机制限制不必要的VLAN广播，使得主交换机和分交换机的VLAN广播相对均衡，减少了主交换机的CPU占用率，因此在大型网络中GVRP有较好的表现。
现在的交换机在支持GVRP协议的同时，一般也都支持VTP协议，但是要记住这两个协议可不允许同时开启的。
2009/04/06
三向重发布路由缺失：只是特例情况的
三向重发布路由缺失：
-lo1(RIP)
R1--OSPF--R2--EIGRP--R3
----->
<-----
第一步： RIP--->OSPF
R2(config-router)#redistribute rip subnets
R1上有路由：
O E2 22.22.22.0 [110/20] via 12.1.1.2, 00:00:08, Serial1/1
而R3上没有
--->结论是，单点三向重发布，重发布路由作用只在相关的两个路由协议之间，不会再重发布给另一个协议。即，RIP重发布给OSPF的路由条目，OSPF不会再将这些条目重发布给EIGRP。
所以需要手动将RIP路由重发布到EIGRP中，需要执行重发布RIP两次。
R2(config-router)#redistribute rip metric 10000 255 100 1 255
R3上就会有：
D EX 22.22.22.0 [170/2235136] via 23.1.1.2, 00:00:08, Serial1/0
第二步：R2上
OSPF<----->EIGRP双向单点重发布
!
router eigrp 90
redistribute ospf 110 metric 10000 255 100 1 1500
redistribute rip metric 10000 255 100 1 255
network 2.2.2.2 0.0.0.0
network 23.1.1.2 0.0.0.0
no auto-summary
!
router ospf 110
router-id 2.2.2.2
log-adjacency-changes
redistribute eigrp 90 subnets
redistribute rip subnets
network 2.2.2.2 0.0.0.0 area 0
network 12.1.1.2 0.0.0.0 area 0
!
router rip
version 2
network 22.0.0.0
no auto-summary
!
第三步：比较三个路由器上的路由条目，都是6条路由。配置正确。
特殊情况：在重发布时使用route-map指定重发布的条目，而使用route-map是在重发布时推荐的做法。
!
router eigrp 90
redistribute connected route-map RIP2EIGRP
!
!
route-map RIP2EIGRP permit 10
match interface Loopback1
!
这样就会在R3上出现路由缺失的情况，因为route-map默认最后是deny any的，所有在redistribute connected route-map的情况下，只是重发布了route-map允许的路由，例如是lo1的路由，而redistribute connected会优于redistribute ospf，所以连R2直连的12.1.1.0网段路由都屏蔽了。如下：
R3#sh ip route
1.0.0.0/32 is subnetted, 1 subnets
D EX 1.1.1.1 [170/2235136] via 23.1.1.2, 00:01:43, Serial1/0
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/2297856] via 23.1.1.2, 00:01:43, Serial1/0
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback0
23.0.0.0/24 is subnetted, 1 subnets
C 23.1.1.0 is directly connected, Serial1/0
22.0.0.0/24 is subnetted, 1 subnets
D EX 22.22.22.0 [170/2297856] via 23.1.1.2, 00:00:49, Serial1/0
实验做到这里，感觉好像是因为自己在重发布的时候画蛇添足了，为何要这样人为地制造麻烦呢，直接redistribute rip route-map 不就行了。。。但是如果在以后需要用到重发布直连redistribute connected route-map，那么可能这些考虑就用到了。。。
这种情况原因：route-map匹配考虑不周全。
解决办法：
R2(config)#route-map RIP2EIGRP permit 20
R2(config-route-map)#end
R2#
R3#sh ip route
1.0.0.0/32 is subnetted, 1 subnets
D EX 1.1.1.1 [170/2235136] via 23.1.1.2, 00:12:59, Serial1/0
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/2297856] via 23.1.1.2, 00:12:59, Serial1/0
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback0
23.0.0.0/24 is subnetted, 1 subnets
C 23.1.1.0 is directly connected, Serial1/0
22.0.0.0/24 is subnetted, 1 subnets
D EX 22.22.22.0 [170/2297856] via 23.1.1.2, 00:12:05, Serial1/0
12.0.0.0/24 is subnetted, 1 subnets
D EX 12.1.1.0 [170/2681856] via 23.1.1.2, 00:00:06, Serial1/0
同样在RIP直连重发布到OSPF中如果使用route-map的时候也要考虑这些情况。
-lo1(RIP)
R1--OSPF--R2--EIGRP--R3
----->
<-----
第一步： RIP--->OSPF
R2(config-router)#redistribute rip subnets
R1上有路由：
O E2 22.22.22.0 [110/20] via 12.1.1.2, 00:00:08, Serial1/1
而R3上没有
--->结论是，单点三向重发布，重发布路由作用只在相关的两个路由协议之间，不会再重发布给另一个协议。即，RIP重发布给OSPF的路由条目，OSPF不会再将这些条目重发布给EIGRP。
所以需要手动将RIP路由重发布到EIGRP中，需要执行重发布RIP两次。
R2(config-router)#redistribute rip metric 10000 255 100 1 255
R3上就会有：
D EX 22.22.22.0 [170/2235136] via 23.1.1.2, 00:00:08, Serial1/0
第二步：R2上
OSPF<----->EIGRP双向单点重发布
!
router eigrp 90
redistribute ospf 110 metric 10000 255 100 1 1500
redistribute rip metric 10000 255 100 1 255
network 2.2.2.2 0.0.0.0
network 23.1.1.2 0.0.0.0
no auto-summary
!
router ospf 110
router-id 2.2.2.2
log-adjacency-changes
redistribute eigrp 90 subnets
redistribute rip subnets
network 2.2.2.2 0.0.0.0 area 0
network 12.1.1.2 0.0.0.0 area 0
!
router rip
version 2
network 22.0.0.0
no auto-summary
!
第三步：比较三个路由器上的路由条目，都是6条路由。配置正确。
特殊情况：在重发布时使用route-map指定重发布的条目，而使用route-map是在重发布时推荐的做法。
!
router eigrp 90
redistribute connected route-map RIP2EIGRP
!
!
route-map RIP2EIGRP permit 10
match interface Loopback1
!
这样就会在R3上出现路由缺失的情况，因为route-map默认最后是deny any的，所有在redistribute connected route-map的情况下，只是重发布了route-map允许的路由，例如是lo1的路由，而redistribute connected会优于redistribute ospf，所以连R2直连的12.1.1.0网段路由都屏蔽了。如下：
R3#sh ip route
1.0.0.0/32 is subnetted, 1 subnets
D EX 1.1.1.1 [170/2235136] via 23.1.1.2, 00:01:43, Serial1/0
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/2297856] via 23.1.1.2, 00:01:43, Serial1/0
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback0
23.0.0.0/24 is subnetted, 1 subnets
C 23.1.1.0 is directly connected, Serial1/0
22.0.0.0/24 is subnetted, 1 subnets
D EX 22.22.22.0 [170/2297856] via 23.1.1.2, 00:00:49, Serial1/0
实验做到这里，感觉好像是因为自己在重发布的时候画蛇添足了，为何要这样人为地制造麻烦呢，直接redistribute rip route-map 不就行了。。。但是如果在以后需要用到重发布直连redistribute connected route-map，那么可能这些考虑就用到了。。。
这种情况原因：route-map匹配考虑不周全。
解决办法：
R2(config)#route-map RIP2EIGRP permit 20
R2(config-route-map)#end
R2#
R3#sh ip route
1.0.0.0/32 is subnetted, 1 subnets
D EX 1.1.1.1 [170/2235136] via 23.1.1.2, 00:12:59, Serial1/0
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/2297856] via 23.1.1.2, 00:12:59, Serial1/0
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback0
23.0.0.0/24 is subnetted, 1 subnets
C 23.1.1.0 is directly connected, Serial1/0
22.0.0.0/24 is subnetted, 1 subnets
D EX 22.22.22.0 [170/2297856] via 23.1.1.2, 00:12:05, Serial1/0
12.0.0.0/24 is subnetted, 1 subnets
D EX 12.1.1.0 [170/2681856] via 23.1.1.2, 00:00:06, Serial1/0
同样在RIP直连重发布到OSPF中如果使用route-map的时候也要考虑这些情况。
汇总路由回馈问题：完美解决 route-map + prefix-list
单点双向重发布：考虑汇总路由回馈问题
R1--OSPF--R2--EIGRP--R3
----->
<-----
R2#sh run
!
router eigrp 90
redistribute ospf 110 metric 10000 255 100 1 1500
network 23.1.1.2 0.0.0.0
no auto-summary
!
router ospf 110
router-id 2.2.2.2
log-adjacency-changes
summary-address 172.16.0.0 255.255.252.0
redistribute eigrp 90 subnets
network 12.1.1.2 0.0.0.0 area 0
!
R2:
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.0/24 [90/2297856] via 23.1.1.3, 00:04:00, Serial1/1
O 172.16.0.0/22 is a summary, 00:00:20, Null0
D 172.16.1.0/24 [90/2297856] via 23.1.1.3, 00:04:30, Serial1/1
D 172.16.2.0/24 [90/2297856] via 23.1.1.3, 00:04:21, Serial1/1
D 172.16.3.0/24 [90/2297856] via 23.1.1.3, 00:04:11, Serial1/1
R3:
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
C 172.16.0.0/24 is directly connected, Loopback4
D EX 172.16.0.0/22 [170/3137280] via 23.1.1.2, 00:00:22, Serial1/0
C 172.16.1.0/24 is directly connected, Loopback1
C 172.16.2.0/24 is directly connected, Loopback2
C 172.16.3.0/24 is directly connected, Loopback3
-----------------------------------------------------------
防止汇总路由回馈：完美解决 route-map + prefix-list
R2#sh run b r e
router eigrp 90
redistribute ospf 110 metric 1000 255 100 1 1500 route-map anti-sum
network 23.1.1.2 0.0.0.0
no auto-summary
!
!
ip prefix-list anti-sum seq 5 permit 172.16.0.0/22
!
route-map anti-sum deny 10
match ip address prefix-list anti-sum
!
route-map anti-sum permit 20
!
R3：
172.16.0.0/24 is subnetted, 4 subnets
C 172.16.0.0 is directly connected, Loopback4
C 172.16.1.0 is directly connected, Loopback1
C 172.16.2.0 is directly connected, Loopback2
C 172.16.3.0 is directly connected, Loopback3
R1--OSPF--R2--EIGRP--R3
----->
<-----
R2#sh run
!
router eigrp 90
redistribute ospf 110 metric 10000 255 100 1 1500
network 23.1.1.2 0.0.0.0
no auto-summary
!
router ospf 110
router-id 2.2.2.2
log-adjacency-changes
summary-address 172.16.0.0 255.255.252.0
redistribute eigrp 90 subnets
network 12.1.1.2 0.0.0.0 area 0
!
R2:
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
D 172.16.0.0/24 [90/2297856] via 23.1.1.3, 00:04:00, Serial1/1
O 172.16.0.0/22 is a summary, 00:00:20, Null0
D 172.16.1.0/24 [90/2297856] via 23.1.1.3, 00:04:30, Serial1/1
D 172.16.2.0/24 [90/2297856] via 23.1.1.3, 00:04:21, Serial1/1
D 172.16.3.0/24 [90/2297856] via 23.1.1.3, 00:04:11, Serial1/1
R3:
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
C 172.16.0.0/24 is directly connected, Loopback4
D EX 172.16.0.0/22 [170/3137280] via 23.1.1.2, 00:00:22, Serial1/0
C 172.16.1.0/24 is directly connected, Loopback1
C 172.16.2.0/24 is directly connected, Loopback2
C 172.16.3.0/24 is directly connected, Loopback3
-----------------------------------------------------------
防止汇总路由回馈：完美解决 route-map + prefix-list
R2#sh run b r e
router eigrp 90
redistribute ospf 110 metric 1000 255 100 1 1500 route-map anti-sum
network 23.1.1.2 0.0.0.0
no auto-summary
!
!
ip prefix-list anti-sum seq 5 permit 172.16.0.0/22
!
route-map anti-sum deny 10
match ip address prefix-list anti-sum
!
route-map anti-sum permit 20
!
R3：
172.16.0.0/24 is subnetted, 4 subnets
C 172.16.0.0 is directly connected, Loopback4
C 172.16.1.0 is directly connected, Loopback1
C 172.16.2.0 is directly connected, Loopback2
C 172.16.3.0 is directly connected, Loopback3
路由优选部分_调整管理距离和metric
路由优选这回事
R1 R2 R3 FR帧中继相连 s1/2 123.1.1.0/24 OSPF
R2 R3 R4 以太网相连 fa 0/0 23.1.1.0/24 EIGRP
R2R3上双点双向重发布
R1上其环回
R1(config)#int lo 1
R1(config-if)#ip add 192.168.1.1 255.255.255.0
R1(config-if)#ip ospf network point-to-point
R1(config-if)#int lo 2
R1(config-if)#ip add 192.168.2.1 255.255.255.0
R1(config-if)#ip ospf network point-to-point
R1(config-if)#int lo 3
R1(config-if)#ip add 192.168.3.1 255.255.255.0
R1(config-if)#ip ospf network point-to-point
R1(config-if)#int lo 4
R1(config-if)#ip add 192.168.0.1 255.255.255.0
R1(config-if)#ip ospf network point-to-point
R1(config-if)#end
这时R4将会收到这几天路由，且由R2R3负载均衡线路。
要求：
192.168.0.0和192.169.2.0走R2
192.168.1.0和192.168.4.0走R3
即要求 奇数网络号走R3，偶数网络号走R2，且不能破坏链路的冗余特性。
===>最佳解决办法，使用route-map修改相应路由条目的metric，使R4不优选从R2或R3发来的这条路由条目。
R2：
!
router eigrp 90
redistribute ospf 110 metric 10000 100 255 1 1500 route-map O2E
network 2.2.2.2 0.0.0.0
network 23.1.1.2 0.0.0.0
no auto-summary
!
router ospf 110
router-id 2.2.2.2
log-adjacency-changes
redistribute eigrp 90 subnets
network 2.2.2.2 0.0.0.0 area 0
network 123.1.1.2 0.0.0.0 area 0
!
access-list 13 permit 192.168.1.0
access-list 13 permit 192.168.3.0
route-map O2E permit 10
match ip address 13
set metric 10000 1000 255 1 1500
!
route-map O2E permit 20
!
R4上的路由表：
D EX 192.168.0.0/24 [170/284160] via 23.1.1.2, 00:00:19, FastEthernet0/0
123.0.0.0/24 is subnetted, 1 subnets
D EX 123.1.1.0 [170/284160] via 23.1.1.2, 00:00:06, FastEthernet0/0
[170/284160] via 23.1.1.3, 00:00:06, FastEthernet0/0
D EX 192.168.1.0/24 [170/284160] via 23.1.1.3, 00:00:07, FastEthernet0/0
D EX 192.168.2.0/24 [170/284160] via 23.1.1.2, 00:00:21, FastEthernet0/0
D EX 192.168.3.0/24 [170/284160] via 23.1.1.3, 00:00:07, FastEthernet0/0
同样这个实验可以大大地扩展，这只是冰山一角而已。好像还可以使用反掩码精确匹配奇数或者偶数路由网络条目。例如：使用
R2(config)#access-list 13 permit 192.168.1.0 0.0.254.255
来代替
access-list 13 permit 192.168.1.0
access-list 13 permit 192.168.3.0
+++++++++++++++++++++++++++++++++++++++++++++++++
R1 R2 R3 FR帧中继相连 s1/2 123.1.1.0/24 OSPF
R2 R3 R4 以太网相连 fa 0/0 23.1.1.0/24 EIGRP
R2R3上双点双向重发布
R1上其环回
R1(config)#int lo 1
R1(config-if)#ip add 192.168.1.1 255.255.255.0
R1(config-if)#ip ospf network point-to-point
R1(config-if)#int lo 2
R1(config-if)#ip add 192.168.2.1 255.255.255.0
R1(config-if)#ip ospf network point-to-point
R1(config-if)#int lo 3
R1(config-if)#ip add 192.168.3.1 255.255.255.0
R1(config-if)#ip ospf network point-to-point
R1(config-if)#int lo 4
R1(config-if)#ip add 192.168.0.1 255.255.255.0
R1(config-if)#ip ospf network point-to-point
R1(config-if)#end
这时R4将会收到这几天路由，且由R2R3负载均衡线路。
要求：
192.168.0.0和192.169.2.0走R2
192.168.1.0和192.168.4.0走R3
即要求 奇数网络号走R3，偶数网络号走R2，且不能破坏链路的冗余特性。
===>最佳解决办法，使用route-map修改相应路由条目的metric，使R4不优选从R2或R3发来的这条路由条目。
R2：
!
router eigrp 90
redistribute ospf 110 metric 10000 100 255 1 1500 route-map O2E
network 2.2.2.2 0.0.0.0
network 23.1.1.2 0.0.0.0
no auto-summary
!
router ospf 110
router-id 2.2.2.2
log-adjacency-changes
redistribute eigrp 90 subnets
network 2.2.2.2 0.0.0.0 area 0
network 123.1.1.2 0.0.0.0 area 0
!
access-list 13 permit 192.168.1.0
access-list 13 permit 192.168.3.0
route-map O2E permit 10
match ip address 13
set metric 10000 1000 255 1 1500
!
route-map O2E permit 20
!
R4上的路由表：
D EX 192.168.0.0/24 [170/284160] via 23.1.1.2, 00:00:19, FastEthernet0/0
123.0.0.0/24 is subnetted, 1 subnets
D EX 123.1.1.0 [170/284160] via 23.1.1.2, 00:00:06, FastEthernet0/0
[170/284160] via 23.1.1.3, 00:00:06, FastEthernet0/0
D EX 192.168.1.0/24 [170/284160] via 23.1.1.3, 00:00:07, FastEthernet0/0
D EX 192.168.2.0/24 [170/284160] via 23.1.1.2, 00:00:21, FastEthernet0/0
D EX 192.168.3.0/24 [170/284160] via 23.1.1.3, 00:00:07, FastEthernet0/0
同样这个实验可以大大地扩展，这只是冰山一角而已。好像还可以使用反掩码精确匹配奇数或者偶数路由网络条目。例如：使用
R2(config)#access-list 13 permit 192.168.1.0 0.0.254.255
来代替
access-list 13 permit 192.168.1.0
access-list 13 permit 192.168.3.0
+++++++++++++++++++++++++++++++++++++++++++++++++
订阅：
评论 (Atom)
博文
