Skip to main content

Configuration Management on the SSR

The following sections describe the various configurations available to you on your SSR, the basics of the configuration workflow, and important things to consider when managing your SSR devices.

Factory Default Configuration​

When a new node is initialized, it is given the factory default configuration. The factory defaults include the configuration attributes given to it during initialization (the router name and node name, and a high availability counterpart node if applicable) as well as various configuration elements that are part of the global data of an Authority – session-type elements that represent common network protocols (e.g., HTTP, HTTPS, SSH), and service-class elements for common DSCP values.

By default, these factory default elements are not displayed when viewing the configuration through the PCLI. To view the factory default settings, add the keyword "verbose" at the end of a show configuration statement; e.g., show config running verbose. Factory default elements are always displayed when viewing the configuration through the GUI.

To restore an SSR system back to its factory defaults, use the restore config factory-default command from the PCLI.

Generated Configuration​

Occasionally, the Conductor generates configuration on behalf of the administrator; this is typically done to facilitate some configuration steps that would otherwise be somewhat onerous or prone to error. When the Conductor generates the configuration on behalf of an administrator, it includes a generated setting in each configuration element it has generated, and sets the value to true.

The Conductor regenerates this configuration each time the configuration is committed. This ensures that the generation properly reflects any changes made to the rest of the configuration from which the generated configuration was derived. When committing configuration, the Conductor first deletes all configuration that has the generated flag set to true.

If you have made any changes to configuration elements that were originally generated by the Conductor, but neglected to set the generated flag to false, those elements will be discarded and regenerated. Thus, it is mandatory that you set the generated flag to false before modifying any generated configuration to make it persistent.

Forcing the Generation of Configuration​

The Force Configuration Generation command (selected from the GUI or using create config autogenerated from the PCLI) generates and stages the configuration changes into the current candidate configuration. This allows you to validate, inspect, make edits, and commit these changes as part of the work flow.

toolbar popup dialog

Running Configuration​

The running configuration is the set of configuration elements that the SSR is currently using to make routing decisions, forward traffic, enforce policy, etc. The SSR loads the running configuration when the software starts; this configuration is either the one that it retrieves at start from its conductor, or from its local disk (in the case where it is either unmanaged, or unable to reach its conductor).

Candidate Configuration​

Configuration concurrency was introduced in version 5.6. This feature creates a candidate configuration for each user the first time they edit their configuration, allowing multiple administrators to modify the running configuration at the same time.

note

Beginning with 5.3, the candidate configuration is not saved to disk and will not persistent through reboot. It is strongly recommended that you export candidate configurations occasionally when making large or important changes to avoid losing your work.

Each user makes edits locally to a candidate configuration. When they have completed their edits locally, they commit the config to the conductor and changes are merged into the running configuration. As other users complete and commit their changes, the updated running configuration is compared to each candidate configuration for conflicts. If none exist, the local changes are committed to the running configuration on the conductor.

How it Works​

Consider the case of User A and User B:

  • Both users access the same conductor, open the configuration, and begin making changes.
  • User A makes three separate changes to the candidate configuration. User A’s changes are kept local.
  • User B makes one change to the candidate configuration. User B’s changes are kept local.

When User A commits their changes, the changes applied to their candidate configuration are validated and then merged into the running configuration. The candidate configuration from User B is now behind the running configuration by User A’s three changes.

User B has one change of their own. The validation and commit process compares the updated running configuration to User B's candidate configuration for conflicts. If none are found, then the local changes are committed to the running configuration on the conductor.

If the validation operation encouters conflicts, an error message containing the details of the conflict is displayed, and the conflicts are deleted from the candiate config. All non-conflicting changes are preserved in the candidate configuration.

Conflict Resolution​

In the example below, User B changed the description of the router Router, but User A had already deleted that router, resulting in the conflict.

To see the configuration changes that were preserved in the candidate despite the conflicts, run compare-config.

The following is an example of a configuration conflict as seen in the PCLI:

*admin@conductor-east-1.RTR_EAST_CONDUCTOR# commit force
Validating, then committing...
% Error: Failed to commit candidate configuration because another user 
has committed conflicting changes. The following changes have been lost, 
run 'compare config' to see changes that were preserved:

1. failed to apply merge configuration change:

config

    authority

        router  Router
            name         Router
            description  hello
        exit
    exit
exit

In this case, using compare-config displays a non-coflicting change that remains in the candidate, and can be committed.

*admin@conductor-east-1.RTR_EAST_CONDUCTOR# compare config

config

    authority
        name  NewAuthority
    exit
exit

GUI Considerations​

Juniper strongly suggests careful configuration of users' permissions to avoid rare configuration conflicts when users concurrently make conflicting updates using the GUI. For information about user permissions, see Configuring Role-Based Access Control.

important

The following conflict may occur when multiple GUI users make changes to the configuration.

