Connecting the world…

file

Juniper SA – Host Checker

Security is getting more and more important for people. I notice that especially IT manager would like to implement some kind of security measurements to improve the safety of their network and data. Lately I have been busy with configuring a Juniper SA solution. The customer wants to publish different kind of services through the Juniper SA to his employees or suppliers. Example of these services are file sharing and full IPSec tunnels. When using file sharing and full IPSec tunnels, the use of a virus scanner is arbitrary for all workstations connecting to the customers network through the Juniper. Juniper provides an option to configure a Host Checker to check if the client has a (specific) virus scanner. This kind of predefined check only works with Windows clients.

I wanted to configure a predefined Host Checker for all the Windows clients connecting to the Juniper SA box. The configured policy checks all Windows clients on a, by Juniper supported, virus scanner. This works perfectly, but I noticed at all Linux and Mac OS X users weren’t able to connect anymore. When configuring a Host Checker policy for Windows, you also have to configure a policy for other OS-users, like Linux and Mac OS X.

I didn’t know which policy to configure for these users, because the outcome of the policy check should be positive at all times. I have the option to check the presence of a specific file. This gave me the idea to configure a dummy file check for Linux and Mac OS X clients. The dummy file check has the following properties:

Host Check

The policy checks the presence of the file mac_dummy_file. To pass the host checker test, the file should NOT be present of the client. I configured a similar rule for Linux clients. By configuring the policy like this, all Windows clients are checked on the presence of a virus scanner and the Linux and Mac OS X hosts are checked on the dummy file. Normally, the dummy file doesn’t exist on the specific Linux / Mac OS X clients, so they are always allowed access to the Juniper.

I guess it’s a nice workaround….

Another NVRAM broken?

On Monday I visited another customer who had problems saving the running configuration of a Cisco devices. The devices involved were a Cisco 2620 and a Cisco 2610XM router. Both routers weren’t able to save their running configuration.

Both routers show the following error-message:

startup-config file open failed (Bad file number)

By both routers I was able to look at the contents of the flash memory, but I wasn’t able to look at the contents of the NVRAM. When trying to look at the contents of NVRAM, you receive the following error-message:

Directory of nvram:/

%Error opening nvram:/ (Bad file number)

No space information available

22w0d: %SYS-4-NV_BLOCK_INITFAIL: Unable to initialize the geometry of nvram

The following information can be found on the error-message on the Cisco website:

%SYS-4-NV_BLOCK_INITFAIL : Unable to initialize the geometry of nvram

 

Explanation    The software has detected that it failed to initialize the NVRAM block geometry (a part of the NVRAM that hosts non-configuration data files). Typically, these files are used by SNMP to store and retrieve non-configuration persistent data across a system reload. This condition may occur when the entire NVRAM is packed with the configuration, and the newer version of software that supports this feature could not find enough room in the NVRAM to initialize the block file system.

Recommended Action    Reduce the configurations in the NVRAM by at least 2Kb.

Source

Luckily one of the two routers was the old production router, which was swapped and the customer thought the NVRAM was broken. So I could use that router for testing purposes.

I started looking at the some physical aspects of both routers. They both had the following hardware specifications:

  • 16 MB Flash memory
  • 64 MB RAM memory
  • 32K NVRAM
  • IOS version 12.4(5)

While looking at the running configuration of the active router, I noticed that the running configuration was almost 2900 bytes (29K), which is stored in NVRAM. I believed that the error-messages were generated because NVRAM was full. I started deleting some configuration from the broken router, until the running configuration was only 20K. But I still wasn’t able to save the running configuration.

The last change I had was updating the IOS. I downloaded the last Main Release, which is 12.4(23). I formatted the flash memory and uploaded the image to the spare router. And fortunately, after a reload, I was able to save the running configuration.

The running configuration was still almost 2900 bytes. I issues the command to compress the configuration:

service compress-config

Now the running configuration is compressed from almost 2900 bytes to 1000 bytes.