vlan.dat file deleted during upgrade

Unanswered Question
Jun 8th, 2009
User Badges:

I've gone through the process three times now and have been able to duplicate.


Using CCA 2.0 to upgrade a UC with code CME 4.2(0) or 4.2(3) / 12.4(11)XW7 to 7.0(3) / 12.4.2T2.


Ensuring that the apply default configuration button is NOT checked and the clean up flash is checked, at some stage during the upgrade but prior to CCA rebooting the UC the vlan.dat file is deleted. Which can cause lose of connectivity if using anything but vlan 1 to connect to the UC and a resulting upgrade failed message, even thought the upgrade worked.


Apart from having to re-create the layer 2 the upgrade process worked smoothly.


I've searched through bug toolkit and release notes but haven't been able to find any mention of this.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Steven DiStefano Tue, 06/09/2009 - 05:24
User Badges:
  • Blue, 1500 points or more

Thanks so much for your post and lets see if we can figure this out.


This is not an answer to this thread, rather providing more data for the Technology Group to help us understand.


I know that when I check the 'Auto Disk CLeanup' checkbox in the Upgrade Settings window for UC520 SW Upgrade on CCA 2.0, and I watch the upgrade from an SSH terminal window on the LAN, I can see the files on flash: get transferred off to a cache somewhere on the CCA PC and then put back in the format we all discussed on this forum as being much better organized (as shown below).  SO the file is supposed to momentarily disappear if your watching it live as I was.


In all the cases I have done an upgrade (including XW7 to 7.0.3) I have seen the file restored, however this is not to say that if I do it enough times I may see the error you see.  Only that I know the PC must remain connected (single NIC preferrably) during the 40 minute or so upgrade, for the obvious reason that if its not connected, you run the risk of missing files.


Now having said that, I recently noticed something interesting.   When I did a COnfiguration Archive Backup from CCA 2.0 and looked in the log, I see the following.  I am concerned about the no vlan.dat file found debug message as well, and wonder if maybe there is common code used for upgrade and baackup that could result in the vlan.dat not being recognized, removed, and then not put back?


[INFO] FtpServer - ------- Apache FTP Server started ------
++: DEBUG:  : WDTask::setHierarchy .VSWWarningDialog
++: DEBUG:  : WDTask::setHierarchy .VSWWarningDialog
++: DEBUG:  : WDTask::setHierarchy .BackupRestoreConfigTask
++: DEBUG:  : Duration for [create() @ com.cisco.cpnm.features.defn.backrest.BackupRestoreConfigTask$BackupConfigTask] = [15] msec.
++: DEBUG:  : WDTask::setHierarchy .BackupRestoreConfigTask.BackupRestoreConfigTask$BackupConfigTask
++: ERROR:  : A widget could not be serialized because its id was not set.
++: DEBUG:  : WDTask::setHierarchy .BackupRestoreConfigTask.BackupRestoreConfigTask$RestoreConfigTask
++: DEBUG:  : Duration for [create() @ com.cisco.cpnm.features.defn.backrest.BackupRestoreConfigTask] = [78] msec.
++: DEBUG:  : Duration for [upd Mirror<--Device() @ com.cisco.cpnm.features.defn.backrest.BackupRestoreConfigTask$BackupConfigTask] = [156] msec.
++: DEBUG:  : Duration for [upd Mirror<--Device() @ com.cisco.cpnm.frmwrk.gen.wd.WDTabbedPane] = [156] msec.
++: DEBUG:  : Duration for [upd Mirror<--Device() @ com.cisco.cpnm.features.defn.backrest.BackupRestoreConfigTask$RestoreConfigTask] = [1500] msec.

...
++: DEBUG:  : serverIp is: 192.168.10.101
++: DEBUG:  : result in PCBUBackupRestore: Not a VLAN Message: Is it a genuine error? %Error opening flash:speeddial.xml (File not found)
++: DEBUG:  : No vlan.dat file on SBCS-MainIGNORED!
++: DEBUG:  : No vlan.dat file on the device.


However on my system, the file is put back on flash: in the root as shown, in fact it looks like it was the 2nd to last file restored, so this is why I am not really sure, but wanted to provide my observations.


