06-07-2023 07:48 AM
Hello all,
If we have the option to use both the reload and reload fast option, would there ever be a reason to use the plain reload command instead of the new reload fast command? Basically, I would think you would always want to use the reload fast command and there's no need to ever use the plain reload command if your switch supports reload fast ?
Solved! Go to Solution.
06-07-2023 05:08 PM
I would use the regular "reload" command because it will restart the switch and flush out any "gunk" in the system. The command "reload fast", however, will not be as reliable as "reload" command and, in my personal opinion, not be good enough to flush out any gunk.
06-07-2023 05:08 PM
I would use the regular "reload" command because it will restart the switch and flush out any "gunk" in the system. The command "reload fast", however, will not be as reliable as "reload" command and, in my personal opinion, not be good enough to flush out any gunk.
06-08-2023 07:05 AM
@Leo Laohoo ah gotcha, good point about the regular "reload" flushing out "gunk." Reminds me of the difference between a "hard reload" (i.e. "reload") and a "soft reload" (i.e. "reload fast"). Thanks again!
06-10-2023 09:05 AM
Laugh, love Leo's wanting to clear out the "gunk", but an ideally done soft or fast reload should do that. Such reloads bypass, or short circuit, things normally done during an OS boot, that should not need to be done again on a running system.
The real issue is, why are you doing a reload? If it's due to some problem, it's possible a fast reload will bypass a step that actually should be done. This is likely why in Cisco's earlier warm reload feature, after several warm reloads a full reload was done.
So, much like Leo wanting to flush out "gunk", a full reload provides more assurance everything will be reset for correct operation again, and basic power on hardware checks have (minimally) passed.
Anything other than a full reload, reduces your assurance that device has been correctly reset.
In some way, choosing to use a fast reload function is much like choosing to upgrade your IOS. Are the "advantages", to you, of the upgrade, worth the "risk" of using a newer IOS in your environment?
If you find, for some reason, rebooting faster is critical to your environment, use it, but just like your core devices, you might not want them to be the first using a new IOS. If possible, you might want to take same non-critical device, and subject it to such a reload, every day, perhaps in the early AM, and determine if it's just as stable as other devices.
06-10-2023 07:14 PM
@Joseph W. Doherty wrote:
Anything other than a full reload, reduces your assurance that device has been correctly reset.
With IOS-XE the most prevalent OS nowadays, even a "full reboot" is not longer "just" enough. Reading some of the Workarounds in some of the Bug IDs where it calls for a "cold reboot" of the appliance just to temporarily flush out those pesky bugs.
I really have no idea what the "use case" is but I am not a believer with "reload fast".
06-11-2023 03:53 AM
Then that tells us, for XR, the traditional reload is likely bypassing some "unnecessary" boot functions done during a cold boot.
Unless you're a programmer, who has directly worked with computer hardware, it might be difficult to understand booting (cold start) vs. restarting (reload) a computer, as the end result should be the same.
In networking, a very rough complexity comparison might be: cold boot like generation of original frame/packet; warm reload like a L3 hop which generates new frame (i.e. existing packet reused); reload like a L2 hop which adds/removes VLAN tag; fast reload like a L3 hop which changes L3 packet, e.g. NAT.
06-11-2023 04:42 AM - edited 06-11-2023 04:45 AM
Not a programmer but, from what I understand "reload fast" is the restart the processes only but the underlying hardware is still running.
I mean we tried "reload fast" once. Only once. Because when we did try, the 9500 crashed spectacularly. We had to get a "warm body" to the site quickly so the power could be removed.
In the end, our experience of "reload fast" took about an hour.
06-11-2023 08:29 AM
BTW, to be clear, I'm not recommending any version of reload vs. another. Just noting it shouldn't matter, but since it very much can matter (like Leo's problem case), you should carefully consider your needs and do your own assurance testing; much like determining whether you should upgrade IOS or hardware. All software and/or hardware, including reload variations, can be buggy.
(Also, BTW, in Leo's case, it's possible the issue might be resolved in a latter release. [One case I like to tell, decades ago I spent half a week documenting a bug I found in a mainframe complier. Months later, mainframe vendor provided fix, they provided replacement manual pages with "This page is intentionally blank." - I kid you not!])
The only advice I can offer, when you use less often used, by most folk, features, you often get to be the first to find any bugs.
06-11-2023 03:56 PM
@Joseph W. Doherty wrote:
BTW, to be clear, I'm not recommending any version of reload vs. another. Just noting it shouldn't matter, but since it very much can matter (like Leo's problem case), you should carefully consider your needs and do your own assurance testing; much like determining whether you should upgrade IOS or hardware. All software and/or hardware, including reload variations, can be buggy.
I did not get that impression at all. As far as I am concern, I am merely sharing my sob story (minus the alcohol).
@Joseph W. Doherty wrote:
you often get to be the first to find any bugs.
With IOS-XE, finding bugs is as easy as turning the appliance on. It is so easy to find them nowadays.
06-13-2023 11:23 AM
@Leo Laohoo and @Joseph W. Doherty , thank you all for providing so much insight into this! And I liked the personal sob stories about the 9500 crash and the mainframe compiler bug fix! I was honestly just curious about the technical differences between the reload and reload fast which you all have basically answered. I will likely stay with the regular reload command but I will keep the reload fast command in the toolbox just in case (depending on the needs/details of each individual situation), but with the knowledge that reload fast has caused problems for others on past IOS-XE versions.
@Joseph W. Doherty wrote:Unless you're a programmer, who has directly worked with computer hardware, it might be difficult to understand booting (cold start) vs. restarting (reload) a computer, as the end result should be the same.
Just curious, in that comment above, what difference were you referring to? I enjoy computer hardware though I've never programmed any chips myself. Are you referring to the difference being that a cold start includes the initialization of the hardware and any POST/environmental checks or other firmware code execution, vs. a "reload" that just reloads the OS itself ?
06-13-2023 11:49 AM
Yes, exactly! I.e. basic soft boot/reload might bypass most or all POST, but how much might be bypassed can vary, which might be selected, like difference between reload and warm reload, the later not physically reloading IOS.
06-13-2023 12:19 PM
@Joseph W. Doherty ok great! Thanks again!
06-13-2023 03:24 PM
Since you mentioned you liked our stories, how about this one . . .
One upon a time (about 40 years ago), I was doing software development on a PC XT clone (running MS-DOS - which did not yet support a multilevel directory structure [i.e. no subdirectories/folders] on the 10 MB hard drive [it did support up to 512 8.3 filenames, without any directory listing sorting options - oh joy]).
Anyway, I was doing something (switching between multiple printers? [again, a very early MS-DOS, possibly a 1.x variant]) where I had to reboot the PC. Either a power recycle boot or a control-alt-delete reboot would work, but the latter took much less time. (For the power recycle boot, I programmatically jumped to the initial start address used by a power on boot - i.e. power wasn't actually cycled, but the full power on boot process was done, POST, etc.)
The starting address for a power on boot was hardware defined for the 8088, but the warm boot, control-alt-delete sequence, was software driven, and could vary between platforms. Basically, all I wanted to know, where the warm boot vector, i.e. the address to jump to, for the PCs I was using.
So, I contacted our distributor, and they said, you need to contact your reseller. I said, we are one of your resellers. Can you provide a technical manufacturer contact? They asked, what's the technical question? I answered I want the warm boot vector. They asked, what's that? I answered the jump address for control-alt-delete. They said, huh? I said, exactly why I want to talk with the manufacturer. I doubt you can convey the question as it make no sense to you, but the "right" person probably knows the answer off the top of their head.
The distributor did get me a direct contact with the manufacturer, and much of the forgoing was repeated. Including the address I want is likely in the BIOS you had to write for your PC.
Finally, they got a developer on the phone, who very timidly says "hello?" (I figure by this time, the developer was told there's some wild guy on the phone who has been ranting and raving about needing some technical information only those familiar with the BIOS [whatever that is] would know.) So, I say "hi, I just calling to find out if you can provide me the warm boot vector". The developer responded [off the top of their head], oh, that's 0xFF...... I said thanks, that's all I wanted to know. With that, the developer relaxes, and we spend the next 10 to 15 minutes talking shop - laugh. Oh, and that address did allow me to programmatically do the same as pressing control-alt-delete, which was considerably faster than using the initial cold start address.
BTW, I have directly programmed computer hardware; not much though, as on mainframes and minis, and later micros/PC, there's was usually some software (e.g. BIOS) to interface with that drove the hardware. But, back in the late '70s, on my own microcomputer (PCs came along a couple of years later), I wrote my own terminal emulator (in Z80 assembler), that directly sent text to the CRT (video), sent data to the printer port hardware (and dealt with printer status relayed by the port hardware), totally drove the RS232 UART hardware, etc. (Most network engineers - reading this - might also say - huh? - but you did note you "enjoy computer hardware".) The only "BIOS" support was, I could receive characters from the keyboard, through it.
My program worked fine, and was a great leaning experience! Interestingly, I wrote this program to print out another assembler terminal emulator program listing, which I could then use, after I assembled it, to download an even "better" terminal emulator, that supported various file transfer programs, like XMODEM, YMODEM, ZMODEM, save to disk, possible emulate some of the common ASCII terminals at that time, etc. (Could I have added such features myself? Probably, but as this program already existed, and was free of cost, I did not feel the need to.)
06-14-2023 07:40 AM
@Joseph W. Doherty wow that's an awesome story! I'm in my 30's but I still enjoy computer history very much, so it is very interesting to hear stories from "once upon a time" as you said : - )
I've never thought about rebooting a PC by having your program just jump to the address that the boot sequence starts at (whether cold or warm boot). That is just awesome. And hilarious that the dev knew the warm boot address off the top of his head, just like you thought he would.
Probably off topic for this post but I recently finished reading through all 123 stories on Folklore.org: The Original Macintosh where Andy Hertzfeld and other dev's recount creating the original Macintosh (I'm not an Apple guy, Android ftw, but I still enjoy reading about early development of such a system as the Mac). Reading about Burl Smith and his hardware genius is pretty cool. In several of the articles they talk about certain memory addresses for doing certain things, even the hidden "copyright infringement" memory address in the original Mac.
And very cool that you wrote your own terminal emulator! I respect anyone who writes in assembly, especially "non-Intel" assembly since those assemblers would be less widely known (maybe not the Z80? maybe it was popular, I'm not sure). And if I read that right, cool/funny that you wrote that terminal emulator assembler program, to print out another assembler terminal emulator program listing, which you could then assemble to download yet another terminal emulator : - D Crazy some of the hoops you had to jump through in the early days to get what you needed! And yes, it can be fun/educational to write a program yourself, but sometimes, if the program already exists and you'd rather use your time elsewhere, it's just easier to use the already-written program.
And you mention that most Network Engineers reading this might also say "huh?" : - D but it's interesting to note how the early network engineers would absolutely have been very familiar with "low-level programming," perhaps not direct hardware programming but certainly programming that was very close to the hardware. Terry Slattery (many know him as the first non-Cisco employee to get the CCIE cert (#1026)) recounts how the first Cisco router had to be re-programmed on the fly by an engineer at a trade show:
The History of the Cisco CLI - NetCraftsmen
Back in the late 1980s and early 1990s, the Cisco CLI underwent several changes. The original Cisco router didn’t even have a CLI. According to Kirk Lougheed, one of the founders of Cisco, it was only intended to have its configuration loaded via TFTP. He told me that he needed the ability to change the configuration at a trade show, so he added a quick hack to allow him to type the configuration into a buffer, which was passed to the function that parsed the TFTP file. The end of the input was indicated with CTRL-Z. You entered all the commands and when you pressed CTRL-Z, the file was parsed and any errors were displayed.
Terry also does a great podcast with Rob Widmur on the Network Collective show, about the history and development of the Cisco CLI , which is very interesting if anyone enjoys computer history stuff and also "lower-level" computer stuff: (see the #9 ranked episode in this link, History Of Networking – Cisco CLI – Terry Slattery and Rob Widmer
Best Underlay Podcasts | Most Downloaded Episodes (owltail.com)
06-14-2023 09:35 AM
I glad you enjoyed my "once upon a time" story. ; )
You know you're getting old when the story of the Macintosh is "computer history". I well remember its release. It was the low cost version of the Apple Lisa, which barely sold because of its cost. When I wrote of programming a Z80, at that time Apple's computer was the Apple II, which, one day discussing an issue with a co-worker that had one, I was really surprised by what hardware the Apple II did not have, like a disk(ette) controller chip! (This was done to reduce the Apple's cost.)
Also at the time, I knew who Bill Gates was even when Microsoft was a company of about 10 employees whose sole product was their (expensive) Basic interpreter.
Also at that time, there was no Cisco, but we did have networks, even the early version of the Internet, but not quite what it is today (even IP hadn't yet become the de facto standard). (I will note, circa 1980, I used to play multiuser games and remotely access my company's mainframe across what would later become the "Internet".)
I'm somewhat amused reading that NetCraftmen's Cisco CLI "history", starting with "I don’t think many people know the history of the Cisco CLI and the impact it has had on the industry."
Why amused? Because CLIs were in use well before Cisco's. Yea, UNIX's is mentioned, but other computer systems had them too in the '60s or '70s. One of the most advanced CLIs I ever personally used (even to this day) was on a DECSystem-20. (The computer books author, Russ Walter, also very highly regarded this OS.)
Basically, Cisco's CLI had no real innovation conceptionally, and perhaps even for its implementation. (The forgoing isn't to knock Cisco, or the hard work done by so many to make Cisco a success - obviously, they've done something right - but I believe it's much more due to other factors than their CLI. Basically, this history is somewhat like saying how innovative the Macintosh was while ignoring the Apple Lisa or the Xerox Alto. Again, Apple did accomplish something grand by making a computer system for the mass market, but the innovated concepts predate the Macintosh.)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide