From: Jay Hennigan (jay@west.net)
Date: Sun May 11 2003 - 01:55:51 GMT-3
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