Ansible Automation with Cisco ASA Multi-Context Mode

I thought I’d share my experience using Ansible and Cisco ASA firewalls in multi-context mode. Right from the beginning I had a few issues deploying the configuration and the switch between the different security context didn’t work well. I got the error you see below when I tried to run a playbook. Other times the changeto context didn’t work well and applied the wrong config:

[email protected]:~$ ansible-playbook -i inventory site.yml --ask-vault-pass
Vault password:

PLAY [all] ***************************************************************************************************************************************************************************

TASK [hostname : set dns and hostname] ***********************************************************************************************************************************************
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: error: [Errno 61] Connection refused
fatal: [fwcontext01]: FAILED! => {"changed": false, "err": "[Errno 61] Connection refused", "msg": "unable to connect to socket"}
ok: [fwcontext02]

TASK [interfaces : write interfaces config] ******************************************************************************************************************************************
ok: [fwcontext02]


After a bit of troubleshooting I found a workaround to limit the amount of processes Ansible use and set this limit to one in the Ansible.cfg. The default is five processes if forks is not defined as far as I remember.

inventory = ./inventory
forks = 1

In the example inventory file, the “inventory_hostname” variable represents the security context and as you see the “ansible_ssh_host” is set to the IP address of the admin context:

fwcontext01 ansible_ssh_host= ansible_ssh_port=22 ansible_ssh_user='ansible' ansible_ssh_pass='cisco'
fwcontext02 ansible_ssh_host= ansible_ssh_port=22 ansible_ssh_user='ansible' ansible_ssh_pass='cisco'

When you run the playbook again you can see that the playbook runs successfully but deploys the changes one by one to each firewall security context, the disadvantage is that the playbook takes much longer to run:

[email protected]:~$ ansible-playbook site.yml

PLAY [all] ***************************************************************************************************************************************************************************

TASK [hostname : set dns and hostname] ***********************************************************************************************************************************************
ok: [fwcontext01]
ok: [fwcontext02]

TASK [interfaces : write interfaces config] ******************************************************************************************************************************************
ok: [fwcontext01]
ok: [fwcontext02]

Example site.yml


- hosts: all
  connection: local
  gather_facts: 'no'

      username: "{{ ansible_ssh_user }}"
      password: "{{ ansible_ssh_pass }}"
      host: "{{ ansible_ssh_host }}"

    - interfaces

In the example Interface role you see that the context is set to “inventory_hostname” variable:


- name: write interfaces config
    src: "templates/interfaces.j2"
    provider: "{{ cli }}"
    context: "{{ inventory_hostname }}"
  register: result

- name: enable interfaces
    parents: "interface {{ item.0 }}"
    lines: "no shutdown"
    match: none
    provider: "{{ cli }}"
    context: "{{ inventory_hostname }}"
  when: result.changed
    - "{{ interfaces.items() }}"

After modifying the forks, the Ansible playbook runs well with Cisco ASA in multi-context mode, like mentioned before it is a bit slow to deploy the configuration if I compare this to Cumulus Linux or any other Linux system.

Please share your feedback.

Leave a comment

Setup Juniper ISG NSRP cluster

This post describes how to rebuild a Juniper NSRP Cluster if the first Juniper firewall is already configured for NSRP.
Please make sure you have the following prerequisite on both Firewalls.

Minimum software and hardware requirements for configuring Active / Passive NSRP:

  • Firewall’s with identical ScreenOS versions and license keys
  • Firewall’s with identical hardware
  • At least one interface on each firewall to be configured in the HA zone, which will be used for carrying control channel information

Configuration steps on the unconfigured Firewall.

Configure the Interface(s) for HA

If possible it makes sense to use the same Interface as used on the other device.

set interface ethernet0/4 zone HA

Configure the NSRP cluster id:

set nsrp cluster id 1

Both firewalls in the cluster must have the same Cluster ID number.

IMPORTANT: Other NSRP firewall pairs on the same segment must have a different set of cluster ids. Once the cluster id is set to a value, all the security interfaces will become part of the VSD-group 0, by default.

Configure cluster name for NSRP:

To define a single name for all cluster members, type the following CLI command:

set nsrp cluster name <name_str>
set nsrp vsd-group id <number> priority <number>

IMPORTANT: Make sure that the desired STANDBY firewall has a HIGHER priority configured than the preferred master. The firewall with the lower priority will be the active master in the cluster!

Physical connection:

Connect only the HA link cable to the interface that is configured for the HA zone.

Check the nsrp cluster status:

You can check the nsrp cluster status via the configuration GUI or via CLI.

To check the NSRP cluster status via GUI connect to the actual master and navigate to Reports > System Log > Event and search for NSRP related entries.

To check the NSRP cluster status via CLI please connect to the actual standby via console. You can check the status with the following command:

get nsrp cluster

Synchronize the configurations:

To synchronize the configuration from the active to the standby unit, please connect to the standby unit via console and execute the following command:

exec nsrp sync global-config save

The following will be reported shortly after you enter the above command:

load peer system config to save
firewall-B(B)-> Save global configuration successfully.
firewall-B(B)-> Save local configuration successfully.
firewall-B(B)-> Done.
firewall-B(B)-> Please reset your box to let cluster configuration to take effect!

Reset the Firewall:

IMPORTANT:  If you are prompted to save the configuration after you enter the reset command, answer n (No).  Then, proceed with the reboot by answering y (Yes).

