Introducing the Network Device Config Collection

Β· 567 words Β· 3 minute read

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.

This is where I need your help! If you checked out the repository, you can see that it is still very bare. If you have a configuration to spare, please input it into the Network Device Config Collector (NDCC) or, if you prefer, submit a manual Pull Request to the Network Device Config Collection. The NDCC uses netconan to anonymize the configurations that you pass in. It processes those server-side, but it reflects what it processed back to you for verification, so you can decide whether the result is anonymous enough for you. The unsanitized configuration is only kept in memory on the server - check out the code if you’d like.

The Why πŸ”—

Recently I was trying to re-build netlint - a piece of software I wrote two years ago whose purpose was supposed to be static analysis of network device configuration files. At the time I abandoned it - not because I didn’t still like the idea but rather because my priorities shifted elsewhere. After a good year of working at Network to Code, I wanted to revisit the idea.

I quickly shifted paradigms from the original implementation and started out not by directly writing linting rules, but rather by first writing a parser that is supposed to transform network device configurations from arbitrary vendors into a single, structured format (if this sounds like OpenConfig to you, you have a point - I thought about it but deemed YANG too much of a hassle to deal with). Then, on the basis of that structured format, I can write linting rules that apply to all network operating systems (NOSes) for which these constructs exist.

Example Cisco interface configuration:

interface GigabitEthernet0/0
 ip address 192.0.2.1/24
!

Example Fortinet interface configuration:

! Fortinet example configuration
config system interface
 edit port1
  set mode static
  set ip 192.0.2.1 255.255.255.0
 next
end

These configurations could for example parse into the following structured data:

{
  "interfaces": [
    {
      "name": "GigabitEthernet0/0",
      "ip_address": "192.0.2.1/24"
    },
    {
      "name": "port1",
      "ip_address": "192.0.2.1/24"
    }
  ]
}

From this data you could then tell the user that they are misusing RFC5737 address space for a non-documentation purpose, clearly indicating a problem with the configuration. But I only have to write this linter once! I am aware of the complexity that I am then pushing into the parser(s), but this is something I think I am willing to deal with.

All of this unfortunately is not available today and the current state of netlint does not use this paradigm. I am hoping to start implementing this once I get a couple of configurations into the collection.

If all this sounds exiting to you, please see how/if you can contribute device configurations that you have access to, provide feedback/pull requests to improve the collector (or the collection itself) or even provide ideas/feedback for the linting tool - I am happy to hear about anything.

Thanks!