GNS3 and Service Compress-Config Problems

I’m a huge fan of GNS3 as a network simulator. While it’s not as CPU efficient as the fabled, not-public, nobody-has-a-copy-honest IOU (IOS-on-Unix) which obviously I know nothing about (how could I?), the graphical interface it provides to Dynamips really does make it easy to build a network topology quickly and run up a simulation.

This week though I hit a problem that I hadn’t seen before, and I’m mad about it. It all comes down to the service compress-config global configuration option.

Once upon a time I used the configuration-file-based dynagen as a front end to dynamips, the hypervisor that makes GNS3’s IOS emulation possible. Then GNS3 came along and added pretty graphics to the whole shooting match and made connecting devices in a visually satisfying manner and triggering dynamips to emulate it all a matter of a few clicks. Initially GNS3 only worked with IOS images  for the 3600 and 7200 platforms, but coupled with the later integration of PIX emulation (Pemu) and other platforms via Qemu and VirtualBox, it’s now a real powerhouse in the network simulation world. And it’s free, though you have to provide your own software images. You also have to provide sufficient CPU and RAM to run all the VMs you are asking it to launch, but hardware limitations aside it’s a regularly-used tool in my networking arsenal.

Free Performance Tip

Let me sideline for a moment. When you choose which hardware and software to emulate, two strategies have worked well for me after they were passed to me by a colleague. I can’t guarantee you that these are scientifically accurate but my own  empirical testing indicates that these tips got me more routers running on a single computer. Your mileage may vary, of course.

1. Seek an image that is memory efficient. The T-train (or similar) images are usually bloated as all get out and require huge wads of RAM, so unless you absolutely need that latest and greatest feature, seek out an image that gives you what you need while demanding the least RAM to run. Choosing a more limited feature set may preserve enough resources to allow you to simulate more routers at a time. We did this before memory sharing was an option in dynamips, but I still follow the advice now.

2. Choose your hardware carefully. For example, if you are simulating routing changes, would a c3600 be sufficient rather than a c7200? If the IOS features you need for your simulation are the same on both, they both have sufficient interfaces, and really you just want to see if things work, then I would always choose the lower end router. Why? Because the CPU in the 7200 runs roughly twice as fast as that in the 3600. Dynamips runs by emulating the CPU on the router platform, so in theory it’s emulating every CPU cycle that goes by. If you choose the 7200 platform, you are choosing to make dynamips emulate twice as many CPU cycles as if you chose a 3600. So even with a nicely tuned idlePC value, you’ll still get more simulation our of your computer if you choose the lower horsepower hardware.

The Scenario

So anyway, last week I started building a simulation to model a client’s network changes, and by the end of the week I had around 7000 lines of configuration over 7 routers, 6500 or so lines of that shared by two routers that were injecting a lotta routes into the test environment. I was running GNS3 0.7.4 I think, but for the purposes of this post I upgraded to the latest 0.8.2 and repeated the exercise.

The problem with putting 3300 lines of configuration into the c3600 routers was that the configuration size exceeded the default 128MB of NVRAM that was allocated. Ok, I could go back to GNS3 and raise that value, but being smart I had a better solution: compress the configuration! All was good until I loaded up my topology again on Monday morning.

Follow The Bouncing Ball

So, follow along with me here while I recreate the problem. First I create a new project:

Nothing exciting going on there. I added two routers to the project:

• R1 – a c3600 running IOS 12.4(10a) telco
• R2 – a c7200 running IOS 15.1(1)XB2 service provider

I wanted some variety, ok? I went in and set the hostname on each to “MyRouter” – a one line configuration change, then I wrote the config. In GNS3 I saved the project, which also ensures that the configs are grabbed and saved as a .CFG file in the configs/ folder within the project folder. Now I can open the configuration files in GVIM to view them. Here’s the R1 config (click to enlarge):

Service Compress-Config

Now I’m going to go back and issue a configuration command:

service compress-config

Now when I write the configuration file, IOS will compress it and it will take up less space. With my 3300 line configuration, this worked perfectly and the compressed config was able to fit within the 128K NVRAM I had. On my test router, I’m enabling service compress-config and I’ll write the config to see the effect:

Success – my configuration was reduced from 413 to 310 bytes – compression at work! I saved the project in GNS3 again, so let’s look at the saved .CFG file again:

Unsurprisingly, it contains nonsense – but then I guess I’d expect that, as it’s compressed. Everything meanwhile works fine, so who cares?

Reload! Reload!

Now let’s reload the routers. Originally this was caused by shutting down for the weekend, but the same result can be achieved by just stopping the routers and restarting them. Here’s the end of the reload for R1 (the 3600):

And for R2 (the 7200) we see a similar sad story (click to read it):

🙁

Both R1 and R2 have reloaded as “Router” – i.e. they are back to their default configuration. In the case of my client simulation, that meant it had lost 3300 lines of configuration on each of the two routers that had service compress-config enabled. Isn’t that just peachy?

Seeking Solutions

I’d like to tell you that I have a solution, but I don’t. To view a file containing a compressed configuration on a router – e.g. the startup configuration – you can issue this command:

more nvram:startup-config

IOS is smart enough to recognize that the config is compressed and it decompresses the file before displaying to you, so what you see isn’t the jibberish we saw in the compressed .CFG file earlier, but instead you are shown the proper text of the configuration. When I try that on my 3600 for example, this is what I see:

Sadly all signs here are pointing to corruption. If IOS displays the file like this, that suggests to me that IOS can’t even recognize this file as a compressed configuration, and that means trouble.

Conclusions

My initial conclusion is: Don’t use service compress-config in GNS3. I did look around but couldn’t find anybody else complaining about it, so maybe it’s something specific to my system. I’m still digging around to see if there’s something I’m doing that triggers this, though I’m not sure what that could be. Maybe I need to not save the config via GNS3, if GNS3 is the problem. And of course ultimately, I can put more NVRAM on my routers next time so I don’t hit that limit so easily – and that’s really the winning workaround. But then, how often do you hit that limit?

Plea for Help

Can anybody reproduce this? It only takes one router, add a hostname and enable config compression, write the config, then restart the router and see how you fare? Does any of this make sense? I’d appreciate your input and suggestions. And if anybody figures out what is happening to my stored CFG file and can tell me how to recover it, I’ll award a gold star!

Now to get back to recreating those configurations… *sigh*