Schlagwort: 6900

Alcatel AOS7 debuggen von high CPU

Generell: hier geht es um debuggen in der Superuser Shell, es kann etwas kaputt gehen, ich übernehme keine Verantwortung!

Sollte man auf einem AOS7/8 Switch mal hohe CPU Last haben kann man über folgende Befehle einige Debug Daten für das TAC ziehen

su
- top –n 1 (mehrfach)
- Hat man die TOP drei der CPU fresser nimmt man "bt" und sammelt Daten. Vorsicht walten lassen, mindestens 5 mal pro Task, jeweils 3-5 Sekunden warten

debug $(pidof ) "thread apply all bt full"
z.B.: debug $(pidof bcmd) "thread apply all bt full"

Daten aus dem Pakettreiber ziehen
- “cat /proc/pktdrv”. folgendes zieht 6 Sekunden lang Daten, daraus lassen sich dann durchs TAC Durchsatz-Raten bestimmen.

cnt=1;while [ $cnt -le 6 ]; do echo "Iteration:$cnt"; cat /proc/pktdrv; cnt=`expr $cnt + 1`; sleep 1; done

Auf der "normalen" CLI:
- show health 
- show health all cpu
- debug qos internal "chassis  slot  list 1 verbose"
z.B.: debug qos internal "chassis 0 slot 1 list 1 verbose"  bei einem Standalone Chassis (wobei mei mir slot 2 zumindest in einem 6900 mit Einschubmodul NICHT funktionierte)

Das sind dann ein paar Basiswerte, die dem TAC für weitere Analysen als Grundlage dienen können.

Nochmal: Alles auf eigene Gefahr.

Alcatel Dynamic Auto fabric Konfiguration entfernen

In vielen Fällen ist die auto-fabric Funktionalität, welche in den 6900 eingebaut ist nicht gewollt. Trotzdem hat man auf einmal einen Berg von Konfiguration, den man nicht haben will, es ist MVRP aktiviert, daher auch Flat Spanning Tree (sonst geht MVRP nicht) etc.

Will man alle dies wieder Rückgängig machen sollten folgende Befehle helfen:
auto-fabric admin-state disable remove-global-config
mvrp disable
spb isis admin-state disable
no spb bvlan 4000-4015
spantree mode per-vlan

Anzahl der Resets auf OS7 Geräten 6900/10k/6860 zurücksetzen

Hat man ausgiebig getestet kann es sein, dass man bei show chassis mehr resets sieht als man vielleicht wahrhaben möchte.

Konnte man das im AOS 6 Stack noch in der Datei „boot.params“ ändern muss man auf AOS 7 Geräten im Proc-Verzeichnis hantieren:

su
TOR # -> echo 1 > /proc/nvram/numberOfResets
TOR # -> echo 1 > /proc/nvram/systemReboots

Danach rebooten.

Einfacher Zugriff auf andere CMM bei 6900/OS10k im Virtual Chassis

Will man „mal eben“ auf die andere CMM in einem OS10K-Chassis oder eionem 6900-VC zugreifen bieten sich neben den vorher dokumentierten Wegen auch der direkte Zugriff auf den NFS mount an.

ACHTUNG hier endet die Alcatel Gewährleistung, die superuser shell sollte nur benutzt werden, wenn man weiß was man tut.

-> su
Entering maintenance shell. Type 'exit' when you are done.

TOR #-> cd /mnt/
TOR #-> ls
CMMA           CMMB           chassis2_CMMA  chassis3_CMMA  otherCMM

