• The Cult of Done
• Prototyping

I’ll be using this repo to track progress as the year goes on.

The Cult of Done

Created by Bre Pettis and Kio Stark here, I discovered “The Cult of Done” through a YouTube video by No Boiler Plate. It is an approach to creative work, that forces you to finish the work at hand. It comes with thirteen tenants listed below -

• There are three states of being. Not knowing, action, and completion.
• Accept that everything is a draft. It helps to get it done.
• There is no editing stage.
• Pretending you know what you’re doing is almost the same as knowing what you are doing, so just accept that you know what you’re doing even if you don’t and do it.
• Banish procrastination. If you wait more than a week to get an idea done, abandon it.
• The point of being done is not to finish but to get other things done.
• Once you’re done you can throw it away.
• Laugh at perfection. It’s boring and keeps you from being done.
• People without dirty hands are wrong. Doing something makes you right.
• Failure counts as done. So do mistakes.
• Destruction is a variant of done.
• If you have an idea and publish it on the internet, that counts as a ghost of done.
• Done is the engine of more.

The plan is to release lots and lots of projects. Some of them may work but some of them may be failures. The purpose though is not the projects themselves but the learning of Golang (and other concepts) along the way.

Prototype - Throw away your first draft

A recent blog post by Nicole Tietz on the importance of prototyping features and initial projects. To put it simply, when first tackling a coding problem, the first draft should be an effort to understand what you are building. Mistakes will be made, the code will be messy, and it won’t follow best practices. The next step is to throw away the code that you wrote. Mistakes will have been made, the code is messy and it doesn’t follow best practices. The next draft will be a clean slate with none of the baggage, but now the second draft can be written with the experience of already solving the problem once.

How the Repo Works

The repo is split into two main branches, Main and Prototype. Most of the work will be done in the prototype branch. Each directory in the branch will be its own mini-project. Most of the projects will never exist outside of the prototype branch. However if one of the projects is particularly interesting, I plan on rewriting the project (from scratch) within the main branch.

Recently I had to provide the ability to validate network state on a specific environment. While this offered an excellent opportunity to use NAPALMs' validation features, it also became an exercise in recursion. The validation with NAPALM is relatively straightforward, but the python dictionary returned is complex and of an unknown origin. To display the dictionary without coding out every single use case, I wrote a recursive function to do it for me.

The Topology

The topology is pretty simple with three routers where router-A connects to both router-B and router-C. If you are interested in the configuration, you can reference the previous blog post here.

The Objective

The overall goal is to validate the state of the network and effectively communicate the results of that validation to the user.

The Script

First, we’ll want to import the get_network driver from NAPALM.

from napalm import get_network_driver

We will then import some more utility modules.

from colors import bcolors
from os.path import exists
from os import system, name

Now let’s define some utility functions. The clear() function will clear the CLI screen in case there is any stale output still there. We leverage the system module to determine if we are running the script on a nix or windows based environment.

def clear():
    if name == 'nt':
        _ = system('cls')
    else:
        _ = system('clear')

The following utility function will print our test results in a more readable format, with special Unicode characters.

def print_result(test_name, test_result, level):
    if test_result:
        print((" " * level) + u'\u2705' + " - " + test_name)
    else:
        print((" " * level) + u'\u274c' + " - " + test_name)

The next function is the real “meat and potatoes” of the entire compliance script. It is a recursive function that will allow us to move through the JSON blob returned by the NAPALM compliance_report() method.

def display_compliance_info(output, level=0):
    keywords = ['extra', 'missing', 'skipped', 'complies', 'present', 'diff']
    for check, value in output.items():
        if check not in keywords:
            print_result(check, value['complies'], level)
            if 'present' in value.keys():
                display_compliance_info(value['present'], level+2)
            elif 'diff' in value.keys():
                if len(value['diff']['missing']) > 0:
                    for missing_value in value['diff']['missing']:
                        print_result(missing_value, False, level+2)
                display_compliance_info(value['diff']['present'], level+2)

To better understand what this function does, let’s first look at the output that we receive from NAPALM.

{
  "get_facts": {
    "complies": true,
    "present": { "hostname": { "complies": true, "nested": false } },
    "missing": [],
    "extra": []
  },
  "get_interfaces_ip": {
    "complies": true,
    "present": {
      "Ethernet1": { "complies": true, "nested": true },
      "Ethernet2": { "complies": true, "nested": true }
    },
    "missing": [],
    "extra": []
  },
  "get_bgp_neighbors": {
    "complies": false,
    "present": {
      "global": {
        "diff": {
          "complies": false,
          "present": {
            "router_id": { "complies": true, "nested": false },
            "peers": {
              "diff": {
                "complies": false,
                "present": {
                  "192.168.0.2": { "complies": true, "nested": true }
                },
                "missing": ["10.0.0.1"],
                "extra": ["10.0.0.2"]
              },
              "complies": false,
              "nested": true
            }
          },
          "missing": [],
          "extra": []
        },
        "complies": false,
        "nested": true
      }
    },
    "missing": [],
    "extra": []
  },
  "skipped": [],
  "complies": false
}

