Fortigate: Firewall debuggen und sessions löschen

diag debug flow show console enable
diag debug flow filter addr 
diag debug enable
diag debug flow trace start 100

o.g. zeigt die nächsten 100 Flows wo die Adresse beteiligt ist.

den Filter kann man natürlich auch auf andere Sachen anwenden:

diagnose debug flow filter 
addr      IP address.
clear     Clear filter.
daddr     Destination IP address.
dport     Destination port.
negate    Inverse filter.
port      port
proto     Protocol number.
saddr     Source IP address.
sport     Source port.
vd        Index of virtual domain.

Achtung: Sessions werden gecacht, wenn man also den Aufbau sehen will muss man uU die bestehenden Sessions löschen, auch hier kann man per filter nur bestimmte löschen, statt alle Sessions wegzuschmeissen:
http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&externalId=FD31635

diagnose sys session filter ?
clear      clear session filter
dport      dest port
dst         dest ip address
negate    inverse filter
policy     policy id
proto      protocol number
sport      source port
src         source ip address
vd          index of virtual domain. -1 matches all

z.B.:

diagnose sys session filter src 10.160.0.1  10.160.0.10
diagnose sys session filter dport 80  888
diagnose sys session filter  session filter:
        vd: any
        proto: any
        source ip: 10.160.0.1-10.160.0.10
        dest ip: any
        source port: any
        dest port: 80-888
        policy id: any
        expire: any
        duration: any

mit

diagnose sys session list

sieht man die sessions, die den Filter matchen mit

diagnose sys session clear

löscht man die gematchten Sessions.

ACHTUNG: ohne einen Filter schmeisst ein clear ALLE sessions der FGT weg.

Fortigate: Debug eines bestimmten VPN Tunnels

Wenn man eine gut bestückte Fortigate hat muss man hin und wieder auch mal Fehler suchen.
Z.B. warum kommt ein VPN Tunnel nicht hoch.

Der „einfache“ Weg
diag debug enable
diag debug console
diag debug ike -1

gibt natürlich Daten über alle VPN Verbindungen, was schnell unübersichtlich wird.

Man kann das ganze aber auch beschränken um z.B. nur Daten für eine Gegenstelle oder eine Phase2 zu sehen:

Zur Auswahl stehen:
diag vpn ike log-filter
clear Erase the current filter.
dst-addr4 IPv4 destination address range to filter by.
dst-addr6 IPv6 destination address range to filter by.
dst-port Destination port range to filter by.
interface Interface that IKE connection is negotiated over.
list Display the current filter.
name Phase1 name to filter by.
negate Negate the specified filter parameter.
src-addr4 IPv4 source address range to filter by.
src-addr6 IPv6 source address range to filter by.
src-port Source port range to filter by.
vd Index of virtual domain. -1 matches all.

z.B.

diag vpn ike log-filter dst-addr4 10.10.10.10
diag debug enable
diag debug console
diag debug app ike -1

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)

Alcatel stack recovery time minimieren

Wenn in einem Stack der Primary ausfällt übernimmt der bisherige Secondary die Managementaufgaben (wird primary) und ein neuer Secondary wird gewählt.

Im Zuge des wechsels ändern sich auch die MAC-Adressen des Stacks (es wird die des Secondarys übernommen).
Damit passiert folgendes:

  • Die Spanning-tree BridgeID ändert sich (ist ja Priority + Mac-Adresse) – Dadurch uU STP Rekalkulationen
  • LACPs brechen zusammen (das ist an die MAC-Adresse gebunden)
  • Vermutlich ändern sich auch die Mac-Adressen der IP Interfaces (vielleicht hat das Default-Gateway danach eine andere Mac als vorher?!)
  • Dadurch kann es auch bei Routingprotokollen zu Problemen kommen
  • Kunden rufen mit Pipi in den Augen an.
  • Terror und Panik bricht aus, Netzwerktechniker werden auf der Straße gelyncht.

Da ja grade die letzten 2 Punkte kritisch sind (und man die ersten Punkte auch erlegen will):

Bei Alcatel heißt das notwendige Kommando

mac-retention status enable

Dadurch bleibt die Mac-Adresse des Stacks bestehen und im besten Fall passiert (fast) garnichts.
Daher: Man sollte das Kommando auf Stacks immer aktivieren (per default ist es disabled).
Sieht dann so aus:

