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: Use Configuration Groups to Establish Regional Configurations
Example: Reference the Preset Statement from the Defaults Group
Example: View Default Statements That Have Been Applied to the Configuration
Example: Configure Conditions for Applying Configuration Groups
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 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 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 ge-0/0/1 interfaces for the MTU value of
1500.
To do configure all of your ge-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 { 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; } }
If you want to configure MTU value for interface ge-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 {
ge-* {
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 replacecommand. -
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 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 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 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 {
<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 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
pvalue 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; } } }
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#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: Configure 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: 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 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.
-
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
fxp0and an external physical interface such asge-0/0/1. -
The
em0management Ethernet interface is used for the TX Matrix Plus router, T1600 routers in a routing matrix, and PTX Series Packet Transport Routers. Junos OS automatically creates the device's management Ethernet interface,em0.
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#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: Use Configuration Groups to Establish Regional Configurations
This example populates one group 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: 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#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: 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.
For more information about the initial configuration for redundant Routing Engine systems and the re0 group, see Junos OS High Availability User Guide.
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.
Example: Configure 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. You can then use
the when statement to apply the group configuration based on
conditions such as these: 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
In 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
Check Group Inheritance with Conditional Data
Purpose
Verify that conditional data from a configuration group is inherited when applied.
Action
Issue the show | display inheritance operational command with the
when data to display the conditional inheritance.
Using this example, you can 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