firewall-B(B)-> reset
firewall-B(B)-> Configuration modified.  Save? [y]/n n
firewall-B(B)-> System reset.  Are you sure? y/[n] y

Check if the configurations are in sync:

Please execute the following command via CLI (console connection) on the backup firewall to check if the configurations are in sync:

exec nsrp sync global-config check-sum

Physical connection:

Please connect all other interfaces in the correct order to the standby unit.

Initial manual failover:

exec nsrp vsd-group 0 mode ineligible

Command reference:


get nsrp cluster Show cluster info
get nsrp monitor Show list of monitored interfaces
get nsrp vsd id 0 Show VSD id 0
get counters ha Show HA interface hardware counters
exec nsrp sync global-config check-sum Allows you to see if the cluster configs are syncronised
exec nsrp sync global save Sync’s the nodes.A reboot is required to complete the update.
exec nsrp vsd-group 0 mode Fails over the cluster. Run this command on the Master node.

Current Settings / Values

get envar get environment variable
get config get device configuration
get system get system information
get arp get arp cache
get route get routing table

Configuration re-sync Juniper ISG NSRP cluster

When the ISG cluster devices are correctly configured, they will start synchronizing the configuration. You can check if the configurations is in sync with the following command:

Cluster1:fw01(M)-> exec nsrp sync global-config check-sum     
configuration in sync

It can happen from time to time that the configuration of the cluster run out of sync:

Cluster1:fw01(M)-> exec  nsrp sync global-config check-sum 
Warning: configuration out of sync

To solve this issue, you should force the configuration sync (only on the backup device!!!!):

Cluster1:fw02(B)-> exec nsrp sync global-config save
load peer system config to save
Save global configuration successfully.
Save local configuration successfully.
Please reset your box to let cluster configuration take effect!

Cluster1:fw02(B)-> reset 
System reset, are you sure? y/[n] y
In reset ...

After the reboot of the backup device, the cluster should be fully operational and in sync.

Note : when the device prompts you to save the config, enter “n” (no)

Cisco ASA Virtual Context Mode

A single Cisco ASA or a cluster of two ASAs can be partition into multiple virtual firewalls known as security contexts. Each context has it’s own independent firewall, with its own security policy, interfaces, and administrators. These contexts are similar to having multiple standalone ASA devices. In combination with failover groups you can run a ASA cluster in active/active state and utilize both devices. Don’t forget when a failover happens that both failover groups need to run on a single device, keep enough ressources free on both devices and do not oversubscribe too much.

You have to look because there are limitation what features are supported in context mode. In version 8 is unsupport to use dynamic routing protocols, VPN, Threat Detection and Quality of Service. In version 9 are some changes and now dynamic routing protocols (not RIP or OSPFv3) and site-to-site IPsec VPNs are supported.

Here the configuration example how to set-up an Cisco ASA 5580 with 10 Gigabit Ethernet interfaces.

Enabling the context mode

mode noconfirm multiple

Physical interface configuration

interface GigabitEthernet4/2 
  description Failover 
  no shutdown 

interface GigabitEthernet4/3 
  description Stateful 
  no shutdown 

interface TenGigabitEthernet5/0 
  description TeTrunk-1st 
  no shutdown 

interface TenGigabitEthernet5/1 
  description TeTrunk-2nd 
  no shutdown 

Redundant interface configuration

interface Redundant 1
  description Redundant-Trunk
  member-interface TenGigabitEthernet5/0
  member-interface TenGigabitEthernet5/1

interface Redundant 1.800
  vlan 800
  description Link-Outside1

interface Redundant 1.801
  vlan 801
  description Link-Outside2

interface Redundant 1.100
  vlan 100
  description Link-Inside1

interface Redundant 1.101
  vlan 101
  description Link-Inside2

interface Redundant 1.500
  vlan 500
  description Link-Management

Here you need to start configuring the ASA failover settings. Like you see in the failover group configuration that I put group 1 to the primary device and group 2 to the seconday device for active/active set-up, when I create the virtual security context I join them to the different failover groups.

failover group 1
  polltime interface 1 holdtime 5

failover group 2
  polltime interface 1 holdtime 5


failover lan unit primary
failover lan interface failover GigabitEthernet4/2
failover interface ip failover standby

failover link stateful GigabitEthernet4/3
failover interface ip stateful standby

failover polltime unit 2 holdtime 6
failover polltime interface 1 holdtime 5
failover timeout 0:00:00

failover active

Failover configuration on the seconday device

interface GigabitEthernet4/2
  description Failover
  no shutdown

failover lan unit secondary
failover lan interface failover GigabitEthernet4/2
failover interface ip failover standby


copy running-config startup-config

Now you start to set-up the virtual contexts and add the interfaces I configured before

admin-context admin-asa-01

context admin-asa-01
  allocate-interface Redundant1.500 Link-Management
  config-url disk0:/admin-asa-01.conf
  join-failover-group 1

context virtual-asa-02
  allocate-interface Redundant1.800 Link-Outside1
  allocate-interface Redundant1.100 Link-Inside1
  config-url disk0:/virtual-asa-02.conf
  join-failover-group 1

context virtual-asa-03
  allocate-interface Redundant1.801 Link-Outside2
  allocate-interface Redundant1.101 Link-Inside2
  config-url disk0:/virtual-asa-03.conf
  join-failover-group 2

In the end save the configuration

write memory all

Afterwards you can change to the configured contexts with the command

changeto context virtual-asa-02

and start configuring your virtual firewalls.