Stack > show mac-retention status 
Admin State         : Enabled,
Trap admin state    : Disabled,
EEPROM MAC address  : e8:e7:32:69:2e:9c,
Current MAC address : e8:e7:32:69:2c:fc,
MAC address source  : Retained,
Topology Status     : Ring Present

Die EEPROM MAC (des Switches) ist e8:e7:32:69:2e:9c, der Stack hat aber eine andere von früher. (Source = Retained)

Aber alles hat natürlich auch einen Nachteil:
Nimmt man den (ex)Primary raus und baut ihn woanders ein hat man doppelte MAC-Adressen (der ex-Primary und der Stack haben die gleiche) und man hat neue Probleme. wie z.B. verlorenen Traffic.

In einem solchen Fall: Im Wartungsfenster nach Rücksprache auf dem Stack mit „mac-retention release“ die gemerkte MAC freigeben und die des aktuellen Switches übernehmen.

STP/LACP Sachen werden dann auch auftreten, aber in einem geplanten Umfeld.

Laut einem Test eines Users im Alcatelunleashed Forum vermindert sich dadurch die Rekonvergenzzeit (unklar was er genau getestet wurde) von 3 Minuten auf 1 Sekunde.. egal: klingt gut.

Im 6900-VC ist die mac-retention (im Gegensatz zu den R6 Switchen) defaultmäßig enabled.

Bei Cisco gibt es das gleiche (Problem wie Lösung), das Kommando heißt hier

stack-mac persistent timer 0

und zum freigeben

no stack-mac persistent timer

Bei Cisco wichtig: ohne „stack-mac persistent timer 0“ kann man eine ASA-X nicht sauber an zwei Stack-Membern anschliessen, da nach einem fail des primarys die Verbindung (dauerhaft?) gestört wäre

Alcatel-Lucent OS6900 Virtual Chassis aktivieren

Mit dem neuen Firmware Release 7.3.1.632 kann man jetzt 2* 6900er oder 2* OS10k stacken.
Das ganze nennt sich dann Virtual Chassis und funktioniert (erstmal) nur für 2 Chassis.

Im Vergleich zu MC-LAG sollte das eine deutlich einfachere Konfiguration mit sich bringen, da man nur noch ein logisches Gerät hat und z.B. einen LACP agg nur noch da konfiguriert (statt vorher auf beiden Geräten identisch).

Vergleichbar also mit Cisco VSS bei den 6500 (und bald 4500).

