|
0:00:13
|
In our next section with the asa we are going to look at an example of the transparent failover
|
|
0:00:19
|
running in active standby mode
|
|
0:00:23
|
So the configuration is going to be very similar to what we saw before in the transparent firewall
|
|
0:00:28
|
where asa1 is now in the layer2 transit path
|
|
0:00:33
|
between router3 and router4
|
|
0:00:36
|
where again we have the same ip subnet
|
|
0:00:39
|
which router3 is using 172.16.34.3
|
|
0:00:43
|
router4 is 172.16.34.4
|
|
0:00:47
|
but they are unseparate VLANs, they inseparate layer2 domains or broadcast domains
|
|
0:00:54
|
So in order to move traffic from the inside to the outside
|
|
0:00:57
|
the asa is going to be using its CAM table or the MAC address table
|
|
0:01:03
|
Now if we take a look at the ASAs to start
|
|
0:01:07
|
asa1 has the basic configuration for the transparent firewall working
|
|
0:01:11
|
we can see its running in single mode and transparent firewall
|
|
0:01:15
|
where asa2 has a blank configuration
|
|
0:01:19
|
other than that we are running in single mode and transparent firewall
|
|
0:01:24
|
So asa1 is going to be our primary device for failover, asa2 is going to be our secondary
|
|
0:01:31
|
Now likewise, just like the previous example
|
|
0:01:35
|
the layer2 configuration
|
|
0:01:38
|
for the relevant interfaces
|
|
0:01:41
|
have the same vlan assignments
|
|
0:01:43
|
which in this case
|
|
0:01:47
|
is the ethernet 0/1 for the inside
|
|
0:01:51
|
ethernet 0/0 for the outside
|
|
0:01:54
|
and then ethernet 0/2 for the failover
|
|
0:01:58
|
So we have identical configurations from the
|
|
0:02:01
|
layer2 switching point of view
|
|
0:02:07
|
Now before we proceed any further with the
|
|
0:02:09
|
the failover, lets take a look at
|
|
0:02:12
|
asa1 and make sure that we can actually transit
|
|
0:02:15
|
traffic through the interfaces
|
|
0:02:17
|
So if we go to router4
|
|
0:02:22
|
we look at the show ip eigrp neighbours
|
|
0:02:26
|
we see that we do have the adjacency with router3
|
|
0:02:29
|
if we were to ping router3
|
|
0:02:33
|
we have connectivity if we were to telnet
|
|
0:02:37
|
to them
|
|
0:02:39
|
to generate a tcp session
|
|
0:02:42
|
when we look at asa1 and look at the show connections
|
|
0:02:46
|
or the show connections detail
|
|
0:02:49
|
we can see that, we have the
|
|
0:02:52
|
tcp session for the telnet being inspected
|
|
0:02:55
|
we also have the eigrp sessions
|
|
0:02:57
|
that are manually being allowed
|
|
0:02:59
|
through the transparent firewall
|
|
0:03:03
|
so again we are called with this configuration
|
|
0:03:06
|
that we need different exceptions to the access-list
|
|
0:03:09
|
then we have in the routed mode
|
|
0:03:13
|
where I am allowing traffic on the inside interface in
|
|
0:03:18
|
in addition to allowing traffic on the outside interface in
|
|
0:03:22
|
so I am doing an exception to allow the eigrp control plane
|
|
0:03:26
|
but then also the traffic that I want to inspect on the inside
|
|
0:03:30
|
which is the icmp, tcp and udp
|
|
0:03:36
|
now the failover configuration is going to be fairly similar between
|
|
0:03:40
|
the active standby in routed mode
|
|
0:03:43
|
and the active standby in transparent mode
|
|
0:03:48
|
but the main difference is that we only have one single ip address
|
|
0:03:53
|
that is assigned for the management
|
|
0:03:56
|
so on asa1, if we look at the show run ip
|
|
0:04:00
|
we have the ip address in global configuration
|
|
0:04:04
|
so if I were to ping router4's address
|
|
0:04:09
|
this traffic is coming from my global management interface
|
|
0:04:15
|
So this now means that when we define the secondary address for the
|
|
0:04:19
|
standby firewall
|
|
0:04:22
|
this is going to go in global config
|
|
0:04:24
|
we will say the primary address is 172.16.34.11
|
|
0:04:31
|
and the standby address
|
|
0:04:34
|
is 172.16.34
|
|
0:04:38
|
....34.12
|
|
0:04:41
|
so this address 172.16.34.12
|
|
0:04:47
|
this is representing the standby firewall which is asa2
|
|
0:04:50
|
and asa1 has the .11 address, is the primary
|
|
0:04:56
|
Now we are still going to need a dedicated link to do the failover over
|
|
0:05:04
|
asa1 is going to be the primary unit, so we will say failover lan unit primary
|
|
0:05:12
|
I am going to be using interface ethernet 0/2
|
|
0:05:16
|
So for the failover lan interface
|
|
0:05:19
|
I need to give it a name, we are going to call it failover
|
|
0:05:22
|
and whats the
|
|
0:05:24
|
the physical interface which here is ethernet 0/2
|
|
0:05:32
|
then the
|
|
0:05:37
|
failover interface, the ip configuration, this is going to be for
|
|
0:05:41
|
we are calling it failover
|
|
0:05:48
|
and we will do the same addressing as before 10.0.1.12
|
|
0:05:55
|
and the standby address is 10.0
|
|
0:05:59
|
actually the other way round
|
|
0:06:04
|
11 and 12
|
|
0:06:07
|
now if we wanted to do stateful failover
|
|
0:06:10
|
to copy the translations and to the tcp sessions over to the standby device
|
|
0:06:15
|
we need to specify whats the failover link
|
|
0:06:19
|
So use the same interface here
|
|
0:06:22
|
if we now look at the show run failover
|
|
0:06:30
|
say show run failover or
|
|
0:06:37
|
show run | [pipe sign] include failover or standby
|
|
0:06:42
|
So essentially the same configuration is going to go on
|
|
0:06:45
|
asa2
|
|
0:06:48
|
but it is going to be the secondary device
|
|
0:06:53
|
so I am going to change failover lan unit to failover lan unit secondary
|
|
0:07:03
|
we look at the show interfaces
|
|
0:07:05
|
again I need to make sure that these are in the up and up state, so lets say show interfaces include line protocol
|
|
0:07:13
|
we could see that all of these are in the up and up state, the ones that I need here
|
|
0:07:18
|
Now again before we actually enable the failover
|
|
0:07:21
|
would be a good idea to save the config here
|
|
0:07:25
|
So just in case the order gets messed up
|
|
0:07:28
|
I don't want to delete
|
|
0:07:30
|
the configure asa1 or essentially failover a blank configuration from the secondary device
|
|
0:07:37
|
on asa1 lets turn failover on
|
|
0:07:41
|
likewise on asa2
|
|
0:07:45
|
so ideally what we should see here is that
|
|
0:07:48
|
the secondary device finds the primary one
|
|
0:07:52
|
and it starts downloading that configuration
|
|
0:07:57
|
if we now look at the show run
|
|
0:08:02
|
we should see the configuration has been replicated, which it can
|
|
0:08:08
|
now one change we are going to make here from our previous example
|
|
0:08:12
|
is to speed up the convergence we are going to change what the
|
|
0:08:15
|
change what the timers are, so lets look at the show failover
|
|
0:08:21
|
and it says that the unit polling time is 1 second, whole time is 15
|
|
0:08:26
|
the interface whole time is
|
|
0:08:29
|
5 seconds and the whole time is 25
|
|
0:08:32
|
Now the inside and the outside links these are already being
|
|
0:08:38
|
monitored, so once we converge they should not sit waiting here
|
|
0:08:43
|
this waiting means that its in the process of converging
|
|
0:08:46
|
so when we show failover
|
|
0:08:56
|
we want to see that both of these say normal
|
|
0:09:01
|
okay there is a couple
|
|
0:09:04
|
of questions here - any example on the real world scenario where you would prefer to do stateless failover instead of stateful failover
|
|
0:09:12
|
the issue is that if you have too much state information
|
|
0:09:17
|
So if there is a problem
|
|
0:09:19
|
where the basically the platforms cannot keep up with replicating the states
|
|
0:09:24
|
then you would want to disable it
|
|
0:09:27
|
Now personally I haven't seen that case where
|
|
0:09:31
|
the platform has so many connections that it cannot tell the secondary one about it
|
|
0:09:35
|
but theoritically you could
|
|
0:09:38
|
hey, pretty much all the configurations I have seen in real world design today is using stateful failover instead of stateless
|
|
0:09:47
|
hey there is another question
|
|
0:09:48
|
did it replicate the access-list as well as the failover config
|
|
0:09:52
|
it replicated the entire configuration
|
|
0:09:56
|
so when we look at
|
|
0:09:58
|
lets look at the show failover again, looks like its still converging a little bit
|
|
0:10:03
|
but on the source that was the active
|
|
0:10:08
|
these access list
|
|
0:10:11
|
these were applied in on the inside interface and in on the outside interface
|
|
0:10:15
|
So essentially all of the config
|
|
0:10:18
|
any changes in the modular policy framework
|
|
0:10:22
|
everything is going to be replicated down
|
|
0:10:25
|
So when we look at show run on the other device
|
|
0:10:28
|
which in this case is asa2
|
|
0:10:30
|
the only thing that you should see is different
|
|
0:10:33
|
between the two configs
|
|
0:10:35
|
is one of them is going to say
|
|
0:10:40
|
failover lan unit secondary
|
|
0:10:43
|
the other one will say failover lan unit primary
|
|
0:10:46
|
other than that everything is going to be identical
|
|
0:10:50
|
now this is the reason why you want to make sure you to save your config first
|
|
0:10:54
|
because if
|
|
0:10:56
|
the secondary unit thinks the primary unit is not there
|
|
0:11:00
|
what can happen is that it can promote itself to active
|
|
0:11:05
|
and then replicate the blank configuration over
|
|
0:11:09
|
but worst case scenario if you already saved your config, you just need to reload and then its going to come back to the working state
|
|
0:11:17
|
Hey, so lets check this again show failover I want to see that
|
|
0:11:20
|
that both of the links are working
|
|
0:11:24
|
So now lets go ahead and change the polling time, so we can see if we can get to converge a little bit faster
|
|
0:11:31
|
So we will say globally
|
|
0:11:34
|
and we could see I want to do this on the other device, not this one
|
|
0:11:37
|
is this is the standby unit
|
|
0:11:44
|
in global config we will say
|
|
0:11:47
|
failover poll time
|
|
0:11:53
|
and lets try to do this as quickly as possible lets say
|
|
0:11:56
|
200 milli seconds
|
|
0:11:59
|
and the whole time is
|
|
0:12:02
|
one second
|
|
0:12:05
|
now I am not 100% sure that this platform can actually take the failover going that fast
|
|
0:12:11
|
Ah, we will see what the result of it is, lets say the failover poll time for the interfaces as well
|
|
0:12:17
|
is 500 milli seconds
|
|
0:12:21
|
whole time is
|
|
0:12:23
|
5 secs, so we will give it essentially the minimum values
|
|
0:12:27
|
we show run failover
|
|
0:12:30
|
Now the lot of the times when you are deal with these type of control plane timers
|
|
0:12:34
|
this might acutally be a bad idea
|
|
0:12:37
|
to set it to the minimum values
|
|
0:12:39
|
because then the platform spends too much time trying to do these keep alives
|
|
0:12:44
|
and if it get saturated with some other work
|
|
0:12:47
|
may be the some applications inspections that will time up the cpu
|
|
0:12:51
|
if it cannot respond within 1 the second
|
|
0:12:55
|
you may failover when you don't want to
|
|
0:12:58
|
and then you end up causing more of a problem than had you just waited longer with the timers
|
|
0:13:04
|
but lets try this anyway, we will see whats the result of it is
|
|
0:13:07
|
So now if I save my config on asa1
|
|
0:13:11
|
ideally we should see this replicate it down
|
|
0:13:14
|
to the standby one
|
|
0:13:16
|
so if we show run failover
|
|
0:13:19
|
we could see now those new timers are there which is what we want to see
|
|
0:13:25
|
we will look at show failover
|
|
0:13:28
|
this unit is the secondary one
|
|
0:13:30
|
its in the standby state and its ready
|
|
0:13:33
|
to takeover the active state if it needs to
|
|
0:13:39
|
So now lets say that there is a failure
|
|
0:13:41
|
between router4 and asa1
|
|
0:13:45
|
So this link ethernet0/1 on asa1
|
|
0:13:49
|
this is physically going to switch1's port
|
|
0:13:54
|
fastethernet 0/13
|
|
0:13:57
|
so on router4
|
|
0:13:59
|
I am going to send some pings out to router3
|
|
0:14:02
|
will shut this port down
|
|
0:14:04
|
and then see exactly how many packets its losing
|
|
0:14:07
|
and then ideally it should resume them when
|
|
0:14:11
|
asa2 is going to take over the active status
|
|
0:14:14
|
so lets ping router3
|
|
0:14:17
|
172.16.34.3
|
|
0:14:21
|
the time out is 1 second
|
|
0:14:23
|
so for every dot thats going to 1 second of convergence time
|
|
0:14:28
|
and then I will give it a high repeat count
|
|
0:14:34
|
now on switch1
|
|
0:14:37
|
again thats attached to asa1's
|
|
0:14:40
|
ethernet0/1
|
|
0:14:44
|
this link is going to fail
|
|
0:14:48
|
and we can see it drop 1 packet
|
|
0:14:52
|
so it was less than 2 seconds to failover then with the
|
|
0:14:57
|
with the timer set to the lowest
|
|
0:15:00
|
Now again whether you want actually do this or not
|
|
0:15:04
|
really depends on how much load the device is under
|
|
0:15:07
|
so if we look at asa2 we see now its the active device
|
|
0:15:11
|
if we show failover
|
|
0:15:15
|
this host is active, even though its the secondary one
|
|
0:15:19
|
and the reason why is that on the primary device
|
|
0:15:22
|
its inside interface failed
|
|
0:15:30
|
if we look at the show connections
|
|
0:15:33
|
we can also see that the state information
|
|
0:15:37
|
was exchanged from the primary down to the secondary
|
|
0:15:43
|
so not only are we doing
|
|
0:15:45
|
active standby with the transparent firewall but we are also doing it
|
|
0:15:49
|
with statefull failover
|
|
0:15:57
|
so again when we look at this configuration, there is really not that many commands that go along with it
|
|
0:16:02
|
the only difference between this one and the routed mode
|
|
0:16:06
|
would be that we would specify the ip addresses on the interfaces
|
