This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
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 napalm-yang.
In summary, napalm-yang tries to bring support for YANG models to devices where:
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 other day I talked with Rob Shakir who has been working very closely with OpenConfig and we came up with the idea of trying to add OpenConfig support to NAPALM.
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: add peer
in=bma ip=10.0.0.1 as=65100.
A few days ago I published a couple of posts in the Spotify Labs Blog about the SIR. Here they are in case you want to check them out: