I’ve been working with an ISP that is going to be using a large amount of configuration in the ‘groups’ section. The statements there will be inherited into the main configuration using the ‘apply-groups’ statement.
This is a clever way of writing commands once and having them apply to multiple parts of the configuration. At a basic level you could match on interfaces beginning with ‘ge-‘ or ‘xe-‘ and set an MTU on them all using one group statement. This MTU setting would not appear in the main configuration unless the configuration was displayed using “show | display inheritance”. There’s a nice explanation of how groups work over at this Packetpushers blog.
The downside is that if large amounts of configuration work is done in groups, applying the config can become slow during the ‘commit’ process.
What happens under the hood when the user issues a commit in Junos? You can see what happens if you issue a ‘commit | display detail’. There is an example in this KB article. As you can see there is a lot of parsing for commit-scripts, interface ranges and apply-groups at the start. The config in these needs to be expanded and incorporated into the configuration at commit time. A new config database is then created, and the various daemons are notified that they need to read in their config. Finally the rollback configs are rotated, and of course if you have two REs in your router, this all has to happen again on the backup RE!
So when the groups section becomes large, this results in a lot of extra work for the mgd daemon to perform at commit time.
The ISP I’m working with has several config elements that I had not come across until now in their system stanza that aims to improve commit time: