In the nearly three decades I've worked in IT, there is a truth that trumps all others: More is better; smaller is better; and more-into-smaller is the best.


Whether your area of interest is storage, DevOps, virtualization, networking, app dev, or InfoSec, squeezing more into a smaller footprint (bits, lines of code, CPUs, etc.) is always better.


The ultimate expression of this is the Hollywood fantasy hacker. This is the computing wizard who steps onto the scene with little more than an average looking laptop, flips it open, and immediately begins bending the systems in question to their will. This magical notebook apparently is outfitted with infinite disk, thousands of CPUs, which can process millions of instructions per second, and connectivity that would put Google® Fiber to shame. If needed, it can spawn dozens of guest instances and mimic routers, load balancers, and firewalls.


Of course, that's just a fantasy. But it's one borne of a very real desire in the hearts and minds of IT professionals all over the world. The ability to create a realistic virtual simulation of a real computing environment, whether for testing, modeling, historical reference, or hacki... I mean penetration testing, is a very real need that often goes unmet in businesses today.


I bring this up because each day we seem to be getting closer to making this a reality. With tools like VMware® and VirtualBox®, we can now carry an entire server farm in our knapsack (as long as we have enough CPU and RAM). But, until recently, the network still eluded those who wanted to create a realistic simulation of their environment, including servers and network devices.


GNS3 has been the go-to option for simulated networks for years, but the primary use was preparing for certification exams. Then, about a year ago, GNS3 introduced the ability to link virtual machines (desktops or servers) to those network devices.


Suddenly, it became possible to not only model the network, but the servers behind those networks as well. We could simulate Active Directory® traffic, watch Web requests traverse the network, hit the load balancers and return to the requesting PCs. We could even test out monitoring.


Obviously, it's that last item that caught my attention. With this new ability to simulate both networks and servers, you could set up a polling engine, monitor the whole shebang, and test out scenarios like parent-child logic, routing failures, detecting configuration changes, and more.


GNS3 even put together a quick-start guide to help users set up SolarWinds® NPM. But this guide overlooked some key challenges:

  • Many members of the SolarWinds community are unfamiliar with setting up networks from scratch. They inherit them, monitor them, and even troubleshoot issues. But setting it up from scratch is often outside their skill set.
  • Many members of the GNS3 community are unfamiliar with monitoring tools in general, and SolarWinds® NPM specifically. So the details of configuring the server, running discovery, and setting up alerts is outside their skill set.

This is why I took the plunge and created a guide that helps both groups.


You can find it here:


It's really two guides in one. For those IT pros who are new to networking, the first half explains how to install GNS3 and then set up a simple three-router network. The second half is for network engineers who want to get SolarWinds NPM set up quickly without any of the false starts that comes with setting up a server application when you prefer to spend your day working with the bottom three layers of the OSI model.


Once you are set up, you will be well on your way to striding into the room, flipping open your magic laptop, and exclaiming, “My simulation shows we’ll be down to 27.3% network cohesion in just under 30 minutes!”


Then you can begin typing frantically, and save the day.