Cisco ASA Active Standby Failover konfigurieren

Situation ist folgende: man hat zwei Cisco ASA und möchte diese für die Ausfallsicherheit als Active/Standby Cluster konfigurieren.
Hier ist eine Möglichkeit,

Der einfachste Weg ist sicher der das ASDM zu nutzen, dafür sind ein paar vorarbeiten sinnvoll:
Per Konsole anhängen, im „initial configuration mode“ auf beiden ASAs je eine IP Adresse für das interne Interface definieren z.B. 192.168.1.1 und 192.168.1.2, asdm mittels
http server enable
http 192.168.1.0 255.255.255.0 inside

freischalten.
Dann verbindet man die ASAs mittels failover links z.B. jeweils gig 0/3
Im ASDM unter Wizards nutzt man den High Availability Wizard.
als Peer IP die Adresse der zweiten ASA: 192.168.1.2 ggf. muss man im Java Dialog dem SSL Zertifikat der zweiten ASA trauen, und schon sollte es gehen.
Als failover Link Interface nimmt man das verbundene (gig 0/3) und denkt sich dafür zwei Ips aus (192.168.133.1 und als Standby IP 192.168.133.2).

Gut zu Wissen: Die jeweils aktive Unit hat immer die Active IP, die andere immer die Standby IP.

Man gibt ein gutes (langes) Password an, das den failover link verschlüsselt und schon sollte man fertig sein.

Um die anderen Interfaces auch mit in den Failover zu nehmen muß man ihnen eine Standby IP geben:
Configuration ->Device Management -> High Availability -> Failover -> Interfaces und da bei den angelegten Interfaces die Standby Ip angeben.
Logischerweise müßen diese natürlich dann im gleichen Netz liegen – physikalisch müßen die Interface von beiden ASAs im gleichen VLAN/im Selben Netz liegen.
Das geht mit VLAN Interface ebenso.

ASDM startet nicht mit java.lang.NullPointerException Vista Business 32 Bit

Die neuen ASDMs in dem Fall 6.1.5(51) wollte unter Vista Business 32Bit bei mir nicht starten:

Java.lang.NullPointerException
at sun.swing.table.DefaultTableCellHeaderRenderer.getColumnSortOrder(Unknown Source)
at com.sun.java.swing.plaf.windows.WindowsTableHeaderUI$XPDefaultRenderer.getTableCellRendererComponent(Unknown Source)
at wb.getTableCellRendererComponent(DashoA10*..:757)
at v1.b(DashoA10*..:216)
at vz.createDefaultColumnsFromModel(DashoA10*..:1497)
at javax.swing.JTable.tableChanged(Unknown Source)
at vz.tableChanged(DashoA10*..:1389)
at javax.swing.table.AbstractTableModel.fireTableChanged(Unknown Source)
at javax.swing.table.AbstractTableModel.fireTableStructureChanged(Unknown Source)
at v6.a(DashoA10*..:197)
at vz.setModel(DashoA10*..:237)
at vy.aj(DashoA10*..:93)
at vy.a(DashoA10*..:88)
at vy.(DashoA10*..:65)
at va.(DashoA10*..:33)
at u8.(DashoA10*..:35)
at ng.a(DashoA10*..:79)
at nc.b(DashoA10*..:360)
at nc.(DashoA10*..:272)
at com.cisco.pdm.PDMApplet.start(DashoA10*..:159)
at com.cisco.nm.dice.loader.r.run(DashoA19*..:410)
java.lang.NullPointerException
at sun.swing.table.DefaultTableCellHeaderRenderer.getColumnSortOrder(Unknown Source)
at com.sun.java.swing.plaf.windows.WindowsTableHeaderUI$XPDefaultRenderer.getTableCellRendererComponent(Unknown Source)
at v1.b(DashoA10*..:216)
at vz.createDefaultColumnsFromModel(DashoA10*..:1497)
at javax.swing.JTable.tableChanged(Unknown Source)
at vz.tableChanged(DashoA10*..:1389)
at javax.swing.JTable.setModel(Unknown Source)
at vz.setModel(DashoA10*..:235)
at y2.d(DashoA10*..:138)
at y2.(DashoA10*..:72)
at va.(DashoA10*..:37)
at u8.(DashoA10*..:35)
at ng.a(DashoA10*..:79)
at nc.b(DashoA10*..:360)
at nc.(DashoA10*..:272)
at com.cisco.pdm.PDMApplet.start(DashoA10*..:159)
at com.cisco.nm.dice.loader.r.run(DashoA19*..:410)
Exception in Starting Main window
Exception in thread "SGZ Loader: launchSgzApplet" java.lang.NullPointerException
at com.cisco.pdm.PDMApplet.start(DashoA10*..:165)
at com.cisco.nm.dice.loader.r.run(DashoA19*..:410)

