Enterasys Networks X-PeditionTM Loading Software Images, Using EOS Fallback to Upgrade the Image

Utilizing the Command Line Interface

Programming 131072(0x20000) bytes at address 0xfffa0000

Programming 48299(0xbcab) bytes at address 0xfffc0000

Verifying Bootrom flash sectors

Locking 3 Bootrom flash sectors

Locking 8 Bootrom flash sectors

***** Bootrom update completed. *****

Do you want to remove the bootrom file bootrom_uncmp.fls? (y/n) y

Using default Bootrom password. The system is not secure!!!

Use “bp” to change password

9.Reboot the XSR by entering bw.

10.Repeat Step 8 with: bU bootrom2_01.fls

11.Reboot the XSR again: bw

12.Your Bootrom in Flash memory is now updated and will be used during the next power up sequence.

Note: For more information, consult the SSR boot Release Notes at:

http://www.enterasys.com/download/

Loading Software Images

If the XSR has a valid Bootrom but no valid firmware, the software can be loaded from Bootrom Monitor mode using FTP. You also have the option of copying the image remotely from a TFTP server, using the copy tftp: flash: command, or locally from cflash:, using the copy cflash: command. Be aware that should the transfer fail, the XSR may temporarily be without valid software in flash: and should not be reloaded or powered down until a new image is downloaded. Also, the CLI session which initiated the copy command is blocked during a TFTP download, with a character repeatedly shown on screen to indicate a file transfer in progress.

Using EOS Fallback to Upgrade the Image

The easy to use Enterasys Operating System (EOS) fallback feature safely upgrades your image, as configured from either the CLI using the reload command or via SNMP. If the new image does not successfully install, the XSR will automatically fall back to the previous running image. The functionality works as follows: you download a new, primary image which the XSR will reboot from. After this image loads, the EOS fallback test will run for a period you configure. The test checks if the XSR crashes, and optionally checks if the configuration causes a syntax error or whether the XSR receives any SNMP messages with the primary image. If successful, the following syslog message is sent:

<186>Jun 8 08:49:39 Toronto PLATF: EOS Fallback Test Completed, file my_new_XSR1800.fls is OK

If the test fails, the XSR will send an error message and reboot with the secondary image - the last image loaded before the primary image - and will disregard the primary image. Syslog failure messages can cite no message from SNMP in 30 minutes, startup-config error, crash and watchdog expired. Respond as follows to these failure causes:

•If XSR reboots with the secondary EOS file, check the fault report generated and retry reload

2-34 Managing the XSR