For those that haven’t heard about it yet, GoBGP is, as they say “an open source BGP implementation designed from scratch for modern environment and implemented in a modern programming language, the Go Programming Language”.
To me, the most interesting part of GoBGP is that it uses a grpc interface to interact with the daemon and anything that can be done via its configuration file and/or CLI can be done via this interface. As a matter of fact, the CLI actually uses this interface to retrieve data and configure things.
It’s been quite some time since my last blog post and, truth be told, I don’t have that much time to blog as I am quite busy with work,
napalm and life in general. However, I wanted to take a few minutes today to announce
A couple of weeks ago I made this presentation/demo about abstractions for network operations titled “Abstract all the Things”. The idea was to show how templating is good but not good enough, sometimes you have to step back and focus on the goal and not on how to get there. Well, if you are interested in the topic you can find below the video, the link to the templates and to the github repo where you can find all the code I used for the demo.
The idea was that a network driver would translate unsupported models to native commands while models supported by the device would be sent via native mechanisms (gRPC, NETCONF, etc.). That would allow people to start using OpenConfig as NAPALM would serve as a transition mechanism.
So, after Rob sent me an example on how to use pyangbind, which he also wrote by the way, I put together a POC. It is very cool to see that thanks to pyangbind adding OpenConfig to NAPALM was really a piece of cake. Open Source for the win!
I have been working on a project to automate all things network related. Not only provisioning new stuff but operations as well. I am not going to tell you about the benefits of automation, everybody should know by now.
However, when talking about operations it is important to note that not all operations can be
automated but all operations can be abstracted. What I mean with that is that if you are
peering with someone you still have to perform some action so your system knows who the new peer
is, their IP address, their AS and where are you going to peer with them. However, the operator
doesn’t need to know that it has to go to the inventory system to add the new peer, then go to the
IPAM system to insert the required information and finally configuring the peer on the router. You
could abstract that entire repetitive and error prone workflow with a single command:
in=bma ip=10.0.0.1 as=65100.