nvram:private-config is destroyed when we write nvram:startup-config

[flaviojs]

I decided to get the filesystem format used in the nvram of the routers.

Apparently startup-config and private-config are kept in a special section at the start of the filesystem, but the nvram_push_config/nvram_extract_config functions don't know how to handle private-config.

This means that by writing startup-config we will destroy any pre-existing private-config... =~~
It probably survives if we happen to write the same amount of data as the existing startup-config.

Ok... I can see two ways of dealing with this:

• Strategy 1 - bundle both in the config file
  • make nvram_extract_config read both files and add some kind of divider to distinguish between them. Ex: "\n!!!! nvram:private-config divider, DO NOT REMOVE !!!!\n".
  • make nvram_push_config split the data if the divider is found
• Strategy 2 - preserve existing private-config
  • make nvram_push_config aware of private-config in the nvram and preserve it when writing startup-config

@grossmj
What would be preferable?

Related Topics

http://forum.gns3.net/topic5520.html
http://forum.gns3.net/topic5374.html

[flaviojs]

I tried doing erase nvram: and erase startup-config in a 1700 router and both startup-config and private-config are erased, so I'm pending for strategy 1.

Question is: what should be used as a divider

[grossmj]

I need to think about it. I'll come back to you soon (I am in holidays).

[rednectar]

FWIW: If you go down this path I suspect the word end on a line by itself would be a an excellent divider (if you are planning to put the contents of the private-config in some kind of text file).

IMHO I think the problem can be solved with existing techniques and simple logic. I.e.

When opening a topology, check if the user is using a local working directory. If so, do NOT do a nvram_push_config when the topology is loaded, because the nvram that is there is just fine the way it is. This is how other users have been getting around the problem (by deleting the cnfg= from their .net files, which effectively does the same thing)

[flaviojs]

After some work on the NVRAM filesystem, I'm pending toward a new strategy.

• Strategy 3 - extend hypervisor commands push_config, extract_config, and set_config
  • when startup/private data isn't provided, preserve existing data
  • push_config takes in a new optional argument for the private data. New behavior: an empty string '' means no data is provided and it should preserve existing data (to write an empty string as data, send a base64 encoded string with only padding '====')
  • extract_config returns both startup and private data.
  • set_config takes in a new optional argument for the file with private data. New behavior: an empty string '' means no config file.

Basically, pass the responsibility of deciding what to do to GNS3/Dynagen.

@rednectar
Nice, using end as the divider is interesting, but I'd like to avoid interpreting the config data if possible. =)

Restricting when push_config is sent (quick fix) can fix the general use case in GNS3, but doesn't fix the underlying bug. =~~

[flaviojs]

Fixed by preserving existing private-config. (Strategy 2)
Still waiting for feedback on what would be preferable. (is Strategy 3 a good idea or not?)

[grossmj]

I like strategy 2 and think strategy 3 is the cleanest solution and most flexible solution. My question is do we really need this kind of flexibility?

[grossmj]

I've been testing strategy 2 with GNS3. Works very well, crypto keys are correctly restored after a reboot and a project reload.

[flaviojs]

With the "Save nvrams..." option NOT selected, the working files are deleted when the project is closed (private-config data is lost).
If this is ok, then strategy 2 is enough. It probably isn't ok.

[grossmj]

True but strategy 3 will require to change the way GNS3 manage the configs. I would rather do it properly in GNS3 1.x versions. So I think strategy 2 is enough for the current and older versions and strategy 3 for the future design.

[flaviojs]

Ok, gonna close this issue and create an enhancement issue for the implementation of strategy 3.