[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]

Configuration Groups Configuration Guidelines

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. This section covers the following topics:

Creating a Configuration Group

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

[edit]
groups {
group-name {
configuration-data;
}
lccn-re0 {
configuration-data;
}
lccn-re1 {
configuration-data;
}
}

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

One reason for the naming restriction is a configuration group called junos-defaults. This preset configuration group is applied to the configuration automatically. You cannot modify or remove the junos-defaults configuration group. For more information about the JUNOS default configuration group, see Using JUNOS Default Groups.

On routers that support multiple Routing Engines, you can also specify two special 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.

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

configuration-data contains the configuration statements applied elsewhere in the configuration with the apply-groups statement. To have a configuration inherit the statements in a configuration group, include the apply-groups statement. For information about the apply-groups statement, see Applying a Configuration Group.

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

n identifies the T640 routing node and can be from 0 through 3. For example, to configure Routing Engine 1 properties for lcc3, you include statements at the[edit groups lcc3–re1] hierarchy level. For information about the TX Matrix platform and routing matrix, see the JUNOS System Basics Configuration Guide

Applying a Configuration Group

To have a configuration inherit the statements in 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 ];
}
}
}
}

Example: Configuring and Applying Configuration Groups

In this example, the Simple Network Management Protocol (SNMP) configuration is divided between the group basic and the normal configuration hierarchy.

There are a number of advantages to placing the system-specific configuration (SNMP contact) into a configuration group and thus separating it from the normal configuration hierarchy—the user 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;
}
}

For information about how to disable inheritance of a configuration group, see Disabling Inheritance of a Configuration Group.

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

[edit]
groups {
re0 { # Routing Engine 0 on TX Matrix platform
system {
host-name <host-name>;
backup-router <ip-address>;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address <ip-address>;
}
}
}
}
}
re1 { # Routing Engine 1 on TX Matrix platform
system {
host-name <host-name>;
backup-router <ip-address>;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address <ip-address>;
}
}
}
}
lcc0-re0 { # Routing Engine 0 on T640 routing node numbered 0
system {
host-name <host-name>;
backup-router <ip-address>;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address <ip-address>;
}
}
}
lcc0-re1 { # Routing Engine 1 on T640 routing node numbered 0
system {
host-name <host-name>;
backup-router <ip-address>;
}
interfaces {
fxp0 {
unit 0 {
family inet {
address <ip-address>;
}
}
}
}
apply-groups [ re0 re1 lcc0-re0 lcc0-re1 ];
}

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 hold-time and link-mode.

[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"
}

For information about applying a configuration group, see Applying a Configuration Group.

Displaying Inherited Values

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 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 Open Shortest Path First (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:

Wildcarding in configuration groups follows the same rules, but the wildcard pattern must be enclosed in angle brackets (<pattern>) to differentiate it from other wildcarding in the configuration file. For example:

[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 example above, the expression <so-*> passes its sonet-options statement to any interface that matches the expression so-*.

Angle brackets allow you to pass normal wildcarding through without modification. In all 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# 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;
}
}
}

Example: Using Wildcards with Configuration Groups

The following example demonstrates the use of wildcarding. The interface so-0/0/0 inherits data from the various SONET/SDH interface wildcard patterns in group one.

[edit]
user@host# show
groups {
one {
interfaces {
<so-*> {
sonet-options {
rfc-2615;
}
}
<so-0/*> {
sonet-options {
fcs 32;
}
}
<so-*/0/*> {
sonet-options {
fcs 16;
}
}
<so-*/*/0> {
sonet-options {
payload-scrambler;
}
}
}
}
}
apply-groups one;
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.0.0.1/8;
}
}
}
}
[edit]
user@host# show | display inheritance
interfaces {
so-0/0/0 {
##
## ’sonet-options’ was inherited from group ’one’
##
sonet-options {
##
## ’32’ was inherited from group ’one’
##
fcs 32;
##
## ’payload-scrambler’ was inherited from group ’one’
##
payload-scrambler;
##
## ’rfc-2615’ was inherited from group ’one’
##
rfc-2615;
}
unit 0 {
family inet {
address 10.0.0.1/8;
}
}
}
}
[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]

[an error occurred while processing this directive]