Using Configuration Groups

Creating Configuration Groups

Configuration groups are created in the groups branch of the configuration tree.

(ex)[/configure]
A:admin@node-2# info
    groups {
        group "isis-backbone" {
            router "Base" {
                isis "0" {
                    interface "int-pe1-pe2" {
                        hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk" hash
                        hello-authentication-type message-digest
                        hello-authentication true
                        interface-type point-to-point
                    }
                }
            }
        }
    }

Multiple configuration groups can be created, each with a unique name.

(ex)[/configure]
A:admin@node-2# info
    groups {
        group "isis-backbone" {
            router "Base" {
                # configuration elements
            }
        }
        group "isis-access” {
            router "Base" {
                # configuration elements
            }
        }      
        group "qos-backbone” {
            card "1" {
                # configuration elements
            }
            port "1/1/1" {
                # configuration elements
            }
            qos {
                # configuration elements
            }
            router "Base" {
                # configuration elements
            }
        }      
    }

The configuration elements in a configuration group always start at a top-level configuration branch, such as router, qos, or card.

To match on a key of a list entry in a configuration group, an exact match or a regular expression match can be used.

Exact Match

With an exact match, configuration elements can only be inherited by the list entry that matches the specified key value. When no list entry is matched, a new list entry is created with the specified key value.

In the following example, interface ‟int-pe1-pe2” is an exact match. When the group is applied and IS-IS interface ‟int-pe1-pe2” exists in IS-IS instance 0, the interface-type leaf is inherited. If the IS-IS interface does not exist, it is created with the interface-type set to point-to-point.

(ex)[/configure]
A:admin@node-2# info
    groups {
        group "isis-backbone" {
            router "Base" {
                isis "0" {
                    interface "int-pe1-pe2" {
                        interface-type point-to-point
                    }
                }
            }
        }
    }

Regular Expression Match

With a regular expression match, configuration elements can be inherited by all list entries for which the key value matches the regular expression. A list entry cannot be created with a regular expression match.

In the following example, interface ‟<.*>” is a regular expression match that matches any interface name. When the group is applied, all configured IS-IS interfaces in IS-IS instance 0 inherit the interface-type leaf.

(ex)[/configure]
A:admin@node-2# info
    groups {
        group "isis-backbone" {
            router "Base" {
                isis "0" {
                    interface "<.*>" {
                        interface-type point-to-point
                    }
                }
            }
        }
    }

Regular Expression Match Format

A regular expression match is specified as a string with the regular expression enclosed in quotation marks and angle brackets: ‟<regex-match>”.

The regular expression match is implicitly anchored: a ^ (match-starting position) is added at the beginning of the regular expression and a $ (match-ending position) is added at the end.

The regular expression is a subset of the Extended Regular Expression (ERE) notation as described in Using Regular Expressions with | match.

For example:

interface ‟<int-.*>” — matches all interfaces that start with ‟int-”
interface ‟<.*>” — matches all interfaces
interface ‟<.*pe[1-3].*>” — matches all interfaces that have ‟pe1”, ‟pe2”, or ‟pe3” in their name

Note: A regular expression match on an encrypted leaf is restricted to a match all: ‟<.*>”. Any other string enclosed in angle brackets (‟<string>”) is accepted as an exact match for the encrypted leaf and displayed as a hashed value in the configuration.

Conflicting Match Criteria Within a Configuration Group

With a regular expression match, a match criteria conflict can occur if two regular expressions match or if a regular expression and an exact match both match on the same list entry. Conflicting matches within a configuration group are not supported and result in a validation error.

In the following configuration example, both interface ‟<int-.*>” and interface ‟int-pe1-pe2” match isis 0 interface ‟int-pe1-pe2”. At validation, this results in a configuration group inheritance failure because of conflicting match criteria:

(ex)[/configure]
A:admin@node-2# info 
    groups {
        group "isis-backbone" {
            router "Base" {
                isis "0" {
                    interface "<int-.*>" {
                        interface-type point-to-point
                        level-capability 2
                    }
                    interface "int-pe1-pe2" {
                        level 2 {
                            hello-interval 1
                        }
                    }
                }
            }
        }
    }

---snip---

    router "Base" {

---snip---

        isis 0 {
            apply-groups ["isis-backbone"]

---snip---
            interface "int-pe1-pe2" {
---snip---

           }
        }
    }

