Cisco VIRL (Virtual Internet Routing Lab)

List of supported features for IOSv:
Features likely to work for IOSv:
HSRP, VRRP, GLBP, EZVPN, QoS, LISP, ZBFW, Performance Monitor• Read more for IOSv: of supported features for IOSvL2:
Layer-2 forwarding (auto-config’d), Switchport (auto-config’d), 802.1q trunk, 802.1q VLANs (auto-config’d), Spanning Tree (auto-config’d), Port-Channel (Pagp and Lacp), 802.1x passthrough, Port-ACLs, Dynamic Arp Inspection, DHCP Snooping, IP device tracking, Switched Virtual Interfaces, Layer-3 forwarding over SVIs, Routing protocol support, VTP v1-3, PVST, QoS, Inter-VLAN routing, VLAN Access Maps (VACLs / access control lists for VLANs), ACL functionality for both layer2 and layer3 protocol packets, Dynamic Trunking Protocol support, Switchport protected mode

• Read more for IOSvL2:

List of supported features for IOS-XRv:

• Read more for IOS-XRv:

List of supported features for NX-OSv:
802.1x, AAA, AMT, BGP, CDP/LLDP, EIGRP, FHRP-HSRP, GLBP, VRRP, ICMP, IGMP, IPv4, IPv4/6, IPv6, ISIS, L3 Routing Protocols, LDAP, LISP, MLD, MSDP, NTP, OSPF, PIM/PIM6, Radius, RIP, SNMP, Syslog, TACACS+, VRF, XML/Netconf, NX-API

• Read more for NX-OSv:

UPDATE 4/10/2016: NX-OSv (Titanium) – end of development
The NX-OSv virtual machine image that has been provided with VIRL is based on the Titanium development platform, using the NXOS operating system with a hardware model based on the NEXUS 7000-series platform.
The virtual machine provides Layer-3 and management-plane features taken from the 7.x.x version of the NXOS operating system. As many of you will be aware, Layer-2 switching functionality is not present in the image.
Development efforts in the NXOS operating system, are now strongly focused on moving to the next generation NXOS as implemented today on the NEXUS 9000-series platform. To that end, Layer-2 and Layer-3 feature development is aligned toward the next generation NXOS virtual machine platform. As a result, there are no plans to deliver Layer-2 switching features on the NX-OSv (Titanium) virtual machine platform.
The first virtual machine platform using the next generation NXOS operating system will be NXOSv9000, which is expected to be available on VIRL in late 2016.

List of supported features for CSR1000v:
Features likely to work for CSR1000v:
HSRP, VRRP, GLBP, EZVPN, QoS, LISP, ZBFW, Performance Monitor

• Read more for CSR1000v:

List of supported features for ASAv:

• Read more for ASAv:


GNS3 Version 1.3: What’s new for Open-Source Routers

In 2014, the GNS3 development team launched a successful Kickstarter crowdfunding campaign to support development of a major new release, version 1.0, which was released in October that same year. I was happy to support the Kickstarter campaign and now I am finally getting around to taking a look at the new version of GNS3.

In this post, I will look at the new version 1.3.7 of GNS3 and evaluate how it works with emulated routers and hosts running open-source software.

What’s new in GNS3 1.x

Below, I describe the new GNS3 1.x features in two sections. The first section summarizes new GNS3 features that are relevant to all users of GNS3, including those who will use GNS3 to emulate networks consisting of routers and hosts running open-source software. The second section summarizes new features relevant only those who are running commercial router images in GNS3.

New features relevant to open-source routers

The following list summarizes new features in GNS3 1.x that improve the experience of working with open-source router and host software in GNS3 1.x, and are also applicable to all users of GNS3 1.x.

  • GNS3 1.x is supported by a new web site,
  • GNS3 1.x has updated graphical user interface styles.
  • GNS3 1.x now same configures all the types of virtual machines used in GNS3 in the GNS3 Preferences function: Dynamips (IOS), IOU, QEMU and VirtualBox.
  • GNS3 1.x now consists of two separate components: a GNS3 GUI and a GNS3 server.
  • GNS3 1.x adds VirtualBox linked clone support, which allows more efficient disk usage when using open-source routers running in virtual machines created by VirtualBox.
  • GNS3 1.x offers improved support for QEMU virtual machines.
  • GNS3 1.x users can now configure simulated PCs from within the GNS3 GUI.

New features for proprietary routers

