Mailing List Archive

I think keeping the existing restart/reload methods is probably a good
idea. However, having something like 'commit after-reload' might be
useful. Then you could just reload as normal and the changes would be
made when the router boots back up. Might also be a good idea to have
some kind of warning when you reload that the current configuration and
the startup configuration differ. Just in case someone did a 'commit
after-reload' and never did their reload.

Just my $.02 worth.

Justin

-----Original Message-----
From: juniper-nsp-bounces@puck.nether.net
[mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of Richard A
Steenbergen
Sent: Tuesday, January 20, 2004 8:56 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Feature idea: commit and-reboot


While attempting to combine a software upgrade and reboot with a commit
change that would require a routing bounce (to minimize flaps
obviously),
I noticed that there is no way to make a change which will take affect
after the reboot is complete.

If you wanted to, say, turn on graceful-restart, change the families you
negotiate on BGP sessions, or otherwise make a session-resetting (but
not
so complex you need the safety net of commit confirmed) change while you
are upgrading or rebooting (the equiv of changing your startup-config
without changing your running-config), there doesn't seem to be any way
to
do it (other than trying to be really fast :P) which won't result in two
bounces.

I know the Juniper philosophy is "always make the configured state the
current state", but perhaps a "commit and-reboot" type command could be
used to check the config, apply it in the appropriate databases for
after
the reboot, and then begin the reboot without reloading the daemons with

the new config?

--
Richard A Steenbergen <ras@e-gerbil.net>
http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1
2CBC)
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

On Wed, 21 Jan 2004, Ryburn, Justin wrote:
> I think keeping the existing restart/reload methods is probably a good
> idea. However, having something like 'commit after-reload' might be
> useful. Then you could just reload as normal and the changes would be
> made when the router boots back up. Might also be a good idea to have
> some kind of warning when you reload that the current configuration and
> the startup configuration differ. Just in case someone did a 'commit
> after-reload' and never did their reload.

This idea is a bit problematic. The syntactic config checker is a bit
.. lacking. You wouldn't want to run into a situation where at
reboot, the router wouldn't come up due to invalid configuration. So,
in that light something like 'commit delay-activation' sounds like a
better idea (activation would be done when rebooting) if necessary --
I personally don't see much value in that though.

> -----Original Message-----
> From: juniper-nsp-bounces@puck.nether.net
> [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of Richard A
> Steenbergen
> Sent: Tuesday, January 20, 2004 8:56 PM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] Feature idea: commit and-reboot
>
>
> While attempting to combine a software upgrade and reboot with a commit
> change that would require a routing bounce (to minimize flaps
> obviously),
> I noticed that there is no way to make a change which will take affect
> after the reboot is complete.
>
> If you wanted to, say, turn on graceful-restart, change the families you
> negotiate on BGP sessions, or otherwise make a session-resetting (but
> not
> so complex you need the safety net of commit confirmed) change while you
> are upgrading or rebooting (the equiv of changing your startup-config
> without changing your running-config), there doesn't seem to be any way
> to
> do it (other than trying to be really fast :P) which won't result in two
> bounces.
>
> I know the Juniper philosophy is "always make the configured state the
> current state", but perhaps a "commit and-reboot" type command could be
> used to check the config, apply it in the appropriate databases for
> after
> the reboot, and then begin the reboot without reloading the daemons with
>
> the new config?
>
>

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On Tue, 20 Jan 2004, Richard A Steenbergen wrote:

> If you wanted to, say, turn on graceful-restart, change the families you
> negotiate on BGP sessions, or otherwise make a session-resetting (but not
> so complex you need the safety net of commit confirmed) change while you
> are upgrading or rebooting (the equiv of changing your startup-config
> without changing your running-config), there doesn't seem to be any way to
> do it (other than trying to be really fast :P) which won't result in two
> bounces.

If it's the bounces that you're trying to avoid, why not de-activate the
sessions or groups that you are going to bounce either just before you
make the config change or as part of it? Then reboot/upgrade the router
and bring the sessions back up when the reboot's complete.

Isn't generally good practice to drop BGP sessions a while before you
reboot a router anyway to allow removal of the path to propagate
downstream?

Rich

Richard A Steenbergen <ras@e-gerbil.net> wrote:
>While attempting to combine a software upgrade and reboot with a commit
>change that would require a routing bounce (to minimize flaps obviously),
>I noticed that there is no way to make a change which will take affect
>after the reboot is complete.

You can say "commit at reboot". JUNOS will do a commit check but
not apply it until you reboot. If there's a pending commit,
no further changes will be allowed to the configuration.
A pending commit can be cleared with "clear system commit", and "show
system commit" will tell you if there's a pending commit.

The completion help for "commit at" doesn't say that it will
accept "reboot" as a time to commit, so perhaps this is a bit of
a stealth feature.

We don't have a way to combine this with a software upgrade,
changing the configuration and upgrading the software are kept as
distinct operations.

Rob