Detecting Corrupt File Configurations - Juniper SYSTEM BASICS - CONFIGURATION GUIDE V 11.1.X Configuration Manual

System basics configuration guide software for e series broadband services routers
Table of Contents

Advertisement

Detecting Corrupt File Configurations

You can detect corruption of running configuration files and CNF files on both the
primary SRP when the corruption is due to a fatal duplicate key error. CNF files must
be present on the active file system to monitor them; you cannot monitor CNF files
that reside alone on the standby SRP.
You can use the service check-configcommand to control the mode of detection for
corruption detection of the running configuration. Auto mode provides a background
monitoring task that periodically checks the validity of running configurations. The
service config-monitor-periodicity command enables you to set the time for
background monitoring of the active and standby SRP. By default, background
monitoring is not running. Manual mode is the default detection mode. For corruption
detection of the CNF files, you must use manual mode.
A critical message that indicates whether the corrupted configuration files are
recoverable appears prompting you to manually recover the corrupt files.
When duplicate key corruption is detected in either the active or standby SRP:
File synchronization and monitoring the file system are separate operations.
Depending on the wake up time of the monitoring task, there is a period of time
when corruption can occur and the file systems are synchronized. We recommend
An interface can be in only one tag group.
Example
host1(config-if)#tag-group red
Use the no version to remove the tag group.
See tag-group.
File synchronization between the active and standby SRP occurs when HA is
enabled. Configuration files are not synchronized to the standby SRP when
corruption is detected and the auto-recovery option is disabled. You can restart
file synchronization of configuration files only when you reinitialize the flash file
system on the corrupted SRP.
If HA is disabled, you cannot enable HA until you reinitialize the flash file system
on the corrupted system. HA is disabled because of the redundancy corruption
criteria. HA cannot be reenabled until the flash file system is reinitialized on the
corrupted system.
You cannot initialize unified ISSU until you reinitialize the flash file system on
the corrupted system. If the corruption is detected after unified ISSU is initialized,
HA is disabled, which then sets a redundancy criteria for corruption that prevents
unified ISSU from starting.
If monitoring is configured to run in auto mode when unified ISSU starts,
monitoring reverts back to manual mode to prevent monitoring during a unified
ISSU upgrade. After a successful unified ISSU upgrade, monitoring switches back
to the originally configured mode on both SRPs.
Chapter 5: Managing the System
Monitoring the Current Configuration
271

Advertisement

Table of Contents
loading

This manual is also suitable for:

Junose 11.1

Table of Contents