ON THIS PAGE
Example: Configure Sets of Statements with Configuration Groups
Example: Use Configuration Groups to Configure a Consistent IP Address for the Management Interface
Example: Use Configuration Groups to Configure Peer Entities
Example: Reference the Preset Statement from the Defaults Group
Example: View Default Statements That Have Been Applied to the Configuration
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:
-
Configure statements into a configuration group. To configure configuration groups and inheritance, you can include the groups statement at the [edit] hierarchy level:
[edit] groups {
group-name
{configuration-data
; } } -
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:
-
Create a group with MTU value 1500:
[edit groups group-1] lab@vSRX3-05# show interfaces { et-0/0/1 { unit 0 { family inet { mtu 1500; } } } }
-
Next, you apply the group in the interface configuration.
[edit interfaces et-0/0/1] lab@vSRX3-05# set apply-groups group-1
-
View the inherited configuration.
[edit] lab@vSRX3-05# show interfaces et-0/0/1 | display inheritance unit 0 { family inet { ## ## '1500' was inherited from group 'group-1' ## mtu 1500; address 5.0.0.254/24; } }
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:
[edit groups group-1] lab@vSRX3-05# show interfaces { et-* { unit 0 { family inet { mtu 1500; } } } }
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.
apply-groups [ group-names ];
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.
apply-groups [ eight nine ten ]; protocols { apply-groups seven; bgp { apply-groups [ five six ]; group some-bgp-group { apply-groups four; neighbor 10.0.0.1 { apply-groups [ one two three ]; } } } }
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.
[edit] groups { basic { # User-defined group name snmp { # This group contains some SNMP data contact "My Engineering Group"; community BasicAccess { authorization read-only; } } } } apply-groups basic; # Enable inheritance from group "basic" snmp { # Some normal (non-group) configuration location "West of Nowhere"; }
This configuration is equivalent to the following:
[edit] snmp { location "West of Nowhere"; contact "My Engineering Group"; community BasicAccess { authorization read-only; } }
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:
apply-groups-except [ group-names ];
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.
[edit] groups { # "groups" is a top-level statement global { # User-defined group name interfaces { <*> { hold-time down 640; link-mode full-duplex; } } } } apply-groups global; interfaces { et-1/1/0 { apply-groups-except global; # Disables inheritance from group "global" # et-1/1/0 uses default value for “hold-time” # and "link-mode" } }
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:
[edit]
user@host# show | display inheritance
snmp {
location "West of Nowhere";
##
## 'My Engineering Group' was inherited from group 'basic'
##
contact "My Engineering Group";
##
## 'BasicAccess' was inherited from group 'basic'
##
community BasicAccess {
##
## 'read-only' was inherited from group 'basic'
##
authorization read-only;
}
}
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:
[edit]
user@host# show | display inheritance | except ##
snmp {
location "West of Nowhere";
contact "My Engineering Group";
community BasicAccess {
authorization read-only;
}
}
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:
[edit]
user@host# show | display inheritance no-comments
snmp {
location "West of Nowhere";
contact "My Engineering Group";
community BasicAccess {
authorization read-only;
}
}
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.
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:
user@host# show groups junos-defaults
# Make vt100 the default for the console port
system {
ports {
console type vt100;
}
}
applications {
# File Transfer Protocol
application junos-ftp {
application-protocol ftp;
protocol tcp;
destination-port 21;
}
# Trivial File Transfer Protocol
application junos-tftp {
application-protocol tftp;
protocol udp;
destination-port 69;
}
# RPC port mapper on TCP
application junos-rpc-portmap-tcp {
application-protocol rpc-portmap;
protocol tcp;
destination-port 111;
}
# RPC port mapper on UDP
}
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.
user@host>show configuration groups junos-defaults applications
## protect: groups junos-defaults
##
#
# File Transfer Protocol
#
application junos-ftp {
application-protocol ftp;
protocol tcp;
destination-port 21;
}
#
# Trivial File Transfer Protocol
#
application junos-ftp-data {
application-protocol ftp-data;
protocol tcp;
destination-port 20;
}
application junos-tftp {
application-protocol tftp;
protocol udp;
destination-port 69;
}
#
# Two-Way Active Measurement Protocol
#
application junos-twamp {
application-protocol twamp;
protocol tcp;
destination-port 862;
}
#
# Real Time Streaming Protocol
#
application junos-rtsp {
application-protocol rtsp;
protocol tcp;
destination-port 554;
}
#
# Network Basic Input Output System - networking protocol used on
# Windows networks session service port
#
application junos-netbios-session {
protocol tcp;
destination-port 139;
}
application junos-smb-session {
protocol tcp;
destination-port 445;
}
application junos-ssh {
protocol tcp;
destination-port 22;
}
application junos-telnet {
protocol tcp;
destination-port 23;
}
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.
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.
[edit] groups { sonet-default { interfaces { <et-*> { sonet-options { payload-scrambler; rfc-2615; } } } } }
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:
[edit] groups { gigabit-ethernet-interfaces { interfaces { "<et-1/2/[5-8]>" { description "These interfaces reserved for Customer ABC"; } } } }
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
:
[edit] user@host#show
groups { one { protocols { bgp { group <*a*> { preference 1; } group <*b*> { preference 2; } group <*c*> { out-delay 3; } group <*d*> { out-delay 4; } group abcd { preference 10; hold-time 10; out-delay 10; } } } } } protocols { bgp { group abcd { apply-groups one; } } } [edit] user@host#show | display inheritance
protocols { bgp { group abcd { ## ## ’1’ was inherited from group ’one’ ## preference 1; ## ## ’10’ was inherited from group ’one’ ## hold-time 10; ## ## ’3’ was inherited from group ’one’ ## out-delay 3; } } }
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:
[edit] user@host#show
groups { basic { snmp { interface et-1/1/1.0; } } } apply-groups basic; snmp { interface et-0/0/0.0; } [edit] user@host#show | display inheritance
snmp { ## ## ’et-1/1/1.0’ was inherited from group ’basic’ ## interface [ et-0/0/0.0 et-1/1/1.0 ]; }
For sets that are not displayed within brackets, all values are also inherited. For example:
[edit] user@host#show
groups { worldwide { system { name-server { 10.0.0.100; 10.0.0.200; } } } } apply-groups worldwide; system { name-server { 10.0.0.1; 10.0.0.2; } } [edit] user@host#show | display inheritance
system { name-server { ## ## ’10.0.0.100’ was inherited from group ’worldwide’ ## 10.0.0.100; ## ## ’10.0.0.200’ was inherited from group ’worldwide’ ## 10.0.0.200; 10.0.0.1; 10.0.0.2; } }
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
.
[edit groups re0 interfaces re0:mgmt-0] unit 0 { family inet { address 10.17.40.131/25 { master-only; } address 10.17.40.132/25; } } [edit groups re1 interfaces re1:mgmt-0] unit 0 { family inet { address 10.17.40.131/25 { master-only; } address 10.17.40.133/25; } }
This feature is available on all routers that include dual Routing Engines.
-
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 aset-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.
[edit] user@host#show
groups { some-isp { interfaces { <xe-*> { gigether-options { flow-control; } } } protocols { bgp { group <*> { neighbor <*> { remove-private; } } } pim { interface <*> { version 1; } } } } } interfaces { xe-0/0/0 { apply-groups some-isp; unit 0 { family inet { address 10.0.0.1/24; } } } } protocols { bgp { group main { neighbor 10.254.0.1 { apply-groups some-isp; } } } pim { interface xe-0/0/0.0 { apply-groups some-isp; } } } [edit] user@host#show | display inheritance
interfaces { xe-0/0/0 { ## ## "gigether-options" was inherited from group "some-isp" ## gigether-options { ## ## "flow-control" was inherited from group "some-isp" ## flow-control; } unit 0 { family inet { address 10.0.0.1/24; } } } } protocols { bgp { group main { neighbor 10.254.0.1 { ## ## "remove-private" was inherited from group "some-isp" ## remove-private; } } } pim { interface xe-0/0/0.0 { ## ## "1" was inherited from group "some-isp" ## version 1; } } }
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.
[edit] user@host#show
groups { mpls-conf { protocols { mpls { label-switched-path <*-major> { retry-timer 5; bandwidth 155m; optimize-timer 60; } label-switched-path <*-minor> { retry-timer 15; bandwidth 64k; optimize-timer 120; } } } } } apply-groups mpls-conf; protocols { mpls { label-switched-path metro-major { to 10.0.0.10; } label-switched-path remote-minor { to 10.0.0.20; } } } [edit] user@host#show | display inheritance
protocols { mpls { label-switched-path metro-major { to 10.0.0.10; ## ## "5" was inherited from group "mpls-conf" ## retry-timer 5; ## "155m" was inherited from group "mpls-conf" ## bandwidth 155m; ## ## "60" was inherited from group "mpls-conf" ## optimize-timer 60; } label-switched-path remote-minor { to 10.0.0.20; ## ## "15" was inherited from group "mpls-conf" ## retry-timer 15; ## ## "64k" was inherited from group "mpls-conf" ## bandwidth 64k; ## ## "120" was inherited from group "mpls-conf" ## optimize-timer 120; } } }
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:
[edit] groups { junos-defaults { applications { application junos-ftp {# Use FTP default configuration application-protocol ftp; protocol tcp; destination-port 21; } } }
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:
[edit] services { stateful-firewall { rule my-rule { term my-term { from { applications junos-ftp; #Reference predefined statement, junos-ftp } } } } }
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:
user@host# show system ports | display inheritance defaults
## ## 'console' was inherited from group 'junos-defaults'
## 'vt100' was inherited from group 'junos-defaults'
## console type vt100;
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:
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.