Nvram Database File

[Marilina Crawn]

Doesanyone know what this is? Can't read it or delete it, both del and erase nvram do not appear to work on it. I am erasing switches and need to confirm that it does not contain sensitive information.

You cannot delete nor read these two files as they strictly belong to the IOS system on your switch or router. Those files do not contain anything sensitive. It is strictly system information that has no relation to any configuration.

Searching for this lead me to believe that the Cisco IOS File System (IFS) saves some persistent date (variables) about the Cisco image in the NVRAM. This data is used upon booting the switch or router.

I wipe clients' sensitive information off of switches for a living. The primary types of switches we work on are the Cisco Catalysts, mainly the 4948 series. Model: WS-C4948E. There are different version numbers, and varied model numbers, but for the most part there a minor differences. You can write the list of commands by entering "help" or "?". You can also see how to complete certain commands by writing a command, such as "write", and then add a "?". For example, entering "erase ?" will write out a list of commands to complete the "erase" command. After entering the command+?, any results that you see show "cr"(with on either side) indicates that you can hit enter with the typed command to execute that prompt. The main commands we use for erasing information off of these switches are "write erase" and "erase /all nvram:". You also want to erase any vlan information by issuing the "erase cat4000_flash:" command. As a double check, we write the command "dir /all all", which will list all the files in each file-system. When it comes to the persistent-data located in the nvram:, it is not possible to delete it. The only possible outcome for a sure-fire reset is to format the system, but that results in a total device wipe, erasing everything including boot files. If you went this route, then the only way it can be booted properly is to add the necessary files back on from the Internet. At that point, it is out of our hands.I hope this helps!

The reason I ask is that I am using Gazell pairing. It seems to me that, for part of the database in nvram, it partitions up its information into 4bit chunks, 8 to a 32 bit word. It shuffles bits and requires a byte to be written, I think for each pairing, which of course turns into a 32 bit word being written per byte demanded i.e. potentially 8 times. It would appear therefore that the nRF52840 is incompatible with the current version of Gazell, which, to say the least is worrying to me since I am sort-of committed to both. What is wrong with my understanding above?

Hello Runar, Ah, not being able to attempt to write 0 more than twice as opposed to not being able to write a 32 bit word more than twice, puts an entirely different light on the limitation. Presumeably, if the bit written 0 the first time, contains a 1 in the next 7 writes, that will be OK?

I did not check whether all the bits already zero are set to 1 on the subsequent writes. That will take a bit of figuring out. Meanwhile, you will find the code in components\proprietary_rf\gzll\nrf_gzp_device.c specifically:

Had the specification been more specific, I would have checked the code carefully before troubling you with such details. I cannot afford the time today, but I will check carefully myself whether anything breaks the clarified restrictions you have given. It would be REALLY nice if you could persuade the specification writers to be more er, specific - your clarification makes a huge difference to the use of the nvram as a permanent data store.

Yes, that's my understanding as well. Did you find time to check the write routine? I am afraid I did not this week, sorry for the inconvenience. Regardless I will register this write routine (the gazell part) as an internal issue so the SDK team can take a look. I have a feeling this is something that was not considered when porting the library to the new chip/platform.

Hello again. Sorry that this has taken so long. I have now updated to version 17 of the sdk and analysed the code of nrf_nvmc.c and my initial conclusions are not optimistic. I include the code below with my comments interspersed so the logic can be checked by one of Nordic engineers. Essentially the code makes no attempt to avoid re-writing zeros to the bytes NOT being written when the write_byte function is called. What it does is to install the values it wishes to write into the correct place in the 32 bit word, leaving the remainder of the word intact. Therefore to write zeros into the four bytes of a word guarantees that at least some of the zeros are written 4 times i.e. once for the first byte write, then repeated 3 more times for the remainder of the bytes.

Instead of reading the existing value, simply set the initial word value to 0xFFFFFFFF and apply all the same logic (or perhaps just OR the value in instead of using addition - a strange choice of the original author.

It is as though the original author thought that zeros could be written back to ones, or is that the case with some of the Nordic chips??? Is it a question of conditional coding for the nrf52840 - the answer to those questions are beyond my knowledge.

I'm a student that will be taking my CCNA exam in early June and I'm doing a lot of practical revision, I tend to get sidetracked by little things such as this question I'm about to post. It's regarding flash and nvram. The terms are sometimes used interchangeably even though they are two different things. For instance, from this Cisco link: _tech_note09186a0080a49dbf.shtml

VTP client and server systems require VTP updates from other VTP servers to be immediately saved in NVRAM without user intervention. The VTP update requirements are met by the default CatOS operation, but the Cisco IOS software update model requires an alternative update operation. For this, a VLAN database was introduced to Cisco IOS software for Catalyst switches as a method to immediately save VTP updates for VTP clients and servers. This VLAN database is in the form of a separate file in NVRAM called the vlan.dat file.

*The vlan.dat stored in NVRAM alone can be accessed by the switch. The vlan.dat file can be copied from its location for backup purposes. The memory location name where the vlan.dat file is stored varies from device to device. Refer to the respective product documentation before you issue the copy command.

And, by Ciscos definition if NVRAM = flash, on a 2960 switch, then yes, the vlan.dat is stored in the NVRAM and what the documentation says is correct. But what about the other NVRAM? the one where the startup-config is stored, that's a different NVRAM entirely! What is going on here?

My problem is, a lot of the time if I'm reading something for the first time, I can never be sure if they are referring to the real NVRAM where the startup-config is stored, or the Flash memory where the IOS is stored (and vlan.dat). It seems to me that they are moving to migrate both flash and nvram? (nvram and const_nvram in the latest series?) I mean, functionally wise, nvram and flash are the same. Writable memory that doesn't wipe after a reload.

To get a better picture of what happens, you can do a show file systems i flashnvram, dir nvram:, and dir flash: on some of the devices in question. The short answer: NVRAM is a kind of flash memory, and it is never removable. The location of vlan.dat varies by switching platform... the IOS configfiles are always in nvram unless the device is forced to manually store them elsewhere.

My original response is still applicable as it is part of the minimal configuration for DHCP snooping. The database agent ensures that database entries are restored after a restart or switchover you have to specify a place to store the binding database via the agent.

Now whether or not you can get away without using the command I'm not sure. I believe it's there for reason stated earlier ie restart/switchover. If it automatically stores the database in RAM, which I'm leaning towards since if a reboot occurs you would loose all of your bindings. Something to lab and test, but I would recommend using the minimal configuration and specifying a place to store the binding database in the event of a reload you don't loose your dhcp bindings.

Under your link or the link I'm posting there's a section that says "Minimum DHCP Snooping Configuration" you must do these steps at a minimum. There is also a few examples of where or how to use the agent to store the binding database.

The ip dhcp snooping database command is an agent used to store the actual Binding Database either to your flash/NVRAM or a remote server such as a TFTP/FTP/RCP Server which you would preferably use rather than use up the limited storage capacity of your flash/NVRAM.

To keep the bindings when the switch reloads, you must use the DHCP snooping database agent. Ultimately that decision is up to you but recognize that when dhcp snooping is enabled the binding database will grow and where it's stored is up you. The agent allows you to store the database to a suitable server.

3a8082e126