Home
This wiki serves as the home for resources & documentation for the NANOG 67 Hackathon! (http://nanog.org/meetings/nanog67/hackathon)
The hackathon's theme is focused on "building a source of truth" for your network. In the world of network automation, we have many possibilities and one road block that may hinder your level of automation is where the source of truth lies for device configurations. Is it on the device themselves? Is it stored in a text file and pushed? Is it modeled [described] in a database and rendered during the build?
Each group will have a Virtual Private Server (VPS) assigned to collaborate on for the duration of the hackathon. Login credentials will be provided at the Hack's opening. Use of the VPS is not required and simply provided as a convenience.
The VPS will be running Ubuntu 14.04 LTS Server with current versions of Python, GoLang, and Perl installed. MySQL server is also installed with appropriate Python modules for database access.
To access the VPS, connect using SSH and the credentials provided. Each VPS runs a local "mosh-server" as well which provides a more reliable SSH-connection for use across unpredictable network connections. See mosh.mit.edu for more detail and to grab a free client. If you have trouble connecting with Mosh, note that it runs over UDP using non-standard ports.
To plant a seed, we've started one "hack" in advance centered on this theme. Our hack is nicknamed NetDB, which is inspired by Facebook's FBNet. FBNet is a network topology database at it's core. It fully describes the Facebook production network down -- starting with the high level of devices and locations and going to the depth of per-neighbor BGP configuration on each device. By fully "modeling" the network in FBNet, we are able to generate device configurations at any time and can build tooling around their configuration through the database -- eliminating the slowness and potential risk of constantly hitting network devices.
NetDB is based on a MySQL database and Python code. The Python code manipulates data through the database using simple SQL queries and the MySQL Python "connector" library found on https://dev.mysql.com/downloads/connector/python/.
All of this has been pre-staged to each group's VPS. On the VPS, you will find the example code in ~/hackathon/, along with data pre-loaded onto the database named hackathon on the locally running instance of MySQL server. To see the pre-loaded data, type mysql on your shell. This is an alias to "mysql -u -p", dropping you into a MySQL shell. Once in that, type use hackathon; and use standard SQL commands such as select * from devices; to view what's already staged.
To destroy the example data and re-create it, run: ~/hackathon/dbsetup.sh. In that shell script, you will find the full database schema too. You will also see a Python script of staging.py but running that directly is not needed to re-build the example - tt will be called by the shell script above.
The example uses a MySQL database named "hackathon", which has a structure described best by the diagram below:
Not shown, there's also a table named "circuits" which allows us to model the physical connections between two network devices. Entries into the "circuits" table represent a physical interface on each end using the A/Z endpoint terminology.
The pre-staged network consists of two datacenters ("atn" and "frc") with two clusters each. A cluster here is simply a logical unit to associate a number of racks (rack switches) and their aggregation layer (cluster switches). In the examples staged, we have 4 x cluster switches and 128 x rack switches per cluster. The currently staged data does not connect either cluster / datacenter together though :-)!
In the screen shot below, we can see a view into the db-level association of the network links connecting rack switches to cluster switches.
While native SQL is used to manage the data, an API was built to provide a friendly Python interface through the library named topology_manager.py.