Introduction to PGT Network Map

What is PGT Network Map

Pretty Good Terminal - or PGT - is a Windows Desktop application designed primarily for developing and deploying scripts on computer networking devices, such as routers and switches.

PGT scripting engine is vendor agnostic by design, and its extensible architecture makes it very easy to generate and deploy simple CLI, Python or Visual scripts for almost any type of device supporting some sort of command interface.

Beyond its superb scripting capability, PGT has several, well-documented development interfaces  allowing the development of custom plugins that can leverage the advanced scripting APIs provided by the software.  

The availability of the development and scripting support, as well as the built-in Python IDE environment has inspired the vision of building an interactive Network Map plugin for PGT. 

Ultimately, PGT Network Map is an optional module of the application making extensive use of Python script parser modules to discover, document and visualize a computer network.

How it works

For those who want to have a quick overview, here is what happens during a discovery process from a helicopter view :

PGT will connect to specified set of devices using SSH or Telnet, then using the appropriate Python parser module collects device information and finds protocol neighbors. These neighbors may become the next target of discovery allowing the process to recursively crawling through the complete network defined by specific boundaries. All of the information collected is written to a topology database from where the visualization engine builds the interactive network map graphic. That's simple it is.

Under the hood

And below are some more details in case you are hungry to understand the process better.

Network Discovery in PGT relies on small Python scripts called Parser Modules that are responsible of transforming device configuration and run-time data to a well-defined format via an API using the required vendor specific CLI commands to collect required information. The parsers dealing with  basic device configuration data - such as interface details, hardware and software version, serial number, etc. - are called Router Modules, while some other parsers must understand specific network protocol details like OSPF, BGP, ISIS or LLDP to name a few. 

Depending the actual version and release of the application, PGT supports multiple vendors and understands several networking protocols. However, minor deviations in CLI language syntax may occur occasionally depending on OS release and device type, therefore some customization of the parser modules may be required to achieve best discovery results.

Basically, discovery will start from the list of seed devices provided at the beginning of the  discovery, by specifying the management address of them. The discovery engine will start connecting to the specified hosts with SSH or Telnet, and tries to find any known Router module that is willing to handle the established connection.  

In other words, PGT will try to find the appropriate parser module for the connected device. If a  Router module is capable to handle a device, parsing will start using that module.  

From this point the parsing logic is the following : the selected Router Module queries the device  first for its basic properties, like Model, Type and Version information, then checks for logical (or  virtual) systems defined on the device and also scans the available VRF routing instances.  Then, for each defined logical system and VRF the Router Module will collect interface level data and examine and report to discovery engine the protocols running on that entity. A  network entity in this context is the logical system – routing instance (VRF) pair. 

In the next step,  the discovery engine will handle each protocol separately and – similarly to above – identifies the  appropriate Protocol Parser Module that matches the vendor, device type and protocol. When identified,  the selected Protocol Parser Module will be invoked to examine the given protocol and find  available peers.  The Protocol Parser Module will need to understand the protocol details, find peers’ router ID  and peering ip address, then register that neighbour with the discovery engine using NDE API.

At this point there is a difference what type of discovery is being run:  

• If an Active discovery is running, the discovery engine will add the peer address to the list  of devices awaiting discovery, assuming that peer matches the actual discovery domain  definition parameters.
• If the discovery process is not in active mode, the details of peering will be registered in  the topology database, but the new peer will not be appended to the discovery list.  

For security reasons, it is very common in networks, that SSH or Telnet connections are not  allowed over the ip addresses discovered by analyzing the protocol peering or static route  destinations. To overcome this situation and correctly identify a peer entity, PGT will always  search the Favorite host database – if available - for the management address of a discovered peer entity. Each Favorite host entry has a field named “secondary ip addresses”. If a newly discovered peer’s ip address can be found in this list of a Favorite host entry, PGT will pick the management address of that device to initiate discovery connection. At the same time, the discovery engine will  also populate this list once a connection is made and routed interface addresses are collected.  As a best practice, always use the management addresses of devices as a seed to start a new  discovery.  

Router and Protocol Parser Modules can be divided into three main categories:  

• Python Script modules, also called PYModules. These are simple and pure Python scripts  implementing functionality to qualify as a valid Router - or Protocol Parser module. These  modules are the easiest to validate, debug and develop, and therefore Network Map will  primarily be focusing on them.
• Visual Script based modules, also called VSModules. They are regular Visual Scripts with  a set of specific call and parameter conventions to properly act as a Router or  ProtocolParser. PGT provides comprehensive development and debugging support for Python based vScripts.
• .NET assemblies(DLL-s) implementing required NetworkMap API interfaces. Such  assemblies are typically developed using an IDE like Microsoft Visual Studio, or any other  development software.  

Below graphic will depict the internal architecture of NDE:

Next steps

Now that you understands the basics, check out upcoming posts to find out how discovery works in practice.