The following list summarizes new features in GNS3 1.x that improve the experience of working with commercial router and switch software in GNS3 1.x. We do not discuss these features in this post.

  • Ethernet switching support improvements for Cisco switching technology.
    • An Etherswitch router may now be any router type that supports the NM-16ESW module.
    • GNS3 1.x now supports Cisco IOS on Unix (Cisco IOU) machines.
  • Instead of a single device template per OS image, GNS3 1.x now supports multiple device templates per OS Image.
  • GNS3 1.x will now import and export config files in a contextual device menu.
  • GNS3 1.x now automatically exports IOS configs when a project closes.

New GNS3 web site

The new GNS3 web site offers resources and forums for GNS3 users. The old GNS3 web site,, now just points to the new web site.

GNS3 Software and GNS3 Appliances may be downloaded from the new GNS3 web site.

How to get appliances

Appliances are located in the Download section of the GNS3 web site. Go to the bottom of the Download page and click on the relevant link listed under the heading, Appliances.

Open-source router and host appliances are available as either QEMU appliances or VirtualBox appliances.

Updated graphical user interface

The GNS3 1.x gaphical user interface is still mostly the same as in GNS3 0.8.7. All the same tools and panels are there. But the graphical design of the icons and color schemes have changed. Also, the annoying “GNS3 Jungle” panel has been added.


GNS3 1.3 supports three styles for the GNS3 GUI. The default style is “Charcoal”, which is a dark theme with “Flat”-style icons. The “Classic” theme uses the same flat icons but is a lighter style. The “Legacy” style replicates the look and feel of the GNS3 0.8 GUI.

New GNS3 1.x user interface styles

To change GUI styles, use the menu command: Edit → Preferences. Select style from the Style selector box. I chose the “Classic” style.

GNS3 Jungle panel

The new GNS3 1.3 GUI includes a panel that displays news from the GNS3 Jungle web forum. It also seems to display adds. The “GNS3 Jungle” panel cannot be closed. This is very annoying.

To reduce this annoyance, you can move the GNS3 Jungle panel out of the main GUI window as a separate window. Click on the panel and drag it away from the GUI to a corner of your computer screen where hopefully you can ignore it.


The other panels in the GUI, other than the topology window, are called docks. You can hide docks by click on the “X” icon in the upper right-had corner of each dock panel. You can restore them from the menu command: View → Docks.

You can also drag the dock panels on top of one another so they will appear as one tabbed panel, as seen below.

GNS3 1.3 with docks configures as tabs in the GNS3 GUI

GNS3 server support

GNS3 1.3 comes with two packages, the Server and the GUI. By default, they would both be installed in the same computer. The GNS3 1.x server manages emulators such as Dynamips, VirtualBox or Qemu/KVM. The GNS3 1.x GUI controls the server.

While the default configuration is to run both components on the same system, the Server and GUI may instead be installed on different computers. Once the GNS3 Server is started on its computer, start the GNS3 GUI on the other computer and enter in the network address and TCP port of the server in the GUI client appropriate preferences page. Then the GNS3 GUI controls the GNS3 Server to which it is connected. While it was possible to run hypervisors on a remote server in GNS3 0.8, this his new GNS3 1.x feature simplifies the procedure.

Configure GNS3 1.3 GUI to connect to the correct GNS3 server settings

Using a remote server may be required for complex network emulations that require a powerful computer, or if one is running GNS3 in a cloud compute environment while managing it from a local PC.

VirtualBox linked clones

A VirtualBox linked clone creates a duplicate VM with a disk image that is linked to a parent disk image of the source VM, but only stores the differences in data compared to the source disk image. This save disk space on the host computer. Cloned disk images use copy-on-write technology to store the differences between disk images and link to the source disk image.

In GNS3 1.3, the user no longer needs to create all the virtual machines ahead of time in VirtualBox and in GNS3. This makes using VirtualBox VMs in GNS3 much easier. He or she can just create a base VM in VirtualBox and then configure it in GNS3’s VirtualBox Preferences. After that, each time the user drags the VM into the GNS3 topology window, it automatically creates a Linked Clone of the VM.

Using VirtualBox linked clones in GNS3 1.3

Linked clones work as follows. We may create one or more base VMs in VirtualBox. In this case, we created a router VM named “Quagga” and a host VM named “Linux-host” using the Core Linux appliances available on the GNS3 VirtualBox Appliances web page.

