Schlagwort: Alcatel

Alcatel Verbinden auf Secondary im Stack

Es kommt schonmal vor, dass man im Stack auch etwas auf der Secondary cmm/Stack-Member machen will.

z.B. schauen wieviel frei ist, bzw. die swlogs anschauen.

SW-Rack > telnet 127.2.2.1
Trying 127.2.2.1...
Connected to 127.2.2.1.
Escape character is '^]'.
login : admin
password :

Welcome to the Alcatel-Lucent OmniSwitch 6450
Software Version 6.6.4.244.R01 Service Release, May 09, 2014.

Copyright(c), 1994-2013 Alcatel-Lucent. All Rights reserved.

OmniSwitch(TM) is a trademark of Alcatel-Lucent registered
in the United States Patent and Trademark Office.

SW-Rack > show running-directory

CONFIGURATION STATUS
Running CMM : PRIMARY,
CMM Mode : DUAL CMMs,
Current CMM Slot : 2,
Running configuration : WORKING,
Certify/Restore Status : CERTIFIED
SYNCHRONIZATION STATUS
Flash Between CMMs : SYNCHRONIZED,
Running Configuration : NOT SYNCHRONIZED,
Stacks Reload On Takeover: ALL NIs (CMM Only Config OUT-OF-SYNC)

SW-Rack >

Auch das swlog kann man sich dann hier einfach anzeigen lassen.

Versucht man das mit den idle units (telnet 127.2.X.1 x= Slotnummer) landet man in der dShell dieser Slots und da will man nicht wirklich hin, wenn man nicht weiß was man tut.

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)

Aruba Alcatel WLAN Controller Passwort resetten

Hat man das Kennwort (für admin oder enable) seines WLAN Controllers vergessen gibt es eine Lösung:
Admin Passwort :

Einloggen auf der Konsole (Remote nicht möglich, man braucht glücklicherweise physikalischen Zugang)

  • “password” als Benutzername und “forgetme!” als Passwort
  • “enable” aufrufen, password ist “enable”
  • “conf t” eingeben (globaler Konfigurationsmodus analog Cisco)
  • “mgmt-user admin root” eingeben, um das Admin Passwort zurückzusetzen

Mit dieser Prozedur wurde gleichzeitig das enable-Passwort auf “enable” zurückgesetzt Daher im Anschluß unbedingt als Admin anmelden und folgende Schritte durchführen, um ein sicheres Enable Passwort zu vergeben:

  • als Admin anmelden
  • “enable” aufrufen, password ist “enable”
  • “conf t” eingeben
  • “enable secret” eingeben, es folgt ein Dialog, in dem ein neues Passwort vergeben werden kann
  • Abschließend “write memory” nicht vergessen !

Beispiel

User: password
Password: forgetme!
(aruba) >enable
Password: enable
(aruba) #configure terminal
Enter Configuration commands, one per line. End with CNTL/Z
(aruba) (config) #mgmt-user admin root
Password:
Re-Type password:
(aruba) (config) #exit
(aruba) #exit
(aruba) >exit

User: admin
Password:
(aruba) >enable
Password: enable
(aruba) #configure terminal
Enter Configuration commands, one per line. End with CNTL/Z
(aruba) (config) #enable secret
Password:
Re-Type password:
(aruba) (config) #write memory

Aruba Alcatel WLAN Controller Passwörter sichtbar machen

Immer wieder kommt man in die Zwickmühle, dass man das, vor Jahren eingerichtete, Kennwort für eine VPN Verbindung oder einen Radiusserver an einem WLAN Controller vergessen hat.

Ist das im kleinen Rahmen nicht so schlimm, mag es in großen Installationen eine Änderung doch viel Aufwand machen.

Zumindestens für PSKs (WPA/Radius/LDAP/IPSEC) gibt es eine Lösung:

SSH zum Controller:


Show run
[..]
aaa authentication-server radius "10.10.10.10"
host "10.10.10.10"
key 58cb239c04c10d531bc452398ce84670
nas-identifier "9999"

jetzt kann man die encryption abschalten:

encryption disable

Danach sieht das ganze anders aus:

aaa authentication-server radius "10.10.10.10"
host "10.10.10.10"
key "switch"
nas-identifier "9999"
!

Kennwörter von Usern sind weiterhin verschlüsselt/gehasht.

mit
encryption enable
schaltet man die Encryption wieder an.

Alcatel Routed Port

Bei vielen Cisco Switchen kann man einen Port als Routed Port machen.

Die Konfiguration ist dann

Interface FastEthernet0/1
no switchport
ip address 192.168.10.1 255.255.255.0

Der Vorteil in einem solchen Routed Port ist, das es keine L2 Protokolle wie z.B. Spanning Tree o.ä. gibt die einem dazwischen funken können.

Seit einem Maintanance Release der 6.4.4 gibt es das ganze auch bei Alcatel 6400/6850/6850E und 9000E Switchen.

Die Konfiguration ist dann:

ip interface RTR1 address 192.168.1.2/24 rtr-port 1/1 rtr-vlan 3

Soll der Port getaggt sein geht das auch:

ip interface "RTR1" address 192.168.2.1 mask 255.255.255.0 rtr-port 1/2 rtr-vlan 4 type tagged

Zur Kontrolle:

show vlan
Vlan type: std => Standard Vlan
Vlan type: rtr => Router Vlan, reserved for rtr-port IP Interface
                              stree                       mble   src        
 vlan  type  admin   oper   1x1   flat   auth   ip   ipx   tag   lrn   name 
-----+------+------+------+------+------+----+-----+-----+-----+-----+---------------------
   1    std   on     on     on    on     off   off   NA   off     on   VLAN 1                          
   2    std   on    off     on    on     off   off   NA   off     on   VLAN 2                          
   3    rtr   on    off    off   off     off    on   NA   off     on   Router VLAN: 3                  
   4    rtr   on    off    off   off     off    on   NA   off     on   Router VLAN: 4                  
  10    std   on     on     on    on     off   off   NA   off     on   vlan10

bzw:


-> show ip interface 
Total 3 interfaces
        Name            IP Address     Subnet Mask   Status Forward  Device
--------------------+---------------+---------------+------+-------+----------------------------------------------------
Loopback             127.0.0.1       255.0.0.0           UP      NO Loopback
RTR1                 192.168.2.1     255.255.255.0     DOWN      NO Rtr-Port 1/2 vlan 3 UNTAGGED
RTR2                 192.168.10.2    255.255.255.0     DOWN      NO Rtr-Port 1/1 vlan 4 TAGGED

Auf einem 6450/6250 geht das imho noch nicht ebenso wenig wie auf einem 6900 und OS10k.

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)