008 ASA Active Standby Failover

[Music] in our next section we're now going to take a look at the configuration for failover starting with failover in a single context mode a routed firewall and then as we progress to multi context mode and transparent mode we'll we will revisit this and then look at the failover variations for those as well now as I mentioned previously with the first requirement of failover is to make sure that you have a matched pair of the hardware and software so assuming that that is not a problem the next step is we need to make sure that there are identical configurations in the infrastructure for the primary device and the secondary device now here we see in our particular diagram that we are going to be dealing with we have the the same design as before where we're going to have three different interfaces we're going to have the inside that goes to the test pc we have the dmz that goes to router one and then we have the outside that goes to router two now we saw that when we were doing basic initialization there were some other steps on the back end that we needed to do like configure the trunk links from the switches to these ports to make sure we're actually forwarding VLANs 115 and 215 and that this link here has the correct access VLAN assignment on to it now when we're doing with this with failover we need to now make sure that we're essentially replicating that config on to the other device as well so this means that whatever configuration we have on this interface of a si1 has to be the identical configuration of this interface on a sa-2 or if we're doing the trunking here on port 13 we need to make sure that we're doing the trunking here on port 15 as well and again within the scope at the lab exam they're probably not going to tell you this it's just an implicit requirement that the infrastructure has to be set up properly in order for these upper layer applications to work so if they don't specify what VLAN numbers you need to use there has to be something configured on there in order for the ASA's to communicate with each other so in our particular case we're going to be using this interface easy ro2 on both of them as the failover link this means that these two ports here they need to be in the same VLAN and we also want to configure these as port fast ports or edge ports from a spanning tree point of view because we want to make sure that if there's a flap of the link that there is not additional layer two convergence on the switch ports that is going to affect the failover convergence on the the ASAS because remember the ASAS are going to be pulling each other here with some sort of timers and we don't want the underlying layer two convergence to cause an issue in the failover convergence so this is where we need to start first is with the layer two configuration so let's look at switch one here and we need to basically take whatever configuration is on ports 12 and 13 and then just replicate this down to interfaces 14 and 15 respectively okay so on switch one let's show run an interface f-100 12 and one o 13 so right now we're not using the management port but this is the important effect this is the trunking config that is for the DMZ and for the outside interface so I need to make sure that this is going to be replicated on to port 15 and no shutdown okay the same is true on switch to so interface 12 whatever that configures needs to be the same as 14 13 needs to be the same as 15 so we don't want to waste time troubleshooting something related to the failover config when it's really just an underlying layer 2 layer 1 infrastructure problem so on switch to let's show run for feste than at 100 12 and this needs to be the identical config of 1 0 14 then if we look at interfaces 13 and 15 that's what we're gonna use for the failover so show run interface f10 13 and 15 we need these two ports to be in the same VLAN and again we would probably want to run them as edge ports for spanning tree so let's say we have a new V then let's say VLAN anything 999 this is going to be 4 I will say the name is a sa failover on the interface range f10 13 and f1o 15 these are switch ports the switch port access VLAN is $9.99 and spanning-tree portfast is on and no shutdown so pretty straightforward here but again it's it's just one of those those minor details that if you were to overlook then of course none of the upper layer protocols are gonna work so always make sure that the basic layer 1 layer 2 is working before you go on to any of the actual application configuration ok also on the aasa' let's make sure that its links are up so let's let's go to all the lengths easier o0 so they say no shut 0 1 + e0 - same thing on the first a sa so if we show interface IP brief easy wrote uno shut down okay let's look at the show interface IP brief again I just want to make sure that the links are up up which they are okay so let's take a look now at the the documentation and figure out what's the step-by-step process that we actually need to do in order to get the the failover to work so again this is under the 80486 documentation and then we're going down to configuring high availability and this is gonna be active standby failover because we're running in single context mode right now not multi context mode and as we saw before the way that we can check this is the show mode and the show firewall so we are in single context routed mode okay what I want to see basically is just what is the task flow for configuring this so what's the step-by-step list of exactly what we need to do and what's the order that we need to do it in so you could look at their example and basically paste it in there but if it doesn't apply in the exact correct order we're gonna have a problem so we're basically gonna follow this step by step okay first it says that we need to configure the primary unit and as we build this I'm gonna list these commands here in my text editor so we can look at the final result afterwards okay so first on the primary unit it says that follow the steps in this section to configure the primary unit in a land-based active standby failover configuration and as I mentioned what does the land-based mean this is States less failover so we need to think about are we gonna run stateful failover as well if so there's going to be an additional step okay it says don't configure an IP address on the interface for the stateful failover link if you're gonna use a dedicated stateful failover interface okay that's what we're gonna do here we're gonna do the stateless LAN and the stateful linked failover together okay so first off on a si one we're gonna say that this is the primary unit what's the interface that we're going to use for failover I says the interface name and then the interface ID so you have to be careful with this and make sure you look at the context sensitive help because some of the commands they look for the name that you're giving it like in this case they're saying fo link and then to some commands it's looking for the physical interface like gig 0 1 and it's it's not always self-explanatory which is wet so here we're gonna say that the interface name is our failover link and the interface our ID in our case is e 0 2 ok then what's the address that we're gonna use on the failover link okay here the if' name this is going to be the the name if that we gave it so now it's referencing failover link and you could see you could also do this for ipv6 if you want to do v6 failover so the interface name is going to be the failover link IP address this is arbitrary because it's you know it's only locally significant between them so let's say 169 254 0 15 and the mask is going to be 255 255 255 0 and then what's the standby address let's say the remote device is and standby is actually the key word there so they are 16 okay so a sa 1 is 15 AS a 2 is 16 then of course we need to make sure the interface is shut down okay we already did this this is now optionally what is going to be this stateful failover link here it's specifying the name and then the physical link in our case if we're doing it with the same one basically we need to just need to copy this command and say the failover link is called in our case failover link and then it's easier to so we're doing both of them on the same link again from a design point of view normally you would not want to do this because this config here is what's generating all that control plane synchronization this one here is just for polling between the devices you want to make sure that the the state replication doesn't get in the way of the polling then what's the field over interface IP address okay we already did that did that here so you know you don't have to do it twice and then turn field over on okay this is actually going to be our very last step we don't want to turn failover on until we make sure that everything is everything is properly prepped okay so this is going to be for a sa one now for a sa to the secondary unit it's basically going to be the same identical config with the exception that it should say here we are the secondary unit so we could take this and then say that they are the secondary and that's essentially yet now of course we can configure the the other minor features like change the pull time and stuff like that but what I would recommend to do is to get the minimum functional configuration and then if you want to make changes afterwards go ahead and do that stuff but I want to make sure that that the configuration replicates from the active to the standby first that I can failover back and forth manually then once that's done I'm gonna do any type of modification like if I want to pull the interfaces ok so our next step now is I want to make sure to save the config because if I do this in the wrong order and I copy this config to the si1 it's basically going to overwrite everything ok that's what's the that is what is the problem with the order of operations ok you can just paste their example in and if you don't have any other configuration that's fine because you don't really care if it if it deletes your blank config any deletes what was already a blank config ok so this is gonna be our primary fail over link interface specified the now that should have said there we go show run failover so this is the state lists failover configure this is the stateful failover config yes sir the again these can be the same one but normally they you would want them not to be so the same configuration on the other side except the difference is they are secondary not primary okay next we're going to turn failover on the primary box first then on the secondary box okay this is going to work what we should see is that we we detected to the active mate this means that the layer to keep alive over the state lists failover link is working so this means that on Ethernet 0 2 there there is communication between the two boxes so if we did not correctly configure the land switches a si 2 would not have been able to find a si 1 and it would have promoted itself from standby to active so we would essentially have a dual active case where a si one is for running in a si 2 is forwarding but there's a disconnect at the underlying layer 2 infrastructure level okay end configuration replication from the mate this is what we want to see on the standby one on the primary we should see that it's it's sending the configuration to the mate or to the remote device okay we can see now both of them are gonna have identical configurations even down to the hostname so here if we look at show run all the other configuration that we already had was replicated over so the the sub interfaces with their IP addresses etc everything is is copied on a one-to-one basis really the only thing that is different between these two boxes from a configuration point of view is gonna be if we show run failover just this command essentially everything should be the same except for this okay next let's look at this show failover says this host is secondary and it is standby the other host is primary in it's the one doing the actual forwarding okay now additionally notice here it says that the inside link is unknown and the other interfaces are not monitored this means that they're they're not completely converged in the process we need to make sure that this says that the it either says up or or okay basically that the poling between them is fine okay then it's going to stay for the stateful failover link how many TCP connections do I have how many UDP connections do I have okay also for the VPNs am i replicating my IP six security associations now if we were to send traffic through the a SA so let's say we go to the test pc and we do a telnet to router 2 telnet 136 one or two 15.2 if the stateful failover is working we should be able to look at the primary box of course and show connections and on the secondary box should have the identical entry this is what is making it the stateful failover that when the connection occurs on the primary device it's automatically copied down to the secondary device now the next thing we probably want to do is to change the prompt for the parser because well again when we're looking at the two console connections to both of the boxes they both have identical host names that are called a si one so if I SSH into the box I should land on the active one and it's going to have the the same host name as the secondary one but the problem is I don't necessarily know without having to look at the show failover which box am I actually on right now am I on the primary one or the secondary one my on the active one or the or the standby one now you will see that when you go into global config if we say config T on the primary box that's as normal it says you know we go to global config if we do the same thing on the on the standby box it should give us a warning message here it says don't make changes because the config is not replicated from the standby to the active box now it is replicated from active to standby it says if you make a change the configuration is no longer gonna be synchronizing there's gonna be a problem and failover the issue is though what if you know I was in global config and I forgot about that and I come back to the Box later I really have no way to tell now without looking at the show failover that this host is actually the standby one and I should not be in a global config here because again any change that I make is not going to get replicated down to the active box there is a simple fix for this though on the active box we want to change the prompt so that it shows the hostname but it also says what is my context and what is my state okay we could say the priority if we want to as well and let's say write memory all or actually right standby ok right name all that's gonna be for when we're in multi context mode this here is going to do an explicit push of the config to the remote box if we look at the roomba remote box now we can see it's a si one but it's the standby box it's the secondary one the other one is active and it is primary so now when we connect to the console we don't have to worry about accidentally making the changes on the secondary one because we can see in the host name it is a si one but in the a si one pair are we talking about the active box or are we talking about the standby box now we'll see when we get to multi context mode active active failover this becomes even more complicated because I can say that a si one is active for context a but a si 2 is active for context B which means that when I make changes for a I need to make sure to make it on a si one and when I make changes for context B I need to make sure to make it on a si two so it can get confusing where you need to make the changes that's why in general you want to change the prompt so that it tells you am I currently the active forwarder or the standby forward or for this individual context ok we're in this case we're running in single context mode so it's it's active standby it's not active active okay let's look at the show failover again and see if the monitor interface is up okay here it says that the interface inside is still that's still unknown it's waiting the reason why if we look at the show run interface inside we're actually either a zero I didn't configure the secondary address that I can use for the monitoring so when we look at the show run failover these let's see this one this basically everything except this that would be the minimum config so it's basically only four commands that you need so is this the primary or secondary unit what's the link that we're gonna pull each other on what's the IP address of the link then turn failover on okay this is saying this is where we're doing this state replication this is for a stateful failover but if we now want to monitor the other interfaces like the inside we need to put IP addresses on them just like we have for the failover link so if we show run for interface zero one dot one one five we would need the standby addresses configured as well now again remember when you actually make these changes you're always making the changes on the active box so even though the secondary one owns the standby address from a configuration point of view the changes from form management are made on the active forwarder this is the reason again that you want to change the prompt so you can see am i active or standby okay so let's go to these interfaces here let's say e 0 0 on a 0 0 this is the address but the standby box is going to have the address dot 16 okay same thing on easy ro1 115 this is the primary but the secondary is or the standby is dot 16 so again you don't necessarily have to do this the only time that you need to configure these addresses on the data plane links is if you want to do the monitor link or monitor interface because the the platform's they're already polling each other over this failover monitoring interface but the problem that you would want to avoid is let's say that someone goes into the lair to switch and they make a change where on this particular port they say no VLAN 115 so someone accidentally edits the allowed list on the link and removes VLAN 1 15 from forwarding now since the ASAS our polling each other over easy Row 2 they don't see that there's a problem there but from an actual data plane forwarding point of view when I go to send traffic out this interface if the switch is not allowing VLAN 115 then it's not going to actually accept that those packets in the data plane this is the reason why you would want to configure the additional monitor interface to make sure that there's not some sort of software or configuration failure that stops the box from forwarding that the field over cannot natively detect if we go to the secondary and look at the show run output we could see that these changes were already replicated ok but you always want to make sure to save the config when you save the config it should be saving it on the primary and then it's also going to push this down to the secondary so the secondary you can see it's saving its config also okay now if we look at this show failover we should see this link is now monitored if we wanted to add those other ones let's say monitor interface on the DMZ and on the outside show monitor interface either going to start to ping back and forth and once they get to keep a lives these should change - they should change from waiting to monitored which they are okay next let's see can we actually get the failover to work the first way I'm going to test this is to force the failover then once it works will fail back and then we'll test it from the actual data plane so is the monitoring working as well so let's say on a si - from exec mode we want to be the failover actor box so we're switching to active so you can see the standby keyword there changed to active the other one now switches to standby now that they've failed over does the data plane still work so can I go to my virtual machine and is my connection to router 2 still working ok which it is so let's say that we do a ping here and while we're doing the ping we failover between the two boxes and let's see is the VM actually going to lose reach ability so on a si one let's say failover he'll overactive so the active forward was changing but you can see there's no additional convergence time okay now we could now we could check is the failover stateful we could check this with a TCP connection so telnet to router to do the failover and see does the telnet connections stay up which it does if this was a state list failover we would see that the connection would be lost it would have to be re-established so we can see that if we go to the active device let's say show run failover and let's remove this command which is the stateful failover so we're now doing stateful failover anymore just stateless we can see the telnet sessions still open if we fail back over actually I would have to let's do this let's let's exit and then restart because they had already previously synchronized that connection it'll tell it to router to then failover to the secondary and now we can see the connections lost so this is really the main difference between the stateless and the stateful is the TCP and UDP connection table along with the IPSec data copied over to the stand by one but again remember it has to do this on a per connection basis so if you're doing them on the same link the poling the devices and doing the state replication the state replication could overwhelm the poling and then the failover would occur on in like an error case so normally again you want to do them on separate links but for our purposes for the lab it's not a design issues just basic functionality okay there's a question here if the monitoring link shows that the pings aren't making it but the failover and lan links are still up would it failover okay that's what we're going to test next now that we're monitoring those inside and outside interfaces so essentially here there is an extra copy of all of these links on a si - so a si - has the inside okay we could say it's part of that segment it's also part of this test PC segment and it's part of the outside segment so since we're monitoring basically the boxes are pinging back and forth between each of between each other on each of these links to do the monitoring so what would now happen let's say we go to our outside and we miss configure the link that goes to a si one even if this interface is up are they still going to failover well it really depends what is our what is the monitoring policy so if the interface policy says that if any of the links fail then failover then we should see it occur but if we configure it as a higher percentage or a higher count we might have to have more than one of them failed the monitoring situation before the the devices actually failover but one is the default so we should see that with making any changes that that's gonna be the case that we run into okay so let's say that a sa one is going to be the active one and a sa one will say failover active so we switched to active they switch to standby okay next let's go to the let's go to the VM and let's ping router - so this traffic is going to go to the outside and let's keep that ping running okay next we're going to go to that outside interface of a si one which is right here and we're going to remove the the VLAN which in this case is is VLAN 125 so we're going to remove this from the allowed list and see if they can detect that between each other and while we're doing this let's look at the ping so on switch one this is going to be on port f1o 13 I want to say which it is so let's go to interface f1o 13 and say switch port trunk allowed VLAN remove to 15 we can see now that that VLANs not forwarding so the traffic is dropping if we look at a sa one let's say show failover and we're looking at the outside interface which is right now being monitored we can see now the active one says I have to fail over because my outside interface failed so this would be the ideal case that you want because not only do you want to check that point-to-point link between them you also want to check is the data plane actually functional now the the easiest failover situation to detect is that if the failover link goes down you know that the other box is gone like if it power cycles then the link is going to go down and you know that the second error needs to promote itself to the active what is the more difficult situation to detect is this type of software failure where either there's a configuration issue or there's you know maybe there's a process crash on the primary box you need to make sure that the secondary one detects that and the case here is that for these sub interfaces it does not do that automatically so this is where we need to go and configure the secondary addresses here are these standby addresses I should say and then also the additional monitor interface policy so so if we show run the show run monitor that we're monitoring monitor interface inside is the default but we want to monitor the DMZ and the outside so again when we look at the show run failover there's really not much that's involved with the configuration it's more of an issue to make sure that the underlying layer 2 infrastructure is working properly first that we do these steps in the correct order and then test doing the failover in software so manually fail it back and forth and then it do some sort of fail if failure situation like shut the link down and see if the failover actually occurs ok there's a question here do we know if both ASA's share the same MAC address so they can work as the the failover yes they do and the way that we can see this is by looking at the IP destination so let's look at router 2 and look at the show ARP and let's do this let's say clear ARP we see that there's two different addresses here there's a s a 1 in there's a sa 2 so this is the primary this is the secondary ok let's go back to the switch and let's let's fix that that failure situation I was doing so switchboard trunk allowed VLAN add to 15 and we're gonna say that the a s a 1 is the active so failover active and let's see how could we check this if we go to router 2 so let's look back at our diagram here on a brother - I'm gonna configure on inbound ACL on this interface here at gigs 0 0 that I'm gonna have it log input now remember we talked about in regular iOS when we're logging ACLs we have two options you could say log or log input or log input is gonna tell you what was the incoming inner interface plus the layer 2 forwarder so what was the MAC address of the device on the link that sent the packet so on router - let's do this let's say access list 100 permit - ICMP any any log input and access list 100 permit IP any any do you show XS + 100 okay this is going to be applied on gig 0 0 inbound so IP excess crew of 100 in okay we can see from 10 100 100 it says the source was eight nine one seven if we look at the show ARP eight nine one seven this is the dot fifteen address okay let's also say this on router two IP access list the log update threshold is every one packet and actually let me make this axis a little bit more specific so it cuts down on some of the outputs let's say here no logging console do show run pipe section access list let's say IP access list extended 100 no sequence 1 I'm gonna change this to say permit ICMP from the hose to 10 100 100 so just from the VM and then log the input there so access lists and then logging console seven okay so what we're looking at here is the the MAC address why is it still logging the so those those must have been old hits that are that are still stuck in the buffer okay so on a si one a si one is the active device we could see the VM is still sending the packets we go to the switch and we cause the failure so we remove VLAN 215 okay now the virtual machine should lose reach ability once it detects this and failover occurs if we go back to router 2 let's see what is the MAC address that the new packets come in from because it's gonna have to switch from a si 1 to a si - so a si one says I'm switching to standby ok now the flow continues and if we look at the ingress MAC address it's 80 917 again when we look at the show ARP who was 80 917 it's the primary address so the idea behind this is that if you did the failover to a different MAC address all of the other layer 3 devices on this segment would have to flush out the ARP cache now you could theoretically do it this way you could have the a si generate a gratuitous ARP in order to flush out the other devices MAC addresses but that's not the way that they did the implementation what they did instead was just to say when the standby takes over the active role have it assumed the primary IP address and the primary MAC address so from a management point of view if we were to ssh into this dot 15 address we're actually going to end up on a si - because it's now the primary forwarder for that particular IP and MAC pair so you can think of it kind of like how H SRP works where it's a virtual address now where whoever is the act of forwarder there they are the one that is assuming that IP and MAC pair okay there's a question here what would occur if the same monitoring interface on a si 1 & 2 both interfaces failed due to a Mis configuration so the question now is well what if I do that same msconfig on the other port this unfortunately they're not going to be able to to account for so if there's a double failure then forwarding is no longer to work so if we look at the show failover let's do this let's say show failover include a host or interface on this host right now it says outside is is normal if we check on the other one we should see that both of these go to actually no they're not going to both go to failed because it depends on the order of operations so the the secondary box wasn't able to detect the primary so the the secondary is promoting itself to the primary and it's saying I'm not going to monitor that interface anymore so yeah it really depends on the order but in any case if there's a double failure there's not anything that you can really do because there's only two devices in the failover pair you cannot have an act of forwarder and then to standbys so it's not like HS RP where you could have three routers in the same group it's a it's a pair it just has to be active standby okay we'll see what the multiple context mode what they call active active failover is actually active standby failover on a per context basis so you still only have one forwarder at a time but it just depends on is this argue the forwarder for context a or context B but you wouldn't both be forwarders for a or both before orders for B at the same time there's a question can this behavior change if we enable the MAC address auto command we are going to look at that when we look into multiple context mode so when we do active active failover and then we have the automatically derived MAC addresses we'll see how that how is that going to affect what is the primary IP address what is the primary MAC address is that the physical interface one or is it the the generated one okay there's another question here to configure failover should the to a SAS have the same exact model hardware features and licenses yes so basically they have to be on identical matched pair all right now I think there is a an exception to this while you are upgrading the code that if you're upgrading the secondary one and then you fail over and then you upgrade the primary one because there you need to be able to do basically an in-service software upgrade so there are cases where you can temporarily mismatch the code while you're doing the upgrade and some other minor things don't need to match the amount of flash doesn't really matter between the two of them but you want to make sure that they're running the same code and that they have the same hardware and licenses okay also for the ISS you if you are doing this in production you need to make sure to check the release notes because it's not hitless for all upgrade paths so if you go if you go between miners sub releases at the same major release like for example like eight four one two eight four two that should be fine but if you go from like eight to two eight four then that's not going to be hitless but in general they should be basically mirror images of each other the the failover boxes [Music]

Channel: Cisco Security

Views: 2,953

Keywords:

Id: j96LAdYM9_4

Length: 46min 29sec (2789 seconds)

Published: Tue Jan 16 2018