(ex)[/configure]
A:admin@node-2# validate
MINOR: MGMT_CORE #2901: configure router "Base" isis 0 interface "int-pe1-pe2" - Configuration group inheritance failed - conflicting match criteria within group   "isis-backbone"

Conflicting match criteria within a configuration group can be avoided by applying multiple configuration groups.

*(ex)[/configure]
A:admin@node-2# info 
    groups {
        group "isis-backbone-common" {
            router "Base" {
                isis "0" {
                    interface "<int-.*>" {
                        interface-type point-to-point
                        level-capability 2
                    }
                }
            }
        }
        group "isis-backbone-custom" {
            router "Base" {
                isis "0" {
                    interface "int-pe1-pe2" {
                        level 2 {
                            hello-interval 1
                        }
                    }
                }
            }
        }
    }

---snip---

    router "Base" {

---snip---

        isis 0 {
            apply-groups ["isis-backbone-custom" "isis-backbone-common"]

---snip---

            interface "int-pe1-pe2" {
---snip---
           }
        }
    }

*(ex)[/configure router "Base" isis 0]
A:admin@node-2# validate

*(ex)[/configure router "Base" isis 0]
A:admin@node-2# info inheritance
    apply-groups ["isis-backbone-custom" "isis-backbone-common"]
    interface "int-pe1-pe2" {
        ## inherited: from group "isis-backbone-common"
        interface-type point-to-point
        ## inherited: from group "isis-backbone-common"
        level-capability 2
        level 2 {
            ## inherited: from group "isis-backbone-custom"
            hello-interval 1
        }
    }

Applying Configuration Groups

To inherit configuration elements from a configuration group, apply the group in a branch of the configuration tree with the apply-groups statement. For example:

(ex)[/configure router "Base" isis 0]
A:admin@node-2# info
    apply-groups ["isis-1"]

Configuration elements from the corresponding branches where the group is applied are inherited. In the following example, the configuration group ‟isis-3” has configuration elements in both the router isis interface and router isis level branch. Because the configuration group is applied at the router isis interface branch, only these configuration elements are inherited.

(ex)[/configure]
A:admin@node-2# info
    groups {
        group "isis-3" {
            router "Base" {
                isis "0" {
                    interface "<int-.*>" {
                        interface-type point-to-point
                        level "2" {
                            metric 30
                        }
                    }
                    level "2" {
                        wide-metrics-only true
                    }
                }
            }
        }
    }

---snip---

   router "Base" {
        isis 0 {
            admin-state enable
            level-capability 2
            area-address [49.0001.0001]
            interface "int-pe1-pe2" {
                apply-groups ["isis-3"]
            }
        }
    }

The resulting expanded configuration can be shown with the info inheritance command:

(ex)[/configure]
A:admin@node-2# info inheritance
   router "Base" {
        isis 0 {
            admin-state enable
            level-capability 2
            area-address [49.0001.0001]
            interface "int-pe1-pe2" {
                apply-groups ["isis-3"]
                ## inherited: from group "isis-3"
                interface-type point-to-point
                level 2 {
                    ## inherited: from group "isis-3"
                    metric 30
                }
            }
        }
    }

The following notes apply to configuration groups and the apply-groups statements:

configuration groups cannot be nested; therefore, apply-groups statements cannot be part of a configuration group
configuration groups that are not applied in the configuration do not functionally change the configuration
configuration groups and apply-groups statements are part of the running configuration and are saved in the MD-CLI configuration file
the apply-groups statement can be configured in the configuration root (that is, /configure) but is not displayed in the online help for the context

Inheritance Rules

Local configuration elements have precedence over configuration group inheritance.

In the following example, the configuration group "isis-1" contains the configuration element level-capability 1, which is not inherited because a corresponding local configuration element exists.

(ex)[/configure]
A:admin@node-2# info
    groups {
        group "isis-1" {
            router "Base" {
                isis "0" {
                    level-capability 1
                    interface "<int-.*>" {
                        interface-type point-to-point
                        level "2" {
                            metric 10
                        }
                    }
                }
            }
        }
    }

---snip---

   router "Base" {
        isis 0 {
            apply-groups ["isis-1"]
            admin-state enable
            level-capability 2
            area-address [49.0001.0001]
            interface "int-pe1-pe2" {
            }
        }
    }

