Using configuration groups

Creating configuration groups

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

Example

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

Example

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.

Example

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 element is inherited. If the IS-IS interface does not exist, it is created with 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.

Example

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 element.

[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.

Example

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"

Example

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.

Example

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

Example: Configuration elements inherited

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

Example: Using the info inheritance command

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.

Example: Configuration group that contains a configuration element is not inherited

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

Example: Expanded configuration after inheritance

[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

Example: interface-type configuration element is inherited from group "isis-1"

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

Example: Expanded configuration after inheritance

[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.

Example: Hierarchy determines the inheritance precedence

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

Example: Expanded configuration after inheritance

[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 policy value). 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 command 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.

Example: Inheritance is disabled for a group

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

Example: Expanded configuration

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.

Example: All statements 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
    }

Example: Using regular expression pattern match

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

Example: Using the info intended command

[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.

Example: User has no access to a configuration branch

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'

Example: 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"
    }

Example: 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.

Example: User admin2 unable to see result of group inheritance

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

Example: Admin users with full privileges able to view inheritance

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

Example: Explicit entry for the configuration group

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"

Example: Removing privileges for user admin2

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

Example: 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
            }
        }
    }

Example: Expanded configuration after inheritance

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

Example: Expanded configuration after inheritance, 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
    }

Restrictions

The following restrictions apply to configuration groups:

Configuration groups are available only in model-driven management interface configuration mode and for configuration elements in the Nokia YANG models.
When configuration groups are used with NETCONF, the <get-config> operation returns the pre-expanded configuration, including the configuration groups definitions and the apply-groups configuration elements. The expanded configuration, including the inherited configuration elements but excluding the configuration groups definitions and the apply-groups configuration elements, can be returned using the <get-data> operation on the intended datastore.
When configuration groups are used with gNMI, the Get RPC command returns the pre-expanded configuration, including the configuration groups definitions and apply-groups configuration elements. The expanded configuration, including the inherited configuration elements, cannot be returned with gNMI.

For more information about NETCONF and gNMI, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide.