Restore vlan.dat file on switches

[lni1]

Running RME 4.0.3, the config files and the vlan info are stored in 2 seperate files. If ,for example, a C2950 switch dies, it needs to be replaced by a new one. The actual config is no problem, but how do you restore the vlan.dat file ?

I already tried to copy the cfg file from the shadow dir into the new switch using tftp, but the actual vlan.dat and the cfg file in the VLAN dir are not the same !! Are there other places where the vlan.dat info is stored without modification ?

In addition, what if you have a switch wich is server in a vtp domain, and loses it's vlan info, you have the same problem, how do you restore the vlan.dat ?? Many thanks in advance.

Lieven Stubbe

Belgian Railways

[David Stanford]

Answered in earlier post for you:

The vlan.dat files are not copied into the shadow directory. They are binary files which are unreadable by humans.

But in the file system (\CSCOpx\files\archive\config) you would

see something like this:

20051028161009running.cfg

20051028161009vlan.cfg

20051028161707running.cfg

20051028161707vlan.cfg

If you have five generations of running configs archived, the version numbers for running

and vlan.dat will be matched. So if you want to restore version 4 of the running config,

you would restore version 4 of the vlan config.

You need to use the CLI to restore the vlan and here is the command:

cwconfig put -u username -p password -device device_name ?version version_number -filetype vlan

You have to reboot the device after downloading the VLAN configuration. Only after you reboot the device, will the VLAN configuration take effect.

[lni1]

I don't understand anymore, beneath the /var/adm/CSCOpx/files/rme/dcma/shadow/Switches & Hubs

directory I have a PRIMARY dir(wich contains the config) and a VLAN dir (I suppose the vlan.dat info ?)

Files like 20051028161009running.cfg are not on my system, anyway the the archive setting is set to : /var/adm/CSCOpx/files/rme/dcma, and in the /archive/config dir I find nothing.

What am I doing wrong ?? I need to find a way to restore my vlan.dat, is this a serious lag in CW ?

Many thanks

[David Stanford]

You can get the version # of the vlan.dat you are looking to restore from the version summary tree

in the GUI. Also, refer to this link:

http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/cw2000e/e_4_x/4_0_3/u_guide/cwcli.htm#wp1078088

Then once you determine the version # you can use the following command:

/opt/CSCOpx/bin/cwcli config put -u -p -device -filetype vlan -version

[rdanevich]

What's the big deal about the vlan.dat file? Add the switch to the vtp domain and let the vlans replicate from the other switches. What am I missing?

Unless it's the only vtp server switch and it went down. Then the vlan information went with it.

[lni1]

Thanks to all for your responses, if the switch is a client in the VTP domain, there is indeed no problem, but if the switch is server and loses it's vlan database, is there a way to restore this using CW ?

[David Stanford]

You can restore it using the above steps and CLI command

[lni1]

I am aware of the cwcli config put command, but if you lose a switch who is server in a VTP domain, this switch becomes unreachable, how do you resolve this problem ? We already had this problem, the only way to resolve is to connect via a console cable and manually enter all the vlans into the switch !!

[David Stanford]

If the switch becomes unreacable then there's nothing that CiscoWorks can do. You would need to connect via console and enter the basic info (IP addr, snmp comm strings) and then you can use the cwcli commands.

[rdanevich]

I have forseen this problem, you've experienced it! It's like putting all your eggs in one basket.

Why not create another VTP server? This will act like a back-up VTP server. No?

[lni1]

I tried to restore a vlan.dat using the cwcli commando on a switch in our testenvironment.

hstest01

INFO - CM0103 Put the config file to VLAN Running Config on device successful

CM0089 Config archival successful for hstest01

INFO - The transport mode used is Telnet

SUMMARY

========

Successful: put

Everything seems to have worked fine, until I do a reload, then I get the following message in the log : %SW_VLAN-4-BAD_VLAN_CONFIGURATION_FILE: VLAN configuration file contai

ned incorrect verification word: 0xBADB100A

What am I doing wrong ?

[miheg]

Does the "new switch" run the same software as the "old" one? I'm tolled this won't work if the IOS in not the same on both machine.

Cheers,

Michel

[lni1]

I set up a test env where I could test the working of cwcli get/put utility. The get works fine and saves the config and vlan data to disk. Things go wrong after the use of the put command, the vlan.dat is pushed back to the device, but it gives this error after reload: SW_VLAN-4-BAD_VLAN_CONFIGURATION_FILE: VLAN configuration file contai

ned incorrect verification word: 0xBADB100A

The vlan.dat has 1 byte more than before the put/get operation. It is not the same file anymore. What went wrong ? There is a serious problem in doing the put of the vlan data file.

[lni1]

I set up a test env where I could test the working of cwcli get/put utility. The get works fine and saves the config and vlan data to disk. Things go wrong after the use of the put command, the vlan.dat is pushed back to the device, but it gives this error after reload: SW_VLAN-4-BAD_VLAN_CONFIGURATION_FILE: VLAN configuration file contai

ned incorrect verification word: 0xBADB100A

The vlan.dat has 1 byte more than before the put/get operation. It is not the same file anymore. What went wrong ? There is a serious problem in doing the put of the vlan data file.

[lni1]

I set up a test env where I could test the working of cwcli get/put utility. The get works fine and saves the config and vlan data to disk. Things go wrong after the use of the put command, the vlan.dat is pushed back to the device, but it gives this error after reload: SW_VLAN-4-BAD_VLAN_CONFIGURATION_FILE: VLAN configuration file contai

ned incorrect verification word: 0xBADB100A

The vlan.dat has 1 byte more than before the put/get operation. It is not the same file anymore. What went wrong ? There is a serious problem in doing the put of the vlan data file.