Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Using Configuration Groups to Quickly Configure Devices

 

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

Understanding Junos OS Configuration Groups

This topic provides an overview of the configuration groups feature and the inheritance model in Junos OS, and contains the following sections:

Configuration Groups Overview

The configuration groups feature in Junos OS enables 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, and 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 Junos OS. For example, you can group statements that are repeated in many places in the configuration, such as when configuring interfaces, and thereby limit updates to just the group.

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

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 can be used throughout the configuration but that are known only to the Junos OS 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.

Note

Junos OS does not support configuring statements corresponding to third-party YANG data models, for example, OpenConfig or custom data models, under the [edit groups] hierarchy.

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. Data values changed in the configuration group are automatically inherited by the target. The target does not need to contain the inherited information, although the inherited values can be overridden in the target without affecting the source from which they were inherited.

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

Configuring Configuration Groups

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

To configure configuration groups and inheritance, you can include the groups statement at the [edit] hierarchy level:

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

Creating a Junos OS Configuration Group

To create a configuration group, include the groups statement at the [edit] hierarchy level:

group-name is the name of a configuration group. You can configure more than one configuration group by specifying multiple group-name statements. However, you cannot use the prefix junos- in a group name because it is reserved for use by Junos OS. Similarly, the configuration group juniper-ais is reserved exclusively for Juniper Advanced Insight Solutions (AIS)-related configuration. For more information on the juniper-ais configuration group, see the Juniper Networks Advanced Insight Solutions Guide  .

One reason for the naming restriction is a configuration group called junos-defaults. This preset configuration group is applied to the configuration automatically. You cannot modify or remove the junos-defaults configuration group.

On routers that support multiple Routing Engines, you can also specify two special group names:

  • re0—Configuration statements applied to the Routing Engine in slot 0.

  • re1—Configuration statements applied to the Routing Engine in slot 1.

Note

The configuration statements re0 and re1 are case senstive.

The configuration specified in group re0 is only applied if the current Routing Engine is in slot 0; likewise, the configuration specified in group re1 is only applied 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.

In addition, the TX Matrix router supports group names for the Routing Engines in each T640 router attached to the routing matrix. Providing special group names for all Routing Engines in the routing matrix allows you to configure the individual Routing Engines in each T640 router differently. Parameters that are not configured at the [edit groups] hierarchy level apply to all Routing Engines in the routing matrix.

configuration-data contains the configuration statements applied elsewhere in the configuration with the apply-groups statement. To have a configuration inherit the statements in a configuration group, include the apply-groups statement. .

The group names for Routing Engines on the TX Matrix router have the following formats:

  • lccn-re0—Configuration statements applied to the Routing Engine in slot 0 in a specified T640 router.

  • lccn-re1—Configuration statements applied to the Routing Engine in slot 1 in a specified T640 router.

n identifies the T640 router and can be from 0 through 3. For example, to configure Routing Engine 1 properties for lcc3, you include statements at the [edit groups lcc3–re1] hierarchy level.

Note

The management Ethernet interface used for the TX Matrix Plus router, T1600 or T4000 routers in a routing matrix, and PTX Series Packet Transport Routers is em0. Junos OS automatically creates the router’s management Ethernet interface, em0.

Applying a Junos OS Configuration Group

To have the Junos OS configuration inherit the statements from a configuration group, include the apply-groups statement:

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

For routers that support multiple Routing Engines, you can specify re0 and re1 group names. The configuration specified in group re0 is only applied if the current Routing Engine is in slot 0; likewise, the configuration specified in group re1 is only applied 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.

Note

The management Ethernet interface used for the TX Matrix Plus router, T1600 routers in a routing matrix, and PTX Series Packet Transport Switches, is em0.

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, then from groups two and 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.

When you configure a group defined for the root level—that is, in the default logical system–you cannot successfully apply that group to a nondefault logical system under the [edit logical-systems logical-system-name] hierarchy level. Although the router 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: Creating and Applying Junos OS Configuration Groups

In this example, the SNMP configuration is divided between the group basic and the normal configuration hierarchy.

There are several advantages to placing the system-specific configuration (SNMP contact) into a configuration group and thus separating it from the normal configuration hierarchy—you can replace (using the load replace command) either section without discarding data from the other.

