Automate Where it Makes Sense\u2026or\u2026 It Makes Sense to Automate?<\/p>\r\n\r\n\r\n\r\n
Well certainly the layman would say to automate where it makes sense\u2026but why not drive your network to a place where it makes sense to automate? Transform your network to one that\u2019s conducive to automation, and the code will flow freely. Like the infamous Dan Bilzerian once said \u201cIts all about setup\u201d.<\/p>\r\n\r\n\r\n\r\n
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 \u201cautomate everything\u201d culture. One time use scripts have their place, but driving a code based architecture \u2026and culture\u2026helps to drive opportunities for automation. This approach can be daunting up front, but the investment will pay off if executed properly.<\/p>\r\n\r\n\r\n\r\n
The way I envision a successful transition to a code based network, would be to follow a three step process.<\/p>\r\n\r\n\r\n\r\n
This doesn\u2019t 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\u2019ve just hit the first non starter for automation. Get the picture?<\/p>\r\n\r\n\r\n\r\n
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.<\/p>\r\n
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.<\/p>\r\n
Here’s my parameterized_template.yml:<\/p>\r\n
{% if dhcp_server %}\r\n\r\n{% for exclude in dhcp_exclusions %}\r\nip dhcp excluded-address {{ exclude['exclude_1'] }} {{ exclude['exclude_2'] }}\r\n{% endfor %}\r\n\r\n{% for pool in dhcp_pools %}\r\nip dhcp pool {{ pool['name'] }}\r\n network {{ pool['network'] }}\r\n default-router {{ pool['default_router'] }}\r\n dns-server {{ pool['dns_server'] }}\r\n option 60 ascii \"{{ pool['option_60_ascii'] }}\"\r\n option 43 hex {{ pool['option_43_hex'] }}\r\n lease 2\r\n{% endfor %}\r\n\r\n{% endif %}\r\n<\/pre>\r\nHere’s my variables.yml:<\/p>\r\n
dhcp_exclusions:\r\n - exclude_1: 10.35.63.1\r\n exclude_2: 10.35.63.24\r\n - exclude_1: 10.35.63.100\r\n exclude_2: 10.35.63.255\r\n - exclude_1: 10.35.64.1\r\n exclude_2: 10.35.64.24\r\n - exclude_1: 10.35.64.100\r\n exclude_2: 10.35.64.255\r\n - exclude_1: 10.35.65.1\r\n exclude_2: 10.35.65.24\r\n - exclude_1: 10.35.65.100\r\n exclude_2: 10.35.65.255\r\n\r\ndhcp_pools:\r\n - name: native_wap\r\n network: \"10.35.63.0 255.255.255.0\"\r\n domain_name: us.ad.submarine.com\r\n default_router: 10.35.63.1\r\n option_60_ascii: \"Cisco AP c1140\"\r\n option_43_hex: f108.0ae6.0805\r\n dns_server: \"10.35.203.132 172.20.0.41\"\r\n\r\n - name: production_internal_vlan\r\n network: \"10.35.64.0 255.255.255.0\"\r\n domain_name: us.ad.submarine.com\r\n default_router: 10.35.64.1\r\n option_60_ascii: \"Cisco AP c1140\"\r\n option_43_hex: f108.0ae6.0805\r\n dns_server: \"10.35.203.132 172.20.0.41\"\r\n\r\n - name: guest_vlan\r\n network: \"10.35.65.0 255.255.255.0\"\r\n domain_name: us.ad.submarine.com\r\n default_router: 10.35.65.1\r\n option_60_ascii: \"Cisco AP c1140\"\r\n option_43_hex: f108.0ae6.0805\r\n dns_server: \"208.67.222.222 208.67.220.220\"\r\n\r\n<\/pre>\r\n\r\n\r\n\r\n\r\n- Manage your structured data like an application, not a network.<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n
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\u2019t 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.<\/p>\r\n\r\n\r\n\r\n
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)?<\/p>\r\n
The coming posts will aim to answer all of these questions…so stay tuned!<\/p>\r\n","protected":false},"excerpt":{"rendered":"
Automate Where it Makes Sense\u2026or\u2026 It Makes Sense to Automate? Well certainly the layman would say to automate where it makes sense\u2026but why not drive your network to a place where it makes sense to automate? Transform your network to one that\u2019s conducive to automation, and the code will flow freely. Like the infamous Dan … <\/p>\n