TOR #-> ls -al /flash
drwxr-xr-x   13 admin    user          4096 Jan 20 15:41 .
drwxr-xr-x   23 root     root             0 Jan 20 15:37 ..
-rw-r--r--    1 admin    user          2195 Jan 20 15:51 .bash_history
drwxr-xr-x    2 admin    user          4096 Jan 20 15:41 app-signature
drwxr-xr-x    2 admin    user          4096 Jan 20 15:48 certified
drwxr-xr-x    2 admin    user          4096 Dec 17  2013 diags
drwxr-xr-x    2 admin    user          4096 Jan 20 15:37 foss
-rw-r--r--    1 admin    user           256 Jan 20 15:37 hwinfo
-rw-r--r--    1 admin    user            40 Jan 16 12:25 licence.txt
drwxr-xr-x    2 admin    user         16384 Dec 18  2013 lost+found
drwxr-xr-x    2 admin    user          4096 Sep  5 07:30 network
drwxr-xr-x    3 admin    user          4096 Sep  5 07:30 pmd
drwxr-xr-x    3 admin    user          4096 Sep  5 07:30 switch
-rw-r--r--    1 admin    user        998306 Jan 16 12:59 swlog
drwxr-xr-x    2 admin    user          4096 Jan 20 15:41 swlog_archive
-rw-r--r--    1 root     root       1187945 Jan 20 16:31 swlog_chassis1
-rw-r--r--    1 admin    user       1280107 Jan 20 15:41 swlog_chassis1.0
-rw-r--r--    1 admin    user       1280105 Jan 20 14:44 swlog_chassis1.1
-rw-r--r--    1 admin    user       1280059 Jan 20 13:24 swlog_chassis1.2
drwxr-xr-x    2 admin    user          4096 Jan 20 13:25 system
-rw-r--r--    1 admin    user       6499328 Jan 20 09:46 tech_support_eng.tar
drwxr-xr-x    2 admin    user          4096 Jan 20 15:47 working

TOR #-> ls -al /mnt/chassis2_CMMA      
drwxr-xr-x   13 admin    user          4096 Jan 20 15:39 .
drwxr-xr-x    7 root     root             0 Jan 20 15:41 ..
-rw-r--r--    1 admin    user          3417 Jan 20 14:59 .bash_history
drwxr-xr-x    2 admin    user          4096 Jan 20 15:41 app-signature
drwxr-xr-x    2 admin    user          4096 Jan 20 15:48 certified
drwxr-xr-x    2 admin    user          4096 Dec 17  2013 diags
drwxr-xr-x    2 admin    user          4096 Jan 20 15:37 foss
-rw-r--r--    1 admin    user           256 Jan 20 15:38 hwinfo
-rw-r--r--    1 admin    user            40 Jan 16 12:28 licence.txt
drwxr-xr-x    3 admin    user         16384 Dec 18  2013 lost+found
drwxr-xr-x    2 admin    user          4096 Sep  5 03:42 network
drwxr-xr-x    3 admin    user          4096 Sep  5 03:42 pmd
drwxr-xr-x    3 admin    user          4096 Jan 16 13:17 switch
-rw-r--r--    1 admin    user        210830 Jan 16 12:59 swlog
-rw-r--r--    1 admin    user       1280003 Jan 16 12:31 swlog.0
drwxr-xr-x    2 admin    user          4096 Jan 20 13:39 swlog_archive
-rw-r--r--    1 root     root        789870 Jan 20 16:31 swlog_chassis2
-rw-r--r--    1 admin    user       1280028 Jan 20 15:39 swlog_chassis2.0
-rw-r--r--    1 admin    user       1280018 Jan 20 14:36 swlog_chassis2.1
-rw-r--r--    1 admin    user       1280040 Jan 20 13:39 swlog_chassis2.2
-rw-r--r--    1 admin    user       1280054 Jan 20 11:45 swlog_chassis2.3
drwxr-xr-x    2 admin    user          4096 Jan 20 15:41 system
-rw-r--r--    1 admin    user       6887936 Jan 20 09:47 tech_support_eng.tar
-rw-r--r--    1 admin    user           437 Jan 16 13:01 vcsetup.cfg.1.err
drwxr-xr-x    2 admin    user          4096 Jan 20 15:47 working
TOR #-> exit

Eignet sich z.B. um mal schnell Logfiles tech-support.eng etc zu kopieren.

Mit ssh geht es auch, ist aber nicht so cool 😉

Datentransfer in einem Alcatel Omniswitch 6900 Virtual Chassis

Will man Dateien von einem Virtual Chassis zu einem anderen transferieren kann man

  • per console und USB Stick Daten kopieren
  • per PC im EMP Netz mit FTP auf die einzelnen Chassis zugreifen.

    • ..