Was ist notwendig?
1. eine Advanced Licence (zum testen kann man auch die 5 Tage Lizenz mittels

debug demo-license

einspielen.
Ein paar Zeilen Konfiguration.

Sinnvollerweise macht man sich ein Testverzeichnis und macht die Experimente da drinnen.

mkdir v_chassis
cp /working/* v_chassis

Man braucht natürlich das richtige AOS in dem Verzeichnis (7.3.1.632) und startet dann den Switch mit der 7.3.1.632
reload from v_chassis no rollback-timeout

Auf dem 1.Chassis gibt man als Chassis-ID die eins, auf dem zweiten die 2.
Plant man mehrere solcher Konstrukte sollte man unterschiedliche Gruppen wählen, damit die Split Brain Detection funktioniert (muss man ja bei MC-LAG auch)

Sinnvollerweise vergibt man auch gleich EMP Adressen – darüber wird später eine Split-Brain Detection gemacht, falls der VF-Link mal weg ist. Die Chassis müssen sich also über das EMP Interface gegenseitig erreichen können, eine 1:1 Direktverbindung ist aber nicht sinnvoll/machbar (zumindest nicht wenn man man mehr CMMs z.B. OS10k) verbinden muß.

1.Chassis

virtual-chassis configured-chassis-id 1
virtual-chassis vf-link 0 create
virtual-chassis vf-link 0 member-port 1/1
virtual-chassis chassis-group 2
ip interface emp address 192.168.252.1/24
write memory
convert-configuration to v_chassis

2.Chassis

virtual-chassis configured-chassis-id 2
virtual-chassis chassis-group 2
virtual-chassis vf-link 0 create
virtual-chassis vf-link 0 member-port 1/1
ip interface emp address 192.168.252.2/24
write memory
convert-configuration to v_chassis

Danach startet man beide Chassis mit der neu erstellten Virtual Chassis Konfiguration (siehe vcboot.cfg/vcsetup.cfg im v_chassis Ordner)

Auf beiden Chassis:

reload from v_chassis no rollback-timeout

Nach dem booten sieht man auf dem primären (Master) das andere Chassis Ports des anderen Gerätes und kann wie in einem gewöhnlichen Stack damit hantieren.

 show virtual-chassis topology 
Local Chassis: 1
                                        Config 
 Chas  Role         Status              Chas ID  Pri   Group  MAC-Address      
-----+------------+-------------------+--------+-----+------+------------------
 1     Master       Running             1        100   2      e8:e7:32:XX:XX:69
 2     Slave        Running             2        100   2      e8:e7:32:XX:XX:89

 show chassis 
Local Chassis ID 1 (Master)
  Model Name:                    OS6900-X40,
  Module Type:                   0x5062202,
  Description:                   Chassis,
  Part Number:                   902910-90,
  Hardware Revision:             B08,
  Serial Number:                 M366XXXX,
  Manufacture Date:              Sep 11 2011,
  Admin Status:                  POWER ON,
  Operational Status:            UP,
  Number Of Resets:              29,
  MAC Address:                   e8:e7:32:XX:XX:69

Remote Chassis ID 2 (Slave)
  Model Name:                    OS6900-X40,
  Module Type:                   0x5062202,
  Description:                   Chassis,
  Part Number:                   902910-90,
  Hardware Revision:             B08,
  Serial Number:                 M366XXXX,
  Manufacture Date:              Sep 11 2011,
  Admin Status:                  POWER ON,
  Operational Status:            UP,
  Number Of Resets:              42,
  MAC Address:                   e8:e7:32:XX:XX:89


->show interfaces status 
 Chas/                   DETECTED-VALUES         CONFIGURED-VALUES    
 Slot/    Admin  Auto  Speed   Duplex  Pause   Speed   Duplex  Pause  Link
 Port     Status Nego  (Mbps)                  (Mbps)                 Trap
---------+------+----+--------+------+-------+--------+------+-------+-----
  1/1/1      en   dis   10000   Full     -     10000    Full     -     dis
  1/1/2      en   dis     -      -       -     10000    Full     -     dis
  1/1/3      en   dis     -      -       -     10000    Full     -     dis
 [.. snip ..]
 1/1/40     en   dis     -      -       -     10000    Full     -     dis
  2/1/1      en   dis   10000   Full     -     10000    Full     -     dis
  2/1/2      en   dis     -      -       -     10000    Full     -     dis
 [.. snip ..] 
 2/1/40     en   dis     -      -       -     10000    Full     -     dis

Will man LACPs anlegen geht das „wie immer“:

linkagg lacp agg 1 size 2 admin-state enable name "To_DC" actor admin-key 1 
linkagg lacp agg 2 size 2 admin-state enable name "To_RZ" actor admin-key 2
linkagg lacp port 1/1/31 actor admin-key 1
linkagg lacp port 2/1/31 actor admin-key 1
linkagg lacp port 2/1/39 actor admin-key 2
linkagg lacp port 1/1/39 actor admin-key 2

->show linkagg port 

Chassis/Slot/Port  Aggregate   SNMP Id   Status    Agg  Oper   Link Prim
-------------------+----------+--------+----------+----+-----+-----+----
         1/1/31     Dynamic      1031   ATTACHED      1  UP   UP    YES
         1/1/39     Dynamic      1039   ATTACHED      2  UP   UP    NO 
         2/1/31     Dynamic    101031   ATTACHED      1  UP   UP    NO 
         2/1/39     Dynamic    101039   ATTACHED      2  UP   UP    YES

Alcatel Command-log aktivieren

Manchmal ist es recht spannend zu wissen, wer, wann was für Befehle eingegeben hat.

Bei Cisco gibt es dafür archive log, bei Alcatel heißt das ganze command-log.
Da man hin und wieder das auch am Syslog Server haben möchte kann man auch ein remote command-log aktivieren.

die notwendigen Befehle dafür sind:

swlog output socket 192.168.1.70 remote command-log
swlog remote command-log enable
swlog console level info
command-log enable

anschauen kann man das command-log mit:

show command-log

Command : command-log enable
  UserName : admin
  Date     : THU DEC 20 13:38:49 
  Ip Addr  : 192.168.1.11
  Result   : SUCCESS

Das beim Syslog die IP Adresse nicht mitgesendet wird ist ein bekannter Bug, der in einer der nächsten Maintanance Releases behoben wird.