Scenario:​

  • User A removes a peer from the configuration, and commits the change. The change has no conflicts and is accepted into the running config.

  • User B changes the description field of the peer that User A deleted. User B then commits their changes.

Rather than an error message informing User B that the peer they are editing has been deleted, the GUI accepts the information directly impacting the change to the description field, but not the entire peer. The resulting commit failure message can be cryptic, as shown below.

GUI Commit Failure

In this case, viewing the configuration changes as seen from the command line, the discrepancies are visible.

config

    authority

        router  RTR_EAST_COMBO
            name         RTR_EAST_COMBO
            peer         bluerouter      <--- DELETED BY USER A
            authority-name    Authority
            router-name       bluerouter
        exit
    exit
exit
config

    authority

        router  RTR_EAST_COMBO
            name         RTR_EAST_COMBO
            
            peer         bluerouter      
                name       bluerouter
                description    "hello user was here"    <--- ADDED BY USER B
        exit
    exit
exit

When User B commits their change, the peer, name, and description are verified to be added back into the configuration. The deleted authority-name and router-name are not found as part of the change, and therefore generate the commit failure message.

To resolve this type of conflict, the error message and candidate configuration should be reviewed with the adminstrator. They can work to identify the user who generated the conflicting changes and review the event logs to reconstruct the changes to the affected objects. Ultimately the users must determine the priority of the configuration changes and commit the result.

High Availability Configurations​

There are several things to be mindful of before configuring high availability:

  • The two nodes must be informed that they are part of a high availability set.
  • They must have a dedicated interface between them for synchronizing state information about active sessions.
  • For software versions prior to 5.3.0, all configuration edit and commit operations must be done on only one node.

Please refer to Configuring Dual Node High Availability for detailed configuration steps and information related to HA configurations.

Configuration Workflows​

Unlike many traditional routers, the Session Smart Networking Platform contains a series of interdependent pieces of configuration – referred to as our data model – to inform its decisions on routing, forwarding, and policy enforcement. These interdependencies mean that the method of working with the SSR may be slightly different than you are accustomed to.

The basic premise is that there may two configurations on your SSR at any point in time: the running configuration and, as soon as you make any edits to the configuration, a candidate configuration is created. You stage configuration changes in the candidate, and when you have completed your configuration activity, you validate and commit them to the running configuration – bringing the candidate and running back into unison. Upon commit, the candidate configuration iFrom there, you may undertake your next set of configuration changes.

This basic workflow (configure, validate, commit) is the fundamental mechanism for effecting change in the behavior of your SSR Networking Platform. Other operations you may be familiar with from other network devices, such as backup/restore, etc., have analogues in the SSR paradigm. These backup/restore operations may operate on the candidate configuration, the running configuration, or both.

Comparing Configurations​

To see the changes between the candidate and running configuration, use the compare config command within the PCLI. This takes positional arguments, candidate, running, or the name of a previously exported configuration. The output for the compare config command shows the differences between the two configurations. The ordering of the arguments is significant; issuing the command compare config running candidate shows the changes that have been made to the candidate configuration. The command compare config candidate running shows the set of changes that would need to be applied to restore the candidate configuration back to the running configuration. The name argument identifies a previously exported configuration file to compare against the running, candidate, or another exported configuration file. This argument allows you to compare configurations without having to import the exported config into the candidate config for comparison.

note

The output of compare config candidate running is formatted such that it can be copied and pasted back into the PCLI, to revert all changes and have the candidate be "reset" to the running configuration. Obviously, you can selectively copy/paste sections of this output back into the PCLI to revert only specific sets of changes. However, care must be taken when doing this, as the configuration is organized in a hierarchy with specific expectations around exiting configuration blocks.

Restoring the Candidate​

Similar to copying and pasting the output of compare config candidate running into the PCLI, there is a specific command for reverting the entire candidate configuration back to the running configuration's state. The command restore config running resets the candidate back to the system's runtime configuration, and deletes the candidate configuration.

From the GUI, use the Revert to Running button in the navigation bar near the top of the window to accomplish the same goal.

Import/Export​

Use the export config command to save the candidate or running configuration. It is strongly recommended to frequently save the candidate configuration as a checkpoint for changes to be committed. In earlier releases the candidate configuration was stored on disk and would persist through product reboots. Beginning with 5.3, the candidate configuration is not saved to disk and will not persistent through reboot.

The running configuration can be exported as a working configuration, or for replicating the same configuration on another SSR, or for replicating the configuration to another system for archival/auditing. It is a useful practice to export the configuration prior to a system upgrade. The candidate or running configuration is backed up by executing export config candidate <export-name> or export config running <export-name>.

To import a configuration that has been exported, execute import config <file-name>. Imported configurations are loaded into the candidate config. To apply the imported configuration to the system, a Commit operation must be executed for it to become the running config.

note

When copying exported configurations onto a SSR platform, the file must be placed in /etc/128technology/config-exports