Adventures in Automation: Part 1

So ever since I heard about automation (and then orchestration) I have finally taken some measures to not only learn but implement some of my own.

Since I realised that I have a reasonable amount of unwanted technical debt building up while having to maintain my 'homelab' in its current state, some the daily hastles can be automated away.

Two such tasks I have just undertaken and completed are"

1. Ansible automation to update, upgrade and clean orphaned/unused packages
2. Script to cleanup snapshots taken prior to ansible playbooks being run

I have a very long way to go before I can get other things automated, but its a start.

I'm also in the process if defining a docker environment where most of my services will operate from within one or more virtual machines.

I will also have to look into github repository of my code and a complete cloud backup solution with onsite encryption (encryped using my own privately owned and stored keys).

Free Range Routing

Since I discovered Docker, I have been busy designing my homelab to be as Cloud Native as possible, but in doing so, I realised that the default docker network (aka bridge) and the other networks defined by other containers from docker-compose bridge type networks isn't known by the upstream network collapsed core access layer network.

In the past I have been adding static routes upstream and a default route on the docker host, but this was not ideal (read scalable) given the dynamic nature of docker networks created with docker-compose.

I quickly realised that since I've developed significant experience in BGP (in service provider environments), I planned to just peer the docker host to the upstream access layer, but until now didn't know how to do this with Linux.

I have always known about Quagga, but been a bit concerned about the learning curve required to get it working, but remembered about its fork called Free Range Routing. So I decided to make the a leap of faith and I have no regrets whatsoever.

I was supprised at how easy it was to install and configure and to get it working which comprised of the following;

On the Docker host;

1. Setup the REPO
2. Installed FRR and configred services for vtysh as per the official documentation
3. Connected to the vtysh interface and
4. Configured BGP and redistributed only conneted routes using route-map/prefix-list

On the upstream switch/access layer;

1. Configured peering to FRR and squelched all but a summary route prefix-list/route-map.

Not only did I define the policies perfectly (woot!), but the neighbor came up without any issues at all!!!

My switch can now route traffic to any docker/docker-compose containers/services that are created with far less effort required to define routes to the containers as well as deleting them if no longer in use.

I am very supprised to learn that not only is it extremely easy to get FRR up and running but it is very easy to configure routing daemons/config for them especially if you have a grounding in Cisco as its vtysh is very closely matched with that of Cisco CLI - there are some slight and obvious differences to Cisco's not to mention the fact that you need to connect to the vtysh interface kind of like the root user does on a Juniper platform (cli).

Next up I need to figure out how to leverage Linux VRF namespaces using FRR vtysh, then I can migrate my infrastructure to MPLS!

juniper-nuances-part1

Once day I was relaiming an interface on my newly aquired Juniper SRX300 (yes, I managed to get one of these nice little units!) and when trying to commit, I came accross the below error, which wile it seems a little misleading, it actually gives a very good clue at the issue (which may seem cryptic to the inexperienced user).

root@srx300# set interfaces ge-0/0/1 unit 0 family ethernet-switching interface-mode trunk
[edit]
root@srx300# set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members all
[edit]
root@srx300# commit check
[edit routing-instances emetric interface]
  'ge-0/0/1.0'
    Interface with 'interface-mode' is allowed only in a virtual-switch
error: configuration check-out failed: (statements constraint check failed)

In the above example, the system claims that 'the interface-mode is allowed only in a virtual-switch' however upon removing the associated interface from the routing-instance (in this case I just deleted the routing instance) and making sure that the following was in place, then commit was successful and no further errors.

[edit]
root@srx300# delete routing-instances emetric
[edit]
root@srx300# commit check
configuration check succeeds
[edit]
root@srx300# show interfaces ge-0/0/1 | display set
set interfaces ge-0/0/1 unit 0 family ethernet-switching interface-mode trunk
set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members all

So, you see the lesson here is READ the output carfeully for the clue as to why the commit is throwing an error. In my case the interface was assigned in a routing-instance and therefore mutually exclusive when the interface is a L2 trunk (highlighted text).