Saving Configurations

Whenever configuration changes are made, the modified configuration must be saved so the changes will not be lost when the system is rebooted. The system uses the configuration and image files, as well as other operational parameters necessary for system initialization, according to the locations specified in the boot option file (BOF) parameters. For more information about boot option files, refer to the Boot Options.

Configuration files are saved by executing implicit or explicit command syntax.

The save command includes an option to save both default and non-default configuration parameters (the detail option).

The index option specifies that the system preserves system indexes when a save command is executed, regardless of the persistent status in the BOF file. During a subsequent boot, the index file is read along with the configuration file. As a result, a number of system indexes are preserved between reboots, including the interface index, LSP IDs, path IDs, etc. This reduces resynchronizations of the Network Management System (NMS) with the affected network element.

If the save attempt fails at the destination, an error occurs and is logged. The system does not try to save the file to the secondary or tertiary configuration sources unless the path and filename are explicitly named with the save command.

System Information

This section covers the basic system information parameters to configure the physical location of the router, contact information, location information such as the place the router is located such as an address, floor, room number, etc., global positioning system (GPS) coordinates, and system name.

Use the CLI syntax shown below to configure the following system components:

General system parameters include:

Configuring Synchronization and Redundancy

Configuring Multi-Chassis Redundancy for LAG

When configuring associated LAG ID parameters, the LAG must be in access mode and LACP must be enabled.

Use the CLI syntax shown below to configure multi-chassis redundancy features.

The following example shows the configuration:

Configuring Mixed Mode

The 7450 mixed mode feature allows a 7450 ESS-7 or ESS-12 chassis to utilize 7750 IOM3-XPs, MDAs, and IMMs to enable 7750 SR capabilities on the associated slots. This allows features such as multicast routing, VPRN and IPv6 support as well as others to be enabled on existing 7450 systems.

The following are mixed-mode requirements:

Note: ESM for IPv6 must run on IOM-3 or IMM hardware only, not on IOM or IOM-2, because the IOM and IOM2 data planes are not capable of routing incoming traffic to the IPv6 ESM hosts. The scaling limits are still defined by the chassis mode. That means only 16k IPv6 ESM subscribers (limited by the ARP scale of chassis mode A).

Enabling Mixed Mode on a 7450 System

To configure mixed mode support, 7750 SR IOM3-XPs, 7750 MDAs, or 7750 SR IMMs must be installed in a 7450 ESS-7 or ESS-12 router that is running OS 8.0 or later. All network interfaces must be migrated to ports on the 7750 SR cards.

The mixed mode state is then enabled by using the mixed-mode-upgrade command:

CLI Syntax:

mixed-mode-upgrade slot-list

This tool will take a list of slots that should have 7750 SR cards installed. The command then checks to ensure that all network interfaces are located on ports on these slots and that they are all 7750 SR cards. It then enables the mixed-mode state at the system level and changes the capability setting for the specified slots to sr.

At this point the 7450 ESS system is operating in a mixed mode state and supported features and services can now be configured on the slots with SR capabilities enabled.

Once in mixed mode use the capability command to configure slots for SR capabilities:

CLI Syntax:

config>card>capability [sr | ess]

Slots using 7750 SR-capable cards will have to have 7750 SR capability enabled on all slots with 7750 SR IOM3s and IMMs, as well as mixed-mode at the system level.

See Table 42 for a description of mixed-mode support.

Note: This table is not intended to be exhaustive, but to provide examples to illustrate the basic principle of mixed versus non-mixed mode operation.

Table 42:  Mixed-Mode Support 

Feature	7450 ESS Standard Mode	7450 ESS Mixed Mode (Limited to 7750 SR IOM3/IMM)
Full IES Support	Limited IES support	Yes
Full VPRN Support	No	Yes
BGP for routing (all address families)	No	Yes
IPv6 routing: IPv6 routing (Unicast and Multicast) 6PE 6VPE (IPv6 VPRN)	No	Yes
IP Multicast routing and forwarding Protocols: PIM, MSDP and IGMP mVPN P2MP LSP support	No	Yes
Spoke termination on L3 (IES/VPRN) interfaces	No	Yes
TPSDA IPv4 & v6 Routed subscriber management support PPPoE support SRRP Routed subscriber management for wholesale	No	Yes
IP Mirroring	No	Yes

Configuring Power Supply Parameters

The following is an example for the 7750 SR and 7950 XRS:

The following is an example for the 7450 ESS:

Configuring ATM System Parameters

The ATM context configures system-wide ATM parameters for the 7750 SR.

The following example shows the ATM configuration.

Configuring Backup Copies

The config-backup command allows you to specify the maximum number of backup versions of configuration and index files kept in the primary location.

For example, assume the config-backup count is set to 5 and the configuration file is called xyz.cfg. When a save command is executed, the file xyz.cfg is saved with a .1 extension. Each subsequent config-backup command increments the numeric extension until the maximum count is reached. The oldest file (5) is deleted as more recent files are saved.

xyz.cfg xyz.cfg.1 xyz.cfg.2 xyz.cfg.3 xyz.cfg.4 xyz.cfg.5 xyz.ndx

Each persistent index file is updated at the same time as the associated configuration file. When the index file is updated, then the save is performed to xyz .cfg and the index file is created as xyz.ndx. Synchronization between the active and standby SF/CPMSF/CPM is performed for all configurations and their associated persistent index files.

The following example shows the config-backup configuration.

Post-Boot Configuration Extension Files