The resulting expanded configuration after inheritance is shown as follows:

(ex)[/configure]
A:admin@node-2# info inheritance
   router "Base" {
        isis 0 {
            apply-groups ["isis-1"]
            admin-state enable
            level-capability 2
            area-address [49.0001.0001]
            interface "int-pe1-pe2" {
                ## inherited: from group "isis-1"
                interface-type point-to-point
                level 2 {
                    ## inherited: from group "isis-1"
                    metric 10
                }
            }
        }
    }

Up to eight configuration groups can be applied to a configuration branch. The configuration order determines the inheritance precedence:

configuration elements in the first listed group have the highest precedence
configuration elements in the last listed group have the lowest precedence

In the following example, both configuration groups "isis-1" and "isis-2" set an interface level 2 metric. Because configuration group "isis-2" is listed first in the apply-groups, its configuration elements have precedence. The interface-type configuration element is inherited from group "isis-1" because a corresponding configuration element is not present in group "isis-2" nor is it locally configured.

(ex)[/configure]
A:admin@node-2# info
    groups {
        group "isis-1" {
            router "Base" {
                isis "0" {
                    level-capability 1
                    interface "<int-.*>" {
                        interface-type point-to-point
                        level "2" {
                            metric 10
                        }
                    }
                }
            }
        }
        group "isis-2" {
            router "Base" {
                isis "0" {
                    interface "<int-.*>" {
                        level "2" {
                            metric 20
                        }
                    }
                }
            }
        }
    }

---snip---

   router "Base" {
        isis 0 {
            apply-groups ["isis-2" "isis-1"]
            admin-state enable
            level-capability 2
            area-address [49.0001.0001]
            interface "int-pe1-pe2" {
            }
        }
    }

The resulting expanded configuration after inheritance is shown as follows:

(ex)[/configure]
A:admin@node-2# info inheritance
   router "Base" {
        isis 0 {
            apply-groups ["isis-2" "isis-1"]
            admin-state enable
            level-capability 2
            area-address [49.0001.0001]
            interface "int-pe1-pe2" {
                ## inherited: from group "isis-1"
                interface-type point-to-point
                level 2 {
                    ## inherited: from group "isis-2"
                    metric 20
                }
            }
        }
    }

Configuration groups can be applied at different hierarchical branches. The hierarchy determines the inheritance precedence.

Configuration elements in groups applied at a lower-level branch have precedence over configuration elements in groups applied at a higher-level branch.

In the following example, all configuration groups set an interface level 2 metric. Because configuration group "isis-3" is applied at the lowest level, its configuration elements have precedence. The interface-type configuration element is also inherited from group "isis-3" for the same reason. As described earlier, the level-capability configuration element from group "isis-1" has lower precedence than the local configured value. The wide-metric-only configuration element from group "isis-3" is not inherited because the group is applied at the interface branch and only configuration elements at that level or lower can be inherited.

(ex)[/configure]
A:admin@node-2# info
    groups {
        group "isis-1" {
            router "Base" {
                isis "0" {
                    level-capability 1
                    interface "<int-.*>" {
                        interface-type point-to-point
                        level "2" {
                            metric 10
                        }
                    }
                }
            }
        }
        group "isis-2" {
            router "Base" {
                isis "0" {
                    interface "<int-.*>" {
                        level "2" {
                            metric 20
                        }
                    }
                }
            }
        }
        group "isis-3" {
            router "Base" {
                isis "0" {
                    interface "<int-.*>" {
                        interface-type point-to-point
                        level "2" {
                            metric 30
                        }
                    }
                    level "2" {
                        wide-metrics-only true
                    }
                }
            }
        }
    }

---snip---

   router "Base" {
        isis 0 {
            apply-groups ["isis-2" "isis-1"]
            admin-state enable
            level-capability 2
            area-address [49.0001.0001]
            interface "int-pe1-pe2" {
                apply-groups ["isis-3"]
            }
        }
    }

The resulting expanded configuration after inheritance is shown as follows:

(ex)[/configure]
A:admin@node-2# info inheritance
   router "Base" {
        isis 0 {
            apply-groups ["isis-2" "isis-1"]
            admin-state enable
            level-capability 2
            area-address [49.0001.0001]
            interface "int-pe1-pe2" {
                apply-groups ["isis-3"]
                ## inherited: from group "isis-3"
                interface-type point-to-point
                level 2 {
                    ## inherited: from group "isis-3"
                    metric 30
                }
            }
        }
    }

