A normal Layer3 Routing device, when receiving a packet on one of its ingress interfaces, first checks the destination IP address of the packet and then consults its routing table in order to forward the packet to the proper outgoing interface. This is the most basic operation of a router.

A stateful firewall (like the Cisco ASA), on the other hand, has a much more complicated work to do on an incoming packet. There are several steps and decision points that the packet has to go though before being allowed and forwarded by the firewall. This is called “conditional forwarding” because the packet must satisfy several rules and conditions before passing through the firewall.

The diagram below shows a simplified traffic flow of a packet through a Cisco ASA device:

As shown on the figure above, the packet coming from the Input Interface is being checked first if it is a part of an existing connection. If yes, it skips many of the intermediate steps and is only checked if it satisfies the Layer7 inspection rules.

Now, if the packet is a new connection, the firewall needs to store in its state table all the pertinent information of this new connection. Some of the information that is stored in the state table include the source and destination IP addresses, the source and destination port numbers, TCP sequence numbers etc. Since the packet is a new connection, it will have to go through several steps and checks before being forwarded to the output interface.

First the firewall checks if there is a Layer3 route for the destination address of the packet in the routing table. After that, it checks if the Access Control List (ACL) on the input interface allows the specific connection to pass. If this is ok, then it checks to see if there is a NAT rule configured for this specific connection. After that, the device verifies that any Layer7 inspection rules allow the specific connection. After all the previous steps have been satisfied successfully, only then the packet is allowed to exit the output interface.

Device virtualization is one of the most popular topics in IT industry today and Cisco has been supporting this concept in the majority of its network devices. In this article we will talk about Cisco ASA virtualization, which means multiple virtual firewalls on the same physical ASA chassis. Virtual ASA is also known as “Security Context”.

All firewall models (except ASA 5505) support multiple security contexts (i.e virtual firewalls). By default, all models support 2 security contexts without a license upgrade (except the ASA 5510 which requires the security plus license).

Each Context has it’s own configuration file and security policy, i.e. one context is completely isolated and does not depend on other contexts. The exception is the Admin Context, from which the whole ASA appliance (physical ASA) is managed and also is used to create the other Contexts. For enabling the creation of virtual contexts on the ASA appliance, we must switch to Multiple Context mode. In this mode some features are not available, like Dynamic Routing, IPSEC and SSL VPN, Multicast and Threat Detection. Let’s make a little discussion when multiple context mode is advisable and when it is not.

When would you want to use multiple security contexts?

●       If you want to use the active/active failover feature. Keep in mind that with active/active failover, you should not use more than half of the available bandwidth.
●       If you are an ISP and need to offer a different security context for each customer.
●       If you need to provide different security policies for various departments, users, or vendors and need to create a separate context for each one.
●       If you’d like to reduce hardware requirements by combining the functionality of multiple firewalls into one.

When should you not use multiple security contexts?

●       If you need to provide VPN services such as remote access or site-to-site VPN tunnels.
●       If you need to use dynamic routing protocols. With multiple context mode, you can use only static routes.
●       If you need to use QoS.
●       If you need to support multicast routing.
●       If you need to provide Threat Detection.

Now let’s consider an example of how Contexts are configured. In the scenario in our topology below, we have one ASA appliance and let’s create two contexts for two customers and one admin context for ASA appliance management.

Physical Topology Diagram:

Logical Topology Diagram:

Equipment Used in this LAB

ASA 5520 – Cisco Adaptive Security Appliance Software Version 8.0(3)

Catalyst 2960 – LAN Lite IOS.

Before starting configuration let’s check if it works in Single context mode or multiple context mode. As I’ve already stated, ASA appliance must be in multiple context mode for creating Security contexts.

!Verify ASA Operating mode.

asa # show mode

Security context mode: single

! enable multiple mode, for switching to this Mode, restart is required.

asa(config)#mode multiple

Then the following output is displayed. ASA Appliance converts the current running configuration into two files: a new startup configuration that comprises the system configuration, and “admin.cfg” that comprises the admin context (stored in the root directory of the internal Flash memory). The original running configuration is saved as “old_running.cfg” (in the root directory of the internal Flash memory).

WARNING: This command will change the behavior of the device
WARNING: This command will initiate a Reboot
Proceed with change mode? [confirm]
Convert the system configuration? [confirm]
!
The old running configuration file will be written to flash

The admin context configuration will be written to flash

The new running configuration file was written to flash
Security context mode: multiple