Aber was macht man, wenn man (per Remote) NICHT im EMP Netz ist? Oder die Variante Console+USB Stick nicht praktikabel ist?

Bei Stacks gibt es Kommandos wie „rcp“ oder „rrm“ um Dateien auf anderen Stackmembern zu kopieren/löschen – in einem Virtual Chassis gibt es das nicht.

Rettung naht!

Man kopiert einfach die Daten zwischen den Chassis über den EMP Port per FTP oder SFTP:

FTP/SFTP zum Filetransfer zwischen zwei Chassis innerhalb VC
Man muss entsprechend EMP-Interface angelegt haben, um eindeutig das jeweilige andere Chassis zu erreichen. Aber das ist ja in einem VC sowieso best practice.
Exkurs:
Hat man das vergessen geht es so (vom Master)

ip interface local chassis-id X emp address 192.168.2.2/24

Wobei X für das Chassis steht, dessen interface man ändern will. Derzeit gibt es noch ein Software-Problem, wenn man die Adressen im laufenden Betrieb ändert, als workaround löscht man die Adressen zu erst (bitte dann nicht über die EMP Adresse verbunden sein)

no ip interface local chassis-id 2 emp
ip interface local chassis-id 2 emp address 192.168.2.2/24

Abspeichern nicht vergessen!

write memory flash-synchro

Genug des Exkurses.. wir haben jetzt EMP Adressen.

Nachfolgend verbinden wir uns z.B. per ssh auf dem Chassis 1 (VC-Master) und nutze eine der CHAS2-EMP-Adressen (10.255.255.32 oder 10.255.255.12) zum Zugriff auf Chassis 2.

Lokale Verzeichnisse sind dann im Flash von Chassis 1 und Remote Verzeichnisse im Flash von Chassis 2.
Mit Put wird also von Chassis 1 zu Chassis 2 übertragen, mit Get in die andere Richtung.
VC-Test> show ip interface
Total 10 interfaces
Name IP Address Subnet Mask Status Forward Device
--------------------------------+---------------+---------------+------+-------+--------
EMP-CHAS1 10.255.255.31 255.255.255.0 UP NO EMP
EMP-CHAS2 10.255.255.32 255.255.255.0 UP NO EMP
EMP-CMMA-CHAS1 10.255.255.11 255.255.255.0 UP NO EMP
EMP-CMMA-CHAS2 10.255.255.12 255.255.255.0 UP NO EMP
EMP-VC 10.255.255.1 255.255.255.0 UP NO EMP

FTP-Verbindung

VC-Test> ftp 10.255.255.12
Connected to 10.255.255.12 (10.255.255.12).
220 (vsFTPd 2.0.7)
Name (10.255.255.12:admin): admin
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.

Umschalten zw. Text und binary-Mode (für Image-Transfer ist Binary Mode erforderlich)
ftp> ascii
200 Switching to ASCII mode.
ftp> binary
200 Switching to Binary mode.
Beispiel für Image-Transfer (inklusive Anlegen des Verzeichnisses auf dem Chassis 2):
mput – zur Übertragung mehrerer Files mit Wildcards (*)
ftp> pwd
257 "/flash"

ftp> mkdir NEW-IMG
257 "/flash/NEW-IMG" created

