Nornir: Inventory Structure and Filtering

The inventory is at the core of Nornir holding all the hosts that tasks will be run against and the variables that will be used by those tasks. Before any tasks can be run by Nornir the inventory has to be initialised.

Nornir – The Basics

If you have an understanding of Python and have been working with Ansible it is likely at some point you will get to the stage where you ask yourself ‘there has to be something better’. For network automation that better could well be Nornir.

Virtual Tunnel Interface (VTI) VPN

Over the years I have built numerous IPsec VPNs on ASAs using crypto maps and an ACL for the interesting traffic. For a simple solution to join small sites with no need for routing these work great and keep the complexity down to a minimum. For more complex environments or cloud connectivity you are probably going to need to use VTIs, this post goes through the process of building VTI VPNs between an ASR and ASA.

EVE-NG Cloud NAT

This post explains how to configure EVE-NG as a DHCP server (isc-dhcp-server) assigning IPs to lab devices that are then dynamically NATed behind the primary EVE management IP address (iptables masquerade) to provide Internet breakout.

The Evolution of Labbing

A trip down memory lane on how things have changed in labbing from using prehistoric switches bought on eBay through emulators that took longer to configure than the labs to the present day solutions that can programmatically build a multi-vendor lab in minutes. Kids today don’t know they are born…..

Automate Leaf and Spine Deployment – Part6

The 6th post in the ‘Automate Leaf and Spine Deployment’ series goes through the validation of the fabric once deployment has been completed. A desired state validation file is built from the contents of the variable files and compared against the devices actual state to determine whether the fabric and all the services that run on top of it comply.

Automate Leaf and Spine Deployment – Part5

The 5th post in the ‘Automate Leaf and Spine Deployment’ series goes through the deployment of the services that run on top of the fabric. These services are grouped into 3 categories, tenant, interface and routing. Services are configured only on the leaf and border switches, the spines have no need for them as they just route the VXLAN encapsulated packets with no knowledge or care of what is within them.

Automate Leaf and Spine Deployment – Part4

The 4th post in the ‘Automate Leaf and Spine Deployment’ series goes through the creation of the base and fabric config snippets and their deployment to devices. Loopbacks, NVE and intra-fabric interfaces are configured and both the underlay and overlay routing protocol peerings formed leaving the fabric in a state ready for services to be added.

Automate Leaf and Spine Deployment – Part3

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.

Automate Leaf and Spine Deployment – Part2

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.

Automate Leaf and Spine Deployment – Part1

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.

Configure NXOS with Napalm

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

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.

Checkpoint Endpoint Security VPNs

Enable SNMP on ESX

OSPF LSA Types

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.

Cisco Express Forwarding (CEF)

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.

VSS Recovery mode

Dual-active Detection (DAD) is designed to prevent a split-brain scenario where both VSS supervisors become active in the event of a VSL link failure. It uses a separate (from the VSL link) secondary communication link to communicate the devices state.
When the VSL link fails the standby switch becomes active and the current active switch is informed of this over the DAD links and goes into recovery mode to stop a split-brain situation occurring.

Checkpoint Identity Awareness

The 3 main elements that run identity awareness under the hub are Active Directory Query (ADQ), PDP and PEP. They all intertwine in some way to allow the different blades of the Checkpoint to track and restrict access based on AD user and machine name. I tested these features as part of a POC and personally I would not consider them fit for purpose in a production environment. See the caveats at the end of the post for more details on this.

Deleting Checkpoint Logs

The directories that need to be emptied to delete all the logs on the Checkpoint managers.