I am hereby launching the Network Device Config Collection and the corresponding Network Device Config Collector (code). The What 🔗The network device config collection is supposed to be a collection of configuration files for any type of network device. These configurations should then serve as the basis for network automation software development whenever real-life configurations are interesting. This means that all kinds of configurations are relevant to it, production or lab, good or bad or even faulty (not in syntax but in semantics), amateur or expert-level.

Over the past year I have been working on adding type hinting (see PEP484) to the Network Automation and Programmability Abstraction Layer with Multivendor support python library (NAPALM). Type hinting is still only used in a subset of all python libraries, so I thought it might be interesting to elaborate on the process. Type hints in combination with a type checker such as Mypy allow for static analysis of Python programs.

If your job as a network administrator is anything like mine then you often get pulled somewhat out of your comfort zone by supposed network issues in end hosts. Some of the problems I’ve had to deal with in this regard are the following: Servers with multiple network interfaces where a firewall rule was requested for the wrong interface Applications that had trouble correctly setting up their sockets and as a consequence don’t listen on the ports they are supposed to listen on Host firewalls blocking traffic destined to the server A handy cheat sheet for these operations can be found at the end of this post.

The somewhat newly released netsim-tools by Ivan Pepelnjak has been on my “check-this-out” list for a couple of weeks now. It contains a set of tools to simplify the process of creating virtual network labs. In the following sections I will lay out how to quickly get started with labbing on Cisco NXOS 9000v or Cumulus Linux devices using netsim-tools. Note: Following the 0.8 release of netsim-tools this post received an update to use the pip-way of installing the tools.

You can find the the code used in this post here. If you just need a webhook receiver for Netbox follow the instructions in the README.md file in that repository. This is a follow-up to my earlier blog post Netbox webhook receiver with Python, Celery and FastAPI. Here we see two major improvements over the previous iteration: Consolidating webhook configuration on the Netbox side into a single webhook Implementing a plugin system, which allows users to share their integrations.

When trying to run Docker and GNS3 on the same Windows system with an AMD processor I was faced with the following challenges: Docker for Desktop on Windows requires Hyper-V or WSL2, the latter in turn requires Hyper-V Hyper-V on AMD processors only supports nested virtualization as of 2020 (in fact the official docs still say that “nesting is currently Intel-only”) Hyper-V officially supports only Hyper-V itself for netsed virtualization, therefore rendering it useless for running GNS3 After being fed up with running GNS3 on a separate physical Linux machine I tried to come up with an actual solution to the problem.

You can find the the code used in this post here. If you just need a webhook receiver for Netbox follow the instructions in the README.md file in that repository. The Netbox IPAM and DCIM tool provides webhooks as a means of integrating with other software. External software you might want to notify of changes in Netbox might be network monitoring software (NMS) or a configuration management database (CMDB). While Netbox supports Jinja2 templating for the body of the webhook HTTP request you sometimes want to issue multiple requests in a particular sequence with some state on a single trigger event (such as a single device changing).