VirtualBox VMs created from GNS3 Core Linux  Appliances

Then we set up the new base VMs in GNS3 and check a box enabling linked clone support. These VMs form the “starting point” for the linked clones.

VB prefs more

Now when we drag a router “Quagga” or a host “Linux-host” into the GNS3 topology panel, GNS3 creates a linked clone based on the base VM and appends a number to the name so it is uniquely identifiable.

GNS3 topology

When the project is saved, changes to each VM’s linked filesystem are saved to a file in the project directory and, when the project is loaded again, each linked clones is created again in VirtualBox and each VM’s filesystem will have the updates saved from the previous session.

In a future post, I will cover more details about using VirtualBox VMs as open-source router nodes in GNS3.

VirtualBox preferences

GNS3 1.3 changes the way it supports VirtualBox virtual machines. The Preferences panel for VirtualBox now looks different, with a separate section for the VirtualBox VMs managed by GNS3.

Improvements to QEMU support in GNS3

GNS3 1.3 now supports up to 32 network interfaces on a QEMU VM, an increase from the 8 network interfaces supported in GNS3 0.8.7.

QEMU virtual machines in a network topology

Also, QEMU VMs may now be suspended and resumed.

Unfortunately, it is still not possible to capture traffic from an interface on a QEMU virtual machine. And, QEMU virtual machines still run slowly, except when the host operating system and the guest operating system are both Linux and are both using the same architecture (for example, AMD64).

In a future post, I will cover more details about using QEMU VMs as open-source router nodes in GNS3.

QEMU Preferences

GNS3 1.x changes the QEMU Preferences panel in the same way as the VirtualBox Preferences panel — as mentioned above — was changed.


VPCS Integration

GNS3 1.x now treats VPCS simulated PCs as devices just like VirtualBox and QEMU VMs, or Cisco and Juniper routers. It is a lot easier to use VPCS simulated PCs on GNS3 1.x, compared to GNS3 0.8.7.

VPCS PCs are shown in the Devices dock and can now be dragged to the topology window where they appear as individual PCs. A VPCS Multihost feature is available from the Tools menu, which runs the same way as VPCS used to work in GNS3 0.8.7.

VPCS simulated PCs now appear as PCs on the topology window

VPCS simulated PCs may be started and stopped like other devices. You can open a VPCS PC console by double-clicking on the PC in the topology window. VPCS support is configurable in the GNS3 Preferences dialogue boxes.

ASA Failover and Redundancy

The following must be identical:

  1. Model (5505 or 5510 or 5520, etc)
  2. Amount of RAM
  3. Number of Interfaces (should be the same type as well)
  4. External Modules (CSC-SSM or IPS-SSM)
  5. Activation key with the same features
  • Failover mode
  • Encryption Level
  • Number of VPN peers

*** Same size Flash is not required ****


Active -> Responsibel for creating the state and translation tables, transferring the data packets and monitoring the other units.

Standby -> reponsible for monitoring the status of the active unit

The active and standby units are connected through a dedicated network link and send failover-related messages to each other. This connection, known as theFAILOVER CONTROL LINK is established over a dedicated failover LAN interface.

*** When failover occurs, the standby unit takes over the IP and MAC address that were used by the previous unit


  • Unit state (active or standby)
  • Network link status
  • Hello or keepalive messages (which are sent on all interfaces. This protocol uses IP 105)
  • MAC address exchange
  • Configuration replication from the active to standby

Conditions that trigger failover:

  • – Administrator has manually switched over from active to standby

-> “no failover active” on the active unit

-> “failover active” on the standby unit

  • – Active unit has lost power or crashed due to a hardware or software defect
  • – Standby unit has stopped receiving hello (or keepalive) packets on the failover interface
  • If 3 consecutive hello packets are missed, additional testing packets are sent to the remaining data-passing interfaces. If it still does not receive a response from the active unit, it assumes that a failure has occured and takes over
  • – The failover control link is down
  • The ASA sends additional testing packets to the remaining interfaces to determine where the peer’s control interface is also down. If the peer’s control interface is also down, then failover does not occure and the failed interface is marked as “Failed”. However, if the peer’s control interface is not down, then failover occurs because the standby unit is deemed healthier than the current active.
  • – The link state of the data-passing interface is down
  • The ASA marks the interface as “Failed” and initiates the failover process. Additionally, if the standby unit does not receive the hello packets for two consecutive polling period on an interface, the appliance goes through a series of additional tests on the interface to determine the root cause of the problem



  1. Link up/down tests -> status of the NIC. For example hardware port failure, unplugged cable and a failure on the hub or switch to which the interfaces are connected
  2. Network Activity Test -> All packets received are counted for up to 5 seconds. If any packets are received, the interface is marked as operational
  3. ARP Test -> ARP table is read for the last 10 entries. It sends an ARP request to those machines one at a time and then counts packets for up to 5 seconds. If any packets are received, the interface is marked as operational
  4. Broadcast Ping Test -> Sends a broadcast ping request and then counts all received packets for up to 5 seconds. If any packets are received, the interface is operational.