SBCS-Main#dir flash:
Directory of flash:/

    1  -rw-         660  May 29 2009 06:56:28 -07:00  vlan.dat
    2  -rw-    28064464  May 29 2009 06:47:28 -07:00  uc500-advipservicesk9-mz.124-20.T2
    3  drw-           0  May 29 2009 06:47:36 -07:00  phones
   99  drw-           0  May 29 2009 06:55:00 -07:00  Desktops
  118  drw-           0  May 29 2009 06:55:14 -07:00  autoattendant
  122  drw-           0  May 29 2009 06:55:18 -07:00  bacdprompts
  130  drw-           0  May 29 2009 06:55:32 -07:00  cca
  134  drw-           0  May 29 2009 06:55:34 -07:00  gui
  156  drw-           0  May 29 2009 06:55:58 -07:00  media
  159  drw-           0  May 29 2009 06:56:06 -07:00  ringtones
  193  drw-           0  May 29 2009 06:56:26 -07:00  sn
  196  -rw-       22437  May 29 2009 07:42:00 -07:00  UC520W-16U-4FXO-K9-factory-7.0.3.cfg

128184320 bytes total (3121152 bytes free)


Steve DiStefano

Systems Engineer,

US Field Channel Sales Team

Marcos Hernandez Tue, 06/09/2009 - 09:13
User Badges:
  • Blue, 1500 points or more

The vlan.dat is included in the bundle ZIP an should be restored after an upgrade or backup. I will have our engineers take a look at what you are describing.


Thanks,


Marcos

gstreet Tue, 06/09/2009 - 18:05
User Badges:

To clarify and provide some more information:


After the upgrade a vlan.dat file is on the flash but issuing a "sh vlan-switch" command shows only the default vlans as configured (1, 1002-1005), where prior to upgrade vlan 2, 109, 110 and 254 were configured.  So the post-upgrade vlan.dat is not the vlan.dat file that was copied off the flash.


I was connected directly into port fa0/1/7 on the UC using a vista business laptop, firewall off, no ftp/tftp etc, and the laptop didn't turn off/sleep during the process.  The port on the UC was configured as access port on vlan 254, the vlan interface was using 192.168.254.1 / 24.


The files were copied ok, and then status bar read "rebooting device", after approx 12 minutes the "software upgrade failed" message appeared.  It was then that consoled into the UC and saw the interface up/down and only the default vlans configured.

Marcos Hernandez Wed, 06/10/2009 - 09:29
User Badges:
  • Blue, 1500 points or more

If you checked cleanup flash during teh upgrade, your existing VLAN.dat will be gone, so any customer vlans will have to be re-added to the database. This is less than ideal, but expected. I will propose an enhancement to address this.


If you are doing a backup and restore, then we should preserve the vlan.dat, and according to Steve we aren't. This is more a bug than an enhancement and I will also request a fix.


I will update the thread with both requested records for tracking purposes.


Thanks a lot for the feedback (and patience).


Marcos Hernandez
Technical Marketing Engineer
Cisco Systems, Inc.

Marcos Hernandez Wed, 06/10/2009 - 09:42
User Badges:
  • Blue, 1500 points or more

The following Software Defect record has been filed for this:


CSCta11291 VLAN.DAT File should be kept after a backup/restore and software upgrade


Thanks,


Marcos

Marcos Hernandez Wed, 06/10/2009 - 13:27
User Badges:
  • Blue, 1500 points or more

I have confirmed the following with engineering:


1) If you do a configuration backup and then a restore, the VLAN.dat file that you had prior to initiating the backup, should be in the new config after the restore.


2) If you upgrade and you DO NOT check “Apply factory config”, the VLAN .dat file you had prior to the upgrade should be untouched after you are done. If you check the box to clean up flash, the flash is formatted, so the vlan.dat is gone for a moment, but it is saved before the format, and restored immediately afterwards.


3) If you upgrade and you check “Apply factory config” then we overwrite VLAN.dat and leave just VLANs 1 and 100.


The 7.x.x ZIP Software Pack files have vlan.dat in the root directory, along with IOS and all the other software. We need it there in order to replace the existing one if default configuration is applied.


In closing, we designed the system to preserve and delete the file correctly, but you are seeing a different behavior. We will take a look at this and use the bug reported earlier to correct any issues.


Thanks,


Marcos

Actions

This Discussion