Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Use Configuration Groups to Quickly Configure Devices

Use configuration groups to set up and apply common elements that are reused within the same configuration.

Configuration Groups Overview

This topic provides an overview of configuration groups and the inheritance model in the Junos OS Evolved CLI.

How Configuration Groups Work

Configuration groups enable you to create a group containing configuration statements and to direct the inheritance of that group’s statements in the rest of the configuration. The same group can be applied to different sections of the configuration. Different sections of one group’s configuration statements can be inherited in different places in the configuration.

Configuration groups enable you to create smaller, more logically constructed configuration files, making it easier to configure and maintain Juniper Networks devices. For example, you can group statements that are repeated in many places in the configuration, such as when configuring interfaces. By grouping statements, you can limit configuration updates to just the group.

You can also use wildcards in a configuration group. Any object that matches the wildcard expression inherits the group configuration data.

The configuration group mechanism is separate from the grouping mechanisms used elsewhere in the configuration, such as BGP groups. Configuration groups provide a generic mechanism that you can use throughout the configuration but that are known only to the CLI. The individual software processes that perform the actions directed by the configuration receive the expanded form of the configuration; they have no knowledge of configuration groups.

Inheritance Model

Configuration groups use true inheritance, which involves a dynamic, ongoing relationship between the source of the configuration data and the target of that data. The target automatically inherits data values that you change in the configuration group. The target does not need to contain the inherited information. However, the inherited values can be overridden in the target without affecting the source from which they were inherited.

This inheritance model enables you to see only the instance-specific information without seeing the inherited details. A command pipe in configuration mode enables you to display the inherited data.

Configure Configuration Groups

For areas of your configuration to inherit configuration statements, you must first put the statements into a configuration group. You then apply that group to the levels in the configuration hierarchy that require the statements.

For areas of your configuration to inherit configuration statements:

  1. Configure statements into a configuration group. To configure configuration groups and inheritance, you can include the groups statement at the [edit] hierarchy level:

  2. Apply the configuration group from step 1 to the levels in the configuration hierarchy that require the statements.

    Include the apply-groups [ group-names ] statement anywhere in the configuration where the configuration statements contained in a configuration group are needed.

Create a Configuration Group

The Junos OS Evolved CLI enables you to create re-usable groups containing configuration statements. You can apply these groups to to different sections of the configuration where the same configuration statements are repeated multiple times.

When you apply the group in different sections of the configuration, that part of the configuration inherits the statements configured in the group. Configuration groups follow the rule of inheritance where the dynamic, ongoing relationship is set between the source of the configuration data and the target of that data. If you change the data values in the configuration group, the inherited target reflects the changes automatically.

You can overwrite the values in the target configuration if required, which does not affect the source in the group.

This inheritance model enables you to see only the instance-specific information without seeing the inherited details. A command pipe in configuration mode enables you to display the inherited data. For example, you may want to configure all of your et-0/0/1 interfaces for the MTU value of 1500.

To do configure all of your et-0/0/1 interfaces for the MTU value of 1500:

  1. Create a group with MTU value 1500:

  2. Next, you apply the group in the interface configuration.

  3. View the inherited configuration.

If you want to configure MTU value for interface et-0/0/1 in different parts of the configuration, you can apply the group statement using the apply-groups option. If you do this manually and later want to increase the MTU, you may have to manually change every interface. If you use a configuration group, you can change the group configuration, thereby automatically updating all associated interfaces.

You can also use wildcards in a configuration group to allow configuration data to be inherited by any object that matches a wildcard expression. For example:

How to Apply a Configuration Group

If you want a Juniper Networks device configuration to inherit the statements from a configuration group, include the apply-groups statement in the configuration.

If you specify more than one group name, you must list the names in order of inheritance priority. The configuration data in the first group takes priority over the data in subsequent groups.