Inheritance rules for leaf-lists are the same as for a single leaf, whether the list is a system-ordered leaf list (for example, configure router interface interface-name if-attribute admin-group value) or a user-ordered leaf list (for example, configure router bgp export policyvalue). The entire leaf-list is inherited, and it is not possible to add values to an existing leaf-list through configuration group inheritance.

Inheritance rules for user-ordered lists (for example, configure policy-options policy-statement name named-entry entry-name) are:

list order is ignored for user-ordered list entry matching
unmatched list entries in the configuration group definition and its descendant configuration elements are inherited in the locally-configured user-ordered list. Newly-created list entries are appended at the end in the order they appear in the configuration group definition.
descendant configuration elements of matched user-ordered list entries are candidates for inheritance

Disabling Inheritance

The apply-groups-exclude statement disables configuration inheritance for up to eight configuration groups in a configuration hierarchy. Configuration elements from the specified groups are not inherited in that branch. Disabling configuration inheritance for a configuration group only affects the configuration if that configuration group is applied at a higher-level branch in the configuration tree.

In the following example, configuration group "isis-1" is applied at the /configure router "Base" isis 0 context, but inheritance for that group is disabled for interface "int-pe1-ce1".

[ex:/configure groups]
A:admin@node-2# info
    group "isis-1" {
        router "Base" {
            isis 0 {
                interface "<int-.*>" {
                    interface-type point-to-point
                    level-capability 2
                }
                level 2 {
                    wide-metrics-only true
                }
            }
        }
    }

[ex:/configure groups]
A:admin@node-2# /configure router isis

[ex:/configure router "Base" isis 0]
A:admin@node-2# info
    apply-groups ["isis-1"]
    admin-state enable
    area-address [49.0001.0001]
    interface "int-pe1-ce1" {
        apply-groups-exclude ["isis-1"]
        passive true
    }
    interface "int-pe1-pe2" {
    }
    interface "int-pe1-pe3" {
    }

In the resulting expanded configuration, the interface parameters specified in the configuration group "isis-1" are not applied for interface "int-pe1-ce1":

[ex:/configure router "Base" isis 0]
A:admin@node-2# info inheritance
    apply-groups ["isis-1"]
    admin-state enable
    area-address [49.0001.0001]
    interface "int-pe1-ce1" {
        apply-groups-exclude ["isis-1"]
        passive true
    }
    interface "int-pe1-pe2" {
        ## inherited: from group "isis-1"
        interface-type point-to-point
        ## inherited: from group "isis-1"
        level-capability 2
    }
    interface "int-pe1-pe3" {
        ## inherited: from group "isis-1"
        interface-type point-to-point
        ## inherited: from group "isis-1"
        level-capability 2
    }
    level 2 {
        ## inherited: from group "isis-1"
        wide-metrics-only true
    }

The following configuration guidelines apply to the apply-groups-exclude statement.

This statement cannot be included in a configuration group.
The statement is included in the running configuration and saved in the MD-CLI configuration file.
The statement cannot be configured at the configuration root (/configure).

Displaying the Expanded Configuration

After configuring and applying configuration groups, the expanded configuration should be reviewed before the configuration is committed. The expanded configuration can be displayed with the info inheritance command. By default, this command displays the expanded candidate configuration. To display the expanded running configuration, use info running inheritance.

All statements that are inherited from a configuration group are tagged with a system comment.

(ex)[/configure router "Base" isis 0 interface "int-pe1-pe2"]
A:admin@node-2# info inheritance
    ## inherited: from group "isis-1"
    interface-type point-to-point
    level 2 {
        ## inherited: from group "isis-2"
        metric 20
    }

Use the regular expression pattern match info inheritance | match '^[ ]*##' invert-match to suppress the system comments in the output of info inheritance.

(ex)[/configure router "Base" isis 0 interface "int-pe1-pe2"]
A:admin@node-2# info inheritance | match '^[ ]*##' invert-match
    interface-type point-to-point
    level 2 {
        metric 20
    }

Note: Conflicting matches are detected at validation. The info inheritance command may display an inherited configuration element in the candidate that is part of a conflicting match criteria.

