Automate Where it Makes Sense…or… It Makes Sense to Automate?

Well certainly the layman would say to automate where it makes sense…but why not drive your network to a place where it makes sense to automate? Transform your network to one that’s conducive to automation, and the code will flow freely. Like the infamous Dan Bilzerian once said “Its all about setup”.

In many cases its useful to run a script to change several network devices, but I believe many stop here when it comes to network scripting, and fail to see the benefits of an “automate everything” culture. One time use scripts have their place, but driving a code based architecture …and culture…helps to drive opportunities for automation. This approach can be daunting up front, but the investment will pay off if executed properly.

The way I envision a successful transition to a code based network, would be to follow a three step process.

Standardize and document EVERYTHING. (Well that’s not very sexy, when do we start coding?)

This doesn’t seem very fun or exciting, but its absolutely critical. Picture this, you want to deploy some new SNMP configurations to your 2000 routers and switches, but many of them are different vendors, and have different AAA configurations. Congratulations, we’ve just hit the first non starter for automation. Get the picture?

You can consider the potential for automation a direct function of how standardized your network is. The documentation of these standards will translate directly to business rules to write code to.

Instantiate all configuration data as structured data.

Right now you probably have a configuration management platform that is backing up all of your configurations as text files. This is great, but we need to be able to have our code (or orchestration tools) act on this data in meaningful and efficient ways. The goal of this step is to take your configurations, and split them into variables, and parameterized templates. The below example was built for ansible, but a python script can apply the variables to the jinja2 template just as well.

Here’s my parameterized_template.yml:

{% if dhcp_server %}

{% for exclude in dhcp_exclusions %}
ip dhcp excluded-address {{ exclude['exclude_1'] }} {{ exclude['exclude_2'] }}
{% endfor %}

{% for pool in dhcp_pools %}
ip dhcp pool {{ pool['name'] }}
 network {{ pool['network'] }}
 default-router {{ pool['default_router'] }}
 dns-server {{ pool['dns_server'] }}
 option 60 ascii "{{ pool['option_60_ascii'] }}"
 option 43 hex {{ pool['option_43_hex'] }}
 lease 2
{% endfor %}

{% endif %}

{% if dhcp_server %}

{% for exclude in dhcp_exclusions %}

ip dhcp excluded-address {{ exclude['exclude_1'] }} {{ exclude['exclude_2'] }}

{% endfor %}

{% for pool in dhcp_pools %}

ip dhcp pool {{ pool['name'] }}

network {{ pool['network'] }}

default-router {{ pool['default_router'] }}

dns-server {{ pool['dns_server'] }}

option 60 ascii "{{ pool['option_60_ascii'] }}"

option 43 hex {{ pool['option_43_hex'] }}

lease 2

{% endfor %}

{% endif %}

Here’s my variables.yml:

dhcp_exclusions:
  - exclude_1: 10.35.63.1
    exclude_2: 10.35.63.24
  - exclude_1: 10.35.63.100
    exclude_2: 10.35.63.255
  - exclude_1: 10.35.64.1
    exclude_2: 10.35.64.24
  - exclude_1: 10.35.64.100
    exclude_2: 10.35.64.255
  - exclude_1: 10.35.65.1
    exclude_2: 10.35.65.24
  - exclude_1: 10.35.65.100
    exclude_2: 10.35.65.255

dhcp_pools:
  - name: native_wap
    network: "10.35.63.0 255.255.255.0"
    domain_name: us.ad.submarine.com
    default_router: 10.35.63.1
    option_60_ascii: "Cisco AP c1140"
    option_43_hex: f108.0ae6.0805
    dns_server: "10.35.203.132 172.20.0.41"

  - name: production_internal_vlan
    network: "10.35.64.0 255.255.255.0"
    domain_name: us.ad.submarine.com
    default_router: 10.35.64.1
    option_60_ascii: "Cisco AP c1140"
    option_43_hex: f108.0ae6.0805
    dns_server: "10.35.203.132 172.20.0.41"

  - name: guest_vlan
    network: "10.35.65.0 255.255.255.0"
    domain_name: us.ad.submarine.com
    default_router: 10.35.65.1
    option_60_ascii: "Cisco AP c1140"
    option_43_hex: f108.0ae6.0805
    dns_server: "208.67.222.222 208.67.220.220"

dhcp_exclusions:

- exclude_1: 10.35.63.1

exclude_2: 10.35.63.24

- exclude_1: 10.35.63.100

exclude_2: 10.35.63.255

- exclude_1: 10.35.64.1

exclude_2: 10.35.64.24

- exclude_1: 10.35.64.100

exclude_2: 10.35.64.255

- exclude_1: 10.35.65.1

exclude_2: 10.35.65.24

- exclude_1: 10.35.65.100

exclude_2: 10.35.65.255

dhcp_pools:

- name: native_wap

network: "10.35.63.0 255.255.255.0"

domain_name: us.ad.submarine.com

default_router: 10.35.63.1

option_60_ascii: "Cisco AP c1140"

option_43_hex: f108.0ae6.0805

dns_server: "10.35.203.132 172.20.0.41"

- name: production_internal_vlan

network: "10.35.64.0 255.255.255.0"

domain_name: us.ad.submarine.com

default_router: 10.35.64.1

option_60_ascii: "Cisco AP c1140"

option_43_hex: f108.0ae6.0805

dns_server: "10.35.203.132 172.20.0.41"

- name: guest_vlan

network: "10.35.65.0 255.255.255.0"

domain_name: us.ad.submarine.com

default_router: 10.35.65.1

option_60_ascii: "Cisco AP c1140"

option_43_hex: f108.0ae6.0805

dns_server: "208.67.222.222 208.67.220.220"

Manage your structured data like an application, not a network.

This is where I get to throw buzzwords like Agile and DevOps out there. These terms are used to describe methodologies for software development. I won’t go into the details of each one on this post, but the takeaway is that your network is now an application. Each configuration snippet should be treated as a software feature.

For example, we want our application to to use ISP2, when ISP1 is down. How should we code this feature and deploy it? How can we unit test this code? How can we roll it back if the deployment goes bad? How can we canary test the deployment to reveal issues early with minimal business impact (fail early fail often)?

The coming posts will aim to answer all of these questions…so stay tuned!

Leave a Reply Cancel reply