*** If both active and standby interfaces fail all tests, then both interfaces go into the “unknown state”. The interface with the unknown state do not count toward the monitored inteface failover limit ***

CONNECTION TABLE: Connection entries include the source and destination IP address, protocol used, current state of the connection, the interface to which it is tied and the number of bytes transferred.

In stateful failover, the active unit sends updates to the standby unit whenever these is a change in the state table. In this mode, the active unit sends stateful updates over a dedicated link to the the standby unit. When the standby unit becomes active, it does not need to build any connection entries because all the entries already exist in its database.

*** You can use the same physical interface for both failover control and stateful link. However it is not recommended if your appliances generate a lot of state updates. Additionally, it is recommended that you use the fastest interface as the stateful link and that the latency for the link should be less than 10 ms to avoid performance degradation. ****

What is not replicated in stateful failover:

  1. Uauth cache
  2. URL Filtering cache
  3. TCP Intercept
  4. SNMP Firewall MIB
  5. Routing Table
  6. State Info for SSM
  7. Phone Proxy sessions
  8. IPv6 sessions

Types of failover -> Device-level failover and interface-level failover

Device-level failover -> Active/Standby and Active/Active

Active/Standby Failover:

  • Active unit passes traffic
  • Standby unit monitors active unit
  • Both units send hello messages to monitor each other’s state



  1. When both are up and running, one unit assumes the role of active while the other unit assumes the standby role
  2. If both units boot up simultenously, the primary unit takes over the active role and the secondary goes into standby. The primary unit uses the active IP address and its MAC address as the Layer 3 and Layer 2 respectively. If failover occurs, the secondary keeps using the IP address and the primary’s MAC addrss as the active
  3. If one of the units boots up and detects an active failover unit, it goes into standby regardless of the primary or secondary designation
  4. If one of the units boots up and doesn’t detect an active failover unit, it goes into the active state regardless of its primary or secondary designation
  5. In case both appliances become active, the secondary changes its state to standby as soon as it discovers another active primary firewall while the primary remains active
  6. In case both units become standby, the primary changes its state to active, while the secondary remains standby after they detect each other’s state


  • Both units pass traffic actively
  • Only supported in multimode
  • Needs at least two user context to work properly
  • With stateful failover, both stand connection tables are replicated
  • Uses per-failover groups instead of per-context

**** It is recommended that you don’t oversubscribe the firewalls in active/active failover as during failover, one of the units has to pass all traffic

In active/active failover, it is possible that packets can leave one active unit and can return to the other active unit. The ASA implements a feature known as “asymmetric routing” to guide packets back to the context from which they originated.


  • Multiple ISPs or remote locations
  • Load-balancing or backup
  • ** only supported in multimode

If the asymmetric routing feature is enabled, the units restore asymmetric routed packets to the correct interface. The unit that sent the original SYN packet will replicate the connection table entry for the SYN packet to the standby unit over the stateful failover link. When the standby unit receives a packet but does not have an active connection, it checks other interfaces that are in the same asymmetric routing group for the corresponding connection. The Layer 2 information is written and forwarded to the original unit.


During traditional device-level failover, traffic gets disrupted even when stateful failover is enabled.


  • All incomplete TCP sessions
  • Routing tables (OSPF, RIP, EIGRP, etc)
  • Most Inspection Engines

Interface-level failover is used to avoid device-level switchover which is much more disruptive

Redundant interfaces are only supported in version 8.0 and higher.


  • All interfaces supported except Ma0/0 or Ma0/1
  • Up to 8 redundant interfaces
  • Network-related commands go on the redundant interface (nameif, security-level, IP address, etc)
  • Speed, duplex and shutdown go on the physical inteface
  • Link status for the physical is monitored by default
  • The standby interface drops all inbound packets and does not send any outbound packets
  • Interface stats on the redundant interface are a summation of the active and standby interfaces. As soon as a physical interface becomes a member of the redundant interface, its interface stats are cleared
  • Redundant interfaces use the MAC address of the first member physical interface unless you are manaully assigning a unique virtual MAC address on the redundant interface
  • *** The physical interfaces in the redundant interface must both be of the same physical type

