Hi Adam,
1. POST is performed first, next the bootstrap program is loaded from ROM in to RAM for CPU execution. Main tasks of bootstrap are locating the IOS and Startup Configuration.
Instead of calling it a "bootstrap" even though that might be an official Cisco name, I would rather call it simply ROM Monitor, or ROMMON. The "bootstrap" has a rather specific meaning which, however, is not clearly used even in Cisco documentation itself - they use it to describe different and differing pieces of software related to booting a device. It's a mess.
This is probably the best explanation of the different boot <something> names I've found;
https://supportforums.cisco.com/discussion/9709036/boot-bootldr-boot-bootstrap-and-boot-system-command#comment-1688901
2. The bootstrap program searches for the IOS file (peer default on Flash). If it fails it will load a limited IOS.
Yes, however, on many recent platforms, there is no limited IOS present on a device. If loading IOS from FLASH fails, the router will drop back into ROMMON mode (this is the basic environment stored in ROM but it is not IOS - you could compare it to BIOS in a certain way).
3. Next the bootstrap program searches for the Startup Config file ( default location NVRAM) . If it fails to locate it, it will enter Setup Mode.
Usually, this is not done by bootstrap (or whatever that is) but rather by the IOS that has booted. I'd describe the sequence for recent platforms as follows:
- POST checks the hardware and starts the ROMMON.
- Depending on the value of config register and other variables, ROMMON tries to load the IOS from FLASH. If the IOS cannot be loaded, the device returns back to ROMMON.
- After the IOS has been loaded and run, it looks for configuration file in NVRAM and tries to parse it. If it does not find it, it starts the initial configuration dialog.
what does it mean "Boots into bootstrap" ? Next they say "Boots into ROM if initial boot fails" so if the router won;t be able to boot into bootstrap it will boot into ROM (do they mean the limited IOS) ?
That text is outdated. It was valid for very old platforms such as Cisco 2500 series routers that ran IOS directly from their FLASH instead of copying it into RAM and unpacking it, and that had a special limited IOS (called RxBoot) stored directly in their ROM. During normal operation, the IOS in the FLASH could not be upgraded because its code was constantly accessed. To upgrade the IOS on these platforms, you had to reboot using the configuration register value of 0x2101 where the RxBoot IOS was loaded, leaving the FLASH unused. You could then upgrade the IOS in the FLASH, put the register back to 0x2102, reload, and start the new IOS from the FLASH.
See here:
http://www.cisco.com/c/en/us/support/docs/routers/2500-series-routers/10252-13.html
On newer platforms, there is no RxBoot nor any other IOS stored in the ROM. Setting the configuration register to 0x2101 usually tells these routers to boot the first IOS in the FLASH they can find, and values from 0x2102 up to 0x210F direct the routers to observe the boot system commands in the configuration file.
If you want your head to start spinning, read this:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sys-image-mgmt/configuration/15-mt/sysimgmgmt-15-mt-book/sysimgmgmt-rebooting.html
Best regards,
Peter
