De ASA ondersteunt twee verschillende failover modes; active/standby en active/active. Bij active/standby is er één unit actief en is de andere aan het wachten totdat de actieve unit uitvalt of totdat hij het commando krijgt om actief te worden.

De active/active variant werkt op basis van actieve contexten. Een context is het beste te omschrijven als een selectie van resources die aan elkaar gekoppeld worden zonder dat de rest van de resources daar bij kan. Zo zou je bijvoorbeeld twee omgevingen met exact dezelfde IP adressen op verschillende contexten kunnen configureren zonder dat ze elkaar in de weg zitten. Per context kan worden bepaald op welke ASA deze actief moet zijn. Het volgende plaatje geeft dit weer.

Alleen context B is dus actief op ASA 2. Het voordeel hiervan is dat Context A op ASA 1 alle bandbreedte, memory en CPU kan gebruiken en Context B kan op ASA 2 alles pakken wat hij nodig heeft. Een nadeel hiervan is dat wanneer ASA 2 uitvalt Context B automatisch actief wordt op ASA 1 en dan weer bandbreedte, memory en CPU moet delen met Context A. Hierdoor ontstaan mogelijk capaciteitsissues; iets waar je zeker goed rekening mee moet houden. Onze insteek is altijd dat in een failover setup, of het nou routers, switches of firewalls zijn, één enkele unit in staat moet zijn om het werk van alle units over te nemen. Hierdoor voorkom je capaciteitsproblemen.

Er bestaat ook nog de mogelijkheid om een cluster te maken van ASA’s waarbij meerdere ASA’s worden aangestuurd alsof het één logische unit is. Het voordeel van die oplossing is dat er meer doorvoersnelheid haalbaar is door verschillende verkeersstromen door verschillende ASA’s te sturen. Dit is alleen interessant als je een omgeving hebt die meer dataverkeer doet dan één enkele ASA aan kan. Het is helaas niet zo dat je bij twee ASA’s ook twee keer zoveel capaciteit hebt. De richtlijnen voor de capaciteit van ASA clusters is:

Wij bouwen veel netwerkoplossingen met gebruik van  ASA Clustering, simpelweg omdat er niet altijd een next-gen firewall nodig is. De setup waar wij altijd voor gaan is; active/standby. Een vereiste voor het aansluiten van deze firewall setup op het netwerk is dat alle interfaces op een redundante switchlaag moeten worden aangesloten. De reden hiervoor is dat elke ASA zijn weg moet kunnen vinden naar devices in het netwerk zoals een PC, een router van een provider of een laag 3 switch verderop in het netwerk. Als laag 3 devices in het netwerk willen weten bij welke ASA ze hun verkeer af moeten leveren doen ze een ARP request voor het IP adres waarover de ASA zou moeten kunnen beschikken. De primaire ASA geeft antwoord op het ARP request wanneer het verkeer op zijn MAC adres kan worden afgeleverd. Alle switches in het netwerk zijn nu op de hoogte van de route naar de ASA. Dit blijft allemaal netjes doordraaien totdat er een issue optreedt met de primaire ASA. Stel dat deze door stroomuitval niet meer beschikbaar is. Op dat moment signaleert de standby ASA dat zijn “hello’s” niet meer beantwoord worden en zal hij na een aantal checks besluiten om actief te worden. De rest van het netwerk is dan nog niet op de hoogte van deze nieuwe situatie dus stuurt de ASA die nu net actief is geworden een gratuitous ARP uit. Dit is een eenmalige actie waarbij hij tegen het complete netwerk roept; het IP adres wat je probeert te benaderen zit nu bij mijn MAC adres. MAC tabellen en ARP tabellen binnen het netwerk worden aangepast en in een mum van tijd is de standby ASA actief geworden.

De tijd die het duurt voordat de standby ASA actief wordt kun je zelf instellen. Uitval zoals in bovenstaand voorbeeld zal waarschijnlijk wel worden opgemerkt door de gebruikers. Het omschakelen van een standby unit naar active zonder uitval, dus via een failover commando, wordt niet bemerkt door de gebruiker. Dit komt doordat ARP entries, VPN tunnels, TCP connecties, UDP connecties en NAT tabellen worden uitgewisseld tussen de actieve en de standby unit. Zo zijn beide firewalls op de hoogte van de actieve staat van het netwerk, het zijn immers stateful firewalls, dus zal het omschakelen van de ene firewall naar de ander geen impact hebben. Hierdoor is het mogelijk om zero-downtime software upgrades uit te voeren en uptime te blijven garanderen naar de gebruikers toe.