For devices that support multiple Routing Engines, you can specify re0 and re1 group names. The configuration specified in group re0 is applied only if the current Routing Engine is in slot 0. Likewise, the configuration specified in group re1 is applied only if the current Routing Engine is in slot 1. Therefore, both Routing Engines can use the same configuration file, each using only the configuration statements that apply to it. Each re0 or re1 group contains at a minimum the configuration for the hostname and the management interface (fxp0). If each Routing Engine uses a different management interface, the group also should contain the configuration for the backup router and static routes.

You can include only one apply-groups statement at each specific level of the configuration hierarchy. The apply-groups statement at a specific hierarchy level lists the configuration groups to be added to the containing statement’s list of configuration groups.

Values specified at the specific hierarchy level override values inherited from the configuration group.

Groups listed in nested apply-groups statements take priority over groups in outer statements. In the following example, the BGP neighbor 10.0.0.1 inherits configuration data from group one first. It then inherits configuration data from group two and group three. Configuration data in group one overrides data in any other group. Data from group ten is used only if a statement is not contained in any other group.

The root level is the default logical system. When you configure a group defined for the root level, you cannot successfully apply that group to a nondefault logical system under the [edit logical-systems logical-system-name] hierarchy level. Although the device accepts the commit if you apply the group, the configuration group does not take effect for the nondefault logical system. You can instead create an additional configuration group at the root level and apply it within the logical system. Alternatively, you can modify the original group so that it includes configuration for both the default and nondefault logical system hierarchy levels.

Example: Create and Apply Configuration Groups

This example illustrates the creation and application of configuration groups. In this example, the SNMP configuration is divided between the group basic and the normal configuration hierarchy.

You gain multiple advantages by placing the system-specific configuration (SNMP contact) into a configuration group, thus separating it from the normal configuration hierarchy:

  • You can replace either section without discarding data from the other, by using the load replace command.

  • You can set a contact for a specific box because the group data is hidden by the device-specific data.

This configuration is equivalent to the following:

Example: Disable Inheritance of a Configuration Group

You can disable inheritance of a configuration group at any level except the top level of the hierarchy. To disable inheritance, you include the apply-groups-except statement in the configuration:

This statement is useful when you use the apply-group statement at a specific hierarchy level but also want to override the values inherited from the configuration group for a specific parameter.

Example: Disable Inheritance on Interface et-1/1/0

In the following example, the apply-groups statement is applied globally at the interfaces level. The apply-groups-except statement is also applied at interface et-1/1/0 so that it uses the default values for the hold-time and link-mode statements.

Configuration groups can add some confusion regarding the actual values used by the device, because a device can inherit configuration data from configuration groups. To view the actual values used by the device, you use the display inheritance command after the pipe ( | ) in a show command. This command displays the inherited statements at the level at which they are inherited and the group from which they have been inherited:

To display the expanded configuration (the configuration, including the inherited statements) without the ## lines, you use the except command after the pipe in a show command:

Note:

Using the display inheritance | except ## option removes all the lines with ##. Therefore, you may not be able to view information about passwords or other important data where ## is used. To view the complete configuration details with all the information (without just the comments marked with ##), you use the no-comments option with the display inheritance command:

Example: Use the junos-defaults Configuration Group

Junos OS Evolved provides a hidden and immutable configuration group called junos-defaults that is automatically applied to the configuration of your device. The junos-defaults group contains preconfigured statements that contain predefined values for common applications. Some of the statements must be referenced to take effect, such as definitions for applications (for example, FTP or telnet settings). Other statements are applied automatically, such as terminal settings.

Note:

Many identifiers included in the junos-defaults configuration group begin with the name junos-. Because identifiers beginning with the name junos- are reserved for use by Juniper Networks, you cannot define any configuration objects using this name.

You cannot include junos-defaults as a configuration group name in an apply-groups statement.

To view the full set of available preset statements from the junos-defaults group, you issue the show groups junos-defaults configuration mode command at the top level of the configuration. The following example displays a partial list of Junos defaults groups:

To reference statements available from the junos-defaults group, you include the selected junos- default-name statement at the applicable hierarchy level.