As we can see, the dictionary can be reasonably complex and of an unknown depth. Because of those two potential items, recursion will be the best way to tackle the iteration through this function. The general premise of the function is to loop through each initial level of the dictionary. In the event of a unique key (get_facts, get_interface_ip, get_bgp_neighbors, global, etc.), we print the value of the complies key, which represents the overall result for the section. If we see the key “present,” we know there is another section to the output, so we call the function again, passing it the value of present, and do it all over again. We do the same thing if we see a non-empty value in the “missing” value of the “diff” section.

The result of this function allows us to do two things.

1. We can keep the code short since we do not have to plan for every possible variation that the NAPALM compliance function returns.
2. We also don’t have to rewrite the script every time a new check is added to NAPALM. All we need to do is update our check file.

The remaining portion of the script will loop through the defined devices, and for each device it will check to see if a compliance file exists for the device. If the file exists, it will run the compliance_report function and display the output.

def main():
    clear()

    devices = [
        {'name': 'router-A', 'host': '192.168.86.201'},
        {'name': 'router-B', 'host': '192.168.86.202'},
        {'name': 'router-C', 'host': '192.168.86.203'},
    ]

    driver = get_network_driver("eos")

    for device in devices:
        with driver(device['host'], 'admin', 'test') as active_device:
            compliance_file = f"compliance/{device['name']}.yml"
            if exists(compliance_file):
                print(
                    f"Checking {bcolors.HEADER}{device['name']}{bcolors.ENDC} for compliance...")
                result = active_device.compliance_report(compliance_file)
                display_compliance_info(result)
                print('\n')


if __name__ == "__main__":
    main()

The Compliance File

NAPALMs compliance file is pretty elegant. All checks are defined as YAML and pretty self-explanatory. Below, we are checking for three things: the device’s hostname, the interface configuration, and the BGP configuration. If any of these checks fail, the overall parent object also fails.

---
- get_facts:
    hostname: router-A

- get_interfaces_ip:
    Ethernet1:
      ipv4:
        10.0.0.1:
          prefix_length: 30
    Ethernet2:
      ipv4:
        192.168.0.1:
          prefix_length: 30

- get_bgp_neighbors:
    global:
      router_id: 1.1.1.1
      peers:
        _mode: strict
        10.0.0.1:
          is_enabled: true
          is_up: true
        192.168.0.2:
          is_enabled: true
          is_up: true

Output

Below is a screenshot of the output for the three devices. I purposely entered some incorrect information into the compliance file for router-a to see the result of a failed compliance run.

Summary

This little project ended up being more work than I originally anticipated, but it gave me some good practice on recursion. While sometimes it may initially seem easier to just brute force your way through a problem, spending the time upfront on the algorithmic side can save you a lot of work on the backend.

Resources

Code: https://github.com/barryCrunch/lab-automation-demo

Napalm Documentation: https://napalm.readthedocs.io/en/latest/index.html

Due to some new environments that we have been spinning up at work, I have been labing a lot of new tech out recently. Because of this, I found myself typing out many commands on the CLI or having to re-type out configurations from scratch if my lab misbehaved. To reduce the time spent on the tedious, I decided to write up a quick script to manage my infrastructure through static files.

The Topology

I will leverage a pretty basic setup to outline the idea, but you can get rather complicated with this basic script since NAPALM supports a whole slew of device types. Below we have three routers, with router-A having a leg to both router-B and router-C. Router-A is also running BGP between itself and each directly attached neighbor. The management interfaces on each Arista switch leg out locally to my home network, which allows me to access each vEOS natively via ssh.

The Objective

Instead of having the configuration on the device be the source of truth, it will be a set of flat files on my computer. I should then be able to “push” these configuration files to the devices removing the need for any manual CLI work. Below is a simple diagram of the workflow that I imagine when setting up and managing a device in the lab.

The Script

First we’ll want to import the get_network driver from NAPALM

from napalm import get_network_driver

Then we will define our list of devices. We could get a little clever here and leverage nornir or netbox but for the sake of a MVP we’ll just have a list of dictionaries.

devices = [
      {'name': 'router-A', 'host': '192.168.86.201'},
      {'name': 'router-B', 'host': '192.168.86.202'},
      {'name': 'router-C', 'host': '192.168.86.203'},
]

