Kategorie: Erfahrungen

Alcatel OAW – RAPs eine neue Firmware geben

RAPs wie die Remote Access Points von Alcatel/Aruba heißen sind ne feine Sache.
Leider kommt nicht jeder RAP mit einer aktuellen Firmware, was bedeutet, dass solche features wie PPPoE oder UMTS Unterstützung uU nicht in der Firmware zum Zero Conf zur Verfügung stehen.

Auf einen aktuellen Firmwarestand kommen sie nach dem provisionieren – Sind sie mit dem Controller verbunden, bekommen sie das AOS vom Controller.L
eider wird nach einem reset wieder ein altes AOS geladen.

Um auch nach einem Reset das aktuelle AOS benutzen zu können muss man die backup-partition der RAPs flashen, das geht mittels des Befehls
(OAW-4504) #apflash ip-addr 192.168.234.20 backup-partition

Mit show ap image version sieht man die vorhandene Version und auch ob das upgrade noch andauert:

(OAW-4504) #show ap image version
AP Image Versions On Controller
-------------------------------
AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010
Access Points Image Version
---------------------------
[snip]
192.168.234.20 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 3.3.2.11-rn-3.0.1(p4build@trinidad.arubanetworks.com)#21263 Wed May 6 22:30:18 PDT 2009 Yes 1 0 0 0 In Progress (3 secs)

Nach dem Upgrade steht statt In Progress dann Completed und der RAP bootet die neue Version.

192.168.234.20 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 3.3.2.11-rn-3.0.1(p4build@trinidad.arubanetworks.com)#21263 Wed May 6 22:30:18 PDT 2009 Yes 1 0 0 0 Completed (65 secs)

Diese wird auch in der backup-partition angezeigt:
192.168.234.10 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 AOS-W version 5.0.3.0 for OAW-AP6x_7x (p4build@cyprus) (gcc version 3.4.3) #26207 Tue Nov 30 09:13:58 PST 2010 Yes 3 0 0 0 Done

Fortigate: Zwei WAN Schnittstellen/ISPs nutzen, einen default Weg haben

Möchte man bei einer Fortigate zweit WAN Zugänge oder ISPs anschliessen, z.B. für Backup oder Lastverteilung kommt man zu dem Punkt: Wie geht das?

Szenario:
Einen Provider am WAN1 (schnelle Leitung)
zweiten Provider am WAN2 (langsamere Verbindung)

Wie kann man vorgehen?
Legt man zwei default Routen mit unterschiedlichen Metriken an ist nur die mit der besseren Metrik in der Routingtabelle, d.h. es wird nur die bessere Route genutzt, Verbindungen über die andere Leitung schlägt fehl (RPF wird das wohl verhindern).

Also trägt man zwei default Routen mit gleicher Metrik an!
Jetzt macht die Fortigate standardmäßig ECMP – also Lastverteilung. Beide Leitungen werden genutzt. Leider schert sich die Fortigate nicht um die Bandbreite (ggf kann man da in den aktuellen Versionen mit weightend ECMP was drehen), wird also recht fix die langsamere Leitung überlasten.

Die Lösung: Prioritäten für Routen. Das ist ähnlich wie Metriken, verhindert aber nicht das die Route aus der Routing Tabelle verschwindet. Sind zwei Routen zum Ziel da wird die mit der niedrigeren Priorität gewählt. bei gleicher Prio greift wieder ECMP.
Dadurch die Route in der Routing Tabelle vorhanden ist kann man Sessions über beide WAN Verbindungen aufbauen und mittel Policy Routing auch einzelnen Traffic über eine WAN Strecke forcieren (z.B. http Traffic über die langsamere Verbindung).

Die Prioritäten kann man nur über die CLI einrichten.
Beispiel:

config router static
show

Die entsprechenden Einträge anpassen
edit 1
" set device ""wan1"""
set gateway 192.168.1.100
set priority 1
next
edit 2
" set device ""wan2"""
set priority 5
set gateway 172.16.31.254
next
In diesem Fall würde der Traffic defaultmäßig über WAN1 gehen (niedrigere Priorität), aber eingehender Verkehr über WAN2 wird erlaubt. Fällt WAN1 weg geht der Verkehr über WAN2.

Natürlich muss man sich noch um passende VIPs/ACLs an den entsprechenden Interfaces kümmern und auch DNS im Hinterkopf behalten.

Die ASA von Cisco hat sowas meines Wissens nicht, es gibt immer nur eine aktive Defaultroute Loadbalancing kann sie nicht. Ein Failover kann man ggf mit SLAs.

Nicht cisco GBICs/SFPs

Cisco will das man nur seine eigenen GBICs benutzt. Bei manchen 3rd Party SFPs gibt es dann Fehler:
%PHY-4-UNSUPPORTED_TRANSCEIVER: Unsupported transceiver found in Gi1/0/1
%GBIC_SECURITY_CRYPT-4-VN_DATA_CRC_ERROR: GBIC in port gi 1/0/1 has bad crc

Mittels der undokumentierten Befehle
service unsupported-transciever
no errdisable detect cause gbic-invalid

kann man sein Glück trotzdem versuchen.
Das klappt nicht auf allen Plattformen und leider nicht mit allen GBICs/SFPs, aber ein Versuch sollte es wert sein.

Cisco Router, NAT und IPSec

Vielleicht kommt man mal in die Verlegenheit, das man nicht alle Daten in einen VPN Tunnel schicken will, sondern einen „local internet breakout“ haben möchte. Man schmeisst also nur ein paar Daten in den Tunnel, der Rest wird dynamisch genattet..

Nehmen wir an das lokale Netz ist 10.10.1.0/24 die Netze in der zentrale, die per Tunnel erreicht werden sind 10.10.20.0/24 und 172.16.2.0/24.

Man erstellt eine ACL die den zu verschlüsselnden Traffic denied

access-list 110 deny ip 10.10.1.0 0.0.0.255 10.10.20.0 0.0.0.255
access-list 110 deny ip 10.10.1.0 0.0.0.255 172.16.2.0 0.0.0.255
access-list 110 permit ip 10.10.1.0 0.0.0.255 any

Jetzt bindet man das an eine Routemap

route-map permit_NAT
permit 10 match ip address 110

Danach benutzt man die Routemap im nat statement:

ip nat inside source route-map permit_NAT interface fast0/0 overload

Und definioert nachher noch nat Inside und outside


int fa0/0
description outside
nat outside
[..]
int fa0/1
description inside
nat inside
[..]

Natürlich muss man auch sicherstellen, dass die routen für den verschlüsselten Traffic auch auf die Tunnel Interface zeigen (dynamisches Routing Protokolle wie eigrp/ospf oder statische Routen)

mit show ip nat translation kann man schauen ob es translations fürs Internet gibt, ansonsten mal testen ob der zugriff in die Zentrale noch geht.

SecureCRT F10 geht nicht unter Linux

Nutzt man SecureCRT und verbindet sich mit SSH zu seiner Linux Kiste kommt i.d.R. erst mal das böse erwachen: CLI Menüs (z.B. im Midnight Commander) werden nicht dargestellt und F-Tasten klappen auch nicht.

Die Lösung ist einfach:
Session Options -> Terminal -> Emulation auf „xterm“ bringt die F-Tasten wieder.
Session Options -> Terminal -> Appearance dort kann man „Character Encoding“ ändern. Heutzutage ist UTF8 meist die richtige Wahl.

Meiner Erfahrung nach muß man die Session beenden und neustarten, damit die Emulation greift.