GNS3 is not the only show in town nowadays – relative newcomers like EVE-NG and CML ( RIP VIRL) have given GNS3 stiff competition and seem to be gaining ground – whenever I see a screenshot of someone’s virtual lab it tends to be in EVE-NG nowadays. I have yet to make the switch and in all honesty Ive not really heard a compelling argument to move from GNS3 – it does everything I need it to do for my studies. Can someone change my mind?
One of the things I recently discovered about GNS3 was its pubic facing API – The ability to programaticly stand up test infrastructures for general labbing, study or integration into a CI/CD pipeline (something I want to cover in another blog) is a feature that I had to explore. The API is on version 2 now so I may be late to the party but this write-up will give a broad overview of my dealings with the API
I am running the GNS3VM locally however these concepts would still apply if you were running on a remote server
The API has great documentation avalable at: https://gns3-server.readthedocs.io/en/latest/#
All code avalable on github: https://github.com/thecraigus/gns3ondemand
Credentials
The GNS3 API is a RESTful API and is authenticated by default. It accepts Basic authentication – the username and password are buried away in a the gns3_server.conf file as below so open the file and make note of these.
Creating a Project (createPoject.py)
Each GNS3 project has a name and a unique Project ID – I created a dictionary with these values in and a dictionary for storing the credentials.
A simple post request to the /projects API endpoint allowed me to create a project workspace.
Adding Nodes (addNodes.py)
The /nodes API operates in much the same way to the project API endpoint – albeit it expects a rather weighty json document per node – in retrospect I should have really authored these json documents using values from YAML files and a jinja2 template rather than having multiple verbose json documents that embedded in the script itself. Maybe this is something I will revisit later.
Adding Links and Starting Nodes (startTestbed.py)
Each link in GNS3 is represented by a json array of 2 nodes and their corresponding ports/adapter numbers. The nodes are referenced by their nodeID that can obtained by the /nodes API get request.
Running the start startTestbed.py script will spin up the topology
if we open up the newly created project file we can see that our testbed topology has been created programaticly.
Summary
The ability to stand up test infrastructures on demand is something that can be leveraged in personal study, labbing and testing as part of a CI/CD pipeline. The infrastructure that is deployed in this walkthrough has the blank default configuration, we could however take this a step further and perform some bootstrapping or an automated console session using something like telnetlib initially to get the infrastructure to a state that mirrors your production environment ready to test your changes.
RouteDefault: Musings of a Network Engineer 