ftp> mput /flash/NEW-IMG/* /flash/NEW-IMG/*
mput /flash/NEW-IMG/Tos.img? y
200 PORT command successful. Consider using PASV.
150 Ok to send data.
226 File receive OK.
155796964 bytes sent in 27.9 secs (5.5e+03 Kbytes/sec)
mput /flash/NEW-IMG/software.lsm? y

ftp> cd NEW-IMG
250 Directory successfully changed.

ftp> ls
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
-rw------- 1 ftp ftp 155796964 Dec 30 14:09 Tos.img
-rw------- 1 ftp ftp 438 Dec 30 14:09 software.lsm
226 Directory send OK.

ftp> bye
221 Goodbye.

SFTP-Verbindung

VC-Test> sftp 10.255.255.12
Connecting to 10.255.255.12...
The authenticity of host '10.255.255.12 (10.255.255.12)' can't be established.
RSA key fingerprint is 5e:c4:3a:37:fa:f6:90:5a:d8:71:98:1c:70:63:24:71.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.255.255.12' (RSA) to the list of known hosts.
Password:
Mögliche Befehle:
sftp> ?
Available commands:
cd path Change remote directory to 'path'
lcd path Change local directory to 'path'
chgrp grp path Change group of file 'path' to 'grp'
chmod mode path Change permissions of file 'path' to 'mode'
chown own path Change owner of file 'path' to 'own'
help Display this help text
get remote-path [local-path] Download file
lls [ls-options [path]] Display local directory listing
ln oldpath newpath Symlink remote file
lmkdir path Create local directory
lpwd Print local working directory
ls [path] Display remote directory listing
lumask umask Set local umask to 'umask'
mkdir path Create remote directory
progress Toggle display of progress meter
put local-path [remote-path] Upload file
pwd Display remote working directory
exit Quit sftp
quit Quit sftp
rename oldpath newpath Rename remote file
rmdir path Remove remote directory
rm path Delete remote file
symlink oldpath newpath Symlink remote file
version Show SFTP version
!command Execute 'command' in local shell
! Escape to local shell
? Synonym for help

Beispiel für Image-Transfer (inklusive Anlegen des Verzeichnisses auf dem Chassis 2):
sftp> mkdir NEW-IMG

sftp> mput /flash/NEW-IMG/* /flash/NEW-IMG
Uploading /flash/NEW-IMG/Tos.img to /flash/NEW-IMG/Tos.img
/flash/NEW-IMG/Tos.img 100% 149MB 5.3MB/s 00:28
Uploading /flash/NEW-IMG/software.lsm to /flash/NEW-IMG/software.lsm
/flash/NEW-IMG/software.lsm 100% 438 0.4KB/s 00:00
sftp>

sftp> bye

Große Teile dieses Posts hab ich schamlos von Silvio geklaut (aber er hat „du darfst“ gesagt)

Alcatel Virtual Chassis – neue Firmware als ISSU

Bisher war ein Software Update in einem Virtuellen Chassis immer mit einer Downtime verbunden.

Man musste die Software einspielen und dann beide Member mit der neuen Version booten.

Da die 6900 doch eine gewisse Zeit zum booten brauchen, gab es einen Ausfall im Minuten Bereich.
Mit den neuen Releases (7.3.1.748 und 7.3.2.374R01) wird nun die Möglichkeit eines ISSU (In-Service Software Upgrade) unterstützt.

Vereinfacht spielt man in einen Virtual-Chassis System die Software ein und stößt das Upgrade an.
Dann wird als erstes der Secondary mit der Software versorgt und damit gebootet. Ist er hochgefahren und bereit übernimmt er die Masterrolle und der vorher aktive bekommt die neue Firmware.
Nachdem auch die Box gebootet hat ist das VC mit der neuen Software bereit, der Ausfall sollte dann minimal sein.

Voraussetzung das neue Image (Tos.img und das passende issu_version file) liegt auf dem Master in einem Verzeichnis z.B. new_firm

Konkret:
Kopieren der Konfig

cp working/vcboot.cfg new_firm
cp working/vcsetup.cfg new_firm

Abspeichern (sicher ist sicher)

write memory flash-synchro

Dann geht es los:

issu from new_firm
Are you sure you want an In Service System Upgrade? (Y/N) : y

Thu Sep 26 14:19:55 : ChassisSupervisor issuMgr info message:
+++ VCISSU: validating images on master. (directory "new_firm")

Thu Sep 26 14:20:16 : ChassisSupervisor issuMgr info message:
+++ VCISSU: images validated.
+++ VCISSU: all slaves copying images...

Thu Sep 26 14:21:02 : ChassisSupervisor issuMgr info message:
+++ VCISSU: slave 1 finished copying images.
+++ VCISSU: all slaves have copied images.
+++ VCISSU: slave 1 is rebooting

Thu Sep 26 14:21:24 : vcmCmm port_mgr info message:
+++ CMM:vcmCMM_client_rx_pm@1412: VFL link 2/0 down (last 2/1/20) [L2]

Thu Sep 26 14:21:24 : ChassisSupervisor bootMgr info message:
+++ bootMgrVCMTopoDataEventHandler: remote chassis 1 no longer in the topology - closing connections

Thu Sep 26 14:21:24 : vcmCmm ipc info message:
+++ CMM:vcmCMM_peer_disconnected@1756: Remote endpoint (chassis 1, slot 65)

Thu Sep 26 14:21:24 : ChassisSupervisor prbDB info message:
+++ fanTray 1,chassis 1 extracted

Thu Sep 26 14:21:24 : ChassisSupervisor issuMgr info message:
+++ VCISSU: slave 1 topology change.  Waiting for shared memory update.

Thu Sep 26 14:21:24 : ChassisSupervisor vcReloadMgr info message:
+++ Remote chassis 1 slot 65 disconnected - status 0

Thu Sep 26 14:21:55 : ChassisSupervisor vcReloadMgr info message:
+++ Reload transaction timeout - canceling

Auf dem Slave sieht man:

Thu Sep 26 14:20:16 : flashManager FlashMgr Main info message:
+++ File vcsetup.cfg differs in /flash/myissu and /flash/new_firm - copying file

Thu Sep 26 14:20:28 : flashManager FlashMgr Main info message:
+++ Image file Tos.img differs - copying file- duplicated 1 times!

Thu Sep 26 14:21:02 : ChassisSupervisor issuMgr alert message:
+++ VCISSU: Slave Chassis rebooting under command from master chassis

Thu Sep 26 14:21:02 : flashManager FlashMgr Main info message:
+++ Verifying image directory new_firm on CMM flash

Thu Sep 26 14:21:02 : ChassisSupervisor issuMgr alert message:
+++ VCISSU: boot manager is reloading from image directory "new_firm".

Thu Sep 26 14:21:24 : ChassisSupervisor reloadMgr info message:
+++ reloadMgrSetupReboot: rebooting primary CMM

Thu Sep 26 14:21:24 : ChassisSupervisor bootMgr info message:
+++ bootMgrRebootCMM: Rebooting CMM
[..]

(none) login: 
Thu Sep 26 14:23:48 : ChassisSupervisor Power Mgr info message:
+++ PS 1 is up

Thu Sep 26 14:23:49 : vcmCmm init info message:
+++ CMM:vcm_mip_eoic_cmm@532: Virtual-chassis mode (chassis 1, protocol 'vcm', max 2) [L0]

Thu Sep 26 14:23:49 : ChassisSupervisor CS Main info message:
+++ Updating chassis ID to 1

Thu Sep 26 14:23:49 : ChassisSupervisor prbDB info message:
+++ PS 1,chassis_id 1 inserted
Alcatel-Lucent OS6900-X40 7.3.2.374.R01 Service Release, August 30, 2013.
Copyright(c), 1994-2013 Alcatel-Lucent. All Rights reserved.


Thu Sep 26 14:23:54 : ipv4 itf info message:
+++ Interface EMP-CHAS1 192.168.252.1/255.255.255.0
chassis mode is
2

Thu Sep 26 14:25:53 : vcmCmm chas_sup info message:
+++ CMM:vcmCMM_cs_handle_chassis_ready@3602: Chassis 1 ready (data 0) [L1]

Thu Sep 26 14:25:56 : vcmCmm port_mgr info message:
+++ CMM:vcmCMM_client_rx_pm@1551: VFL link 1/0 up (pri 1/1/1:0x0) [L2]

Thu Sep 26 14:25:56 : vcmCmm protocol info message:
+++ CMM:vcmCMN_protocol_ready_update_cb@13348: Chassis 1, role Slave, status Running, master 2 [L3]

Thu Sep 26 14:25:57 : vcmCmm ipc info message:
+++ CMM:vcmCMM_peer_connected@1792: Remote endpoint (chassis 2, slot 65) [L4]

Thu Sep 26 14:25:57 : vcmCmm node_sync info message:
+++ CMM:notify_sync_complete@757: Sync complete 'multi node' (peers 1, conn 1, sync 1) [L5]

Thu Sep 26 14:25:59 : healthCmm main warning message:
+++ CPU crossed Above the Threshold Limit!

Thu Sep 26 14:26:10 : ChassisSupervisor prbDB info message:
+++ PS 1,chassis_id 2 inserted

Thu Sep 26 14:26:10 : isis_spb_0 TASK info message:
+++ Base MAC changed to e8:e7:32:0e:65:69

Thu Sep 26 14:26:10 : ChassisSupervisor bootMgr info message:
+++ Sending VC Takeover to NIs and applications [L6]

Thu Sep 26 14:26:10 : ConfigManager CONFD info message:
+++ Slave Configuration Manager waiting for Master sync
+++ Slave Configuration Manager Connecting with Master

Thu Sep 26 14:26:12 : isis_spb_0 TASK info message:
+++ VC Takeover: chassis_id:1

Thu Sep 26 14:26:12 : ipv4 itf info message:
+++ Interface EMP-CHAS1 192.168.252.1/255.255.255.0

Thu Sep 26 14:26:12 : SNMP aluSubagent_thread info message:
+++ snmp_vc_takeover_callback | VC Takeover complete

Thu Sep 26 14:26:12 : appfpCmm main error message:
+++ Master running old version : 

Thu Sep 26 14:26:13 : qosNi Info info message:
+++ VC Takeover in progress.
+++ VC Takeover complete.

Thu Sep 26 14:26:13 : appfpNi main error message:
+++ Master running old version : 

Thu Sep 26 14:26:16 : ChassisSupervisor bootMgr info message:
+++ Received VC Takeover Complete event from all apps [L7]
Chassis Supervision: CMM has reached the ready state [L8]

Thu Sep 26 14:26:18 : ChassisSupervisor reloadMgr info message:
+++ Redundancy time expired - updating next running to new_firm

Thu Sep 26 14:26:50 : vcmCmm port_mgr info message:
+++ CMM:vcmCMM_client_rx_pm@1569: VFL link 1/0 down (last 1/1/20) [L2]

Thu Sep 26 14:26:50 : vcmCmm config info message:
+++ CMM:vcmCMM_check_emp_exec@15094: No EMP query - controlled reset (chassis 2, mac e8:e7:32:0e:66:89)

Thu Sep 26 14:26:50 : ChassisSupervisor bootMgr info message:
+++ bootMgrVCMTopoDataEventHandler: remote chassis 2 no longer in the topology - closing connections

Thu Sep 26 14:26:50 : healthNi main info message:
+++ [hmon_reconnect_to_cmm:156] 

Thu Sep 26 14:26:50 : vcmCmm ipc info message:
+++ CMM:vcmCMM_peer_disconnected@1907: Remote endpoint (chassis 2, slot 65)

Thu Sep 26 14:26:50 : ipni udprelay info message:
+++ UDPRelay disconnected (104)

Thu Sep 26 14:26:50 : ChassisSupervisor prbDB info message:
+++ fanTray 1,chassis 2 extracted

Thu Sep 26 14:26:50 : ChassisSupervisor vcReloadMgr info message:
+++ Remote chassis 2 slot 65 disconnected - status 0

Thu Sep 26 14:26:50 : ChassisSupervisor bootMgr alert message:
+++ Master chassis ID has changed (1/65) - triggering a Virtual Chassis Takeover

Thu Sep 26 14:26:50 : ChassisSupervisor bootMgr info message:
+++ Sending VC Takeover to NIs and applications [L6]
+++ bootMgrSendSecondaryMasterChanged: entry

Thu Sep 26 14:26:55 : ChassisSupervisor bootMgr info message:
+++ Received VC Takeover Complete event from all apps [L7]
Chassis Supervision: CMM has reached the ready state [L8]

Thu Sep 26 14:26:57 : ChassisSupervisor reloadMgr info message:
+++ Redundancy time expired - updating next running to new_firm

Thu Sep 26 14:26:59 : healthCmm main warning message:
+++ CPU crossed Below the Threshold Limit!

Der Slave hat also mit der neuen Firmware geboote.

Es ist dann Master geworden und hat das Management übernommen, damit der vorherige Master das Update machen kann

Die Ausgabe auf dem (Ex)Master dabei:

Thu Sep 26 14:25:56 : vcmCmm port_mgr info message:
+++ CMM:vcmCMM_client_rx_pm@1394: VFL link 2/0 up (pri 2/1/1:0x20000) [L2]

Thu Sep 26 14:25:57 : vcmCmm ipc info message:
+++ CMM:vcmCMM_peer_connected@1634: Remote endpoint (chassis 1, slot 65) [L4]

Thu Sep 26 14:25:57 : vcmCmm port_lib error message:
+++ CMM:vcmCMM_process_config_sync_msg@4010: Get port info (vfl 0, ifidx 40000257, ret -3)

Thu Sep 26 14:26:10 : ChassisSupervisor prbDB info message:
+++ PS 1,chassis_id 1 inserted

Thu Sep 26 14:26:10 : ChassisSupervisor issuMgr info message:
+++ VCISSU: slave 1 updated shared memory. Waiting for slave vc takeover events.

Thu Sep 26 14:26:15 : ChassisSupervisor prbDB info message:
+++ PS 1,chassis_id 1 inserted
For Chassis 1 slot 1 flag is 1 :haVlanHandleCsNIUp

Thu Sep 26 14:26:16 : evbCmm main error message:
+++ plGetUportRangeFromChassisSlot failed: 1/2, rv=-30

Thu Sep 26 14:26:16 : rmon main error message:
+++ plGetUportRangeFromChassisSlot chass: 1 slot: 2 ret: -30

Thu Sep 26 14:26:16 : evbCmm main error message:
+++ plGetUportRangeFromChassisSlot failed: 1/3, rv=-30

Thu Sep 26 14:26:16 : rmon main error message:
+++ plGetUportRangeFromChassisSlot chass: 1 slot: 3 ret: -30

Thu Sep 26 14:26:16 : ChassisSupervisor issuMgr info message:
+++ VCISSU: slave 1 finished vc takeover events.  Waiting for vc ready acknowledgement.

Thu Sep 26 14:26:20 : ChassisSupervisor prbDB info message:
+++ PS 1,chassis_id 1 inserted

Thu Sep 26 14:26:25 : ChassisSupervisor prbDB info message:
+++ PS 1,chassis_id 1 inserted

Thu Sep 26 14:26:30 : ChassisSupervisor prbDB info message:
+++ PS 1,chassis_id 1 inserted

Thu Sep 26 14:26:35 : ChassisSupervisor prbDB info message:
+++ PS 1,chassis_id 1 inserted

Thu Sep 26 14:26:46 : ChassisSupervisor issuMgr info message:
+++ VCISSU: slave 1 acknowledged vc ready. VCISSU complete for this slave.

Thu Sep 26 14:26:46 : ChassisSupervisor issuMgr alert message:
+++ VCISSU: Master Chassis rebooting at end of VCISSU procedure

Thu Sep 26 14:26:46 : flashManager FlashMgr Main info message:
+++ Verifying image directory new_firm on CMM flash

Thu Sep 26 14:26:46 : ChassisSupervisor issuMgr alert message:
+++ VCISSU: boot manager is reloading from image directory "new_firm".

Thu Sep 26 14:26:49 : ChassisSupervisor reloadMgr info message:
+++ reloadMgrSetupReboot: rebooting primary CMM

Thu Sep 26 14:26:49 : ChassisSupervisor bootMgr info message:
+++ bootMgrRebootCMM: Rebooting CMM

Thu Sep 26 14:26:49 : MIP_GATEWAY mipgwd info message:
+++ msgRouter: Client unavailable, dropping response msg=MIP_SETF_RSP(15) msg_id(55509069) (APPID_CHASSISUPER(64/0) -> APPID_CLI(67
Disabling ports
All ports disabled

Thu Sep 26 14:26:49 : ChassisSupervisor bootMgr alert message:
+++ _bootMgrRebootCMM: rebooting system

Thu Sep 26 14:26:50 2013 :: Local Flash Sync complete - fail watchdog is 0
Thu Sep 26 14:26:50 2013 :: Unmounting flash


[..]

Nachdem das durch ist haben beide Maschinen die neue Firmware. (Hier ein Update von 7.3.1.748 auf 7.3.2.374)