Cisco 6503 - Manual (Page 13)

Cisco Systems, Inc.
All contents are Copyright © 1992–2002 Cisco Systems, Inc. All rights reserved. Important Notices and Privacy Statement.
Page 13 of 19
The following commands enable MSFC config-sync:
MSFC-Sup-15 (config)# redundancy
MSFC-Sup-15 (config-r)# high-availability
MSFC-Sup-15 (config-r-ha)# config-sync
With config-sync, all configurations for the designated and nondesignated MSFCs are done through the CLI of the designated
MSFC. Configuration of the nondesignated MSFC is accomplished through the use of the alt keyword. This is the only way
to configure the nondesignated MSFC when config-sync is enabled. For example:
MSFC-Sup-15 (config-if)# ip address a.b.c.1 x.x.x.0 alt ip address a.b.c.2 x.x.x.0
MSFC-Sup-15 (config-if)# standby 10 priority 100 alt standby 10 priority 50
The command syntax does not change. The portion of the command listed before the alt keyword applies to the MSFC in slot
1 and the portion of the command listed after the alt keyword applies to the MSFC in slot 2. The config-sync feature is only
supported for general IP or IPX configurations; configuration parameters for Appletalk, DECnet, etc. do not have
corresponding alt keyword options.
WAN Interfaces in DRM
In DRM, the Optical Service Module (OSM) or FlexWAN interfaces of a WAN module are managed by only the designated
MSFC. Prior to enabling the config-sync feature, the WAN interfaces do not show up in the nondesignated MSFC
configuration so are not configurable on the nondesignated MSFC. During a supervisor engine or MSFC failover, the MSFC
that becomes the new designated MSFC will not have properly configured WAN interfaces. For this reason a redundant
supervisor or MSFC configuration without config-sync was not supported with WAN modules installed. By enabling the
MSFC config-sync feature, this limitation is removed and WAN modules are supported in a redundant supervisor
configuration. WAN modules should not reset during a high-availability switchover with config-sync enabled.
DRM Challenges
DRM was the original option for MSFC redundancy. This solution has been very successful by allowing for stateful Layer 3
failover between MSFCs, but it also introduces some complexity into network design and administration. The following three
points present scenarios where DRM does not provide the best solution for Layer 3 redundancy:
• Each MSFC must have a unique IP address for each VLAN interface. In a distribution or core implementation using DRM
as well as dual chassis, this could require up to five router IP addresses to be allocated per VLAN (four router addresses
plus one HSRP address). This also increases the number of routing protocol neighbors, which can add to the CPU burden
on a router. The tasks of addressing and managing four routers in this case can be a challenge that outweighs the benefits
of added redundancy.
• In a redundant configuration where multiple MSFCs are connected to the same Ethernet segment, only one MSFC
forwards the multicast traffic from the source to the receivers on the outgoing interfaces. The Protocol Independent
Multicast designated forwarder (PIM-DF) forwards the data in the common VLAN, but the non-PIM-DF receives the
forwarded multicast traffic as well. The redundant MSFC (non-PIM-DF) must drop this traffic because it has arrived on
the wrong interface and will fail the reverse path forwarding (RPF) check. Traffic that fails the RPF check is called
non-RPF traffic. In general, routers may not handle non-RPF traffic efficiently. With DRM, there is at least one router (the
other MSFC) on each VLAN that will receive this non-RPF traffic.
• The requirement for exact configuration parameters on both MSFCs has been a complicated point for many customers.
The effort to ensure that all configuration parameters are the same is a challenge when working with large Cisco IOS
configuration files. Feature enhancements such as config-sync have been developed to simplify this process but do not
scale.