the worlds gone mad

The 3rd post in the ‘Automate Leaf and Spine Deployment’ series goes the through the variables from which the core fabric declaration is made and how this transposes into a dynamic inventory. This uses only the base and fabric roles to create the fabric ready for the service sub-roles (tenant, interface and route) to be deployed on top of the fabric at a later stage.

The 2nd post in the ‘Automate Leaf and Spine Deployment’ series describes process used for validating the variable files format and content. The idea behind this offline pre-validation is to catch any errors in the variable files before device configuration is attempted. Fail fast based on logic instead of failing halfway through a build. It wont catch everything but will eliminate a lot of the needless errors that would break a fabric build.

This series of posts will describe the process of deploying a NXOS Leaf and spine fabric in a declarative manner using Ansible. This came from my project for the IPSpace Building Network Automation Solutions course and was used in part when we were deploying leaf and spine fabrics in our Data Centers. I originally only planned to build tenants and do fabric validation but over time this has morphed into a full blown fabric deployment.

Napalm offers an easy way to configure and gather information from network devices using a unified API. No matter what vendor it is used against the input task and returned output will be the same. The only thing that will not be vendor neutral is the actual commands run and configuration being applied. This post documents experiences of trying to replace the whole configuration on NXOS using Napalm with Ansible.

Jinja template inheritance uses the concept of block to define sections of the base parent template that can be overridden by sections from a child template. An extends statement links the child template to the parent template so that when the child template is rendered the parent template is also rendered and the block statement contents inherited by the parent template.

Link-state advertisements (LSA) are used to communicates the router’s local routing topology to all other local routers in the same OSPF area. There are 11 types of LSAs although only the 6 most commonly used ones are described in this post.

I am currently studying to rectify my CCIE and it is at these times that I realise there is so much I have studied and learnt but forgotten. There are many cool things I come across that I think at the time are useful features that I need to remember, but unfortunately if you don’t have a real world use for them they are soon put to the back of the brain and over time forgotten. The same applies with taking for granted the way things work, be that ARP, DHCP or the process a switch or router goes through when moving traffic. I came across some of my old notes on CEF which I thought worth sharing.