*** The redundant interfaces can be configured with or without device-level failover


  1. Select the failover link
  2. Assign failover IP address
  3. Set the failover key (optional)
  4. Designate the primary unit
  5. Enable the stateful failover (optional)
  6. Enable failover globally
  7. Configure failover on the secondary unit

*** There can’t be a “nameif” command on an interface when configuring failover on it. Also “managment-only” needs to be removed.

You can use the “failover exec” command to send commands to the correct unit.

Failover link is used for failover control messages

*** If a failover key is not used, the active appliance sends all information in clear text, including the TCP/UDP states, the user credentials and VPN-related information.

You must designate the primary and secondary status through software configureation

If you want to use the failover control interface as the stateful failover link, use the “failover link” command without specifying the physical interface


Enable the failover control interface

“no shutdown”

Failover designation as secondary

“failover lan unit secondary”

  • Failover link interace
  • “failover lan interface failover Gi0/1”
  • Same failover interface IP addresses
  • “failover interface ip failover standby”
  • Same failover shared key
  • “failover key cisco 123”
  • Failover enable (enabled globally)
  • “failover”



  • Select the failover link
  • Assign failover interface IP addresses
  • Set the failover key (optional)
  • Desginate the primary unit
  • Enable stateful failover (optional)
  • Set up failover group
  • Assign failover-group membership
  • “join-failover-group”
  • Assign interface IP addresses
  • Set up asymmetric routing (optional)
  • Enable failover globally
  • Configure failover on the secondary

**** Connection and translation tables are sent over the stateful failover link. So is the asymmetric routing updates


  • Interface-policy
  • MAC address
  • polltime
  • Preempt
  • Primary
  • Replication
  • Secondary

**** You must enable HTTP inspection to allow the HTTP traffic to work in the Active/Active setup with asymmetric routing

*** The Admin context is always a part of failover group 1. If you don’t explicitly map a context to a failover group, then it is automatically assigned to group 1.

*** The “http replication” command in the failover group overrides the global “http replication” command


Specify failover MAC address – in Active/Active failover, during failover, the IP addresses ad MAC addresses are swapped between units. The new active unit sends out a gratuitous ARP on the network. Using gratuitious ARP, the Layer 2 devices including bridges and switches, also update the CAM tables with the MAC address and the updated switch port information. The use of virtual MAC addresses is useful to avoid disruptions. With the virtual MAC address, the appliances do not need to swap the MAC address.


  • Use the virtual MAC cofigured on the interfaces (physical, logical or subinterface)
  • Use the “failover mac address ” configured globally
  • Use the burned-in MAC address


  • Use the virtual MAC at the interface level (physical, logical or subinterface)
  • Use the “mac address” in the failover group configuration mode
  • Use the “mac address auto” in the System Execution Space
  • Use the burned-in MAC on the physical interface

**** In Active/Active setup, the failover “mac address” command has no effect if issues in the global configuration mode


  • Status of all interfaces monitored
  • If one of the interfaces fails to repsond, failover occurs

If you want to change this behavior, use the “criteria” tab in the ASDM

*** This setting is applied to the failover group in Active/Active


By default, ASA sends periodic keepalives (hello) packets to check the status of the peer failover unit. If the standby unit does not receive acknowledgement packets for the keepalives sent out, it initiates a failover only if it deems itself healthier than the current unit.

Two types of failover hello messages -> Unit (sent every second)

-> Interface (every 15 seconds)

In active/active failover, unit failover timers are changed in the System Execution Space. The interface failover timers are changed in the failover group policy.

*** When an ASA is configured for failover, whether active/standby or active/active, it monitors the status of all the main physical interfaces that have a “nameif” and an IP address configured.

*** Interface monitoring is disabled by default on all subinterfaces until you explicitly enable it.

*** Stateful failover is mandatory for a zero-downtime software upgrade.

Cisco ASA Firewall Active / Standby Failover

The Cisco ASA firewall is often an important device in the network. We use it for (remote access) VPNs, NAT/PAT, filtering and more. Since it’s such an important device it’s a good idea to have a second ASA in case the first one fails.

