Automation

I dislike the fact, that on my MX series routers, when I run a commit script it prints warning messages for both RE's.  I'd prefer to print the messages once for the primary/active RE. 

Is there a variable that will tell me which RE the script is being run on?

if ($routing-engine = "primary") {
   <xnm:warning> {
      <message> "you missed something in your config";
   }
}

It looks like there is: http://jnpr.net/techpubs/software/junos/junos83/junoscript83-guide/html/summary-junoscript-tags21.html

However, I'm not sure how to get that into a variable.  $top will look at the top of the config.  How do I look in commit-results, and does commit-results.  I don't know if I can use this anyhow, as it looks like a result from the 'server' AFTER the config commit is completed, and may not be available at the time I want the warning to show.

I found a template (subroutine) in this script that accomplishes this.  It seems to work just fine.

Has anyone found a simpler/better way?

Unfortunately I think using the logic shown in those templates is the best way to determine what the local RE is as well as whether or not the local RE is the master.  I doubt they work correctly with J/SRX chassis clusters though as I don't know if that has ever been tested, the same goes for TX matrix.  If you customize the logic using the templates as an example then make sure you do not fail the commit if you receive no response back from the Junos API requests because the boot-up commit will likely receive no data from those sources and if you generate a commit error in response then you'll end up with a rebooted box with no configuration.

Yikes!

>boot-up commit

I wasn't aware there is a boot-up commit?  How's this work?  Basically the config (in a file) is applied and commited, and runs the commit scripts during that commit?  This is a pitfall I didn't know about.  I'll have to go look at each of my commit scripts to make sure I can't cause a problem during bootup.

When the Junos system boots it has to commit the configuration in order to activate and load the proper settings into its daemons.  This commit is a full commit process including the processing of all commit scripts.  Normally this is no problem, but if commit scripts are requesting information via the Junos API then they need to be aware that during bootup much of this information will not be available (since the daemons are not initialized yet).

The same is true for the non-master routing engine in many cases.  The commit is performed, along with commit script processing, by all routing engines.  This means that if the backup (or linecard in the case of a EX VC) routing engine does not have all the information that the master does then the API results could be different.