This article explains why you should avoid using the “apply-groups” knob at top of the hierarchy.

When apply-groups is applied at the top of the hierarchy or at the root level, mark-changed is set at the top-level knob, which makes it behave like a commit full for all immediate configuration knobs.

This may result in re-applying all the configurations under that hierarchy even if they are not touched.

[edit]
root@re0# show groups LOC-PREF-GROUP 
policy-options {
    policy-statement LOC-PREF {
        then {
            local-preference 100;
        }
    }
}
 
[edit]
root@re0# set apply-groups LOC-PREF-GROUP
 
[edit]
root@re0# show | display inheritance | display xml | display mark-changed | match mark-changed
            <policy-options junos:mark-changed="mark-changed">
                <policy-statement junos:mark-changed="mark-changed">
                    <then junos:mark-changed="mark-changed"

Therefore, instead of applying it at the top of the hierarchy, you can apply it as follows:

set policy-options policy-statement LOC-PREF apply-groups LOC-PREF-GROUP

Note the following points when applying groups:

• Use groups judiciously.

• It is meant to reduce the total configuration size and it is costly compared to foreground (due to expansion and inheritance).

• groups should be applied at the local scope, as deep as possible to minimize the bit changes.

• Avoid applying groups at the root level, which makes it commit full for all immediate configuration knobs.

• If groups is not bringing down the overall configuration size, it is better to put the configuration in the foreground and use deactivate/activate to disable/enable.

2023-05-03: Initial publication

2023-05-30: Corrected config example

2023-06-22: Added information about applying groups locally instead of at the top of the hierarchy

BGP User Guide - apply-groups