***
*** — SHUTDOWN NOW —
***
*** Message to all terminals:
***
***   change mode

Rebooting….
Booting system, please wait…

!after rebooting verify ASA Operation mode

asa# show mode
Security context mode: multiple

After restarting let’s start configuration of Contexts. First configure the admin context.

!Configure the admin context
asa(config)# admin-context admin
asa(config)# context admin
asa(config-ctx)# allocate-interface Management0/0
asa(config-ctx)# config-url disk0:/admin.cfg

!configure the Sub-interfaces for Customer1
interface GigabitEthernet0/1.11
vlan 11
interface GigabitEthernet0/0.21
vlan 21

!configure the Sub-interfaces for Customer2
interface GigabitEthernet0/1.12
vlan 12
interface GigabitEthernet0/0.22
vlan 22

Now we start creating contexts for Customer-1 and Customer-2 and allocate interfaces.

! Configure the Customer1 context shown as C1 in diagram.
asa(config)# context c1
asa(config-ctx)# allocate-interface gigabitethernet0/0.21
asa(config-ctx)# allocate-interface gigabitethernet0/1.11
asa(config-ctx)# config-url disk0:/c1.cfg

! Configure the Customer2 context shown as C2 in diagram.
asa(config)# context c2
asa(config-ctx)# allocate-interface gigabitethernet0/0.22
asa(config-ctx)# allocate-interface gigabitethernet0/1.12
asa(config-ctx)# config-url disk0:/c2.cfg

I will not describe how VLANs on Switches are configured. Let’s consider switching between Contexts. We can switch to any context from admin context, but we can’t switch from Customers context to anywhere.

! Let’s log in to Customer1 context. The syntax of command is the following:
changeto context <context name>

asa#changeto context  c1

! Let’s switch to system configuration mode. Switching to this mode is available only from Admin Context. In system configuration mode Contexts are created and resources are allocated.

asa#changeto system

The Cisco ASA failover configuration requires two identical security appliances connected to each other through a dedicated failover link and, optionally, a stateful failover link. The health of the active interfaces and units is monitored to determine if specific failover conditions are met. If those conditions are met, failover occurs. In case of Active/active configuration both Units carry traffic. For creating active/active Failover, configuring both ASA devices in Multiple context mode is required.

For ASA redundancy scenario the two devices must be the same models, must have the same number and type of interfaces and the same license is required. ASA 5505 and 5510 do not support active/active failover without license upgrade.

For active/active configuration, Failover Contexts and Failover groups need to be created. The Failover group is then applied to Primary or Secondary physical ASA unit. After this, the particular Failover group is applied to a Context. For example, primary unit is active ASA of Failover group1, but Secondary unit is Standby ASA of Failover group1. If primary ASA is out of order, Secondary ASA will become Active of Failover group1.

For explaining Active/Active Failover configuration in details, let’s do the following LAB.

Click on the image above for larger size diagram

Configuration

!Switch both ASA devices to multiple context mode.
asa(config)#mode multiple

!When ASAs are reloaded, connect them to each other with Ge0/2 and Ge0/3 ports. First start with the Primary Unit configuration. Before starting configuration, all interfaces must be in the up state.

!enable LAN Failover.
asa(config)#failover lan enable

!set this unit as primary.
asa(config)#failover lan unit primary

Determine Failover and State interfaces. These two interfaces can be the same physical interface if you don’t need to consume one extra port. In our example here we use two separate physical interfaces.
In this article, the “failover” (interface name for GigabitEthernet0/2) is used as a failover
interface.

!Define Failover Interface
asa(config)#failover lan interface failover Ge0/2

!assign IP address on Failover Interface. MUST be in same Subnet as the standby on the other unit.
asa(config)#failover interface ip failover 192.168.3.1 255.255.255.0 standby 192.168.3.2

In this documentation, the “state” (interface name for GigabitEthernet0/3) is used as a state
interface.

!Define stateful Failover interface
asa(config)#failover link state Ge0/3

!assign IP address on Stateful Failover interface
asa(config)#failover interface ip state 192.168.4.1  255.255.255.0 standby 192.168.4.2

!Create Failover groups, where Failover group1 will be the Primary, i.e. active on Primary Unit and Failover group2 will be the Standby on Primary Unit. Configure also HTTP Replication, after which occurs HTTP Connection state replication between active and Standby ASAs. Also determine Preempt Delay. Preempt Delay means in what time to regain role of Active after Fail Recovery.

