Active Standby: The two systems need to be the same.
An ASA can share its stateful failover link with a regular data interface only when the unit is operating in single context, routed mode. Although it is highly recommended using a dedicated interface and a key for optimum uptime and security.
Active device moves traffic and the standby device does nothing until the active has a problem. The secondary device will takeover the primaries IP address and mac addresses of all it’s interfaces. Secondary will also do a gratuitous ARP so the switches all know where the layer 2 addresses are. All stateful information will be replicated to the secondary device when it is secondary so when it comes up it has all information it needs and when the firewall goes down the user will never notice. Any configuration changes done to the active firewall are replicated over the failover links to the secondary firewall. By default all the flows are not replicated to secondary machine. If we want the machines to be stateful replicated meaning secondary knows of all flows and PAT clients then we need a stateful interface. The failover interface is for config and keepalive, while the stateful interface is for state. Non replicated info: dhcp client info if active is acting as DHCP server, Phone Proxy, and hardware modules. If you are replicating by default http is not replicated that needs to be added. Configuration changes will only be done on active firewall once failover is configured. If the ASA recognizes it hasn’t seen the Active for 15 seconds it will then check if link is up, because what if this ASA is the problem device maybe it shouldn’t be going up. You wouldn’t want active/active in an active/standby config. It’s not supported. Both ASAs would be using the same IPs. The mac addresses of the interfaces would be used, but could be configured, and we could also configure active/standby macs and these would be superior. To recognize which device you are on you can use -> show failover; and the primary device configured will show Primary on the 3rd line whether or not the device is active or standby. No response from mate means no standby found. If you have a special license for lets say SSL VPN sessions the license for both ASA will be accumulative. You can not configure a standby address with a /31 address, the smallest address you can use is /30.
->show ip; will show two sets of IP’s, System, and current. Current maybe the standby address. If sets of IPs are the same you know it’s the active device.
ip address 172.16.1.1 255.255.255.248 standby 172.16.1.2; For failover and stateful- These links do not change when active/standby flip use Xover ip address 172.16.2.1 255.255.255.254 standby 172.16.2.0;
ASDM- Device Management, Configuration, High Availability, Failover.
CLI- int Gig3 no shut; ip address 10.1.1.1 255.255.255.0 standby 10.1.1.2 int Gig4 no shut; ip add 220.127.116.11 255.255.255.0 standby 18.104.22.168; int Gig1 no shut; failover lan interface fail-1 Gig1; failover interface ip fail-1 10.1.2.1 255.255.255.252 standby 10.1.2.2; assigning the failover keepalive interface and command config int gig 2; no shut; failover link fail-2 G2; failover interface ip fail-2 22.214.171.124 255.255.255.252 standby 126.96.36.199; failover replicate http; failover mac address Gig1 0000.1111.2222 0000.3333.4444; failover key cisco; failover lan unit primary failover; turns the feature on. no fail active; makes other ASA active.
This was all done on the primary device for the secondary all we need if the lan link up and it will get all the configs from the primary device. int Gig 1; no shut; failover interface ip fail-1 10.1.1.1 255.255.255; failover lan interface fail-1 Gig1; failover key cisco; failover lan unit secondary; link means stateful replication AND lan means failover/ config You could use the same interface for lan and link, NOT RECOMMENDED. If you didn’t have enough interfaces though, it could be done. Realtime replication, configs, and keepalives all on the same interface can be a little risky. You could also change your prompt to show you hostname, priority and state. ->prompt hostname priority state; Recall that all commands are replicated so both devices have to have same hostname.
show commands: show failover; no failover active; to test switchover from primary. -> failover active; to test switchover from secondary.
https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/116639-technote-asa-00.html VPN RA and Site-to-Site is supported.
Two failover groups 1 & 2. One is active for group 1 and other active for group 2. The failover commands are all configured from system context and the ip addresses on the interfaces are configured from their contexts because they will be assigned to the contexts. There is no preempt by default. We may want to configure this.
From the primary device: in system mode.
failover group 1; primary; preempt 120; primary is default so you won’t see this in config failover group 2; secondary; preempt 120; This makes the secondary active for any contexts associated with the failover group. So, primary made the primary active for any contexts associated with that failover group.
By default all contexts belong to failover group 1;
context CTX-1; join-failover-group 1 ; context CTX-2; join-failover-group 2; exit failover lan interface fail-config Gig4; failover interface ip fail-config 188.8.131.52 255.255.255.252 standby 184.108.40.206; int gig 4; no shut failover link interface fail-state Gig5; failover interface ip fail-state 220.127.116.11 255.255.255.252 standby 18.104.22.168; int Gig5; no shut;
Before configuring your context interfaces ensure from system you no shut the interfaces. ->prompt hostname context priority state; to let us know where we are. changeto context Ctx-1; inter Gig 1; ip address 10.0.0.1 255.255.255.0 standby 10.0.0.2; interface gig3; mac-address cc1e.6763.2222; ip address 192.168.1.171 255.255.255.0 standby 192.168.1.181. changeto context Ctx-2; int gig 2; ip address 10.2.2.1 255.255.255.0 standby 10.2.2.2; Funny thing with this is I am configuring from Sys of primary for context 1 but I am configuring this interface locally that will really be the secondary applied to local machine. inter gig3; mac-address cc1e.6783.3333 standby cc1e6783.4444; ip address 192.168.1.172 255.255.255.0 standby 192.168.1.181;
changeto system; failover; write mem all; saves all context information not just system.
Now for the second ASA. It must also be in multimode. That can not be taken be the lan failover interface. Both need same hardware, same RAM, same multi mode and routed. mode multiple; failover lan unit secondary; int gig4; no shut; failover lan interface fail-config Gig4; failover interface ip fail-config 22.214.171.124 255.255.255.252 standby 126.96.36.199; already configured this device to know it’s standby so it will take the standby IP. standby should really mean secondary especially on lan and link where the IPs never swap. But, secondary might make people think it is a secondary IP on an interface like a router. So we know it’s just the IP used by secondary device.
Testing -> failover active group 2; no it out for opposite affect.
So basically what we are doing is combining these two configs. It’s kind of like load balancing with two switches with HSRP one distro switch is active for a VLAN and another distro switch is active for another VLAN. Except for with networks. So CTX-1 ASA1 is active for DMZ and CTX-2 ASA2 is active for LAN. Both contexts are active on the WAN side Gig3.
In the above config asymmetrical routing can never occur. However, we may one day be in an environment where someone configured asymmetrical routing. In a scenario where asymmetrical routing can occur we will need our devices to join ASR-groups to prevent asymmetrical routing issues because the ASA doesn’t have the state of the traffic. What happens with the asr-group is that when it receives traffic that is a replay to wrong ASA it words it to other ASA in the group.
ASDM- Device Setup, Routing,ASR Group. CLI- int Gig1; asr-group 1;
If you were configuring a context on a device that is standby for the particular context you could get by with the failover commands. But, in general you should configure commands for the context on the active device. ->failover exec active interface Gig 2; failover exec active asr-group 1; This would only be done this way if it was from standby device being send to active device.
Added notes for multi context. Features not supported: RIP, OSPFv3, Thread detection, Multicast routing, UCS, QoS, terminating of VPNs.