Two post-boot configuration extension files are supported and are triggered when either a successful or failed boot configuration file is processed. The commands specify URLs for the CLI scripts to be run following the completion of the boot-up configuration. A URL must be specified or no action is taken. The commands are persistent between router (re)boots and are included in the configuration saves (admin>save).

The following example shows the command output:

Edit Mode

To enter the mode to edit timing references, you must enter the begin keyword at the config>system>sync-if-timing# prompt.

Use the following CLI syntax to enter the edit mode:

The following error message shows when the you try to modify sync-if-timing parameters without entering the keyword begin.

Configuring Timing References

Use the following CLI syntax to configure timing reference parameters. The source port specified for ref1 and ref2 is dependent on the router model type and chassis slot. Please refer to the details in the specific command descriptions.

The following shows a timing reference configuration example for the router:

Using the Revert Command

The revert command allows the clock to revert to a higher priority reference if the current reference goes offline or becomes unstable. When the failed reference becomes operational, it is eligible for selection.

When mode is non-revertive, a failed clock source is not selected again. If a node would enter holdover due to the references being in previous failed state, then the node will select one of the previously failed references rather than going into holdover.

If the current reference goes offline or becomes unstable the revert command allows the clock to revert to a higher-priority reference.

When revertive switching enabled a valid timing reference of the highest priority is used. If a reference with a higher priority becomes valid, a reference switch over to that reference is initiated. If a failure on the current reference occurs, the next highest reference takes over.

If non-revertive switching is enabled, the valid active reference always remains selected even if a higher priority reference becomes available. If the active reference becomes invalid, a reference switch over to a valid reference with the highest priority is initiated. The failed reference is eligible for selection once it becomes operational.

Other Editing Commands

Other editing commands include:

Forcing a Specific Reference

The debug sync-if-timing force-reference command should only be used to test and debug problems. Network synchronization problems may appear if network elements are left with this manual override setting. Once the system timing reference input has been forced, it may be cleared using the no force-reference command.

You can force the CPM clock to use a specific input reference using the force-reference command.

When the command is executed, the CPM clock on the active CPM immediately switches its input reference to that specified by the command. If the specified input is not available (shutdown), or in a disqualified state, the CPM clock shall use the next qualified input reference based on the selection rules.

This command also affects the BITS output port. If the BITS output port selection is set to line-reference and the reference being forced is not the BITS input port, then the system uses the forced reference to generate the signal out the BITS output port. If the BITS output port selection is set to internal-clock, then the system uses the output of the CPM clock to generate the signal for the BITS output port.

On a CPM activity switch, the force command is cleared and normal reference selection is determined.

Debug configurations are not saved between reboots.

The 7750 SR-c4 has two BITS input ports on the CFM. The force reference command on this system allows the selection of the specific port.

Creating Events

The event command controls the generation and notification of threshold crossing events configured with the alarm command. When a threshold crossing event is triggered, the rmon event configuration optionally specifies whether an entry in the RMON-MIB log table be created to record the occurrence of the event. It can also specify whether an SNMP notification (trap) be generated for the event. There are two notifications for threshold crossing events, a rising alarm and a falling alarm.ping-address

Creating an event entry in the RMON-MIB log table does not create a corresponding entry in the event logs. However, when the event is set to trap the generation of a rising alarm or falling alarm notification creates an entry in the event logs and that is distributed to whatever log destinations are configured: console, session, memory, file, syslog, or SNMP trap destination. The logger message includes a rising or falling threshold crossing event indicator, the sample type (absolute or delta), the sampled value, the threshold value, the rmon-alarm-id, the associated rmon-event-id and the sampled SNMP object identifier.

The alarm command configures an entry in the RMON-MIB alarm table. The alarm command controls the monitoring and triggering of threshold crossing events. In order for notification or logging of a threshold crossing event to occur there must be at least one associated rmon event configured.

The agent periodically takes statistical sample values from the MIB variable specified for monitoring and compares them to thresholds that have been configured with the alarm command. The alarm command configures the MIB variable to be monitored, the polling period (interval), sampling type (absolute or delta value), and rising and falling threshold parameters. If a sample has crossed a threshold value, the associated ‘event’ is generated.

Preconfigured CLI threshold commands are available. Preconfigured commands hide some of the complexities of configuring RMON alarm and event commands and perform the same function. In particular, the preconfigured commands do not require the user to know the SNMP object identifier to be sampled. The preconfigured threshold configurations include memory warnings and alarms and compact flash usage warnings and alarms.

To create events, use the following CLI:

The following example shows the command output:

System Alarm Contact Inputs

Alarm contact inputs are physical input pins on the Alarms Interface Port of the CPM that allow the operator to monitor and report changes in external environmental conditions. In a remote or outdoor deployment, alarm inputs typically allow an operator to detect conditions such as whether a door is open or closed, an air conditioner fault has occurred, and so on.

There are four input pins, each of which can be configured with an associated severity level and normally open/normally closed state. When an input pin changes state, the router can generate log events and raise facility alarms.

There is a separate log event for each pin (for example, CHASSIS event 3003 tmnxSasAlarminput3StateChanged for input pin 3). The severity level of input pin 3 is controlled by configuring the severity level of the associated log event (using the configure log event-control command).

There is also a single +24VDC power output pin on the Alarms Interface Port of the CPM that can be used to supply power for the alarm inputs.

The alarm inputs can be powered in one of two ways:

The power output pin provided on the CPM is monitored, and the router can report when the power source fails.

If using an external power source for the alarm inputs, then it is recommended that the normal-state closed configuration be used so that a failure of the external power source will trigger all the alarm pins to detect a change of state. If normal-state open is used, a failure of the external power source will not generate any notifications and the alarm input pins will no longer operate correctly.