ON THIS PAGE
Example: Configuring Sets of Statements with Configuration Groups
Example: Configuring a Consistent IP Address for the Management Interface Using Configuration Groups
Example: Configuring Peer Entities Using Configuration Groups
Example: Establishing Regional Configurations Using Configuration Groups
Example: Referencing the Preset Statement from the Defaults Group
Example: Viewing Default Statements That Have Been Applied to the Configuration
Example: Configuring Conditions for Applying Configuration Groups
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 Configuration Groups
This topic provides an overview of configuration groups and the inheritance model in the Junos OS CLI.
Configuration Groups Overview
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, 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 Juniper Networks devices. 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.
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.
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 that group 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.
Creating a Configuration Group
The Junos OS CLI allows 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.
Configuration groups enable you to create smaller, more logically constructed configuration files, making it easier to configure and maintain device configurations. 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.
When you apply the group in the different sections of the configuration, that part of the configuration inherits the statements configured in that 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 changes are reflected automatically in the inherited target.
You can overwrite the values in the target configuration if required, which does not affect the source in the group.
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. For example,
you may want to configure all of your ge-0/0/1 interfaces
for the MTU value of 1500. To do this, you create a group with MTU
value 1500:
[edit groups group-1]
lab@vSRX3-05# show
interfaces {
ge-0/0/1 {
unit 0 {
family inet {
mtu 1500;
}
}
}
}Next, you apply the group in the interface configuration.
[edit interfaces ge-0/0/1] lab@vSRX3-05# set apply-groups group-1
View the inherited configuration.
[edit]
lab@vSRX3-05# show interfaces ge-0/0/1 | display inheritance
unit 0 {
family inet {
##
## '1500' was inherited from group 'group-1'
##
mtu 1500;
address 5.0.0.254/24;
}
}In this way, if you want to configure MTU value for interface ge-0/0/1 in different parts of configuration, you can apply
the group statement using 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 had used a configuration group, you could
just change the group config and all associated interfaces would be
automatically updated.
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 {
ge-* {
unit 0 {
family inet {
mtu 1500;
}
}
}
}See Also
Applying a Configuration Group
To have a Juniper Networks device configuration inherit the statements from a configuration
group, include the apply-groups statement:
apply-groups [ group-names ];
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.
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.
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 ];
}
}
}
}
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 Configuration Groups
In this example illustrating the creation and application
of configuration groups, 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.
[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;
}
}
See Also
Disabling Inheritance of a 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:
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: 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.
[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 {
so-1/1/0 {
apply-groups-except global; # Disables inheritance from group "global"
# so-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 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.
[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, 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 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:
[edit]
user@host# show | display inheritance no-comments
snmp {
location "West of Nowhere";
contact "My Engineering Group";
community BasicAccess {
authorization read-only;
}
}
See Also
Using the junos-defaults Configuration Group
Junos OS and Junos OS Evolved provide 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.
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:
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, 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.
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.
[edit]
groups {
sonet-default {
interfaces {
<so-*> {
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 <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:
[edit]
groups {
gigabit-ethernet-interfaces {
interfaces {
"<ge-1/2/[5-8]>" {
description "These interfaces reserved for Customer ABC";
}
}
}
}
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.
[edit] user@host#showgroups { 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 inheritanceprotocols { 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; } } }
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.
Example: Configuring Sets of Statements with Configuration Groups
When sets of statements exist in configuration groups, all values are inherited. For example:
[edit] user@host#showgroups { basic { snmp { interface so-1/1/1.0; } } } apply-groups basic; snmp { interface so-0/0/0.0; } [edit] user@host#show | display inheritancesnmp { ## ## ’so-1/1/1.0’ was inherited from group ’basic’ ## interface [ so-0/0/0.0 so-1/1/1.0 ]; }
For sets that are not displayed within brackets, all values are also inherited. For example:
[edit] user@host#showgroups { 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 inheritancesystem { 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: 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.
[edit] user@host#showgroups { atm-options { interfaces { <at-*> { atm-options { vpi 0 maximum-vcs 1024; } unit <*> { encapsulation atm-snap; point-to-point; family iso; } } } } } apply-groups atm-options; interfaces { at-0/0/0 { unit 100 { vci 0.100; family inet { address 10.0.0.100/30; } } unit 200 { vci 0.200; family inet { address 10.0.0.200/30; } } } } [edit] user@host#show | display inheritanceinterfaces { at-0/0/0 { ## ## "atm-options" was inherited from group "atm-options" ## atm-options { ## ## "1024" was inherited from group "atm-options" ## vpi 0 maximum-vcs 1024; } unit 100 { ## ## "atm-snap" was inherited from group "atm-options" ## encapsulation atm-snap; ## ## "point-to-point" was inherited from group "atm-options" ## point-to-point; vci 0.100; family inet { address 10.0.0.100/30; } ## ## "iso" was inherited from group "atm-options" ## family iso; } unit 200 { ## ## "atm-snap" was inherited from group "atm-options" ## encapsulation atm-snap; ## ## "point-to-point" was inherited from group "atm-options" ## point-to-point; vci 0.200; family inet { address 10.0.0.200/30; } ## ## "iso" was inherited from group "atm-options" ## family iso; } } } [edit] user@host#show | display inheritance | except ##interfaces { at-0/0/0 { atm-options { vpi 0 maximum-vcs 1024; } unit 100 { encapsulation atm-snap; point-to-point; vci 0.100; family inet { address 10.0.0.100/30; } family iso; } unit 200 { encapsulation atm-snap; point-to-point; vci 0.200; family inet { address 10.0.0.200/30; } family iso; } } }
See Also
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 primary Routing Engine, you must
know which Routing Engine is active and use the appropriate IP address.
Optionally, for consistent access to the primary 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 primary Routing Engine. During switchover, the address moves to the new primary 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 primary 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.
[edit groups re0 interfaces fxp0]
unit 0 {
family inet {
address 10.17.40.131/25 {
master-only;
}
address 10.17.40.132/25;
}
}
[edit groups re1 interfaces fxp0]
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. 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.
If you configure the same IP address for a management interface or internal interface such as
fxp0and an external physical interface such asge-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.
[edit] user@host#showgroups { 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 inheritanceinterfaces { 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: 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:
[edit] user@host#showgroups { standard { interfaces { <t3-*> { t3-options { compatibility-mode larscom subrate 10; idle-cycle-flag ones; } } } } northwest { interfaces { <t3-*> { t3-options { long-buildout; compatibility-mode kentrox; } } } } } apply-groups standard; interfaces { t3-0/0/0 { apply-groups northwest; } } [edit] user@host#show | display inheritanceinterfaces { t3-0/0/0 { ## ## "t3-options" was inherited from group "northwest" ## t3-options { ## ## "long-buildout" was inherited from group "northwest" ## long-buildout; ## ## "kentrox" was inherited from group "northwest" ## compatibility-mode kentrox; ## ## "ones" was inherited from group "standard" ## idle-cycle-flag ones; } } }
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.
[edit] user@host#showgroups { 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 inheritanceprotocols { 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: Referencing 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: Viewing Default Statements That Have Been Applied to the Configuration
To view the defaults that have been applied to the device configuration, issue the show |
display inheritance defaults command. For example, to view 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.
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 Junos OS High Availability User Guide.
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, although it should be noted that this example was configured and tested using an MX240 device.
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.
set groups test1 when model mx240set groups test1 when chassis lcc0set groups test1 when routing-engine re0set groups test1 when member member0set groups test1 when node node0set groups test1 when time 9 to 5
Procedure
Step-by-Step Procedure
To configure conditions for configuration group test1:
Set the condition that identifies the model MX240 router.
[edit groups test1 when] user@host#
set model mx240Set the condition that identifies the chassis type as LCC0.
[edit groups test1 when] user@host#
set chassis lcc0Set the condition that identifies the Routing Engine operating as
RE0.[edit groups test1 when] user@host#
set routing-engine re0Set the condition that identifies the virtual chassis
member0.[edit groups test1 when] user@host#
set member member0Set the condition that identifies the cluster
node0.[edit groups test1 when] user@host#
set node node0Set the condition that applies the group only between the hours of 9:00 a.m. and 5:00 p.m. daily.
[edit groups test1 when] user@host#
set time 9 to 5Note: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.Commit the configuration.
user@host#
commit
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.
user@host# show groups test1
when {
time 9 to 5;
chassis lcc0;
model mx240;
routing-engine re0;
member member0;
node node0;
}
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:
user@host>show | display inheritance when model mx240user@host>show | display inheritance when chassis lcc0user@host>show | display inheritance when routing-engine re0user@host>show | display inheritance when member member0user@host>show | display inheritance when node node0user@host>show | display inheritance when time 9 to 5