We are excited to announce Ansible modules for Batfish. Now, network engineers can invoke the power of Batfish within Ansible-based automation workflows.

Network automation is like a car with a powerful engine— it may get you places quickly, but does not guarantee that you’ll get there safely. Safe driving requires advanced collision prevention systems. Similarly, safe network automation requires pre-deployment validation which can ensure that network changes have the intended impact, do not cause an outage, and do not open a security hole, before the change is pushed to the network.

Batfish is a powerful pre-deployment validation framework. It can guarantee security, reliability, and compliance of the network by analyzing the configuration (changes) of network devices. It builds a detailed model of network behavior from device configurations and finds violations of network policies (built-in, user-defined, and best-practices).

Before today, using Batfish required writing Python code. Today’s release enables engineers to add validation to their Ansible playbooks without writing any Python code.

Let’s walk through a few example use cases to get a taste of how it can be done.

Use case I: Fact extraction

To extract “facts” (config settings) from configuration files, one can simply do the following.

 - name: Setup connection to Batfish service
    host: localhost
    name: local\_batfish

 - name: Initialize the example network
    network: example_network
    snapshot: example_snapshot
    snapshot_data: ../networks/example
    overwrite: true

 - name: Retrieve Batfish Facts
     output_directory: data/bf_facts
   register: bf_facts

The first task above establishes a connection to the Batfish server. The second command initializes the snapshot from provided data. The third command extracts facts from the snapshot and writes them to a directory. For each device Batfish will generate a file in the specified output directory.

The complete output can be found here. This snippet below highlights key facts that Batfish extracts from device configuration files:

 as1border1:                           ⇐ Device name
  BGP:                                 ⇐ BGP Process configuration attributes
    Neighbors:                         ⇐ BGP Neighbor configuration attributes
      - as1_to_as2
      Local_AS: 1
      Peer_Group: as2
      Remote_AS: '2'
  Community_Lists:                     ⇐ Defined Community-lists
  - as1_community
  Configuration_Format: CISCO_IOS      ⇐ Device Vendor & OS Type
  DNS: ...                             ⇐ DNS configuration attributes
  IP6_Access_Lists: []                 ⇐ Defined IPv6 access-lists
  IP_Access_Lists:                     ⇐ Defined IPv4 access-lists
  - '101'
  Interfaces:                          ⇐ Interface configuration attributes
      Access_VLAN: null
      Active: true
      Allowed_VLANs: ''
      Description: null
      Incoming_Filter_Name: null
      MTU: 1500
      Native_VLAN: null
      OSPF_Area_Name: 1
      OSPF_Cost: 1
      VRF: default
      VRRP_Groups: []
  NTP ...                              ⇐ NTP configuration attributes
  Route6_Filter_Lists: []              ⇐ Defined IPv6 prefix-list/route-filters
  Route_Filter_Lists:                  ⇐ Defined IPv4 prefix-list/route-filters
  - '101'
  Routing_Policies:                    ⇐ Defined routing policies/route-maps
  - as1_to_as2
  SNMP ...                            ⇐ SNMP configuration attributes
  Syslog ...                           ⇐ Syslog configuration attributes
  VRFs:                                ⇐ Defined VRFs
  - default
 version: batfish_v0                     ⇐ Batfish Fact model version

The functionality above uses the full-config (e.g., the output of “show run”) parsing capabilities of Batfish. While there are other tools available for parsing configs, Batfish is unique in being vendor neutral (unlike Cisco’s Parse Genie) and being able to parse full configurations instead of specific show commands.

Those advantages aside, the real power of Batfish is in being able to validate configs, with respect to both config settings and the resulting network behavior. We talk about these next.

Use case II: Fact validation

Validating that facts in device configs match what is expected is easy with the  bf_validate_facts module.

- name: Validate facts gathered by Batfish
    expected_facts: data/validation
  register: bf_validate

The task above will read facts from the specified folder and check that they match those in the initialized snapshot (done in a prior task). You can validate a subset of the attributes or all of them. The task will fail if any of the facts on any of the nodes does not match.

Use case III: Behavior validation

Beyond parsing configs, Batfish builds a full model of device configurations and resulting network behavior. This model can be validated in a range of ways, as follows:

 - name: Validate different aspects of network configuration and behavior
       - type: assert_reachable
          name: Confirm web server is reachable for HTTPS traffic received on Gig0/0 on as1border1
            startLocation: '@enter(as1border1[GigabitEthernet0/0])'
              dstIps: ''
              ipProtocols: 'tcp'
              dstPorts: '443'

        - type: assert_filter_denies
          name: Confirm that the filter 101 on as2border2 drops SSH traffic
            filter_name: 'as2border2["101"]'
            applications: 'ssh'

        - type: assert_no_incompatible_bgp_sessions
          name: Confirm that all BGP peers are properly configured

        - type: assert_no_undefined_references
          name: Confirm that there are NO undefined references on any network device

The task above includes four example assertions from our assertion library. The bf_assert module includes more, and based on community feedback, we’ll continue to make more of Batfish’s capabilities available this manner.

Today’s release makes network validating broadly accessible, furthering our commitment to helping network engineers build secure and reliable networks.

To help you get started with Batfish and Ansible, we have created a series of tutorials which can be found in this GitHub repository.

For feedback and feature requests, reach us via Slack or GitHub.