Active-Active Design mit Cisco ASA
Kunden haben immer die besten Ideen. In diesem Fall erschließt der Kunde einen zweiten Standort und möchte beide Standorte mit je einer ASA ausstatten, die aber beide den Traffic möglichst lokal behandeln sollen. Wenn was ausfällt, soll aber im Prinzip alles andere weiter laufen. Ein klarer Fall für Active/Active Failover.
Schritt für Schritt zum richtigen Design
Zuerst plant man mal, wie es ohne alle Failover-Features aussehen soll.
Gegeben sind zwei Standorte mit vielen VLANs. Anhand der VLANs kann festgestellt werden, wo der Traffic eigentlich liegen soll. Die VLANs stehen per Querverbindung zwischen den Standorten aber grundsätzlich überall bereit.
Wenn in einem eventuellem Ausfall Systeme an den anderen Standort migriert werden, behalten sie die IP und das VLAN von ihrem normalen Standort. Damit ändert sich für alle Beteiligten nichts, das Netzwerk wird dann allerdings nicht optimal ausgelastet.
Aus Gründen der Übersichtlichkeit werden nur drei Netze berücksichtigt:
- Ein Außenanschluß im VLAN10.
- Ein Standortnetz im VLAN110.
- Ein Netz am anderen Standort im VLAN100.
- Eine Querverbindung zwischen den ASAs im VLAN200 (die ASAs werden wie Router behandelt)
Als erster Schritt wird angenommen, die ASAs würden pro Standort als Active/Standby Failover ausgebaut.
Die Standby-Geräte sind farblos dargestellt, die inaktiven Leitungen sind gestrichelt. Wie üblich bringen alle Standby-Geräte neue Interfaces mit, die mit den gleichen VLANs versorgt werden müssen.
Standortübergreifende Absicherung erreicht man, indem man die Standby-Geräte auf die jeweils andere Seite stellt. Der Quertraffic fließt auf den inaktiven Leitungen ja normalerweise nicht.
Active/Active Failover bei Cisco bedeutet, daß die physikalischen ASAs in zwei virtuelle ASAs (Context) aufgespalten werden. Diese so entstehenden vier Kontexte (zwei Kontexte auf zwei Maschinen) werden so geschaltet, daß sie sich gegenseitig als Active/Standby-Paar absichern. Pro Gerät ist dann im Normalfall ein Kontext aktiv.
So kann man die vier geplanten ASAs durch zwei physikalische Geräte ersetzen.
Unglücklicherweise ist beim Vereinigen der Geräte ein Konflikt mit dem Querverbindungs-VLAN enstanden. Es ist nicht mehr feststellbar, welcher virtuellen ASA dieses VLAN an einem konkreten Standort zugeteilt werden muß.
Bei allen anderen Interfaces ist die Zuordnung einfach, da pro Standort unterschiedliche VLANs verwendet wurden.
Die offenkundige Lösung besteht darin, das Querverbindungs-VLAN auf unterschiedlichen Ports zweimal pro Gerät zuzuführen.
Schaut man sich den Ausfall dann mal an, kann man feststellen, ob der Plan überhaupt funktionieren kann.
Im Falle eines Ausfalls gibt es keine Gegenstellen mehr für die Querverbindung. Das VLAN muß also aktiv wieder an die ASA zurückgeführt werden.
Normalerweise ist das sowieso kein Problem, da die Standorte per Trunk verbunden sind und auf lokalen Switchen aufgeteilt werden.
So funktioniert das Konzept schon mal.
Weitere Probleme
Aber was ist, wenn die Anzahl der Interfaces an der ASA keine extra Zuführung des Quertraffic-VLANs zuläßt?
Die ASA beherrscht auch eine gemeinsame Nutzung eines Interfaces durch mehrere Kontexte. Frames auf diesem shared Interface müssen dann anhand unterschiedlicher MAC-Adressen oder Ziel-IPs unterschieden werden.
Im Failover-Fall sieht das dann so aus:
Solange das shared-Interface nicht komplett down geht, kann die ASA die Pakete sich selbst zusenden. Dieses Setup nennt man "Cascaded context" und sieht ebenfalls aus, als ob es tun würde.
Diese Vorschläge berücksichtigen, daß Pakete u.U. zweimal durch eine Firewall müssen. Die klassischen Designentwürfe von Cisco beherrschen den Quertraffic von Kontext zu Kontext entweder gar nicht oder benötigen einen extra Router, der pro Kontext als "Uplink" angesprochen werden kann.
1 Kommentare