Die Lösung war Java 1.6.11 zu entfernen und 1.6.7 zu nutzen, damit funktioniert alles wie es soll.. Solche Software liebt man!

Update: Es geht auch mit der Version 1.6.13 nicht, dafür funktioniert es zumindest mit letzterer Java Version problemlos unter Windows XP Pro. Soviel also zu „Java ist plattformunabhängig“

Update2:
Bei Cisco wird der Bug als CSCsw43498 geführt und ist in der Interimsversion asdm 6.1.57 behoben.
als Workaround beschreibt Cisco:
1. Right-click on the Cisco ASDM Launcher shortcut.
2. Select "Property"
3. Click on "Compatibility"
4. Click on the box "Disable Visual Theme"
5. Restart ASDM

IOS Update C3750

Software von Cisco laden, und auf einem Rechner per tftp verfügbar machen (ich empfehle den 3CDaemon)
switch#archive download-sw /overwrite /allow-feature-upgrade tftp://10.10.10.2
Danach muß man eine ganze Weile warten bis firmware und ggf die images etc für das SDM entpackt hat (ca 15 Minuten), teilweise bleibt der prompt 5-10 Minuten stehen.. einfach warten.

Danach neu booten und fertig.

Cisco Catalyst 3750 Passwort Recovery

Ganz einfach:
Konsolen Kabel anschliessen
Mode Knopf gedrückt halten dann Strom anstecken, nach 15 Sekunden leuchtet die Sys LED, dann loslassen.
Am Switch-Prompt: geben wir erst flash_init, dann load_helper an. mittels rename fllash:config.text flash:config.old benennen wir die Konfiguration um, danach können wir mit boot neu starten.
in den Enable Mode wechseln und dann die config renamen und neu einbinden
rename flash:config.old flash:config.text
copy flash:config.text system:running-config

Danach wie immer den usernamen/passwort ändern, man ist ja noch im enable mode..

unrar unter debian

Das freie Debian unrar (unrar-free) ist leider nicht wirklich fähig geteilte rar-Archive zu entpacken. dafür nimmt man am besten das Paket unrar aus dem non free repository.

in /etc/apt/sources.list fügt man contrib und non-free ein:
deb http://ftp2.de.debian.org/debian/ lenny main contrib non-free
deb-src http://ftp2.de.debian.org/debian/ lenny main contrib non-free
deb http://security.debian.org/ lenny/updates main contrib non-free
deb-src http://security.debian.org/ lenny/updates main contrib non-free

dann
aptitude update
aptitude install unrar
unrar e meinarchiv.rar

und alles ist toll.

Kernel Panic – Fallback mit Lilo und im System

Wer kennt das nicht: Man will einen neuen Kernel nutzen, hat aber Angst, dass man seinen Server, der im Rechenzentrum in Frankfurt steht, abschiesst.

Beim bootloader lilo kann man sich eine Hintertür aufhalten:

/etc/lilo.conf
..
default=Linux
image=/boot/vmlinuz-2.6.18-6-686-bigmem
label=Linux
initrd=/boot/initrd.img-2.6.18-6-686-bigmem
image=/boot/vmlinuz-2.6.26-1-686-bigmem
label=Linux-new
initrd=/boot/initrd.img-2.6.26-1-686-bigmem
append ="panic=30"

Einfach den Parameter „append =“panic=30“ anfügen. Das gibt dem Kernel einen Paramter mit der aussagt: im Falle einer Kernel Panic nach 30 Sekunden neustarten.

lilo konfigurieren:
/sbin/lilo -v

Noch haben wir nichts gewonnen, sagen aber lilo nun das er im folgenden einmal den neuen Kernel booten soll:
/sbin/lilo -R Linux-new
Linux-new korrespondiert mit dem label in der lilo.conf

Nach einem Reboot das große Bangen: bootet die Kiste mit neuem Kernel?

Falls ja: einfach die Labels in der lilo.conf ändern und mittels /sbin/lilo -v schreiben lassen.

Generell kann es praktisch sein den Server im Falle einer Kernel Panic neustarten zu lassen.
Das sollte über so funktionieren:

in /etc/sysctl.conf trägt man ein
kernel.panic=30

und lädt den Parameter mittels
/sbin/sysctl -p
(oder startet den Server neu)