To view the list of applications from the junos-defaults group, you issue the show configuration groups junos-defaults applications. The applications that begin with junos- are configured by Juniper Networks by default. The following example displays a partial list of Junos defaults groups applications.

Example: Use Wildcards with Configuration Groups

You can use wildcards to identify names and allow one statement to provide data for a variety of statements.

Using wildcards in normal configuration data is done in a style that is consistent with that used with traditional UNIX shell wildcards. In this style, you can use the following metacharacters:

  • Asterisk ( * )—Matches any string of characters.

  • Question mark ( ? )—Matches any single character.

  • Open bracket ( [ )—Introduces a character class.

  • Close bracket ( ]  )—Indicates the end of a character class. If the close bracket is missing, the open bracket matches an open bracket [ rather than introducing a character class.

  • A character class matches any of the characters between the square brackets. Within a configuration group, you must enclose in quotation marks an interface name that includes a character class.

  • Hyphen ( - )—Specifies a range of characters.

  • Exclamation point ( ! )—You can complement the character class by making an exclamation point the first character of the character class. To include a close bracket (]) in a character class, make it the first character listed (after the !, if any). To include a minus sign, make it the first or last character listed.

Note:

If using an identifier inside the groups hierarchy, start the identifier name with something other than <. However, if you are defining a wildcard statement, you can use < because the wildcard statement must have a closing >.

Using wildcards in configuration groups follows the same rules as using them for normal configuration. However, < and > have a special meaning when used under the groups hierarchy. In the groups hierarchy, you must enclose in angle brackets any term using a wildcard pattern <pattern> to differentiate it from other wildcards in the configuration file.

Wildcard expressions match (and provide configuration data for) existing statements in the configuration that match their expression only. In the previous example, the expression <et-*> passes its sonet-options statement to any interface that matches the expression et-*.

The following example shows how to specify a range of interfaces:

Angle brackets enable you to pass normal wildcards through without modification. In any matching within the configuration, whether it is done with or without wildcards, the first item encountered in the configuration that matches is used. In the following example, data from the wildcarded BGP groups is inherited in the order in which the groups are listed.

  • The preference value from <*a*> overrides the preference in <*b*>.
  • The p value from <*c*> overrides the one from <*d*>

Data values from any of these groups override the data values from abcd:

How to Improve Commit Time When Using Configuration Groups

You use configuration groups to apply configurations across other hierarchies without re-entering configuration data. You can specify every configuration detail in a configuration groups. You can also use wildcards in configuration groups to configure ranges of data, without detailing each configuration line. Another way to use configuration groups is to create an inheritance path that includes a long string of configurations to be applied.

When a configuration that uses configuration groups is committed, the commit process expands and reads all the configuration data of the group into memory to apply the configurations as intended. The commit performance can be negatively affected if many configuration groups are being applied, especially if the configuration groups use wildcards extensively.

If your system uses many configuration groups that use wildcards, you can configure the persist-groups-inheritance statement at the [edit system commit] hierarchy level to improve commit time performance.

Using this option enables the system to build the inheritance path for each configuration group inside the database rather than in the process memory. This change can improve commit time performance. However, it can also increase the database size.

Example: Configure Sets of Statements with Configuration Groups

When sets of statements exist in configuration groups, all values are inherited. For example:

For sets that are not displayed within brackets, all values are also inherited. For example:

Example: Use Configuration Groups to Configure a Consistent IP Address for the Management Interface

On devices with multiple Routing Engines, each Routing Engine is configured with a separate IP address for the management interface. To access the primary Routing Engine, you must know which Routing Engine is active and use the appropriate IP address.

Another option for consistent access to the primary Routing Engine is to configure an additional IP address. You then use this address for the management interface regardless of which Routing Engine is active. This additional IP address is active only on the management interface for the primary Routing Engine. During switchover, the address moves to the new primary Routing Engine.