In addition, setting a contact for a specific box is now possible because the group data would be hidden by the router-specific data.

This configuration is equivalent to the following:

Example: Creating and Applying Configuration Groups on a TX Matrix Router

The following example shows how to configure and apply configuration groups on a TX Matrix Router.

Disabling Inheritance of a Junos OS Configuration Group

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

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: Disabling Inheritance on Interface so-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 so-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 router, because configuration data can be inherited from configuration groups. To view the actual values used by the router, 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, 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 might also not be able to view information about passwords and other important data where ## is used. To view the complete configuration details with all the information without just the comments marked with ##, use the no-comments option with the display inheritance command:

Using the junos-defaults Configuration Group

Junos OS provides a hidden and immutable configuration group called junos-defaults that is automatically applied to the configuration of your router. 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, 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, include the selected junos- default-name statement at the applicable hierarchy level.

Using Wildcards with Configuration Groups

You can use wildcards to identify names and allow one statement to provide data for a variety of statements. For example, grouping the configuration of the sonet-options statement over all SONET/SDH interfaces or the dead interval for OSPF over all Asynchronous Transfer Mode (ATM) interfaces simplifies configuration files and eases their maintenance.

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 a [ rather than introduce a character class.

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

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

  • Exclamation point ( ! )—The character class can be complemented 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 used inside the groups hierarchy, an identifier name cannot start with < unless you are defining a wildcard statement, in which case the wildcard statement must have a closing >.

Wildcarding in configuration groups follows the same rules, but < and > have a special meaning when used under the groups hierarchy. In the groups hierarchy, any term using a wildcard pattern must be enclosed in angle brackets <pattern> to differentiate it from other wildcarding 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 <so-*> passes its sonet-options statement to any interface that matches the expression so-*.

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

Angle brackets allow you to pass normal wildcarding 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*>, just as the p value from <*c*> overrides the one from <*d*>. Data values from any of these groups override the data values from abcd.

Improving Commit Time When Using Configuration Groups

Configuration groups are used for applying configurations across other hierarchies without re-entering configuration data. Some configuration groups specify every configuration detail. Other configuration groups make use of wildcards to configure ranges of data, without detailing each configuration line. Some configurations have 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 impacted 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 allows the system to build the inheritance path for each configuration group inside the database, rather than in the process memory. This can improve commit time performance. However, it can also increase the database size by up to 22 percent.

Example: Configuring 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: Configuring Interfaces Using Configuration Groups

You can use configuration groups to separate the common interface media parameters from the interface-specific addressing information. The following example places configuration data for ATM interfaces into a group called atm-options.

Example: Configuring a Consistent IP Address for the Management Interface Using Configuration Groups

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

Optionally, for consistent access to the master Routing Engine, you can configure an additional IP address and 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 master Routing Engine. During switchover, the address moves to the new master Routing Engine.

In the following example, address 10.17.40.131 is configured for both Routing Engines and includes a master-only statement. With this configuration, the 10.17.40.131 address is active only on the master Routing Engine. The address remains consistent regardless of which Routing Engine is active. Address 10.17.40.132 is assigned to fxp0 on re0, and 10.17.40.133 is assigned to fxp0 on re1.

This feature is available on all routers that include dual Routing Engines. On a routing matrix composed of the TX Matrix router, this feature is applicable to the switch-card chassis (SCC) only. Likewise, on a routing matrix composed of a TX Matrix Plus router, this feature is applicable to the switch-fabric chassis (SFC) only.

Note
  • If you configure the same IP address for a management interface or internal interface such as fxp0 and an external physical interface such as ge-0/0/1, when graceful Routing Engine switchover (GRES) is enabled, the CLI displays an appropriate commit error message that identical addresses have been found on the private and public interfaces. In such cases, you must assign unique IP addresses for the two interfaces that have duplicate addresses.

  • The management Ethernet interface used for the TX Matrix Plus router, T1600 routers in a routing matrix, and PTX Series Packet Transport Routers, is em0. Junos OS automatically creates the router’s management Ethernet interface, em0.

Example: Configuring Peer Entities Using Configuration Groups

In this example, we create a group some-isp that contains configuration data relating to another Internet service provider (ISP). We can then insert apply-group statements at any point to allow any location in the configuration hierarchy to inherit this data.

Example: Establishing Regional Configurations Using Configuration Groups

In this example, one group is populated with configuration data that is standard throughout the company, while another group contains regional deviations from this standard:

Example: Configuring Wildcard Configuration Group Names

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

In this example, you configure 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 onto label-switched-path metro-major and any other label-switched-path configuration group containing -major in its name.

Example: Referencing the Preset Statement from the Junos OS defaults Group

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

To reference a preset Junos default statement from the Junos defaults group, include the junos-default-name statement at the applicable hierarchy level. For example, to reference the Junos 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: Viewing Default Statements That Have Been Applied to the Configuration

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

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

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

Setting Up Routing Engine Configuration Groups

In a router with two Routing Engines, one configuration should be shared between both Routing Engines. This 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.

For more information about the initial configuration for redundant Routing Engine systems and the re0 group, see High Availability Feature Guide.

  1. Create the configuration group re0. The re0 group is a special group designator that is only used by RE0 in a redundant routing platform.

  2. Navigate to the groups re0 level of the configuration hierarchy.

  3. Specify the device hostname.
    Note

    The hostname specified in the device configuration is not used by the DNS server to resolve to the correct IP address. This hostname is used 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 the TX Matrix Plus router, T1600 or T4000 routers in a routing matrix, and PTX Series Packet Transport Routers:

    • For the TX Matrix Plus router, T1600 or T4000 routers in a routing matrix only, and PTX Series Packet Transport Routers:

      To use em0 as an out-of-band management Ethernet interface, you must configure its logical port, em0.0, with a valid IP address.

    • For a T1600 standalone router (not connected to a TX Matrix Plus router and not in a routing matrix):

  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 except the TX Matrix Plus router, T1600 or T4000 routers in a routing matrix, and PTX Series Packet Transport Routers:

    • For the TX Matrix Plus router and T1600 or T4000 routers in a routing matrix only:

      To use em0 as an out-of-band management Ethernet interface, you must configure its logical port, em0.0, with a valid IP address.

    • For a T1600 standalone router (not connected to a TX Matrix Plus router, and not in a routing matrix):

  10. Return to the top level of the hierarchy.

  11. Specify the group application order.

Using Conditions to Apply Configuration Groups

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

You can configure a group to be applied 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.

Example: Configuring Conditions for Applying Configuration Groups

This example shows how to configure conditions under which a specified configuration group is to be applied.

Requirements

No special configuration beyond device initialization is required before you configure this example.

Overview

You can configure your group configuration data at the [edit groups group-name] hierarchy level, then use the when statement to have the group applied based on conditions including: Type of chassis, model, routing-engine, virtual chassis member, cluster node, and start and optional end time of day or date.

If you specify multiple conditions in a single configuration group, all conditions must be met before the configuration group is applied.

You can specify the start time or the time duration for the configuration group to be applied. If only the start time is specified, the configuration group is applied at the specified time and it remains in effect until the time is changed. If the end time is specified, then on each day, the applied configuration group is started and stopped at the specified times.

This example sets conditions in a configuration group, test1, such that this group is applied only when all of the following conditions are met: the router is a model MX240 router with chassis type LCC0, with a Routing Engine operating as RE0, is member0 of the virtual chassis on node0, and the configuration group will only be in effect from 9:00 a.m. until 5:00 p.m. each day.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Step-by-Step Procedure

To configure conditions for configuration group test1:

  1. Set the condition that identifies the model MX240 router.
  2. Set the condition that identifies the chassis type as LCC0.
  3. Set the condition that identifies the Routing Engine operating as RE0.
  4. Set the condition that identifies the virtual chassis member0.
  5. Set the condition that identifies the cluster node0.
  6. Set the condition that applies the group only between the hours of 9:00 a.m. and 5:00 p.m. daily.
    Note

    The syntax for specifying the time is: time <start-time> [to <end-time>] using the time format yyyy-mm-dd.hh:mm, hh:mm, or hh.

  7. Commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show groups test1 command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

Checking Group Inheritance with Conditional Data

Purpose

Verify that conditional data from a configuration group is inherited when applied.

Action

The show | display inheritance operational command can be issued with the when data to display the conditional inheritance. Using this example, you could issue one of these commands to determine that the conditional data was inherited: