Before we begin (optional section)

Before we go on, I’d like to put a little disclaimer about terms being used in this post. TDD, and its counterpart BDD, are well-known and accepted practices in development world. Both rely on the assumption that tests will be written before the code and will drive code development. This seemingly unnatural approach became extremely popular with the advent of Agile and is still being widely used, specifically in web development. What I will be developing will look more like a BDD rather than TDD, since it will be testing overall system behaviour rather than small self-contained portions of configuration. However, I still prefer to use the term TDD, firstly, because it’s easier to understand for people from a non-dev background, secondly, because it’s very hard/impossible to test small portions of network configuration (like routing protocol configuration), and lastly, since my tests will rely heavily on traceroutes, TDD may as well stand for Traceroute-Driven Development.

How will it work?

Traffic flow patterns, a.k.a. traffic paths is one bit of information that even higher-level management is able to comprehend. With a nice network diagram it is easy to show how low-latency traffic from Network_A will flow to Network_B through private VPN link on Router_X, while an internet-bound traffic will traverse a low-cost, high-latency Internet link on Router_Y. The TDD framework will use the same idea but in a text format

1. Testing of Primary Link
  1. From Router1 to Router2 via Router4, Router5
  2. From Router2 to Router1 via Router5, Router4
2. Testing of Backup Link
  1. From Router4 to Router1 via Router3
  2. From Router4 to Router2 via Router7

This format can be understood by both network engineers and their clients and can be used as a basis for network acceptance and verification testing. At the same time it follows a strictly defined format which can be parsed, processed and actioned by a program. I’ll show how to write an Ansible module that parses this text, runs a traceroute and checks if the test was successful.
These tests can also be used during regression testing of the network each time network configuration changes. This kind of verification offers a much more reliable result compared to visual examination of traceroute results and routing tables.

Step-by-step procedure

This is how I see the whole development process now (before I started). Some section may get added/removed in the process. I’ll try to write at least one post a week aiming to complete the series in under one month.

1. Development environment setup
2. Getting started with Ansible for Cisco IOS
3. Developing Ansible library to gather facts from Cisco devices
4. Developing Ansible library to verify test scenarios

A quickstart guide for those interested to see the final product in action.