This example configures address 10.17.40.131 for both Routing Engines and includes a master-only statement. With this configuration, the 10.17.40.131 address is active only on the primary Routing Engine. The address remains consistent regardless of which Routing Engine is active. Address 10.17.40.132 is assigned to re0:mgmt-0 on re0, and 10.17.40.133 is assigned to re1:mgmt-0 on re1.

This feature is available on all routers that include dual Routing Engines.

Note:

  • You must assign unique IP addresses for two interfaces that have duplicate addresses on private and public interfaces. When graceful Routing Engine switchover (GRES) is enabled, the CLI displays an appropriate commit error message if it finds identical addresses. This error can occur if you configure the same IP address for a management interface or internal interface such as re0:mgmt-0 and an external physical interface such as et-0/0/1.

Example: Use Configuration Groups to Configure Peer Entities

This example creates a group some-isp that contains configuration data relating to another ISP. It then inserts apply-group statements at various points to allow those locations in the configuration hierarchy to inherit this data.

Example: Configure Wildcard Configuration Group Names

Wildcards are configuration group names that use special characters to create a pattern that you can apply to multiple statements. Wildcards are useful for copying one set of configuration options to many different configuration groups. You must set up your wildcard name properly to ensure that the wildcard configuration options get copied to the appropriate configuration groups.

This example configures different values for the <*-major> and <*-minor> wildcard groups under the label-switched-path statement. The asterisk (*) character represents a section of the wildcard name that can match any string of characters. For example, the configuration options under label-switched-path <*-major> are passed on to label-switched-path metro-major and any other label-switched-path configuration group containing -major in its name.

Example: Reference the Preset Statement from the Defaults Group

The following example is a preset statement from the defaults group that is available for FTP in a stateful firewall:

To reference a preset default statement from the defaults group, include the junos-default-name statement at the applicable hierarchy level. For example, to reference the default statement for FTP in a stateful firewall, include the junos-ftp statement at the [edit services stateful-firewall rule my-rule term my-term from applications] hierarchy level:

Example: View Default Statements That Have Been Applied to the Configuration

To view the defaults that have been applied to the device configuration, you issue the show | display inheritance defaults command. This example displays the inherited defaults at the [edit system ports] hierarchy level:

If you choose not to use existing default statements, you can create your own configuration groups manually.

To view the complete configuration information omitting any comments marked with ##, use the no-comments option with the display inheritance command.

Set Up Routing Engine Configuration Groups

In a device with two Routing Engines, both Routing Engines should share one configuration. This setup ensures that both Routing Engine configurations are identical. Within this configuration, create two Routing Engine groups, one for each Routing Engine. Within these groups, you specify the Routing Engine–specific parameters.

To set up a Routing Engine configuration group:

  1. Create the configuration group re0. The re0 group is a special group designator that RE0 uses, only in a redundant routing platform.
  2. Navigate to the groups re0 level of the configuration hierarchy.
  3. Specify the device hostname.
    Note:

    The DNS server does not use the hostname that you specify in the device configuration to resolve to the correct IP address. The DNS server uses this hostname to display the name of the Routing Engine in the CLI. For example, the hostname appears at the command-line prompt when you are logged in to the CLI:
  4. Configure the IP address and prefix length for the device Ethernet interface.

    • For all devices except PTX Series Packet Transport Routers:

  5. Return to the top level of the hierarchy.
  6. Create the configuration group re1.
  7. Navigate to the groups re1 level of the configuration hierarchy.
  8. Specify the device hostname.
  9. Configure the IP address and prefix length for the device Ethernet interface.

    • For all devices:

  10. Return to the top level of the hierarchy.
  11. Specify the group application order.

How to Use Conditions to Apply Configuration Groups

You can use the when statement at the [edit groups group-name] hierarchy level to define conditions under which to apply a configuration group.

You can configure a group to apply based on the type of chassis, model, or Routing Engine, virtual chassis member, cluster node, and start and optional end time of day or date.

For example, you could use the when statement to create a generic configuration group for each type of node and then apply the configuration based on certain node properties, such as chassis or model.