Once we have the dictionary all we need to do is loop through it and apply the local file to each respective device.

for device in devices:
      driver = get_network_driver('eos')
      active_device = driver(device['host'], 'admin', 'password')
      active_device.open()
      active_device.load_replace_candidate(filename=f"configurations/{device['name']}.conf")
      compare_result = active_device.compare_config()

      if compare_result == '':
            active_device.discard_config()
      else:
            active_device.commit_config()
      active_device.close()

As you can see, the logic is pretty quick and dirty. First, we open up a connection to the device. Then we proceed to stage the configuration file by loading it to the device. We then check to see if there are any changes. If the string is not empty, we commit the configuration; otherwise, we discard it. And finally, we close the session to the device.

The load_replace_candidate() method will return a string with the changes to the configuration; if there are no changes, it will return an empty string.

Output

Below is an output from running the script. I have added some print statments to log the output.

(arista) mbarry@desktop:~/projects/automation$ python deployment.py
******************************************************************
Connectiong to router-A...
Loading configuration...
Configuration changes....

@@ -23,6 +23,8 @@
    ip address 192.168.0.1/30
 !
 interface Ethernet3
+   no switchport
+   ip address 10.1.1.1/30
 !
 interface Ethernet4
 !
Commiting configuration....
COMPLETED


******************************************************************
Connectiong to router-B...
Loading configuration...
<<<<<<<<<<<<<NO CHANGES>>>>>>>>>>>>


******************************************************************
Connectiong to router-C...
Loading configuration...
<<<<<<<<<<<<<NO CHANGES>>>>>>>>>>>>

We can see I added some IP address configuration to router-A on interface Ethernet3 and made no changes to router-B or router-C.

Summary

Nothing too complicated above, but it allows me to iterate through my labs a bit quicker. Plus if you start storing the configuration in a git repo and wrap it in a CI/CD pipeline with pre and post validations you have yourself a genuine Infrastructure-As-Code deployment.

Resources

Code: https://github.com/barryCrunch/lab-automation-demo

Napalm Documentation: https://napalm.readthedocs.io/en/latest/index.html

Recently I came across the requirement to leak routes from a VRF to the Global Route Table (GRT) and vice versa. The task took me longer than I care to admit, and my biggest stumbling block was deciding how exactly to go about it. The way described below is just one way to accomplish the task and specifically works for exchanges across dynamic routing protocols. Below is only one way to do it and the way that I found to be the most intuitive.

The Topology

We are going to work off of an elementary topology with three routers. The first and third routers will exist within a single VRF, while the second router will have an interface in each VRF. The second router will peer with the first and third via BGP and leak routes from VRF-A to its GRT and vice versa.

router01 base config

hostname router01
!
interface Loopback1
 ip address 10.1.1.1 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 10.0.0.2 255.255.255.252
 duplex auto
 speed auto
 media-type rj45
!
router bgp 65002
 bgp log-neighbor-changes
 neighbor 10.0.0.1 remote-as 6500
 !
 address-family ipv4
  redistribute connected
  neighbor 10.0.0.1 activate
 exit-address-family
!

Nothing special here; we just apply the IP addresses to the interfaces. Establish a BGP relationship with router02 and advertise our connected interfaces.

router02 base config

hostname router02
!
ip vrf VRF-A
 rd 1:1
 import ipv4 unicast map GLOBAL_TO_VRF
 export ipv4 unicast map VRF_TO_GLOBAL
 route-target export 1:1
 route-target import 1:1
!
interface GigabitEthernet0/0
 ip vrf forwarding VRF-A
 ip address 192.168.0.1 255.255.255.252
 duplex auto
 speed auto
 media-type rj45
!
interface GigabitEthernet0/1
 ip address 10.0.0.1 255.255.255.252
 duplex auto
 speed auto
 media-type rj45
!
!
router bgp 6500
 bgp log-neighbor-changes
 neighbor 10.0.0.2 remote-as 65002
 !
 address-family ipv4
  neighbor 10.0.0.2 activate
 exit-address-family
 !
 address-family ipv4 vrf VRF-A
  neighbor 192.168.0.2 remote-as 65001
  neighbor 192.168.0.2 activate
 exit-address-family
!
!

A couple noteworthy things in the router02 configuration. We create the VRF with the command:

ip vrf VRF-A

We then set a route descriptor of 1:1 with the following command:

rd 1:1

After creating our VRF, we place interface GigabitEthernet0/0 in that VRF with ip forwarding vrf VRF-A under the interface configuration.

interface GigabitEthernet0/0
  ip forwarding vrf VRF-A

router03 base config

