Re: 12.3T - a niiiiice feature :)

On Wed, Aug 06, 2003 at 04:26:56PM +0200, Gert Doering wrote:
> Hi,

        Grusse,

> I don't see any reason to "carelessly reboot" machines, though - like
> what I've seen at customer sites ("this box is rebooted once per day,
> whether necessary or not, it *might* cause problems if we don't reboot").

        I call this redmond syndrome.

> >     there are also other reasons besides memory leak, etc.. to reload
> > routers.
> > 
> >     there are some of us that manage very large router configurations.
> > something like this would possibly mean if we are making large policy
> > changes, we would be able to copy from our tftp/rcp server (where the
> > configuration is generated out of sql, m4, etc.. and is actually the
> > 'master' config, not the nvram ... works well on juniper w/ 
> > load override fyi..) reboot and start going rather quickly.
> 
> I'm not sure whether I think this makes sense.
> 
> In the standard case (access lists, AS path filters, prefix lists) the
> lists can be uploaded to the running router just fine, without requiring
> a replacement of the complete startup-configuration and subsequent reboot.

        Note I said "large policy changes". :)  Everything today we have
automated to within the confines of the environment that the vendors
have provided.  Cisco included.

> So even if reboots can be made much faster by this, I still want to avoid
> reboots wherever possible - and it that means "invest more brains into
> operational procedures", so bet it.

        Sure, there are also reasons to not reboot, igp/egp convergance
and flap issues, but this will make the downtime just that much less
if you experience a memory leak bug.  Obviously you want to be rebooting
to the fixed software, but Cisco doesn't seem to move at that speed.
the CT3/SNMP issue won't have fixed software for a few more months for
example.

> (I am aware that your network is much bigger than mine, but as I already
> do most of these cases in an automated way, I think it can scale up pretty
> well.  Exceptional cases excempt, of course)

        We've taken to as-much-automation-as-possible in this realm.
here's a trivia question for you (and other readers):

        If cisco provided a way to generate your machine-readable
configuration and ship it to the router and take care of any changes
(similar to sending a SIGHUP to gated/syslogd/named, etc..) that
were made, would you shift your paradigm from using the routers
nvram as the master and automation to keep the router up-to-date to
using a *nix or other system to generate the configs then feed them
to the router?

        - Jared

-- 
Jared Mauch  | pgp key available via finger from jared@xxxxxxxxxxxxxxx
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.
_______________________________________________
cisco-nsp mailing list  cisco-nsp@xxxxxxxxxxxxxxx
http://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/