[AusNOG] Juniper Rescue Configs

[Ben Dale]

Hi James,

On 21 May 2014, at 10:44 am, James Morgan <James.Morgan at vernet.com.au> wrote:

> Hi all,
> 
> I was hoping to ask what those of you running Juniper kit use in your
> rescue configs; do you use it as a bare-bones config to use when your
> world has caught fire, or do you use it (as the documentation seems to
> suggest) as a last-known-working config?  How often do you update your
> rescue config?

On kit we deploy into remote areas, it's usually the as-built/last-known-working configuration, particularly with branch SRXs.  Branch office configs don't tend to change much and they're usually the places hardest to get hands and feet to in an emergency.  On the other hand, it should be quite easy to talk most people through pressing the Reset Config button to rollback to rescue if someone has a bad day on the console and forgets "commit confirmed".

For boxes like EX2200s that don't have the LCD panel, rescue configs don't make a lot of sense, as there is no way to externally trigger the rescue process.

For stuff deployed in critical locations (DCs etc.) where changes might be made quite regularly, you can't go past an OoB terminal server into the console port and just issuing a rollback, so in these locations, rescue tends to be the as-built configuration (to get rid of the factory alarm), then woefully out of date from that point on ; )

Between commit check, commit confirmed, commit scripts, rollback and rescue configs, there shouldn't be too many times you'll ever need it, but it's nice to know it's there.

> The reason I ask is I was performing some software updates recently and
> was interested to learn that the upgrade will fail the pre-flight check
> if you have graceful-switchover enabled in your rescue config.  It got
> me wondering what actually was in our rescue config, and what process we
> have for updating it.  Is there an industry best-practice on this?


As for the validation checks on the rescue config, yes - you'll also run into it when upgrading an SRX chassis cluster when the rescue config has been set with a stand-alone member configuration.  "no-validate" is your friend in this scenario ; )

Depending on how formalised your change management process is, you could include updating the rescue configuration as the final step in every CR after validation testing. 

Cheers,

Ben