Created by Samir Parikh on June 14, 2019
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 bf_session: host: localhost name: local_batfish - name: Initialize the example network bf_init_snapshot: network: example_network snapshot: example_snapshot snapshot_data: ../networks/example overwrite: true - name: Retrieve Batfish Facts bf_extract_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:
nodes: as1border1: ⇐ Device name BGP: ⇐ BGP Process configuration attributes Router_ID: 1.1.1.1 Neighbors: ⇐ BGP Neighbor configuration attributes 10.12.11.2: Export_Policy: - as1_to_as2 Local_AS: 1 Local_IP: 10.12.11.1 Peer_Group: as2 Remote_AS: '2' Remote_IP: 10.12.11.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 GigabitEthernet0/0: Access_VLAN: null Active: true All_Prefixes: - 1.0.1.1/24 Allowed_VLANs: '' Description: null Incoming_Filter_Name: null MTU: 1500 Native_VLAN: null OSPF_Area_Name: 1 OSPF_Cost: 1 ... Primary_Address: 1.0.1.1/24 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 bf_validate_facts: 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 bf_assert: assertions: - type: assert_reachable name: Confirm web server is reachable for HTTPS traffic received on Gig0/0 on as1border1 parameters: startLocation: '@enter(as1border1[GigabitEthernet0/0])' headers: dstIps: '2.128.0.101' ipProtocols: 'tcp' dstPorts: '443' - type: assert_filter_denies name: Confirm that the filter 101 on as2border2 drops SSH traffic parameters: filter_name: 'as2border2["101"]' headers: 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. To stay up-to-date about what’s happening at Intentionet fill in the box at the bottom of the page.