The ASA supports active/standby failover which means one ASA becomes the active device, it handles everything while the backup ASA is the standby device. It doesn’t do anything unless the active ASA fails.

The failover mechanism is stateful which means that the active ASA sends all stateful connection information state to the standby ASA. This includes TCP/UDP states, NAT translation tables, ARP table, VPN information and more.

When the active ASA fails, the standby ASA will take over and since it has all connection information, your users won’t notice anything…

There are a number of requirements if you want to use failover:

  • Platform has to be the same: for example 2x ASA 5510 or 2x ASA 5520.
  • Hardware must be the same: same number and type of interfaces. Flash memory and RAM has to be the same.
  • Same operating mode: routed or transparent mode and single or multiple context mode.
  • License has to be the same..number of VPN peers, encryption supported, etc.
  • Correct license. Some of the “lower” models require the Security Plus license for failover (the ASA 5510 is an example).

In this lesson we’ll take a look how to configure active/standby failover. Here’s the topology I will use:

ASA1 ASA2 Active Standby Failover

We have two ASA firewalls…ASA1 and ASA2. ASA1 will be the active firewall and ASA2 will be in standby mode. Their Ethernet 0/0 interfaces are connected to the “INSIDE” security zone while the Ethernet 0/1 interfaces are connected to the “OUTSIDE” security zone. The Ethernet 0/3 interface in the middle will be used to synchronize connection information for failover. R1 and R2 are only used so we can generate some traffic.


We will start with the failover interface on ASA1. Make sure it’s not shut:

ASA1(config)# interface Ethernet 0/3
ASA1(config-if)# no shutdown

And then we configure this ASA to be the active (primary) device:

ASA1(config)# failover lan unit primary

Now we will configure Ethernet 0/3 to be the failover interface:

ASA1(config)# failover lan interface FAILOVER Ethernet 0/3 
INFO: Non-failover interface config is cleared on Ethernet0/3 and its sub-interfaces

And we’ll tell the ASA to use this interface for stateful failover:

ASA1(config)# failover link FAILOVER Ethernet 0/3

We can now configure the IP addresses on the failover interface. We need to use a dedicated subnet for this:

ASA1(config)# failover interface ip FAILOVER standby

ASA1 (active) will use IP address and ASA2 (standby) will use Now we can enable failover:

ASA1(config)# failover

Failover is now configured on ASA1. Let’s configure some security zones and IP addresses on the “normal” Interfaces:

ASA1(config)# interface Ethernet 0/0
ASA1(config-if)# no shutdown
ASA1(config-if)# nameif INSIDE
ASA1(config-if)# ip address standby
ASA1(config)# interface Ethernet 0/1
ASA1(config-if)# nameif OUTSIDE
ASA1(config-if)# ip address standby

The ASA requires something that triggers the failover mechanism. An interface that fails is a good trigger. When the inside or outside interface fails, we should failover. By default all physical interfaces are monitored but let me show you the command anyway:

ASA1(config)# monitor-interface INSIDE
ASA1(config)# monitor-interface OUTSIDE

This is all we have to configure. We can now configure ASA2:

ASA2(config)# failover lan unit secondary
ASA2(config)# failover lan interface FAILOVER Ethernet 0/3
ASA2(config)# failover link FAILOVER Ethernet 0/3
ASA2(config)# failover interface ip FAILOVER standby
ASA2(config)# failover

We configure ASA2 to be the standby device, its Ethernet 0/3 interface will be used for failover and we configure the active and standby IP addresses. Let’s enable this interface so that the ASA’s can talk with each other:

ASA2(config)# interface Ethernet 0/3
ASA2(config-if)# no shutdown

This is what you will see on ASA1 and ASA2:

Beginning configuration replication: Sending to mate.
End Configuration Replication to mate
Failover LAN became OK
Switchover enabled
Configuration has changed, replicate to mate.

State check detected an Active mate
Beginning configuration replication from mate.
End configuration replication from mate.

Switching to Standby

Failover is up and running, the configuration has been replicated from ASA1 to ASA2. Whenever you make changes to the configuration, you only have to save on the active ASA and it will be replicated to the standby ASA:

ASA1# write memory 
Building configuration...
Cryptochecksum: 690a4de8 e1179377 f8eabae6 8cf5242e 

3372 bytes copied in 3.240 secs (1124 bytes/sec)

After saving the configuration you will see this on the standby ASA:

ASA1# Cryptochecksum: 5739e8f7 32355bc0 a97e7dfa dd54ad71 

3373 bytes copied in 3.240 secs (1124 bytes/sec)

Let’s see if failover is really working shall we?


A simple method to verify if its working is to check the show failover command:

ASA1# show failover 
Failover On 
Failover unit Primary
Failover LAN Interface: FAILOVER Ethernet0/3 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 2 of 110 maximum
Version: Ours 9.1(5), Mate 9.1(5)
Last Failover at: 12:23:34 UTC Dec 19 2014
	This host: Primary - Active 
		Active time: 1664 (sec)
		slot 0: ASA5510 hw/sw rev (2.0/9.1(5)) status (Up Sys)
		  Interface INSIDE ( Normal (Monitored)
		  Interface OUTSIDE ( Normal (Monitored)
		slot 1: empty
	Other host: Secondary - Standby Ready 
		Active time: 31 (sec)
		slot 0: ASA5510 hw/sw rev (1.1/9.1(5)) status (Up Sys)
		  Interface INSIDE ( Normal (Monitored)
		  Interface OUTSIDE ( Normal (Monitored)
		slot 1: empty

Stateful Failover Logical Update Statistics
	Link : FAILOVER Ethernet0/3 (up)
	Stateful Obj 	xmit       xerr       rcv        rerr      
        General		90         0          89         0         
        sys cmd  	89         0          89         0         
        up time  	0          0          0          0         
        RPC services  	0          0          0          0         
        TCP conn 	0          0          0          0         
        UDP conn 	0          0          0          0         
        ARP tbl  	0          0          0          0         
        Xlate_Timeout  	0          0          0          0         
        IPv6 ND tbl  	0          0          0          0         
        VPN IKEv1 SA 	0          0          0          0         
        VPN IKEv1 P2 	0          0          0          0         
        VPN IKEv2 SA 	0          0          0          0         
        VPN IKEv2 P2 	0          0          0          0         
        VPN CTCP upd 	0          0          0          0         
        VPN SDI upd 	0          0          0          0         
        VPN DHCP upd 	0          0          0          0         
        SIP Session 	0          0          0          0         
        Route Session 	0          0          0          0         
        User-Identity 	1          0          0          0         
        CTS SGTNAME 	0          0          0          0         
        CTS PAC 	0          0          0          0         
        TrustSec-SXP 	0          0          0          0         
        IPv6 Route 	0          0          0          0         
        Logical Update Queue Information
                 	Cur 	Max 	Total
        Recv Q: 	0 	2 	91
        Xmit Q: 	0 	25 	482

This gives us a nice overview, you can see which device is active/standby but also what kind of stateful information is being exchanged. Let’s create some telnet traffic between R1 and R2 so that you can see that the firewalls are exchanging TCP connection information:

Trying ... Open

User Access Verification



When we check the show failover command again you will see this:

ASA1# show failover | include TCP
	TCP conn 	5          0          0          0

The connection information for my TCP session has been exchanged between the two ASAs. To really test our failover, we have to simulate a link failure. I’ll shut the interface on my switch that connects to the Ethernet 0/0 interface of ASA1:

SW1(config)#interface FastEthernet 0/14

Now you will see this on the active ASA:

Switching to Standby

And the standby ASA will tell us:

Switching to Active

Of course we can also check the show failover command again:

ASA1# show failover | include This host
	This host: Primary - Failed
ASA1# show failover | include This host
	This host: Secondary - Active

This proves that failover is working as it should, the standby ASA has become active after the link failure.

Active/standby failover does not use preemption. Once you enable the interface again, the currently active ASA will remain active.

That’s all there is for now! I hope you enjoyed this lesson, if you have any questions…feel free to leave a comment!

Download GNS3 Cisco IOS images

Download Cisco IOS image for GNS3

Hi dear all, that’s really a great to share my hard work  with you , After a lots of  hit in Google  I finally found trick to search Cisco IOS in free of course. So without talking much here are the link where you can free download Cisco ios image and you can upload or use this ios to the router and as well as in GNS3.
Small Collection of IOS Images.
{Updated}Big Collection of IOS Images (Almost All Cisco IOS Images)
Another Big Collection


(NEW)Cisco IOS Images Big Collection v3. **Direct HTTP Link** Binary files for GNS3
New Big IOS Collection

Back to top