How do you run scripts to collect data from routers and switches today? You prepare some commands in a text editor then open a Terminal application and copy-paste the commands, one-by-one, also collecting the response to another text document? And then you perform some magic text processing to extract the relevant data that is finally copied to a spreadsheet? We have a better idea…

1. Once I participated on a brainstorming session where we were asked about our visions on how the
operation of a NOC could be made more effective and fancy, including any ideas about future, not
even yet existing technologies or devices.
That time I envisioned a big, transparent glass wall displaying the interactive, live topology of the
network. You know, I am talking about something you can see in the Iron Man movie series Tony
Stark works with.
And no, I am definitely not yet there :-)
But I took the first step in creating an interactive network map I am introducing shortly in this article.
1 What is Network Map
The Network Map is an optional module of PGTnetwork which is designed to perform discovery and
visualization of Layer 3 network infrastructure. The discovery engine will analyze routing protocols
for each hop by means of parser modules to crawl through the routed network. Most of the parser
modules are written in Python and represented as a Visual Script to make customization easy.
Below sections will briefly describe the concepts of the tool and demonstrate how to quickly perform
a network discovery. If you prefer watching videos instead, a more detailed training video series is
also available at PGTnetwork website: https://pgtnetwork.com/
2 Overview
Network Map uses parser modules to analyse routing protocols by sending specific CLI commands
and interpreting the response. As a result, network discovery is performed using Telnet/SSH
connections and not SNMP.
Parser modules are organized into two main categories:
 Router modules: a router module must be able to retrieve specific configuration items from a
connected device;
 Protocol Parsers: a protocol parser must provide support for a given Router module by
parsing one or more protocols
A specific parser module can provide support for a particular vendor and/or model and a given
protocol, like routing protocol. At the time of writing only layer 3, routing protocol parsers are
supported but later layer 2 parsers - like LLDP or CDP - will also be added.

2. An example module would be the Cisco IOS Router module that is able to handle Cisco IOS routers.
Another one is the Juniper OSPF Protocol Parser that is able to understand and parse OSPF protocol
details on JunOS based Juniper router / switch or even SRX firewall.
Parser modules can be dynamically added to Network Map to provide support for a new vendor or
model or routing protocol. Parsers can also be implemented as dll-s using Network Discovery API or
can be written in Python as Visual Scripts.
PGT delivers many examples for both scenarios and also includes vScript templates for Router and
ProtocolParser modules. All of the .NET based default parser modules are open sourced, and the C#
code can be cloned from Github repository PGTNetworkMap.Parsers:
https://github.com/lafrank/PGTNetworkMap.Parsers
The output of a network discovery is an interactive graph that can be saved to file and loaded later
on demand. Network Map is tightly integrated with Favourite host database, therefore it is
recommended to populate Favourite hosts beforehand, although this is not a prerequisite.
3 Perform a Quick discovery
To start a network discovery, one must specify at least one device by its ip address. This is going to be
the seed device from where discovery can start. Alternatively, multiple seed devices can be enlisted
to speed up discovery. The Device list is a free text entry, the only requirement is to specify one ip
address per line, other fields in a line separated by comma are optional:
When started, the discovery engine will connect to the specified seed devices and select and launch
the appropriate parsers to discover the connected device and search for new peers. The number of
parallel connections can be controlled depending on actual system capability.

3. As discovery crawls through the network, new peers will be detected and added to discovery list
depending on the Discovery Domain specification. A Discovery Domain is specified by the ip address
to be included or excluded and the routing protocols to be examined on each entity :
If the Discovery Domain specification allows, a peer will be added to the list of items awaiting
discovery, and will be assigned a priority value. As the scheduler allocates parsers to connected
devices, this priority will be considered. Items with lower priority would be served first. The priority
assigned to a new discovery item depends on the routing protocol that discovered the new peer,
with BGP given the highest priority (lowest value) and STATIC routing is the lowest (the highest
value).
The Discovery Domain specification tab will allow the selection of a routing protocol only if a Protocol
Parser Module is detected that supports a given protocol.
The list of available modules and supported devices / protocols can be checked on the Modules &
Settings tab:

4. Returning to discovery, if everything looks good, press the big green “Start discovery process” button
on the Discovery List tab. The discovery engine will slowly start connecting to specified hosts and
display the discovery status :

5. Once the discovery is done, the view will be switched to the Network Topology tab :
The displayed map is an interactive map, from where one can start connecting to a device or initiate
script generation or check properties by right clicking an entity:
More information: https://pgtnetwork.com/product-overview/