Regular expressions
are used in configuration groups to make them widely applicable. Portable
Operating System Interface for UNIX (POSIX) 1003.2 regular expressions are
supported in the names of configuration statements. Single quotes must be used
to delimit a regular expression.
Note
|
Not all POSIX
regular expressions are supported.
|
Regular
Expressions for Interface Identifiers
Configuration groups
do not accept exact interface identifiers. You must use a regular expression to
identify a group of interfaces that are applicable to the configuration group.
The regular expression ‘.*’ is not allowed. You must begin the regular
expression for an interface identifier with an unambiguous word, followed by
the regular expression. For example, to configure Gigabit Ethernet interfaces,
use the regular expression 'GigabitEthernet.*'.
To display a list of
available interface types for your router configuration, enter
interface ? at
the configuration group prompt:
RP/0/RP0/CPU0:router(config-GRP)# interface ?
ATM 'RegExp': ATM Network Interface(s)
BVI 'RegExp': Bridge-Group Virtual Interface
Bundle-Ether 'RegExp': Aggregated Ethernet interface(s)
GigabitEthernet 'RegExp': GigabitEthernet/IEEE 802.3 interface(s)
IMA 'RegExp': ATM Network Interface(s)
Loopback 'RegExp': Loopback interface(s)
MgmtEth 'RegExp': Ethernet/IEEE 802.3 interface(s)
Multilink 'RegExp': Multilink network interface(s)
Null 'RegExp': Null interface
PW-Ether 'RegExp': PWHE Ethernet Interface
PW-IW 'RegExp': PWHE VC11 IP Interworking Interface
Serial 'RegExp': Serial network interface(s)
tunnel-ip 'RegExp': GRE/IPinIP Tunnel Interface(s)
tunnel-mte 'RegExp': MPLS Traffic Engineering P2MP Tunnel interface(s)
tunnel-te 'RegExp': MPLS Traffic Engineering Tunnel interface(s)
tunnel-tp 'RegExp': MPLS Transport Protocol Tunnel interface
Note
|
Although you are
required to enter only enough characters for the interface type to be unique,
it is recommended that you enter the entire phrase. All interface types used in
regular expressions are case-sensitive.
|
To specify a
subinterface, prefix the expression with the characters \. (backslash period).
For example, use
interface
'GigabitEthernet.*\..*' to configure all Gigabit Ethernet
subinterfaces.
You can specify
Layer 2 transport interfaces or point-to-point interfaces as shown in these
examples:
group g-l2t
interface 'Gi.*\..*' l2transport
.
.
end-group
group g-ptp
interface 'Gi.*\..*' point-to-point
.
.
end-group
Regular
Expressions for an OSPF Configuration
Exact router process
names and OSPF areas cannot be used. You must use a regular expression to
specify a process name or group of OSPF areas. To specify that the OSFP area
can be either a scalar value or an IP address, use the regular expression ‘.*’,
as in this example:
group g-ospf
router ospf '.*'
area '.*'
mtu-ignore enable
!
!
end-group
To specify that the
OSPF area must be an IP address, use the expression '\.' as in this example:
group g-ospf-ipaddress
router ospf '.*\..*\..*\..*'
area '.*'
passive enable
!
!
end-group
To specify that the
OSPF area must be a scalar value, use the expression '1.*', as in this example:
group g-ospf-match-number
router ospf '.*'
area '1.*'
passive enable
!
!
end-group
Regular
Expressions for a BGP AS
Exact BGP AS values
cannot be used in configuration groups. Use a regular expression to specify
either AS plain format, or AS dot format as in the format X.Y. To match AS
plain format instances, use a simple regular expression. To match AS dot format
instances, use two regular expressions separated by a dot, as shown in this
example:
group g-bgp
router bgp '*'.'*'
address-family ipv4 unicast
!
!
end-group
Regular
Expressions for ANCP
Exact Access Node
Control Protocol (ANCP) sender-name identifiers cannot be used in configuration
groups. Because the sender name argument can be either an IP address or a MAC
address, you must specify in the regular expression which one is being used.
Specify an IP address as
'.*\..*\..*\..*'; specify a MAC address as
'.*\..*\..*'.
Resolving to a
Uniform Type
Regular expressions
must resolve to a uniform type. This is an example of an illegal regular
expression:
group g-invalid
interface ‘.*’
bundle port-priority 10
!
interface ‘.*Ethernet.*’
bundle port-priority 10
!
end-group
In this example,
the
bundle command
is supported for interface type GigabitEthernet but not for interface type
‘FastEthernet’. The regular expressions ‘.*’ and ‘.*Ethernet.*’ match both
GigabitEthernet and FastEthernet types. Because the
bundle command
is not applicable to both these interface types, they do not resolve to a
uniform type and therefore the system does not allow this configuration.
Note
|
If the system
cannot determine from the regular expression what the configuration should be,
the expression is not considered valid.
|
Note
|
The regular
expression ‘.*’ is not allowed when referring to an interface identifier. You
must begin the regular expression for an interface identifier with an
unambiguous word, followed by the regular expression. Refer to
Regular
Expressions for Interface Identifiers in this section for more
information.
|
Overlapping Regular Expressions
Regular expressions are used in names of configuration statements within a configuration group. This permits inheritance
by the configuration when applied to matching names. Single quotes are used to delimit the regular expression. Overlapping
regular expression within a configuration group for the same configuration is permitted.
The example, given below, illustrates the process of creating and applying multiple configuration groups:
RP/0/RP0/CPU0:router(config)#group FB_flexi_snmp
RP/0/RP0/CPU0:router(config-GRP)# snmp-server vrf '.*'
RP/0/RP0/CPU0:router(config-GRP-snmp-vrf)# host 1.1.1.1 traps version 2c group_1
RP/0/RP0/CPU0:router(config-GRP-snmp-vrf)# host 1.1.1.1 informs version 2c group_1
RP/0/RP0/CPU0:router(config-GRP-snmp-vrf)# context group_1
RP/0/RP0/CPU0:router(config-GRP-snmp-vrf)#
RP/0/RP0/CPU0:router(config-GRP-snmp-vrf)#commit
RP/0/RP0/CPU0:router(config-GRP-snmp-vrf)#root
RP/0/RP0/CPU0:router(config)#
RP/0/RP0/CPU0:router(config)#snmp-server vrf vrf1
RP/0/RP0/CPU0:router(config-snmp-vrf)#snmp-server vrf vrf10
RP/0/RP0/CPU0:router(config-snmp-vrf)#!
RP/0/RP0/CPU0:router(config-snmp-vrf)#snmp-server vrf vrf100
RP/0/RP0/CPU0:router(config-snmp-vrf)#
RP/0/RP0/CPU0:router(config-snmp-vrf)#commit
RP/0/RP0/CPU0:router(config-snmp-vrf)#root
RP/0/RP0/CPU0:router(config)#
RP/0/RP0/CPU0:router(config)#apply-group FB_flexi_snmp
RP/0/RP0/CPU0:router(config)#do sh running-config group
group FB_flexi_snmp
snmp-server vrf '.*'
host 1.1.1.1 traps version 2c group_1
host 1.1.1.1 informs version 2c group_1
context group_1
!
end-group
apply-group FB_flexi_snmp
snmp-server vrf vrf1
!
snmp-server vrf vrf10
!
snmp-server vrf vrf100
!
RP/0/RP0/CPU0:ios#show running-config inheritance detail
group FB_flexi_snmp
snmp-server vrf '.*'
host 1.1.1.1 traps version 2c group_1
host 1.1.1.1 informs version 2c group_1
context group_1
!
end-group
snmp-server vrf vrf1
## Inherited from group FB_flexi_snmp
host 1.1.1.1 traps version 2c group_1
## Inherited from group FB_flexi_snmp
host 1.1.1.1 informs version 2c group_1
## Inherited from group FB_flexi_snmp
context group_1
!
snmp-server vrf vrf10
## Inherited from group FB_flexi_snmp
host 1.1.1.1 traps version 2c group_1
## Inherited from group FB_flexi_snmp
host 1.1.1.1 informs version 2c group_1
## Inherited from group FB_flexi_snmp
context group_1
!
snmp-server vrf vrf100
## Inherited from group FB_flexi_snmp
host 1.1.1.1 traps version 2c group_1
## Inherited from group FB_flexi_snmp
host 1.1.1.1 informs version 2c group_1
## Inherited from group FB_flexi_snmp
context group_1
The example given below demonstrates the regular expression. In this example snmp-server vrf '.*’ and snmp-server vrf '[\w]+ are two different regular expressions.
group FB_flexi_snmp
snmp-server vrf '.*’
host 1.1.1.1 traps version 2c group_1
host 1.1.1.1 informs version 2c group_1
context group_1
!
snmp-server vrf '[\w]+’
host 2.2.2.2 traps version 2c group_2
host 2.2.2.2 informs version 2c group_2
context group_2
!
end-group
This individual regular expression gets combined to all the three expressions - snmp-server vrf vrf1, snmp-server vrf vrf10 and snmp-server vrf vrf100 as given below.
apply-group FB_flexi_snmp
snmp-server vrf vrf1
!
snmp-server vrf vrf10
!
snmp-server vrf vrf100
!
In a configuration group, there can be instances of regular expressions overlap. In such cases, the regular expression with
the highest priority is activated and inherited, when applied. It has that regular expression, which comes first in the lexicographic
order that has the highest priority.
The following example shows how to use overlapping regular expressions and how the expression with higher priority is applied:
group FB_flexi_snmp
snmp-server vrf '.*’
host 1.1.1.1 traps version 2c group_1
host 1.1.1.1 informs version 2c group_1
context group_1
!
snmp-server vrf '[\w]+’
host 2.2.2.2 traps version 2c group_2
host 2.2.2.2 informs version 2c group_2
context group_2
!
end-group
The expression shown below has the highest priority:
group FB_flexi_snmp
snmp-server vrf '.*’
host 1.1.1.1 traps version 2c group_1
host 1.1.1.1 informs version 2c group_1
context group_1
The examples given above, show two different regular expression snmp-server vrf '.*’ and snmp-server vrf '[\w]+'.
The expression below, shows how these two expressions get merged together:
apply-group FB_flexi_snmp
snmp-server vrf vrf1
!
snmp-server vrf vrf10
!
snmp-server vrf vrf100
!
Any change in a regular expression with lower priority will not affect the inheritance.
Any changes made to an existing regular expression, which is of less (non-top) priority, it will not have any effect on the
inheritance.
snmp-server vrf '[\w]+’
host 2.2.2.2 traps version 2c group_2
host 2.2.2.2 informs version 2c group_2
context group_2
The expression with the higher priority gets inherited, as shown below:
group FB_flexi_snmp
snmp-server vrf '.*’
host 1.1.1.1 traps version 2c group_1
host 1.1.1.1 informs version 2c group_1
context group_1
Apply Groups Priority Inheritance
Priority governs inheritance.
Note
|
From the Cisco IOS XR, Release 6.3.1 onwards, you are able to enter the Flexible CLI config group definition, apply-group and exclude-group command in any order as long as the entire commit has all the group definitions needed.
|
Apply groups priority inheritance helps flexible configuration groups to handle common configuration statements between groups.
When multiple configuration groups have common configuration statements, the inheritance priority is such that the configuration
statements present in inner groups have precedence over those configuration statements present in outer groups. In case of
tiebreakers, the priority is assigned in accordance to the lexicographical order of regular expressions. User defined order
of commands are not accepted.
For example, a configuration statement in configuration group ONE has precedence over another group. A configuration statement
in configuration group SEVEN is used only if it does not exist in any other group. Within a configuration group, inheritance
priority is the longest match.
apply-group SIX SEVEN
router ospf 0
apply-group FOUR FIVE
area 0
apply-group THREE
interface GigabitEthernet0/0/0/0
apply-group ONE TWO
!
!
!
The above example shows two scenarios. The inner most group (apply-group ONE TWO) has the highest priority.
Case 1
The first scenario shows which group gets the priority. The example states which group is applied between different configuration
groups (different groups with nothing in common). While applying group one (ONE TWO), all the seven groups matches the interface
interface GigabitEthernet0/0/0/0- is applied.
Case 2
Here, when all have the same (common) configuration, group one will be active. That is apply-group ONE TWO is active. If group ONE is deleted, then group TWO will be active.
Feedback