Kategorie: Allgemein

Weihnachtsrätsel bei der Netzwerft – Kiva Card gewonnen

Das Weihnachtsrätsel der Netzwerft konnte ich ja nicht an mir vorbei gehen lassen.
Den Fehler in einem Netzwerk suchen.

Super!

Tatsächlich bin ich dann auf den fehlenden Link zwischen den „Outside“ Switchen der unteren ASA gestossen, was im Failover Fall dazu führen kann das die aktive ASA nicht an den aktiven Router kommt.

Erfreulicherweise war nicht nur die Antwort richtig, sondern ich gehörte auch zu den ausgelosten Gewinnern!

Zwischen ESET Lizenz und Kiva Card hab ich mich dann für ein $25 Mikrokredit-Guthaben bei Kiva entschieden, da ich das doch wirklich für eine schöne Idee halte.

Noch ein bisschen eigenes Geld eingezahlt und einen bunten Strauss von Projekten unterstützt. Bin gespannt was dann dabei rauskommt, ein gutes Gefühl macht es zumindest.

Mein Dank geht an Karsten und die Netzwerft, tolles Geschenk!

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 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)

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