From: ccie2be (ccie2be@nyc.rr.com)
Date: Sun May 11 2003 - 08:51:58 GMT-3
Hey there Jay,
Between you and Kym Blair, my heretofore nebulus understanding of this topic
is becoming much clearer. You guys are great and there's hardly a day that
goes by where I don't pick up some valuable nugget of knowledge because of
Group Study and the generous contribution of people like yourself, Kym,
Brian Dennis, Scott Morris ( he's an expert on Mobile IP) and many, many
others.
I think I understand what you explained to me but let me restate it in
simple terms just to be 100% sure I got it.
Some 2500 routers have code Cisco's calls, Flash Load Helper. So, those
routers with that code don't require the register to be manually reset
because that code causes the router to reboot into the mini ios boot mode
automatically when the copy tftp flash command is entered. Then, after the
router reboots, it does the copy operation, reboots again and everything is
back to normal, except the router now has a new copy of ios.
Other 2500 routers, don't have this code. For these routers, one has to
manually reset the registry appropriately to have the router boot to the
mini ios in the boot rom where once in this mode, the flash is made
(read/write) and you can now run the copy tftp flash command. And, once the
copy is complete reset the registry to it's normal value of 2102.
If this is correct, then the logical next question is, How does one know in
advance if the registry has to be manually reset?
Apparently, having newer ios versions isn't a sure fire way to know. The
router that wouldn't upgrade yesterday without the manual setting of the
register was running version 12.0 something, and yet I upgraded routers
running earlier ios versions such as 11.0, 11.1 and 11.2 without touching
the register. I sure did get spoiled. Obviously, it's clear that if
everthing else is OK and the copy tftp flash doesn't work, then one knows
that the register has to be reset before proceeding, but it wouldn't
surprise me if there's a better, less time consuming way to know which
method needs to be used. And, assuming there is, I'm hoping you'll let me
know.
Once again, thank you for all the time you took to explain all this to me.
Jim
----- Original Message -----
From: "Jay Hennigan" <jay@west.net>
To: "ccie2be" <ccie2be@nyc.rr.com>
Cc: "Group Study" <ccielab@groupstudy.com>
Sent: Sunday, May 11, 2003 12:55 AM
Subject: Re: IOS Upgrade problem
> On Sat, 10 May 2003, ccie2be wrote:
>
> > Thank you so much. I don't understand why these register settings work,
but
> > so far, it's seems to be working fine. Right now the router is in the
> > process of copying over the new ios.
>
> It would be in your best interest to understand why they work. :-)
>
> > I looked up the register settings in Solie's Practical Studies and he
> > doesn't mention anything about bit 6 or bit 1 changing the flash from
read
> > only to read/write. Instead, he says setting bit 6 to 1 (4 decimal)
causes
> > the rtr to ignore nvram and bit 1 means to boot to boot mode. So, if
you
> > could explain it, I'd like to understand why this works.
>
> The situation you have is unique to Cisco's lower-end products that
> "run from flash", but it could be useful in the case of a faulty IOS
> image.
>
> There are four memory subsystems on Cisco routers:
>
> * Boot ROM - Burned at factory, unalterable. Consider this to be like the
> BIOS of a PC. Code in the boot ROM is capable of a very minimal subset
> of IOS such as IP connectivity, console communication, and TFTP. Not
> capable of dynamic routing or most IOS features.
>
> * Flash - "Read-mostly memory". This memory contains the IOS image.
> It can be re-written in the field via TFTP or XModem when the IOS is
> upgraded, but for the most part its contents are unchanged for normal
> operation. In many of the higher-end routers with the more advanced
> feature sets of IOS, the IOS image in flash is compressed. More on
> this later...
>
> * RAM - Random-access memory. Used for many things such as packet
buffers,
> route tables, general CPU storage, etc. In most routers, the IOS in
> flash is loaded into RAM at boot time. The boot ROM has the routine to
> copy the IOS image to RAM, and if compressed to uncompress it into RAM
> at boot. Some routers run IOS from flash directly, uncompressed. More
> on this later, too...
>
> * NVRAM - Non-volatile memory. This stores the configuration. Wnen you
> "copy run start" or "write memory", you're writing to NVRAM. In normal
> operation, the configuration in NVRAM is read and used at boot.
Bypassing
> this is the key to password recovery. By setting the configuration
> register to ignore the NVRAM configuration, the router boots without
> a configuration, and hence without an enable password. You can then
> enable the router, "copy start run" to load the configuration, change
> the enable secret, and "copy run start" to save the configuration with
> the new secret.
>
> OK. Here's the kicker that's getting you. The 2500 series and some of
> the early 1600 series routers "run from flash". This means that the IOS
> is not compressed, and the boot ROM normally boots its startup mini-IOS,
> then points the CPU to the real IOS in flash and executes it. The image
> is NOT copied to RAM at boot, but executed directly from the flash memory
> itself.
>
> This causes a catch-22 when upgrading. If you were to boot the router
> normally and then try to erase and rewrite the flash, you would be erasing
> the very code the router is using to run, causing it to crash and be
> unusable due to a partially-erased IOS. Cisco protects against this by
> marking the flash "read-only" when the router is running from the image
> on the flash itself.
>
> The way around this is to boot only to the mini-IOS in the boot ROM.
> Now the router has just enough horsepower to operate the console, turn
> up its interfaces, do a little static routing, and run TFTP to rewrite
> the flash with the new IOS. There are two ways that this can be done.
> Changing the configuration register is one that will always work, but
> as you discovered it's cumbersome. The newer boot ROM and IOS images
> semi-automate this by accepting the TFTP command, rebooting into the
> boot ROM mode, executing the copy, and then rebooting with the newly
> installed IOS. This is less cumbersome but requires that the boot ROM
> and IOS support it. Cisco calls it "flash load helper".
>
> Another lab trick you may run into is "mzmaker", a way to cheat a 2500
> into running a larger image than will fit on flash. It requires that you
> have enough RAM to hold the IOS and also run the router, not good for
> production environments. Mzmaker compresses a normally uncompressed
> run-from-flash 2500 image to make it smaller. At run-time it gets
> uncompressed and the router is run from RAM just like the higher-end
> more powerful Ciscos. But, a 2500 with an image that is bigger than
> 8MB uncompressed will probably need quite a bit of RAM to run anyway
> so there's a price to pay for using mzmaker. The RAM that's holding
> the uncompressed image isn't available for other tasks which hurts the
> router performance and may keep it from running at all or cause crashes.
> Don't use it other than for lightly-loaded lab scenario tests. Better
> yet, buy more flash.
>
> As a CCIE candidate, you should have a good understanding of the various
> types of memory and their uses as well as the configuration register and
> how to manipulate it for password recovery and forcing a ROM only boot to
> recover from a faulty or missing IOS. Beware that there are settings in
> the configuration register that can make it difficult to use the console
> port, so use caution or you'll be playing console speed roulette. The
> procedure you used for upgrading IOS on a 2500 is similar in theory to
> what you would use for password recovery. You're changing register bits
> to force a portion of the normal bootup to be skipped, making changes,
> and then changing the register back to allow normal operation.
>
> --
> Jay Hennigan - CCIE #7880 - Network Administration - jay@west.net
> NetLojix Communications, Inc. - http://www.netlojix.com/
> WestNet: Connecting you to the planet. 805 884-6323
This archive was generated by hypermail 2.1.4 : Mon Jun 02 2003 - 15:13:40 GMT-3