asa(config)#failover group 1
asa(config-fover-group)#primary
asa(config-fover-group)#preempt 120
asa(config-fover-group)# replication http

asa(config)#failover group 2
asa(config-fover-group)#secondary
asa(config-fover-group)#preempt 120
asa(config-fover-group)# replication http

Now let’s start creating Contexts and assigning interfaces in each Context.

!Configure the admin context
asa(config)# admin-context admin
asa(config)# context admin
asa(config-ctx)# allocate-interface Management0/0
asa(config-ctx)# config-url disk0:/admin.cfg

!configure the Sub-interfaces
interface GigabitEthernet0/0.10
vlan 10
interface GigabitEthernet0/0.11
vlan 11
interface GigabitEthernet0/1.20
vlan 20
interface GigabitEthernet0/1.21
vlan 21

! Configure the  contexts
asa(config)# context c1
asa(config-ctx)# allocate-interface gigabitethernet0/0.10
asa(config-ctx)# allocate-interface gigabitethernet0/1.20
asa(config-ctx)# config-url disk0:/c1.cfg

asa(config)# context c2
asa(config-ctx)# allocate-interface gigabitethernet0/0.11
asa(config-ctx)# allocate-interface gigabitethernet0/1.21
asa(config-ctx)# config-url disk0:/c2.cfg

!Snap each Context to Failover Groups. If we don’t indicate Contexts to Failover Groups, each context will be in Group1 by default.
asa(config)# context c1
asa(config-ctx)# join-failover-group 1
asa(config)# context c2
asa(config-ctx)# join-failover-group 2

!Configure IP addresses on Context1.
asa#changeto context c1
asa/c1# show running-config interface
!
interface GigabitEthernet0/0.10
nameif outside
security-level 0
ip address 192.168.10.1 255.255.255.0 standby 192.168.10.2
!
interface GigabitEthernet0/1.20
nameif inside
security-level 100
ip address 192.168.20.1 255.255.255.0 standby 192.168.20.2

!Configure IP addresses on Context2.
asa#changeto context c2
asa/c2# show running-config interface
!
interface GigabitEthernet0/0.11
nameif outside
security-level 0
ip address 192.168.11.1 255.255.255.0 standby 192.168.11.2
!
interface GigabitEthernet0/1.21
nameif inside
security-level 100
ip address 192.168.21.1 255.255.255.0 standby 192.168.21.2
!

Now let’s start Secondary Unit configuration.

!Define Failover Interface
asa(config)#failover lan interface failover Ge0/2

!assign IP address on Failover Interface. MUST be in same Subnet as other unit.
asa(config)#failover interface ip failover 192.168.3.1 255.255.255.0 standby 192.168.3.2

!enable LAN Failover.
asa(config)#failover lan enable

!set this unit as secondary
asa(config)#failover lan unit secondary

With the above piece of configuration commands everything is completed and now let’s start checking.

Verification:

!verify Primary UNIT
asa# show failover

Failover On
Failover unit Primary
Failover LAN Interface: failover GigabitEthernet0/2 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 4 of 250 maximum
Version: Ours 8.2(1), Mate 8.2(1)
Group 1 last failover at: 05:12:14 tbilisi Dec 7 2010
Group 2 last failover at: 10:13:04 tbilisi Oct 24 2010

This host:    Primary
Group 1       State:          Active
Active time:    14536379 (sec)
Group 2       State:          Standby Ready
Active time:    0 (sec)

slot 0: ASA5520 hw/sw rev (2.0/8.2(1)) status (Up Sys)
c1 Interface outside (192.168.10.1): Normal
c1 Interface inside (192.168.20.1): Normal
c2 Interface outside (192.168.11.1): Normal
c2 Interface inside (192.168.21.1): Normal
slot 1: empty

Other host:   Secondary
Group 1       State:          Standby Ready
Active time:    1104 (sec)
Group 2       State:          Active
Active time:    14537266 (sec)

slot 0: ASA5520 hw/sw rev (2.0/8.2(1)) status (Up Sys)
c1 Interface outside (192.168.10.2): Normal
c1 Interface inside (192.168.20.2): Normal
c2 Interface outside (192.168.11.2): Normal
c2 Interface inside (192.168.22.2): Normal
slot 1: empty

