Оригинал статьи тут - http://blog.masker.net/post/7321179541/using-rommon-to-recover-startup-config-from-nvram.
Восстановить startup-config из nvram через ROMmon.
We had a supervisor die in a core switch today. (Alas! He served us well…) Incidentally, an unrelated issue with CiscoWorks meant that I did not have the fresh, readily-available backup config that I have come to take, all too much, for granted. A quick look through my console logs (I keep a local log of everything I ever do. Remind me to post on that later.) revealed that my last ‘show tech’ for this particular device was back in December of last year. It would not have been a huge deal to start there and make a few updates, but I really really really like to be confident I have the most fresh config possible. I would hate to miss some small detail and have an issue down the road attributed to human error. So… why not pull the config out of NVRAM from the half-baked supervisor?
The answer would be because you can’t. At least that was the response from the TAC Engineer when I asked. Of course, I didn’t believe him. ;) The real challenge was that, in this particular case, the supervisor would no longer boot. It would crash and break back into ROMmon before there was an opportunity to enter any commands in IOS and, apparently, there is no (easy) way to access the NVRAM file system from within ROMmon. The ‘dev’ command will show what file systems are available.
Your devices may vary with different platforms. On my WS-SUP720-3B, the appearance of the devices prefixed with ‘mk’ depended on when I broke into ROMmon. Only devices marked as file system capable can have their contents displayed with the ‘cat’ or ‘fdump’ commands.
Hmm.. No NVRAM. A real bummer, because entering ‘cat nvram:startup-config’ would have been the perfect happy ending. My next thought was to use the password recovery procedure. I thought that if I could get the switch to boot more quickly without any configuration then I just might have enough time to copy the startup-config from NVRAM to flash. No luck. Possibly due to the nature of the failure, the supervisor was completely ignoring the ‘ignore system config info’ setting in the confreg. Setting ‘confreg 0x2142’ in ROMmon had no effect—the switch continued to parse the config and crash at the end. It really looked like, if there was a solution, it was going to have to come from within ROMmon itself.
If there was no solution, there would be no content for a blog post. ;) So here is what I came up with:
With ROMmon there are some fairly powerful debug tools at your disposal. You can access these by entering the ‘priv’ command.
After entering the ‘priv’ command, you have access to more commands which you can see by entering the ‘?’ command. Also, the output of commands that were previously available may be altered.
Another command revealed by ‘priv’ that is of interest is the ‘dump’ command.
I say all that to say this: Back up your config. It really is a lot less hassle. =)
Shout out to @netpappy for joining in the fun. (And, yes… also for waking me up this morning to let me know my core was down. ;P )
Оригинал статьи тут - http://blog.masker.net/post/7321179541/using-rommon-to-recover-startup-config-from-nvram.
The answer would be because you can’t. At least that was the response from the TAC Engineer when I asked. Of course, I didn’t believe him. ;) The real challenge was that, in this particular case, the supervisor would no longer boot. It would crash and break back into ROMmon before there was an opportunity to enter any commands in IOS and, apparently, there is no (easy) way to access the NVRAM file system from within ROMmon. The ‘dev’ command will show what file systems are available.
rommon 10 > dev
Devices in device table:
id name
net: network
bootdisk: boot disk (device is file system capable)
disk0: PCMCIA Disk 0 (device is file system capable)
disk1: PCMCIA Disk 1 (device is file system capable)
eprom: eprom (device is file system capable)
mkseg1: main memory (kseg1)
mkseg0: main memory (kseg0)
mkuseg: main memory (kuseg)
Your devices may vary with different platforms. On my WS-SUP720-3B, the appearance of the devices prefixed with ‘mk’ depended on when I broke into ROMmon. Only devices marked as file system capable can have their contents displayed with the ‘cat’ or ‘fdump’ commands.
Hmm.. No NVRAM. A real bummer, because entering ‘cat nvram:startup-config’ would have been the perfect happy ending. My next thought was to use the password recovery procedure. I thought that if I could get the switch to boot more quickly without any configuration then I just might have enough time to copy the startup-config from NVRAM to flash. No luck. Possibly due to the nature of the failure, the supervisor was completely ignoring the ‘ignore system config info’ setting in the confreg. Setting ‘confreg 0x2142’ in ROMmon had no effect—the switch continued to parse the config and crash at the end. It really looked like, if there was a solution, it was going to have to come from within ROMmon itself.
If there was no solution, there would be no content for a blog post. ;) So here is what I came up with:
With ROMmon there are some fairly powerful debug tools at your disposal. You can access these by entering the ‘priv’ command.
rommon 2 > privNevermind the warning, that isn’t there for us. :) Besides, my supervisor wouldn’t boot anyway. What is there to loose? On some platforms you need a password to enter the ‘priv’ command. (Google that.) On this particular platform, no password was required.
You now have access to the full set of monitor commands.
Warning: some commands will allow you to destroy your
configuration and/or system images and could render
the machine unbootable.
After entering the ‘priv’ command, you have access to more commands which you can see by entering the ‘?’ command. Also, the output of commands that were previously available may be altered.
rommon 3 > meminfoIssuing the ‘meminfo’ command before entering ‘priv’ gives output on the size of the main memory, the offset of the first available block and the size of the NVRAM and BootFlash. Entering ‘priv’ before entering the ‘meminfo’ command discloses additional details, including the physical address of the ROM, NVRAM, Boot Flash & IO Registers. Interesting.
Main memory size: 512 MB.
Main memory size: 0x20000000
Available main memory starts at 0xa000f500, size 0x1fff0b00
NVRAM size: 0x200000
BootFlash size: 0x4000000
Physical Address :
ROM : 0x1fc00000
NVRAM : 0x1e000000
Boot Flash : 0x1a000000
IO Registers : 0x1e880000
Another command revealed by ‘priv’ that is of interest is the ‘dump’ command.
rommon 16 > dumpBy now you know where we’re headed. It looks like the physical address and length of NVRAM output by ‘meminfo’ will fit nicely into the parameters accepted by the ‘dump’ command!
usage: dump [-dlbw] addr length
rommon 4 > dump 0x1e000000 0x200000Not quite. It turns out the key is when you break into ROMmon. I need to research this more, but I suspect it has to do with if control has been passed to the route processor yet, etc. Basically, you need to be at the right stage of the boot process to even access the NVRAM. If you broke into ROMmon at an early stage of the boot process (i.e., right after reloading the switch like most of us do) then you will see the exception above if you try to ‘dump’ the physical address of the NVRAM. The key is to let the first system image extract and decompress and break in after you see the first Cisco IOS banner.
1e000000
*** TLB (Load/Fetch) Exception ***
Access address = 0x1e000000
PC = 0xbfc156c0, SP = 0x800071e8, RA = 0xbfc15658
Cause Reg = 0x00000408, Status Reg = 0x3041c003
monitor: command “dump” aborted due to exception
rommon 11 > resetNow, try the commands again.
System Bootstrap, Version 8.5(4)
Copyright (c) 1994-2009 by cisco Systems, Inc.
Cat6k-Sup720/SP processor with 524288 Kbytes of main memory
Autoboot executing command: “boot disk0:s72033-ipservicesk9_wan-mz.122-8.SXF14.bin”
Loading image, please wait …
Initializing ATA monitor library…
Self extracting the image… [OK]
Self decompressing the image :
#######################################################################################################[OK]
Restricted Rights Legend
Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software - Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.
cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134-1706
Cisco Internetwork Operating System Software
IOS (tm) s72033_sp Software (s72033_sp-IPSERVICESK9_WAN-M), Version 12.2(18)SXF14, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by cisco Systems, Inc.
Compiled Thu 08-May-08 02:14 by kellythw
Image text-base: 0x40101040, data-base: 0x4148E730
*** System received an abort due to Break Key ***
signal= 0x3, code= 0x0, context= 0x50007688
PC = 0x402d1dec, Cause = 0x2020, Status Reg = 0x34008002
Exit at the end of BOOT string
rommon 1 >
rommon 2 > privWe have output. Neato. Now, I’ve redacted some of my output above for fear of the unknown, but you’ll notice that the 2102 in the first two lines of output looks suspiciously like it must be the location of the confreg. Now to poke around and find the location of the startup-config. My configuration was on the large side, so I chose to take a peek at 0x1e010000, then 0x1e020000, 0x1e030000 and so on. Once you find something that looks like a configuration, you can back up to the point in memory where it begins and dump from there. It should be easy to find because the entire config will appear at least twice in NVRAM for the startup-config and underlying-config. You can stop the output at any time by sending a break to the console. I ended up finding my config at 0x1e0207f0.
You now have access to the full set of monitor commands.
Warning: some commands will allow you to destroy your
configuration and/or system images and could render
the machine unbootable.
rommon 3 > meminfo
Main memory size: 512 MB.
Available main memory starts at 0xa000f000, size 0x1fff1000
NVRAM size: 0x200000
BootFlash size: 0x4000000
Physical Address :
ROM : 0x1fc00000
NVRAM : 0x1e000000
Boot Flash : 0x1a000000
IO Registers : 0x1e880000
rommon 4 > dump 0x1e000000 0x200000
1e000000 0000 0000 0000 0000 0000 0000 0000 0000 …………….
1e000010 0000 0000 2102 ffff ffff ffff 0000 0000 ….!………..
1e000020 0000 0000 0000 0000 0000 0000 0000 0000 …………….
1e000030 0000 0000 0000 0000 0000 0000 0000 0000 …………….
1e000040 0000 0000 0000 0000 0000 0000 0000 0000 . …………..
rommon 24 > dump 0x1e0207f0 0x100000Let the ‘dump’ command output the startup-config in its entirety and then break out and save the output of your console. At this point you already have the configuration, but there is still a little work involved in getting it into a usable format. I had the best results using Notepad++ and regular expression find/replace to parse out the offset prefix, ascii output and any extra newlines or spaces (super easy because the fields are output at a fixed length), then using a conversion utility to convert the hex back to ascii. Using the hex, rather than the ascii portion of the output ensures that all formatting and spacing will be exactly the same. Fun, no?
1e0207f0 0000 0000 0000 0000 0000 0000 0000 0000 …………….
1e020800 0000 0000 0000 f0a5 abcd 0001 7892 0c02 …………x…
1e020810 1e02 082c 1e04 4ba2 0002 4376 0000 0000 …,..K…Cv….
1e020820 0000 0000 0000 0000 0000 0000 0a21 0a21 ………….!.!
1e020830 204c 6173 7420 636f 6e66 6967 7572 6174 Last configurat
1e020840 696f 6e20 6368 616e 6765 2061 7420 3136 ion change at 16
1e020850 3a33 393a 3137 2045 4454 2057 6564 204a :39:17 EDT Wed J
1e020860 756e 2032 3920 3230 3131 2062 7920 6a6d un 29 2011 by jm
I say all that to say this: Back up your config. It really is a lot less hassle. =)
Shout out to @netpappy for joining in the fun. (And, yes… also for waking me up this morning to let me know my core was down. ;P )
Оригинал статьи тут - http://blog.masker.net/post/7321179541/using-rommon-to-recover-startup-config-from-nvram.
Комментариев нет:
Отправить комментарий