Note: Configuration groups appearing in apply-groups and apply-groups-exclude leaf lists at the same configuration hierarchy are detected at validation. The info inheritance command displays the inherited configuration elements in the candidate that are part of a configuration group that is present in apply-groups and apply-groups-exclude leaf lists at the same hierarchy.

The expanded running configuration can also be displayed with the info intended command. This command displays the intended configuration datastore as specified in RFC 8342, Network Management Datastore Architecture (NMDA) as follows:

the groups, apply-groups, and apply-groups-exclude configuration statements are suppressed
the expanded configuration with all statements that are inherited from a configuration group is displayed without the ## system comments

(ex)[/configure router "Base" isis 0 interface "int-pe1-pe2"]
A:admin@node-2# info intended
    interface-type point-to-point
    level 2 {
        metric 20
    }

Authentication, Authorization, and Accounting (AAA) in Configuration Groups

User profiles can restrict the configuration branches that a user can change. Denied and read-only configuration branches in user profiles automatically prohibit inheritance of these branches via configuration groups.

To restrict a user from viewing, creating, or editing configuration branches inside a configuration group, an explicit entry for the configuration group must be added in the user profile.

In the following example, user admin2 has no access to the sap-ingress configuration branch.

(ex)[/configure qos]
A:admin2@node-2# sap-ingress high-bw
MINOR: MGMT_CORE #2020: Permission denied - unauthorized use of 'sap-ingress'

This is enforced via the following entry in the local user profile:

(ro)[/configure system security aaa local-profiles profile "restricted-admin"]
A:admin@node-2# info

---snip---

    entry 200 {
        action deny
        match "configure qos sap-ingress"
    }

The same entry prohibits configuration group inheritance for user admin2.

[ex:/configure groups]
A:admin2@node-2# info
    group "grp-1" {
        qos {
            sap-ingress "high-bw" {
                queue 1 {
                    rate {
                        pir 200000
                    }
                }
                fc "be" {
                    queue 1
                }
            }
        }
    }

[ex:/configure]
A:admin2@node-2# /configure qos apply-groups "grp-1"
MINOR: MGMT_CORE #2020: configure qos sap-ingress "high-bw" - Permission denied

User admin2 can still view, create, or change sap-ingress QoS policies inside a configuration group if the changes do not result in configuration group inheritance of the sap-ingress QoS policy.

User admin2 cannot see the result of configuration group inheritance of a sap-ingress QoS policy because the info command is subject to the AAA rules defined in the user profile.

[ex:/configure groups]
A:admin2@node-2# info
    group "grp-1" {
        qos {
            sap-ingress "high-bw" {
                queue 1 {
                    rate {
                        pir 200000
                    }
                }
                fc "be" {
                    queue 1
                }
            }
        }
    }

[ex:/configure groups]
A:admin2@node-2# /configure qos

[ex:/configure qos]
A:admin2@node-2# info inheritance
    apply-groups ["grp-1"]
    md-auto-id {
        qos-policy-id-range {
            start 65000
            end 65535
        }
    }

An administrative user with full privileges can see the inherited configuration, which includes the sap-ingress QoS policy created by user admin2.

[ro:/configure qos]
A:admin@node-2# info inheritance
    apply-groups ["grp-1"]
    md-auto-id {
        qos-policy-id-range {
            start 65000
            end 65535
        }
    }
    ## inherited: from group "grp-1"
    sap-ingress "high-bw" {
        ## inherited: from group "grp-1"
        queue 1 {
            ## inherited: from group "grp-1"
            rate {
                ## inherited: from group "grp-1"
                pir 200000
            }
        }
        ## inherited: from group "grp-1"
        fc "be" {
            ## inherited: from group "grp-1"
            queue 1
        }
    }

To prevent user admin2 from viewing, creating, or changing sap-ingress QoS policies inside a configuration group, an explicit entry for the configuration group must be added to the AAA user profile.

[ex:/configure system security aaa local-profiles profile "restricted-admin"]
A:admin@node-2# info

---snip---

    entry 200 {
        action deny
        match "configure qos sap-ingress"
    }
    entry 201 {
        action deny
        match "configure groups group qos sap-ingress"

This configuration removes the privileges for user admin2 to view, create, or change sap-ingress QoS policies inside a configuration group.

[ex:/configure groups]
A:admin2@node-2# info
    group "grp-1" {
        qos {
        }
    }

[ex:/configure groups]
A:admin2@node-2# group "grp-1" qos sap-ingress "high-bw"
MINOR: MGMT_CORE #2020: Permission denied - unauthorized use of 'sap-ingress'

Configuration Group Example

The following configuration is an example of configuring IS-IS interface parameters using configuration groups.

In this example, all backbone IS-IS interface configuration parameters are part of the ‟isis-bb-interface” configuration group. A regular expression match ‟<int-.*>” is used to match on all backbone IS-IS interface names that start with ‟int-‟. The system loopback interface does not match the regular expression, so cannot inherit the configuration elements from the group.

The ‟isis-bb-interface” configuration group is applied at the router ‟Base”, IS-IS instance 0 branch. When a new IS-IS backbone interface is added with a name that starts with ‟int-‟, it also inherits the configuration elements from the configuration group.

(ex)[/configure]
A:admin@node-2# info
    groups {
        group "isis-bb-interface" {
            router "Base" {
                isis "0" {
                    interface "<int-.*>" {
                        hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk" hash
                        hello-authentication-type message-digest
                        hello-padding adaptive
                        hello-authentication true
                        interface-type point-to-point
                    }
                }
            }
        }
    }

---snip---

    router "Base" {
        isis 0 {
            apply-groups ["isis-bb-interface"]
            admin-state enable
            ipv4-routing true
            ipv6-routing native
            level-capability 2
            area-address [49.0001.0001]
            multi-topology {
                ipv6-unicast true
            }
            interface "int-pe1-pe2" {
            }
            interface "int-pe1-pe3" {
            }
            interface "system" {
                passive true
            }
            level 2 {
                wide-metrics-only true
            }
        }
    }

The resulting expanded configuration after inheritance is shown as follows:

(ex)[/configure router "Base" isis 0]
A:admin@node-2# info inheritance
    apply-groups ["isis-bb-interface"]
    admin-state enable
    ipv4-routing true
    ipv6-routing native
    level-capability 2
    area-address [49.0001.0001]
    multi-topology {
        ipv6-unicast true
    }
    interface "int-pe1-pe2" {
        ## inherited: from group "isis-bb-interface"
        hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk" hash
        ## inherited: from group "isis-bb-interface"
        hello-authentication-type message-digest
        ## inherited: from group "isis-bb-interface"
        hello-padding adaptive
        ## inherited: from group "isis-bb-interface"
        hello-authentication true
        ## inherited: from group "isis-bb-interface"
        interface-type point-to-point
    }
    interface "int-pe1-pe3" {
        ## inherited: from group "isis-bb-interface"
        hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk" hash
        ## inherited: from group "isis-bb-interface"
        hello-authentication-type message-digest
        ## inherited: from group "isis-bb-interface"
        hello-padding adaptive
        ## inherited: from group "isis-bb-interface"
        hello-authentication true
        ## inherited: from group "isis-bb-interface"
        interface-type point-to-point
    }
    interface "system" {
        passive true
    }
    level 2 {
        wide-metrics-only true
    }

The resulting expanded configuration after inheritance is shown as follows, without system comments:

(ex)[/configure router "Base" isis 0]
A:admin@node-2# info inheritance | match '^[ ]*##' invert-match
    apply-groups ["isis-bb-interface"]
    admin-state enable
    ipv4-routing true
    ipv6-routing native
    level-capability 2
    area-address [49.0001.0001]
    multi-topology {
        ipv6-unicast true
    }
    interface "int-pe1-pe2" {
        hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk" hash
        hello-authentication-type message-digest
        hello-padding adaptive
        hello-authentication true
        interface-type point-to-point
    }
    interface "int-pe1-pe3" {
        hello-authentication-key "KrbVPnF6Dg13PM/biw6ErHmrkAHk" hash
        hello-authentication-type message-digest
        hello-padding adaptive
        hello-authentication true
        interface-type point-to-point
    }
    interface "system" {
        passive true
    }
    level 2 {
        wide-metrics-only true
    }

Using Configuration Groups

Creating Configuration Groups

Exact Match

Regular Expression Match

Regular Expression Match Format

Conflicting Match Criteria Within a Configuration Group

Applying Configuration Groups

Inheritance Rules

Disabling Inheritance

Displaying the Expanded Configuration

Authentication, Authorization, and Accounting (AAA) in Configuration Groups

Configuration Group Example

Caveats