Allied Telesis SwitchBlade x8100 Series - Manual (Page 16)

| SwitchBlade x8100 Series System Overview alliedtelesis .com 16
SwitchBlade x8100 Series | System Overview
Software upgrading
Like other AlliedWare Plus switches, the SwitchBlade x8100
Series has no restriction on upgrading between software
versions. So minor release upgrades (e.g. 5.4.3-2.5 to 5.4.3-3.6)
and major release upgrades (e.g. 5.4.3-2.5 to 5.4.4) are both
supported.
Upgrading the software on a SwitchBlade x8100 Series requires
the software to be distributed to all cards in the system. For the
user, however this is very straightforward, as it is handled behind
the scenes as described earlier.
To upgrade to a newer software release, it simply needs to be
loaded onto the master CFC, set to be used, and the chassis
rebooted. This will cause the CFC to boot with the new
software release, and distribute it to the other cards via the
internal network using its TFTP server.
Incompatible software releases
It is imperative that all cards in the SwitchBlade x8100 system
are running the same software release. This is managed by
the master CFC distributing the software release to the line
cards. This guarantees that the line cards always have the same
software release on them as the master CFC.
There are some situations where it would be possible to end
up with incompatible software versions between the two CFCs.
These are handled by the SwitchBlade x8100 to ensure that a
system will not be running this way.
If the standby CFC boots with a different software version from
what is installed on the master, it would not be in a position to
take over as master if required, as its software would not match
what is installed on the line cards by the original master CFC.
To avoid this possibility, the chassis will automatically upgrade
the standby CFC to match the software installed on the master.
There are two mechanisms to do this depending on how
different the version of software release is:
1) Minor software release variation:
If the two CFCs have a minor release variation, for example,
5.4.3-2.5 and 5.4.3-3.6, they are still able to communicate. As
such the master CFC will use auto-sync to push the software
release that should be used to the standby CFC, which will then
reboot using the correct software release.
2) Major software release variation:
If the two CFCs have a major release variation, for example,
5.4.3-2.5 and 5.4.4-0.1, then the mechanism used to load
software onto the line cards is employed. A trigger file is written
to flash on the standby CFC and it is rebooted. The bootloader
finds the file and attempts to boot the CFC via a BOOTP
request, with subsequent TFTP delivery of the software release
as happens for the line cards. Auto-sync will sync the file to the
standby CFCs flash, so it is ready for any subsequent reboots
with the correct software release.
CFC disabled master
When incompatible software releases present themselves,
there is a situation where the standby CFC could end up
unusable in the system, and as such enter the “disabled master”
state. In this state the system will run with only the master
CFC, meaning only half the backplane bandwidth that would
otherwise be available. This disabled master is not operational
and as such not available to take over as master in the event
of a master CFC failure or hot-swap, so the situation needs
resolving. Log entries are created when a CFC enters the
disabled master state.
The reason a CFC could enter the disabled master state is
that there is not enough flash memory available to store the
software release that the master CFC wishes to auto-sync.
When auto-sync attempts to sync the correct software release
to the standby CFC, if its flash does not have enough space, old
software releases are deleted to make room. The only reason
for a failure to store the new software release is if the flash is full
of other files (core files and so on). As there is 128MB of flash
on the CFC400 and 512MB on the CFC960, this should be a
very rare occurrence.