Stateful Failover Logical Update Statistics
Link : state GigabitEthernet0/3.2 (up)
Stateful Obj    xmit       xerr       rcv        rerr
General         2405585244 0          75798262   188
sys cmd         1938317    0          1938317    0
up time         0          0          0          0
RPC services    0          0          0          0
TCP conn        1241561564 0          43443406   91
UDP conn        1157379296 0          28582971   84
ARP tbl         3799402    0          1833568    13
Xlate_Timeout   0          0          0          0
SIP Session     906665     0          0          0

Logical Update Queue Information
Cur     Max     Total
Recv Q:         0       49      90335543
Xmit Q:         0       7       2405585244

!verify Secondary unit

ASA# show failover

Failover On
Failover unit Secondary
Failover LAN Interface: failover GigabitEthernet0/2
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 4 of 250 maximum
Version: Ours 8.2(1), Mate 8.2(1)
Group 1 last failover at: 05:12:14 tbilisi Dec 7 2010
Group 2 last failover at: 10:13:03 tbilisi Oct 24 2010

This host:    Secondary
Group 1       State:          Standby Ready
Active time:    1104 (sec)
Group 2       State:          Active
Active time:    14537372 (sec)

slot 0: ASA5540 hw/sw rev (2.0/8.2(1)) status (Up Sys)
c1 Interface outside (192.168.10.2): Normal
c1 Interface inside (192.168.20.2): Normal
c2 Interface outside (192.168.11.2): Normal
c2 Interface inside (192.168.21.2): Normal
slot 1: empty

Other host:   Primary
Group 1       State:          Active
Active time:    14536486 (sec)
Group 2       State:          Standby Ready
Active time:    0 (sec)

slot 0: ASA5520 hw/sw rev (2.0/8.2(1)) status (Up Sys)
c1 Interface outside (192.168.10.1): Normal
c1 Interface inside (192.168.20.1): Normal
c2 Interface outside (192.168.11.1): Normal
c2 Interface inside (192.168.21.1): Normal
slot 1: empty

Stateful Failover Logical Update Statistics
Link : state GigabitEthernet0/3.2 (up)
Stateful Obj    xmit       xerr       rcv        rerr
General         111758344  0          1089580597 1046
sys cmd         1938331    0          1938331    0
up time         0          0          0          0
RPC services    0          0          0          0
TCP conn        73801356   0          581933209  113
UDP conn        34185062   0          501003000  886
ARP tbl         1833595    0          3799403    36
Xlate_Timeout   0          0          0          0
SIP Session     0          0          906654     11

Logical Update Queue Information
Cur     Max     Total
Recv Q:         0       7       1104118240
Xmit Q:         0       1       111758344

As we observed from above, active/active Failover is working and everything is as expected.

In January 2011 Cisco announced the newest Cisco ASA 5500 version 8.4. This release is coming after almost one year from the previous major release (version 8.3 was introduced in Feb-March 2010). You can upgrade to version 8.4 from any previous ASA version but you should know that if your current software release is older than 8.3, you will need memory upgrade as well (for ASA models 5505, 5510, 5520, 5540). Also, ASA version 8.4 requires ASDM GUI version 6.4 and later.

Most Notable Changes in new version

There are not many important changes compared to 8.3 and older except a couple of new features such as EtherChannel support, stateful failover with dynamic routing protocols, ability to see the top CPU processes etc. In more detail:

EtherChannel Support:

This is the biggest change in my opinion. With EtherChannel (supported on 5510 and higher models) you can group together up to eight physical interfaces which can form one EtherChannel group (up to 48 EtherChannel groups can be created). Therefore, you can have flexible incremental bandwidth since the EtherChannel technology allows bandwidth aggregation in multiples of 100Mbps, 1Gbps, or 10Gbps depending on the speed of the aggregated physical links. Also, resiliency and load balancing between the links is improved.

Stateful Failover with Dynamic Routing Protocols

In the past, when you had dynamic routing protocols configured on the device (such as OSPF, EIGRP) and the device was running in Active/Standby redundancy mode, any failover from the active to the standby device resulted in losing all dynamically learned routes. Now, routes that are learned through dynamic routing protocols on the active unit are now maintained in a Routing table on the standby unit. Upon a failover event, traffic on the secondary unit now passes with minimal disruption because routes are already known on the secondary standby unit.

Show Top CPU Processes

You can now monitor the processes running on the device and see how much CPU is consumed by each process. Use the command show process cpu-usage sorted.

Scalability Features

The new release increases some scalability features (such as number of Vlans, connections, contexts, Anyconnect VPN sessions etc) mainly on higher end models such as 5580, 5585-X.

The full additional feature list can be found on the official Cisco release notes here.