We were thinking about redundancy options for CCIE.PL today. There are few restrictions we have there, both came either from policy or our personal thoughts about several aspects of paid services and sharing admin access. But simply we are thinking how to automate failover in case our primary server or database have problems. Easiest solution would be to use Cloudflare free tier service but let’s say we don’t want to do this now. So we were looking on the other options and there was an idea that maybe we can use cloud load-balancer for on-premise services. First thought – it’s brilliant. On second thought – definitely that idea was wrong. Let me show you why.
Hardware failures happens. If you have active service contract you’ll get new device from Cisco with same hardware parameters. One thing you don’t know is which version of software will be installed. In almost all cases it’s not the one you are using. Installing new firewall firmware on ASA is not a problem but what if you’re running SourceFire Management Center version 6.2 but your device came with 5.x or 6.0 firmware on SFR module? Well, prepare for process that will take few hours – you need to perform recovery procedure which is one of the ways of upgrading SourceFire.
Most common cases when we have to use recovery procedure for SFR are:
- Problems with booting the SFP module after upgrade performed from Firesight Management Center
- First software installation on SFR (in example when we just put SSD drives in our ASA to get benefits from Sourcefire NGIPS)
- Need to upgrade firmware but our module cannot be registered in Firesight Management Center due to firmware mismatch
Last case is the one usually happening when we get new device during RMA process. Each Firesight Management Center have list of compatible firmwares that are supported on modules and unfortunatelly backward compatibility is not full. If you run one of the most common version 6.1 or 6.2 you need to have your modules in at least 6.1 version. Recovery process require that whole memory is erased and new firmware installed.
One reader asked me few days ago following question when he had problem establishing the failover in his lab: “I’ve tried to create ASA failover pair on VIRL and it was not working. I’ve looked through manual and VIRL forum for the solution. I believe that failover is supported configuration on VIRL. I think my configuration is correct, nodes can ping each other but I still cannot establish failover relationship”. Configuration he made was correct except he forgot about one thing – interfaces numbers are important when you setup failover using ASAv.
Cisco VIRL uses ASAv image for virtual firewalls. This is same image that you use in production on ESXi. That means all restrictions applies also to virtual firewall if you run it on VIRL. In this image we must configure failover link using interfaces GigabitEthernet0/8. It’s clearly stated in documentation. If we use any other interface the configuration will be accepted but failover never established.
failover lan unit primary failover lan interface Fail-link GigabitEthernet0/8 failover replication http failover link State-link GigabitEthernet0/7 failover interface ip Fail-link 192.168.255.253 255.255.255.252 standby 192.168.255.254 failover interface ip State-link 192.168.254.253 255.255.255.252 standby 192.168.254.254 failover ipsec pre-shared-key 0 FailoverKey failover
We also need to remember we can’t configure Active-Active failover. This mode is not supported so we have to stick to Active-Standby model. It’s direct result of lack of support for virtual contexts so remember about it as well.
I’ve said during several conferences where I had a privilege to be a speaker that clouds are one of the futures of computing along with DevOps/SysOps and Machine Learning. But there is no computing if you don’t have the data to compute or you have no way to send it to the cloud in reliable and secure way or you don’t have cloud infrastructure to perform computation. That’s why we need to take a look how to setup VPN between Juniper SRX and AWS Cloud.
I think that hybrid cloud will be the model how many of computer system will work in net few years. Private clouds are not scalable and public clouds cannot address all needs of current systems. So hybrid mode is a solution. But it requires reliable and easy to setup and maintain ways to connect on-premise resourced to public cloud. The technology is here and it’s called VPN.