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 SDH/SONET interfaces or the dead interval for OSPF over all ATM interfaces simplifies configuration files and eases their maintenance.
Wildcarding in normal configuration data is done in a style that is consistent with traditional UNIX shell name wildcarding. In this style of wildcarding, you can use the following metacharacters:
* )—Matches any string of characters.
? )—Matches any single character.
[ )—Introduces a character class.
] )—Indicates the end of a character class. If the close bracket is missing, the open bracket matches a [ rather than introducing a character class.
- )—Specifies a range of characters.
! )—The character class can be complemented by making an exclamation point the first character of the character class. To include a ``]'' 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.
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#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; } } }
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#showgroups { 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 inheritanceinterfaces { 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; } } } }