hostname router03
!
interface Loopback1
 ip address 192.168.1.1 255.255.255.255
!
interface GigabitEthernet0/0
 ip address 192.168.0.2 255.255.255.252
 duplex auto
 speed auto
 media-type rj45
!
router bgp 65001
 bgp log-neighbor-changes
 neighbor 192.168.0.1 remote-as 6500
 !
 address-family ipv4
  redistribute connected
  neighbor 192.168.0.1 activate
 exit-address-family
!

Objective

The goal will be to just share 10.1.1.1/32 into VRF-A and 192.168.1.1/32 into the Global Route Table. When all is said and done, we should be able to ping from Loopback1 on router01 to Loopback1 on router03.

Configuration

Before we start importing and exporting routes, we will need to create a couple of route maps to identify the routes we want to import/export.

ip prefix-list GLOBAL_TO_VRF seq 10 permit 10.1.1.1/32
!
ip prefix-list VRF_TO_GLOBAL seq 10 permit 192.168.1.1/32
!
route-map VRF_TO_GLOBAL permit 10
 match ip address prefix-list VRF_TO_GLOBAL
!
route-map GLOBAL_TO_VRF permit 10
 match ip address prefix-list GLOBAL_TO_VRF
!

We know we want to grab the two /32 routes, so we create two prefix lists and then use those to identify the addresses within the route maps.

Once the route maps are built, they are applied to import/export statements within the vrf configuration.

ip vrf VRF-A
 import ipv4 unicast map GLOBAL_TO_VRF
 export ipv4 unicast map VRF_TO_GLOBAL

We are almost there. The last configuration required is to configure the route target on exported routes. This will tag any routes exported from VRF-A with the RD 1:1

ip vrf VRF-A
 route-target export 1:1

Validation

First, let’s check the Global Route Table on router02

router02#show ip route

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.0.0.0/30 is directly connected, GigabitEthernet0/1
L        10.0.0.1/32 is directly connected, GigabitEthernet0/1
B        10.1.1.1/32 [20/0] via 10.0.0.2, 01:20:51
B        10.3.3.3/32 [20/0] via 10.0.0.2, 01:29:03
      192.168.1.0/32 is subnetted, 1 subnets
B        192.168.1.1 [20/0] via 192.168.0.2 (VRF-A), 01:27:56

At the bottom, we see the route for 192.168.1.1/32 exported from VRF-A.

When we look at the route table for VRF-A we see the route for 10.1.1.1/32.

router02#show ip route vrf VRF-A

Routing Table: VRF-A

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 1 subnets
B        10.1.1.1 [20/0] via 10.0.0.2, 01:26:28
      192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/30 is directly connected, GigabitEthernet0/0
L        192.168.0.1/32 is directly connected, GigabitEthernet0/0
      192.168.1.0/32 is subnetted, 1 subnets
B        192.168.1.1 [20/0] via 192.168.0.2, 01:30:09

The route for 10.1.1.1/32 isn’t tagged with a RD or the name of VRF since it didn’t come from a particular VRF but the Global Routing Table. Once we have the routes properly injected into each route table we should now see them in the route tables of router01 and router03.

router03#show ip route

Gateway of last resort is not set

      10.0.0.0/32 is subnetted, 1 subnets
B        10.1.1.1 [20/0] via 192.168.0.1, 01:41:19
      192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/30 is directly connected, GigabitEthernet0/0
L        192.168.0.2/32 is directly connected, GigabitEthernet0/0
      192.168.1.0/32 is subnetted, 1 subnets
C        192.168.1.1 is directly connected, Loopback1

router01#show ip route

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.0.0.0/30 is directly connected, GigabitEthernet0/0
L        10.0.0.2/32 is directly connected, GigabitEthernet0/0
C        10.1.1.1/32 is directly connected, Loopback1
C        10.3.3.3/32 is directly connected, Loopback2
      192.168.1.0/32 is subnetted, 1 subnets
B        192.168.1.1 [20/0] via 10.0.0.1, 01:45:33

And finally, we should now be able to ping the loopback on router03 while sourcing from the loopback on router01.

router01#ping 192.168.1.1 source 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/7/10 ms

Summary

Overall this is a pretty quick and straightforward way to import/export routes from a VRF to the Global route table. It should be noted that this will only work if you are utilizing some sort of dynamic routing protocol. If you would like to use static/connected routes, some different approaches need to be taken. I have included some links to resources below.

Resources

Pretty comprehensive blog on route leaking between VRF and GRT using several different methods.
https://ipwithease.com/route-leaking-between-vrf-and-global-routing-table/

Cisco configuration guide, the one that got it over the line for me.
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/15-mt/irg-15-mt-book/irg-prefix-export.html