Several years ago while driving through Nebraska in the middle of the night, a curious idea struck me.
“We have systematic testing for software, and for hardware, but why not for networking?”
Lucky for me, I was also searching for a thesis topic at the time.
Most networks are carefully hand tuned and watched over by experienced network engineers and IT personnel. Unfortunately this leaves them vulnerable to human error, configuration mistakes, or rot from “moves, adds, and changes”. Subnets evolve, routing grows more complex, cables get unplugged.
Can DHCP clients on that particular subnet reach the internal network as well as the internet? Are your switch ports in the correct VLAN’s? Is the guest wireless network accidentally bridged to your datacenter? Are you sure?
After installing dozens of new routers, switches, firewalls, and access points over the course of a frenetic downtime schedule, you’d be forgiven for second guessing yourself.
Most network verification is ad-hoc and sporadic. We can do better.
Bringing the best of Hardware and Software Testing to The Networking Stack
My background up until that point included studying Computer Engineering at Wisconsin, a summer internship at Cisco, and two additional summers working as a network engineer doing everything from installing routers and switches in dusty closets, to deploying VoIP systems and stashing wireless access points in the ceiling. I had also progressed a few years into my stint at Fluke Networks, one of the premier networking test equipment vendors. I believe that this confluence of experience led me to the idea of NETCDL.
In other words, I had seen the best verification ideas of the hardware and software folks, the current state of the art in network testing, and the real challenges of keeping a network running in top shape.
While designing and thinking through the concept, I was inspired by technologies such as Cucumber, and Verilog. Cucumber is an expressive, plain english method of specifying software tests. Verilog is powerful and declarative, describing precisely how you want your circuit to behave, with details of implementation being sorted out later by synthesis software.
The NETCDL Language declares how your network should behave, simply and easily. And you don’t even have to hack together a Bash script or Perl program to tickle your network.
# Certification Subject: Home Network
# Author: Cody Hanson <cody@clh.io>
# Date: 10/1/2016
# Version: 1.0
define host myRouter as 192.168.1.1
define network myNetwork as 192.168.1.0/24
define network DMZ as 10.0.0.0/24
define host ftpSite as speedtest.tele2.net
link speed should be 1000Mb/s
link duplex should be full
iperf download from ent.local should be at most 30Kbps
iperf upload to ent.local should be at least 30Kbps
access vlan should be 500
dhcp server should be myRouter
dhcp dns should be myRouter
dhcp network should be 192.168.1.0/24
dhcp gateway should be 192.168.1.1
myRouter should be reachable by ping
domain name google.com should resolve using server 8.8.8.8
domain name ent.local should resolve to 192.168.1.144 using server myRouter
myRouter should be reachable on TCP port 22
myRouter should not be reachable on TCP port 23
myRouter should not be reachable on UDP port 100
#File fetch assertions, default port used for protocol, if omitted
http server at myRouter should not serve "/path/to/file" on port 8080
http server at google.com should serve "/index.html"
http server at google.com should not serve "/index.html" on port 12345
tftp server at ent.local should serve "RouterUpdate.img"
tftp server at ent.local should not serve "RouterUpdate.img.missing"
ftp server at ftpSite should serve "1KB.zip"
ftp server at ftpSite should not serve "missingfile"
traceroute to 184.99.1.89 should traverse [192.168.1.1 10.0.0.1 184.99.0.12]
traceroute to 10.0.0.1 should traverse [192.168.1.1]
packets from network DMZ should not be seen
packets from host 10.250.0.1 should not be seen
packets with type 0x18 should not be seen
packets with TCP destination port 544 should be seen
packets with TCP source port 1000 should not be seen
packets with UDP source port 1010 should be seen
packets with UDP destination port 4000 should not be seen
frames with ethertype 0x18 should not be seen
Even without ever having seen NETCDL before, one can easily read any network specification. NETCDL Is not a programming language, so we optimize the syntax for human reading and writing, not compilers.
The Open Standard for Network Verification
From the start, I knew that I wanted the NETCDL language and concept to be free and open for anyone to use, similar to other important protocols in the networking world (TCP/IP, SNMP, etc). It is possible (and welcomed) that proprietary implementations of certifier tools may emerge, but crucially, the specifications written in NETCDL will be unencumbered and have a standard dialect.
To read more about NETCDL, check out Netcdl.org, including my thesis and defense slide deck.
The reference certifier implementation can be found here.
