Well let's look at this boot sequence, not so we can memorize it, it's not why we're doing this, but so we understand what's happening here with our router. ROM is utilized first as we can see, perform our power-on self test, or POST, make sure the hardware is there, make sure they're functioning properly, load the microcode, the code that is necessary to find the various features we need, such as our IOS image and our configuration file.
So we load this bootstrap, and think of a bootstrap as just preparing for a real operating system. It's the operating system before the operating system, if you will. And then step three would be hey, let's find the IOS, let's go ahead and find it and it could be in a few different places. We prefer it to be in Flash on our chassis so you don't have to look elsewhere. But there are mechanisms to load it from a or TFTP server. I'm not a big fan of that functionality. Why? Because then your device would not be able to get it's operating system if it lost IP connectivity to the TFTP server. So that's not something we would choose to do in a typical enterprise network, okay. Then we loaded our operating system. I want you folks thinking about this. We load our operating system then what happens? You should be able to tell us, in general terms, what is going to follow after loading the operating system? Device is booting up, found the operating system, loaded the operating system, what then?
And then it has to find our configuration file, has to return us to that previously configured state we were at. It's just like when you load your PC. Once the operating system is loaded, I want the same desktop, I want the same icons, I want the same colors. Same thing here, I want the same configuration. So where do we look at first? We're looking at NVRAM, nonvolatile RAM for that. Now if it's not in NVRAM, there are other places it can look - TFTP server.
There's a broadcast mechanism, in fact, where we'll shout and say, "Hey, any TFTP servers out there? I need some help." I don't like to use that, it's actually pretty tricky to set up, but it, technically, is a feature that we can do. And then once we might not have loaded the startup-config and not found anything else. Let me ask you, what happens if no startup configuration could be obtained? What happens?
We call Cisco Technical Assistance Center, or TAC. No we don't! We mentioned this earlier, we get a prompt for system configuration dialog, what is that? A mini setup wizard walking you through the steps of setting up your device for the first time. So if you see system configuration dialog and it's not the first time you are using this router, it's a sure bet that your startup configuration file is missing from NVRAM.
I'll challenge that. Is there any other reason why we might see the setup script or not be able to load the startup-config on a router chassis?
Yes there is, there is. If we modify something known as the configuration register. Then this configuration register value would then be telling the router, don't load the configuration file from NVRAM, even if it's there, just leave it alone, and just load the router without a configuration.
Okay. So we're kind of priming you for something we're going to talk about momentarily and that is, there's this value that, in fact, can override this behavior. You can tell it, in fact, to go straight to things like ROM monitor, or ROMMON, or you could tell it, "Hey, don't even load a startup-config." Let's learn a little bit more about this thing called the configuration register value.
The configuration register
So this configuration register value, it gives us the ability to change the way our router behaves. And we'll see here that it's four hexadecimal values. Well first of all, how do we know it's hex? Is there something we can see here that identifies that it's hexadecimal and not just decimal values?
Boot Field Value
|0x0||Use ROMMON mode (manually boot using the boot command)|
|0x1||Boots the first image from the Flash memory|
|0x2 to 0xF||Sequentially examine NVRAM for boot system commands|
Well hexadecimal is base 16 and there are ways of representing what number system we're talking about. 0B is binary, 0D is decimal. I don't know if 0O exists, but that would be octal. So the 0x says hexadecimal. Here is just a little word of caution, when you manipulate this value, you have to be mindful of the fact that you do want to preface it with the 0x. I had a friend who turned to be a CCIE, but he made a mistake one day that he really paid for and that was, he changed this value. Let's say he was changing it to the default, but all he did is he said, 2102. But he didn't put in the 0x, easy mistake, right? Well the problem is, he put it in as 2102 decimal, who the heck knows what the interpretation of that is? And he locked himself out of the console until he figured out the speed of the console port that was enforced by the change that he made erroneously, accidentally. So don't make that same mistake, okay. Put in the 0x if you ever manipulate this value.
Configuration register is 0x2102 (will be 0x2101 at next reload)
So what is our focus on here? Our focus will be around the last two hexadecimal values. So we're referring to the last two, we're not counting 0x here, right? Well we said, it's 4 hexadecimal values. So in this example, 2102, each one of those. And the final two, the last 2 will be our focus. For here right now, let's just focus on the very last value, the 2 at the end. What is that? What does it represent? Well this is known as the boot field, the boot field. So I want you to guess right now as to what we could manipulate by changing this last value in the configuration register? If you guess that we could manipulate how the device boots, it's exactly what we can do. Now let's understand here, there is a default value for the configuration register and we're looking at it right now, 2102 that's the default, that's what we expect under normal operating conditions. So, the boot field of 2 at the very end, if I see 2, what does that mean?
It means the default. And the default is, the router is going to boot up, it loads the bootstrap, and then it's going to say, "Hey, do you want to tell me where my operating system is?" And the way that we tell the operating system location to a router is, we use what is called a boot system command. boot system command done from global configuration mode says, "Hey I'm going to tell you exactly where it is." And you could point to it. Now we don't have those by default. But if one exists, it's going to tell us explicitly where to attempt to load the operating system from and I think that makes sense. So 2 is a pretty good default for us.
What if I had a value of 8 in the last field? What does that mean?
There's no "D" code beyond 2 and this number is a really old number. I think it's probably two and half decades old, 2 through F don't mean a thing apart from one another 2 is same as 3, 4, 5, 6, 7, 8, all the way through F. So we usually just see 0, 1, or 2.
And so 2 is the default, but if you saw F or anything else it means the same thing. What about 1, what if we change that to 1? Well, remember, 2 through F states look in NVRAM for that boot system command and use it. If we have multiple boot system commands, it's going to use the first one it finds. So it looks through it sequentially. Now if I have a 1, how is that going to change the behavior of the boot?
Well in that case, it's the same as not having a boot system command, kind of the same thing. What a router would do under default circumstances if it had a 2, it is going to look hey, do I have any boot system commands and then I don't find any. In that case, it's going to say, "I want to look at Flash and I want to look for the binary file." Binary files are my operating system files and I'm going to go through from top to bottom. And we say it loads the first file in Flash, specifically, or more correctly, the first operating system file in Flash and that's what we would get with the default setup with no boot system commands. It's also what we could say if we did have boot system commands and we wanted to bypass them, that's what a 1 is going to do for us. It just says, "Don't even pay attention to a boot system command, I want to just load the first operating system in Flash." Here is one of the good things about that. Let's say you had two operating systems and you had a boot system command pointing to the second operating system, which is probably the newer and then that isn't working for you. So what you could do is, you could go into ROMMON mode, you could modify this value to a 1, and then you're going to revert to the previously working operating system. So that's how you could use this to your benefit and I think that's a pretty good function.
What about the third one here, the 0?
0 will take us to the scary place, what scary place? ROMMON mode. What did we say we could do in ROMMON mode?
Password recovery and IOS recovery. So it's the recovery place. It may not be fun, it may be the scary place, but I find myself there from time to time. And remember, how we began this journey together for management? We want you to have confidence in the chassis, we want you to understand how to work with the chassis. And knowing this value and knowing how to work in ROM monitor mode, can really help you out.
So how do we verify the current configuration register value? show version, go right to the bottom of the output, you'll see it listed right there.
But how do we change it? We change it in global configuration mode with the command config register.
Branch#copy running-config startup-config
Sample code for verifying new configuration register value is as follows:
Configuration register is 0x2102 (will be 0x2101 at next reload)
Notice the 0x in front of the value we're specifying. Don't make the mistakes that others have done in the past. 0x for hex and then 2101. Now folks, we made that change and we affected the boot field that's what we've affected. So is it going to change anything right now? No it just changed the configuration register value, it doesn't take effect until the next reload, right? Because that's where we're going to boot again. But we can see here, that the next time we load, we're going 2101. So what does that mean? The boot field is 1, what will happen?
If it's 2, it looks for boot system commands. If it's 0, boot to ROMMON. But if it's 1 numeric value 1, we're going to bypass the boot system commands and try to, kind of, boot normally by looking at Flash.