graham@arcturus.uucp (Thomas D. Graham) (11/20/90)
First the disclaimer, I am a new (ab)user of the cisco router. Question is, why is there not a "replace config" command, so that, when I do config editting on my PC editor and then upload it to the router as the NEW config file, it replaces the old config file with my new one???? Apparently, the only way to accomplish this today is the "final solution", which is, erase non-volatile memory, and then power off to erase volatile memory, and then power back on and config "from scratch"!!!! Really????? s
JOHN@heap.cisco.com (John Wright) (11/28/90)
There are three configuration files that one could have: The contents of non-volatile battery backup up memory. The active running RAM configuration information. The file on a local TFTP server. The configuration information is at startup from the console or via tftp. Once a system is up any changes made are to the active running system configuration file in RAM...this is done from the console or from a tftp loaded file. Yes, both the console and tftp loaded commands will do the same thing and modify the existing running configuration file. To make any changes you would need to turn off any services/commands which you do not wish to keep, for example NO DEFAULT-NETWORK A.B.C.D, most commands are removed from the configuration by placing a NO in front of the command being parsed. It may seem easier to make a large number of changes at once by erasing memory and placing the modified configuration file on a local tftp server and net booting the new configuration file during a reload. I do this alot when testing customer configurations in the CE lab. The problem with a replace command would be having to erase the active configuration and therefor halt the running of the system while we parse the brand new configuration information, not something you normally want to do on an active running production network. It is more likely you would load a file containing commands with both disabling some services with "NO ..." commands, and then turning services on with perhaps difference addresses or parameters later in that file. The contents of the active configuration file in RAM are written to NVM with the write memory command. John Wright Customer Engineering cisco Systems, Inc.
jconti@barnard.usc.edu (John Conti) (11/28/90)
JOHN@heap.cisco.com (John Wright) writes: >...... The >problem with a replace command would be having to erase the active >configuration and therefor halt the running of the system while we >parse the brand new configuration information, not something you >normally want to do on an active running production network. It is >more likely you would load a file containing commands with both >disabling some services with "NO ..." commands, and then turning >services on with perhaps difference addresses or parameters later >in that file. The contents of the active configuration file in RAM >are written to NVM with the write memory command. I often have to erase the NVRAM, reload, and config from scratch when I make signifigant changes to a configuration. Because of the above it involves downtime which neither the users, nor the administrator (me) like. I was wondering if a diff program could be written for the cisco configs. The program would know enough so that it could take a human readable (comments, command differences, and different order of presentation) config file and generate a "diff" between that and another file that contained the active config or the config in NVRAM (previously downloaded from the router). This way you could change your config and just generate the "NO" commands neccessary to change the active config correctly. This first occured to me because I used to try to do the above by hand and would always make some little mistake, and my boss would get all over my case because the running config wouldn't match our copy on disk somewhere. This is made worse because we don't use tftp to download the configs. All of our boxes have NVRAM and are expected to work independant of supporting hosts. I have to use serial lines to re-gen our routers. I think all you would need to do this would be a complete listing of the parse tree for the configuration language. This looks simple and maybe cisco even has a yacc file or something. Would cisco feel like releasing and updating such a document? -- ,John John Conti { jconti@usc.edu | jconti@xenon.usc.edu (NeXT mail) } Computing Services, University of Southern California, (213)740-2957 -- ,John John Conti { jconti@usc.edu | jconti@xenon.usc.edu (NeXT mail) } Computing Services, University of Southern California, (213)740-2957
fortinp@bwdls56.bnr.ca (Pierre Fortin) (11/29/90)
In article <12641311988012@heap.cisco.com>, JOHN@heap.cisco.com (John Wright) writes: > There are three configuration files that one could have: > > The contents of non-volatile battery backup up memory. > The active running RAM configuration information. > The file on a local TFTP server. [...stuff deleted...] > in that file. The contents of the active configuration file in RAM > are written to NVM with the write memory command. ...and the NVRAM can be erased with (at least the following commands): write erase ! obvious test memory ! SURPRISE!! Gotcha! > > John Wright > Customer Engineering > cisco Systems, Inc. Pierre Fortin Bell-Northern Research I know, my postings are Internet Systems P.O.Box 3511, Stn C terse and humourless. So? (613)763-2598 Ottawa, Ontario RIP: aptly named protocol fortinp@bnr.ca Canada K1Y 4H7 AppleTalk: Adam&Eve's design
JOHN@heap.cisco.com (John Wright) (11/29/90)
The test memory behavior of erasing NVM when you run it on the address space for NVM is document on page C-17 and 18-15 of the 8.1 manual. John Wright Customer Engineering cisco Systems, Inc.