Professional Documents
Culture Documents
Lab Guide
Version 4.1
November, 2010
2
Table of Contents
Introduction......................................................................................................................... 3
Log into the lab portal ........................................................................................................ 8
Exercise 1: Prepare for Launch Meeting.......................................................................... 10
Exercise 2: Verify Initial Connectivity (Baseline) ............................................................ 13
Exercise 3: Review ASA Configuration and Licenses....................................................... 32
Exercise 4: Configure Failover on the ASA Firewalls ..................................................... 42
Exercise 5: Fine-tune Failover Settings ........................................................................... 66
Exercise 6: Install ASDM and Review ASA Configuration .............................................. 68
Exercise 7: Test Failover on the ASA Firewall ................................................................ 84
Exercise 8: Disaster Recovery Backup ............................................................................. 96
Appendix A: Answers to Exercise Questions .................................................................. 103
Appendix B: Final ASA Configuration ........................................................................... 106
Introduction
Your company has successfully deployed an ASA 5510 firewall upgrade for Inside.local,
a mid-size organization that employs 500 people and is growing. They are very happy
with the deployed ASA and are calling upon you for your skills and knowledge on the
ASA to help deploy a second ASA in a high availability configuration.
They have the second ASA onsite already racked and cabled with the factory default
configuration. They have created Vlans for the Inside and DMZ interfaces for both ASAs
and are using an unmanaged switch for the state and failover interfaces. There is a
scheduled outage to allow you to complete this deployment and for testing.
The customer is ready for you to do your ASA magic!
Key requirements:
You must provide the customer a logical topology diagram.
You need to outline the key differences between an active/active and
active/standby design and why you chose an active/standby design.
Configure the second ASA in the cluster and minimize any downtime.
Create a test plan to test your new high availability design.
Ensure this deployment aligns with future initiatives.
Provide post-installation recommendations.
Logical Topology
The diagram below depicts the logical L3 and L2 topology of the network for this lab.
Please note that the UserPCs and Servers are VMware images and that if you shut down
any of these machines you will lose all changes. Please ensure that you use restart,
if/when needed. Unless otherwise specified, all logins are administrator and passwords
are cisco123, all in lower case, except for pc-inside.inside.local where the username is
johndoe and the password is cisco123.
L3
192.0.2.50
PC outside
Internet
ISP Router
.1
192.0.0.0/24
HA-State
192.168.60.4/30
.5 .6
HA-Failover
e0/3 e0/3
192.168.60.0/30 .253
.254
e0/0 e0/0
.1 .2
Primary Mgt Secondary
Mgt
Active ASA Standby
ASA
e0/1 .254 .253 e0/1
.254 e0/2 192.168.1.0/24 e0/2 .253
v600
.10
.1
lo0
10.0.255.1/32
Core-sw1
.1 .1
10.0.1.0/24 10.0.2.0/24
v10 v20
PC Inside
DC inside Exchange inside
L2
PC outside
Virtual Internet
ISP Router
ISP Router
e0/0 e0/0
e0/3 HA-State e0/3
v500 v600
v500 v600
g1/0/8 g1/0/7
g1/0/5 g1/0/6
PC Inside DMZ inside
g1/0/1 g1/0/2
v20 v20
Disclaimer
This lab is intended to be a sample of one way to configure the ASA to provide the
customer the required connectivity. There are many ways the ASA can be configured,
which vary depending on the situation and the customer’s goals/requirements. Please
ensure that you consult all current official Cisco documentation before proceeding with a
design or installation. This lab is primarily intended to be a learning tool and may not
necessarily follow best practice recommendation at all times in order to convey specific
information.
ASA asa831-6-k8.bin
ASDM asdm-631.bin
AVC AnyConnect-win-2.5.0217-k9.pkg
VPN Client vpnclient-win-msi-5.0.07
Prerequisite knowledge
This lab is the second module in a series of ASA labs created by the ASTEC team. This
lab assumes that you have taken our first lab, ASA 8.3 Basics and New Features, or have
viewed the recorded tech session or have equivalent basic understanding of IP
technologies and the Cisco ASA 5500. It is suggested that you take the modules in the
recommended order unless you are already familiar with the information in the previous
modules.
If you reload your ASA during the lab, it will initialize in ROMMON.
Should this happen, issue the following commands:
In this lab, we use the Cisco ASA 5510 appliance which has 1 Gigabyte of memory.
Your proctor will provide you with the login and pod number information. Type this into
the Username/Password box and click Login. Also write this information below.
Username __________________________
Password __________________________
Pod number __________________________
Click Continue.
On the ASTEC Student Portal web page, when launching the web bookmarks to access
PC-Inside and PC-Outside, please click the Open in a new Browser icon.
Hopefully most of this design was discussed as part of the pre-sales process and the
detailed design meetings that occurred in order to prepare an accurate statement of work.
Now the time has arrived to start the project. The Inside.local engineering team wants a
kickoff meeting to review exactly what you will be doing and provide you with any final
details you need to begin. The main focus of the meeting is to explain the difference
between active/active and active/standby high availability designs and explain some
testing that you will execute to validate the high availability design.
Lab Task: Review the diagram below and think through how it could be used to
storyboard the project for the customer.
192.0.2.50
PC outside
Internet
ISP Router
.1
192.0.0.0/24
HA-State
192.168.60.4/30
.5 .6
HA-Failover
e0/3 e0/3
192.168.60.0/30 .253
.254
e0/0 e0/0
.1 .2
Primary Mgt Secondary
Mgt
Active ASA Standby
ASA
e0/1 .254 .253 e0/1
.254 e0/2 192.168.1.0/24 e0/2 .253
v600
.10
.1
lo0
10.0.255.1/32
Core-sw1
.1 .1
10.0.1.0/24 10.0.2.0/24
v10 v20
PC Inside
DC inside Exchange inside
In discussions with Inside, they agreed and purchased a second ASA firewall and are
looking for your recommendation on a deployment design. You have reviewed their
network topology, services and future requirements.
You explained to Inside’s network manager the two high availability designs,
active/active and active/standby, and although both designs are valid and have pros and
cons, you tell the network manager you decided on an active/standby design, and
explained the reason for this decision.
The main reason for active/standby is the current limitation in active/active to support
VPN connections.
When the security appliance is configured for Active/Active Stateful Failover, you cannot
enable IPsec or SSL VPN. Therefore, these features are unavailable. VPN failover is
available for Active/Standby failover configurations only.
You verified that the two ASA firewalls are the same model with the same module, have
the same amount of RAM, and are running the same version of code.
Open a command prompt and issue the ipconfig command. There is a cmd prompt
shortcut on the desktop.
From pc-inside, launch Internet Explorer and browse to the DMZ web server.
In the browser, type http://192.168.1.10.
From the desktop, double click the VPN icon, highlight the Inside-ipsec profile and
Connect.
Once you are connected, open a command prompt and issue the following ping
commands:
ping 10.0.2.10 DC
ping 10.0.2.100 Exchange
ping 192.168.1.10 DMZ
From pc-outside, launch Internet Explorer and browse to the DMZ web server.
In the browser, type http://192.168.1.10.
Return to pc-inside and from the desktop, launch the OoB Console Access shortcut.
Select your pod number from the Pod Number drop-down box and select ASA 2 – ASA
High-Availability from the Content Package drop-down and click Access Console Map.
The console map is a customized webpage with hotspot icons. Clicking on these icons
launches a telnet session to a terminal server where the device console cables are
connected.
Click each of the ASA icons so that you can connect via the console. This will launch a
Telnet application which will connect to the ASA console ports.
Click in each of the telnet windows and press Enter twice in each of the terminal boxes.
You now have accessed the primary and the secondary ASAs. Remember that the
primary ASA is Inside.local’s production firewall. Notice the hostname is asa-lab.
The secondary ASA is Inside.local’s new ASA firewall and has the default hostname of
ciscoasa.
Now minimize the consoles web page, but leave the two Telnet console windows open.
This will make it easier to look at both ASA firewalls and to view the commands, and
compare and sync between both. It will also allow you to see what happens during
failover testing.
The enable password for the primary ASA (with the hostname asa-lab) is cisco123.
There is no enable password set for the secondary ASA. If you are prompted for a
password, just press Enter. Remember that this firewall has the factory default
configuration.
If the ASA firewalls are not in enable mode, type enable and press Enter. Type cisco123
as the password for the primary ASA and leave the password blank for the secondary
ASA.
Contact your proctor if you have any issues or if any of the pings fail before proceeding.
Switch to the other ASA firewall and type enable if you’re not already in enable mode.
The factory default setting does not have an enable password so just press Enter when
prompted for the password.
In your discussion with Inside’s manager, you explained the cabling recommendations
and requirements for the ASA failover and state interfaces.
You can use any unused Ethernet interface on the device as the failover link; however,
you cannot specify an interface that is currently configured with a name. The LAN
failover link interface is not configured as a normal networking interface; it exists for
failover communication only. This interface should only be used for the LAN failover
link (and optionally for the Stateful Failover link).
Using a switch, with no other device on the same network segment (broadcast
domain or VLAN) as the LAN failover interfaces of the ASA firewalls
Using a crossover Ethernet cable to connect the ASA firewalls directly, without
the need for an external switch
However, when you use a crossover cable for the LAN failover link, if the LAN interface
fails, the link is brought down on both peers. This condition may hamper troubleshooting
efforts because you cannot easily determine which interface failed and caused the link to
come down.
With the exception of the ASA 5505, all the models support Stateful Failover.
To use Stateful Failover, you must configure a Stateful Failover link to pass all state
information. You have three options for configuring a Stateful Failover link:
You can use a dedicated Ethernet interface for the Stateful Failover link.
If you are using LAN-based failover, you can share the failover link.
You can share a regular data interface, such as the inside interface. However, this
option is not recommended.
If you are using a dedicated Ethernet interface for the Stateful Failover link, you can use
either a switch or a crossover cable to directly connect the units. If you use a switch, no
other hosts or routers should be on this link.
When Stateful Failover is enabled, the active unit continually passes per-connection state
information to the standby unit. After a failover occurs, the same connection information
is available at the new active unit. Supported end-user applications are not required to
reconnect to keep the same communication session.
Inside’s manager would like to know precisely what information gets replicated to the
standby firewall. You help the manager understand this by sharing the following table:
After this discussion, the manager agrees to use a dedicated unmanaged layer 2 switch for
the state and failover interfaces for both ASA firewalls. The manager also had the
network engineer create two new Vlans to be used by the ASA’s Inside and DMZ
interfaces on their internal managed layer 3 switch.
As with all good engineers, you believe in verifying configurations and want to verify
this Vlan configuration before you proceed with your ASA configurations.
From the OoB Console Access page that you minimized earlier, click the Core-sw1 3750
console icon so that you can connect via the console. This will launch a Telnet
application which will connect to the 3750 switch console.
Here we can see that the primary ASA’s inside interface is in Vlan 500 connected to
interface G1/0/5, and the DMZ interface is in Vlan 600 connected to interface G1/0/6.
We can also see that the standby ASA’s inside interface is also in Vlan 500 connected to
interface G1/0/8, and the DMZ interface is in Vlan 600 connected to interface G1/0/7.
If you have closed your ASA console sessions, you will need to re-launch them.
Click the ASA so that you can connect via the console, (refer to the red arrows). This will
launch a Telnet application which will connect to the ASA console.
From the console of the primary ASA, issue the show activation-key command.
In the table below, find your pod number and serial number. Record the activation key
that matches your serial number for the primary ASA.
From the console of the secondary ASA, issue the show activation-key command and
also retrieve the serial number for this firewall.
In the table above, find your pod number and serial number. Record the activation key
that matches your serial number for the secondary ASA.
What is your activation key? ________________________________________________
Now that we have the new activation keys for the ASA firewalls, let’s add these.
****** You may want to open Notepad from pc-inside and type the activation keys
in Notepad. This will enable you to copy and paste as needed.********
From the console of the primary ASA, type configure terminal to get into global
configuration mode.
Type activation-key followed by your activation key for the primary ASA from the table
above.
Let’s do the same steps for the secondary ASA. From the console of the secondary ASA,
press Enter for the password.
Type activation-key followed by your activation key for the secondary ASA from the
table above.
From the console of the primary ASA, type show activation-key detail.
Q3.3: Looking at the licensed features for this platform, how many SSL VPN Peers
licenses do we have?
As can be seen from the show activation-key detail command, we now have permanent
and time-based keys simultaneously enabled on this ASA.
Remember that you can tell the difference between the primary and secondary ASA by
looking at the firewall hostname. The primary ASA is called asa-lab while the secondary
ASA has the default name of ciscoasa.
Q3.7: Looking at the licensed features for this platform, how many SSL VPN Peers
licenses do we have?
Q3.9: Are there any time based licenses, if so, which feature?
As can be seen from the show activation-key detail command, we now have permanent
and time-based keys simultaneously enabled on this ASA also.
Let’s next start the high availability active/standby configuration and then return and see
if this changes the licensing.
From the console on the primary ASA, issue the show failover command. We can
confirm that failover has not been already configured.
Let’s verify the interfaces on this ASA. From the console of the primary ASA, type show
running-config interface.
Although we could use one interface for state information and failover, it is best practice
to use separate interfaces and that is what we will configure.
If you use the failover link as the Stateful Failover link, you should use the fastest
Ethernet interface available. If you experience performance problems on that interface,
consider dedicating a separate interface for the Stateful Failover interface.
Since we have two available interfaces, interface management 0/0 and interface Ethernet
0/3, we will use interface management 0/0 as the failover link and interface Ethernet 0/3
as the Stateful failover link.
From the console on the primary ASA, if the ASA is not in global configuration mode,
type configure terminal to enter global configuration mode.
Issue the interface management 0/0 command and then type no shutdown. This will
enable this interface.
Type the following commands. This is letting the ASA know that it will be the primary
firewall in the active/standby cluster, that we will be using the management 0/0 interface
as the failover interface, and that we have named this interface failover. And lastly, we
assigned the IP address to this ASA and its standby mate.
Let’s see if failover is now enabled. Type the show failover command.
Notice that failover is still marked as off. We are missing one more failover command.
We also see that we have not enabled Stateful failover. Issue the show failover state
command. This command will indicate that stateful failover is disabled.
Let’s continue and configure the Stateful failover interface and then we will complete the
final command to enable failover.
Type interface Ethernet 0/3 from global configuration mode and no shutdown.
Type the following commands to configure the Stateful failover on the primary ASA.
These commands are assigning a state of “link” to the Ethernet 0/3 interface and giving it
the name “state”. We configure the state IP address of this ASA and of the ASA’s
failover mate.
Issue the show failover command on the primary ASA. Let’s observe what this ASA
firewall is indicating here.
We can see this is the Primary unit and we can also see that the Secondary ASA has not
yet been detected. This is expected as we have not yet completed the secondary ASA
configuration.
Now let’s switch our focus to the secondary ASA. If you recall, this ASA is already
racked and cabled and is waiting to be configured.
From the console on the secondary ASA, type show failover. We can see that failover
has not been configured.
We need to see what interfaces are available so type show running-config interface.
As could be expected, only the Management 0/0 interface is configured with the
192.168.1.1 255.255.255.0 IP Address and its name is management. This is the default
factory setting. We also know that DHCP service is also enabled.
From global configuration mode on the secondary ASA, issue the following commands:
We could see that the primary ASA is trying to sync with the secondary ASA. This will
continue to fail until the secondary ASA is configured and is able to respond. The
secondary ASA configuration is very simple and straightforward. All we need to
configure is the failover interface. All the remaining configurations will be sent from the
primary ASA, including the state link interface information.
Let’s continue with the configuration. On the secondary ASA, type the following
commands:
Now we should see the primary ASA detect its mate and start with the configuration
replication. We should also see information regarding licensing. We will look into this
further in the next few steps. Another item to notice are the warning messages. It is
indicating: This command will not take effect until interface “inside” has been
assigned an IP address.
We need to investigate this further as this could potentially cause us problems in the
future.
Let’s issue the show failover command on the primary ASA firewall.
We can see that failover is now on. We can also see that this ASA (This host) is Primary
and is the active unit. The secondary ASA (Other host) is in a Standby Ready state.
We next see all the monitored interfaces listed on both the primary and secondary ASA
firewall, and that they are in a normal (waiting) state.
What is missing from our configuration that is causing the monitored interfaces to be in a
normal (waiting) state instead of just a normal state?
Looking at the show failover command, we see the secondary ASA has the IP address
0.0.0.0 for all its interfaces. We forgot to assign the standby IP addresses for the
secondary firewall!
We need to add this configuration onto the primary ASA and watch this sync with the
secondary firewall.
From global configuration on the primary ASA, type the following commands:
Let’s wait 10 seconds and be certain that the two ASA firewalls have synchronized their
configs and re-issue the show failover command.
This looks much better! All the monitored interfaces are in a normal state. We can see
that both ASA firewalls have their IP addresses and can now communicate with each
other over all monitored interfaces.
We did not configure the Stateful failover interface on our secondary ASA.
From the console on the secondary ASA, let’s issue the show failover state command
and confirm that these commands have been replicated between the two ASA firewalls.
Success! The two ASA firewalls have synchronized and we can see that Stateful failover
is now enabled.
Type show failover. We now can see that failover is enabled, that this is the secondary
unit, and we can also see that this ASA (This host) is in Standby Ready mode and that the
primary (Other host) is Active.
Let’s next review our interfaces. Type the show running-config interface command.
The management0/0 and Ethernet 0/3 interfaces, which are used for failover and state
replication, do not have any IP addresses associated with them.
Let’s next look at the licenses and spend some time to understand this.
Older versions of adaptive security appliance software required that the licenses match on
each unit. Starting with Version 8.3(1), you no longer need to install identical licenses.
Typically, you buy a license only for the primary unit; for Active/Standby failover, the
secondary unit inherits the primary license when it becomes active. If you have licenses
on both units, they combine into a single running failover cluster license.
The license usage of the two units combined cannot exceed the failover cluster license.
For example, you have two ASA 5510 adaptive security appliances with 250 SSL VPN
sessions each; because the platform limit is 250, the combined license allows 250 SSL
VPN sessions and not 500 SSL VPN sessions.
For the ASA 5505 and 5510 adaptive security appliances, both units require the Security
Plus license; the Base license does not support failover, so you cannot enable failover on
a standby unit that only has the Base license.
From the primary ASA firewall, issue the show version command.
Q4.3: How many days are left for the time-based licensed features?
Let’s test this by deactivating the time based licenses and compare the outputs again.
From the console of the primary ASA and from global configuration mode, type
activation-key followed by your time-based activation key.
Q4.6: Looking at the output of the show version command, what has changed?
Q4.7: How many days are left for the time-based licensed features?
With the ASA firewalls now configured in an active/standby cluster, their licenses are
aggregated and combined. The primary ASA only has the permanent licenses enabled
while the secondary ASA has both time-based and permanent licenses enabled.
Let’s test further by deactivating the time-based license on the secondary ASA.
From the console of the secondary ASA, in global configuration mode, type activation-
key followed by your time-based activation key.
Return to the console of the primary ASA and issue the show version command again.
We now see no time-based licenses anymore. We are combining both permanent licenses
from the two ASA firewalls. However, since both perpetual licenses are for 250 SSL
VPN sessions and the ASA 5510 limit is 250 SSL VPN sessions, this becomes the
maximum number.
Let’s reactivate both time-based licenses on each ASA firewall and start our test plan.
From the console of each ASA and from global configuration, type activation-key
followed by your activation key.
The final step here is to save our configuration. Issue the write memory command on the
primary ASA. Notice how this gets synchronized with the secondary unit.
All information sent over the failover and Stateful Failover links is sent in clear text
unless you secure the communication with a failover key. If the ASA is used to terminate
VPN tunnels, this information includes any usernames, passwords and preshared keys
used for establishing the tunnels. Transmitting this sensitive data in clear text could pose
a significant security risk. We recommend securing the failover communication with a
failover key if you are using the ASA to terminate VPN tunnels.
From the console of the primary ASA and from global configuration, type the following
commands:
The failover exec mate command issues the failover key cisco123 command on the
secondary ASA.
Now the information sent over the failover and Stateful failover links will be secured.
This is recommended if the ASA will be terminating any VPN tunnels.
By default, the ASA does not replicate HTTP session information when Stateful Failover
is enabled. Because HTTP sessions are typically short-lived, and because HTTP clients
typically retry failed connection attempts, not replicating HTTP sessions increases system
performance without causing serious data or connection loss. The failover replication http
command enables the Stateful replication of HTTP sessions in a Stateful Failover
environment, but it could have a negative impact upon system performance.
From global configuration on the primary ASA, type failover replication http.
Click Run.
Click Install.
Let’s log onto the ASA’s inside IP address of 10.0.0.254 using the local administrator
account and cisco123 password.
Check Always trust content from this publisher and click Yes.
This is the home view in the ASDM. From here we can view lots of valuable information
such as Device information, Interface status and IP addressing, Traffic status, System
Resources status and Failover Status.
This will take us to the ASDM monitoring page. This is the equivalent of the show
failover CLI command. We can also see that we could execute commands from here,
such as changing the role of the ASA to Standby or Reloading the Standby unit.
Let’s next look at the licensing through the ASDM. Navigate to Configuration > Device
Management > Licensing > Activation Key.
Displayed here is the unit’s serial number, the activation keys for the permanent and
time-based licenses as well as the effective running license for the high availability
cluster.
Select the time-based license activation key and click Show license details.
We can see the license features, license value and duration for this activation key.
Click OK.
From the Activation Key page, click the Show information of license specifically
purchased for this device alone. This is how you would see what effective licenses are
enabled for this ASA firewall as opposed to the ASA firewall cluster.
Click OK.
We can graphically see that failover is enabled, and there is a failover shared key which
is used to secure the information sent through the failover and stateful failover interfaces.
We next can see all the IP addressing for the LAN Failover and State Failover interfaces
and that we enabled HTTP replication.
From here we can see that the three interfaces, Inside, Outside and DMZ are being
monitored. You can monitor up to 250 interfaces divided between all contexts.
The ASA determines the health of the other unit by monitoring the failover link. When a
unit does not receive three consecutive hello messages on the failover link, the unit sends
interface hello messages on each interface, including the failover interface, to validate
whether or not the peer interface is responsive. The action that the ASA takes depends
upon the response from the other unit. The following are possible actions:
If the ASA receives a response on the failover interface, then it does not fail over.
If the ASA does not receive a response on the failover link, but it does receive a
response on another interface, then the unit does not failover. The failover link is
marked as failed. You should restore the failover link as soon as possible because
the unit cannot fail over to the standby while the failover link is down.
If the ASA does not receive a response on any interface, then the standby unit
switches to active mode and classifies the other unit as failed.
You can configure the frequency of the hello messages and the hold time before failover
occurs. A faster poll time and shorter hold time speed the detection of unit failures and
make failover occur more quickly, but it can also cause “false” failures due to network
congestion delaying the keepalive packets.
Now select the Criteria tab. From here we can configure and fine-tune the interface
polling frequency and what criteria would trigger a failover.
In Active/Standby failover, the MAC addresses for the primary unit are always associated
with the active IP addresses. If the secondary unit boots first and becomes active, it uses
the burned-in MAC address for its interfaces. When the primary unit comes online, the
secondary unit obtains the MAC addresses from the primary unit. The change can disrupt
network traffic.
You can configure virtual MAC addresses for each interface to ensure that the secondary
unit uses the correct MAC addresses when it is the active unit, even if it comes online
before the primary unit. If you do not specify virtual MAC addresses the failover pair
uses the burned-in NIC addresses as the MAC addresses.
You cannot configure a virtual MAC address for the failover or Stateful Failover links.
The MAC and IP addresses for those links do not change during failover.
Close the ASDM. We will now start with the failover test.
From pc-inside, stagger the two ASA console sessions so that both are visible and issue
the show failover command on both ASA firewalls.
We see that the primary ASA is the Active unit and that the secondary is the Standby
unit.
From pc-outside, verify if the VPN session is still established (notice the lock icon in the
taskbar). If it is not, click Connect and provide johndoe/cisco123 as the
username/password when prompted.
Open a command prompt and ping the FTP server at 192.168.1.10 to verify connectivity.
Next open Internet Explorer and type ftp://192.168.1.10 in the Address bar and select the
FTP-file.cab file.
When prompted, click Save. Select the Desktop for the Save location.
While the 252 MB file is being copied to the desktop of pc-outside, return to the pc-
inside PC and issue the no failover active command from the primary ASA or failover
exec mate no failover active from the secondary ASA.
*****Caution*****
Only typing no failover tells the ASA not to participate in a failover cluster. This
would in fact break the failover cluster and cause the secondary ASA to become
active and assume the primary’s ASA IP addresses. But because the primary ASA is
still up, you would get IP addressing conflicts.
There is an alternative command to use on the secondary ASA which switches the
ASA active role. From the secondary ASA, issue the failover exec mate no failover
active command. This is a safer command to send to the ASA.
The failover exec mate command indicates to the ASA that this command is for its
failover mate.
OR
2- Using the failover exec mate no failover active command on the secondary ASA
Notice how this forces an immediate failover without a confirmation prompt. The
primary unit indicates that it is now in a standby state and that the secondary unit has
taken over the active role.
Let’s return to pc-outside and look at the FTP file transfer. We see that the VPN
connection is still established and the file copy is still going.
Let’s toggle between pc-outside, where the FTP file is being copied, and the pc-inside to
see the status of the ASA firewalls and their Active/Standby status.
We can see that the roles have reversed between the primary and secondary ASAs as far
as who is Active and who is in Standby mode.
We also see that the FTP file transfer never got interrupted and the VPN session never
got disconnected.
Returning to the console of the primary ASA firewall, issue the show failover command.
We can see the primary is now in Standby Ready mode. Issue show failover from the
console of the secondary ASA also.
We want to reset the primary ASA as the Active unit. This could be accomplished in two
ways as seen previously: we could console to the secondary ASA and issue the no
failover active command, or from the primary ASA console, issue the failover exec
mate no failover active command. If you recall from earlier, the failover exec mate
command is sending the command to the ASA’s mate, so if issued from the primary
ASA, then this command is sent to the secondary ASA.
Again, we can see the Active and Standby roles being switched between the two ASA
firewalls.
It is always an excellent idea to back up the configuration data. ASDM has a backup
utility built-in that will create a ZIP file on your PC with the configuration and any other
data required to recover the ASA in a failure. This is also excellent data to present to the
customer as part of final documentation for the project along with the ASA activation
key.
From ASDM, click Tools and select Backup Configurations from the drop-down menu.
This opens a Backup Configurations dialog box. Notice we have several options for what
we want to back up using this backup wizard. What is different between running a
backup using this tool as opposed to backing up your startup-config to a TFTP server?
What about SSL VPN configurations, how have you backed these up in the past? You
could select Backup All and this would grey out all the boxes and back up all your ASA
files and configs.
Let’s click the Browse Local… button and browse to the Desktop. Type ASA-backup in
the File name. Click Select File.
Click Backup.
We see the progress bar as all the selected items get backed up to the desktop.
Now what would happen if we selected to backup CSD image or Plug-ins but we had
none of these on the Flash?
We see below that we would get a Failure message that those items are not available.
Click OK.
Now we have a process to restore configs or any other relevant file to our ASA!
Q2.1: What version of code is running on this ASA? The ASA is running the 8.3(1)6
version of code.
Q2.2: How many SSL VPN Peers are licensed? The license is for 250 SSL VPN Peers.
Q2.3: How many UC Phone Proxy Sessions are licensed? There are 24 UC Phone
Proxy installed licenses.
Q2.4: Are there any time-based licenses? If so, which features? No, there is no time-
based license on this ASA.
Q2.6: What version of code is running on this ASA? The ASA is running the 8.3(1)6
version of code. We need identical version of code to enable high availability.
Q2.7: How many SSL VPN Peers are licensed? The license is for 250 SSL VPN
Peers.
Q2.8: How many UC Phone Proxy Sessions are licensed? There are 24 UC Phone
Proxy installed licenses.
Q2.9: Are there any time-based licenses? If so, which features? No, there is no time-
based license on this ASA.
Q3.1: What is the serial number for your ASA? Answers will vary on each ASA.
Q3.2: What has changed on the licensing? We now have permanent and time based
licenses on this ASA.
Q3.3: Looking at the licensed features for this platform, how many SSL VPN Peers
licenses do we have? We still have 250 SSL VPN licenses.
Q3.4: How many UC Phone Proxy sessions? We now have 50 UC Phone Proxy
licenses.
Q3.5: Are there any time-based licenses, if so, which feature? There are now several
time-based licenses, including Botnet Traffic Filter, SSL VPN Peers, and Intercompany
Media Engine.
Q3.6: How many days are left? This answer will vary.
Q3.7: Looking at the licensed features for this platform, how many SSL VPN Peers
licenses do we have? There are 250 SSL VPN Peers licenses.
Q3.8: How many UC Phone Proxy sessions? We now have 74 UC Phone Proxy
sessions licenses.
Q3.9: Are there any time based licenses, if so, which feature? There are now several
time based licenses, including Botnet Traffic Filter, SSL VPN Peers, and Intercompany
Media Engine.
Q3.10: How many days are left? This answer will vary.
Q4.1: How many unused and available interfaces do we have? We have two
available unused interfaces.
Q4.2: Looking at the output of our command, what has changed? The ASA license
has changed because it is aggregating the licenses from the secondary ASA up to the
platform’s maximum capacity.
Q4.3: How many days are left for the time-based licensed features? Answer will
vary but it will aggregate the numbers of the primary and secondary ASA.
Q4.4: How many UC Phone Proxy Sessions licenses are available? There is 100 UC
Phone Proxy sessions license, which is the maximum number for an ASA 5510. Each
ASA had 24 permanent and 50 time based UC Phone Proxy licenses. Cumulatively, this
numbers exceeds 100 so the ASA caps this number at 100.
Q4.5: Are any feature licenses exceeding the platform’s capacity? Yes, the SSL VPN
Peers and the UC Phone Proxy sessions now exceed the platform’s maximum capacity.
Q4.6: Looking at the output of the show version command, what has changed? By
deactivating one of the ASA firewall’s time-based licenses, we are decrementing that
value from the high availability cluster’s running license configuration.
Q4.7: How many days are left for the time-based licensed features? This answer will
vary but we are decrementing the value by one for the time-based licenses.
Q4.8: How many UC Phone Proxy Sessions licenses are available? Once deactivating
one of the time based license, the cumulative permanent licenses of 24 from each ASA
and the 50 time based licenses on 1 of the ASA firewalls makes this number now at 98.
Q4.9: Are any feature licenses exceeding the platform’s capacity? Yes, the SSL VPN
Peers is exceeding the ASA 5510 maximum capacity and gets capped at 250.
Primary ASA
subscribe-to-alert-group environment
subscribe-to-alert-group inventory periodic monthly
subscribe-to-alert-group configuration periodic monthly
subscribe-to-alert-group telemetry periodic daily
profile Inside
destination address email johndoe@inside.local
destination transport-method email
subscribe-to-alert-group configuration export full
Cryptochecksum:d41d8cd98f00b204e9800998ecf8427e
: end
Secondary ASA
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-password *****
ldap-login-dn cn=administrator,cn=users,dc=inside,dc=local
server-type microsoft
aaa authentication ssh console LOCAL
aaa authentication telnet console LOCAL
http server enable
http 10.0.0.0 255.0.0.0 inside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
service resetoutside
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac
crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac
crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac
crypto ipsec transform-set ESP-AES-192-MD5 esp-aes-192 esp-md5-hmac
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto ipsec transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac
crypto ipsec transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac
crypto ipsec transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set pfs group1
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set transform-set ESP-AES-128-SHA
ESP-AES-128-MD5
ESP-AES-192-SHA ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-MD5 ESP-3DES-SHA ESP-
3DES-MD5 ESP-DES-S
HA ESP-DES-MD5
crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map outside_map interface outside
crypto isakmp enable outside
crypto isakmp policy 10
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto isakmp policy 65535
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
telnet 10.0.0.0 255.0.0.0 inside
telnet timeout 5
ssh 10.0.0.0 255.0.0.0 inside
ssh timeout 5
console timeout 0
tls-proxy maximum-session 125
threat-detection basic-threat
threat-detection statistics host
threat-detection statistics port
threat-detection statistics protocol