Meet us at Cisco Live Las Vegas 2024
Home
>
Blog
>
Network Discovery Part 2: Setting Forth into the Great Unknown

Network Discovery Part 2: Setting Forth into the Great Unknown

7 minute read
Home
>
Blog
>
Network Discovery Part 2: Setting Forth into the Great Unknown
Updated: October 27, 2023
February 12, 2019
Updated: October 27, 2023
7 mins

In this post, we looked at the network discovery process overall. Here, we'll dive into how exactly automated network assurance can change this process. Traditionally, you'd rely on a time-consuming manual process that will result in a High-Level Design (HLD) document, Low-Level Design document (LLD), access credentials, a list of devices with access information, and more. However, the IP Fabric approach can flip how you view this necessary information. Are static documents really an effective way of documenting a large and complex enterprise network? Why not rely on dynamically updated documentation that comprehensively captures your network state at a point in time, using no hours or effort from your engineers?

To contrast two methods of discovering the network - manual vs IP Fabric - let's use a simple High-Level Design doc as our case study. We'll assume:

  • The network contains about 20–30 devices with approximately 10–15 connected hosts
  • Two routers are like exit points for all the traffic, connected to the switching core on the LAN side. There is also a VPN block and a DC block connected to the same switching core to provide various functions.
  • All the devices are managed manually through SSH or TELNET, use local credentials, and use specific SNMP community string for management purposes
  • The whole IP addressing scheme is based on the private IP addresses, mostly from 172.16.0.0/12 and using other IPs from the RFC 1918. Additionally, 172.31.100.0/24 is allocated for the management loopbacks.

Now that we have all the information we need, let’s start  discovering the network.

Please note that this whole lab is virtual and based on the IOL devices; therefore the switch is identified as “linux_l2” and router as “linux-l3.”

The Manual Method

So that we can see how beneficial IP Fabric is, we’ll need to go over the traditional manual method of discovering a network.

The manual method is an old concept that shouldn’t be used on the kind of networks we’re dealing with — large and complex networks. However, it may very well be the method you're stuck with today. To start, use a device list that looks like this:

After that, we need to log into the first known device so that we can connect with other devices, starting with the ones closest to the center. Use commands to:

  • collect information on the vendor, device type and specific product ID
  • collect information on the interfaces and IP addresses configured locally, including management loopback
  • check the CDP/LLDP neighbor table and the details of each directly adjacent device

Every node needs to be checked, and every adjacent device should be noted for later examination. The short video below shows the beginning of this manual process.

1*eQBcxtQFMBq ZrpT9R qQ
Manual network discovery

It’s blatantly evident that this approach is very time-consuming and isn’t feasible for large, complex networks. When creating a proper network diagram, all active interfaces need to be documented, and each device needs to be drawn in relation to neighboring devices throughout the whole network.

Your mileage may vary, but analyzing all the active nodes and filling out the table above took us approximately 45 minutes, drawing the network diagram took somewhere around an additional 30 minutes.

Automate Whenever Possible

Today, businesses see the value in automating repetitive tasks to save time, which in turn cuts costs. There are plenty of methods that can be used to simplify the network discovery — you could, for example, use your own scripts and very simple tools like NMAP or BASH scripting, then use some management protocol, like SNMP (shown below).

1*q69BlBCBRSOhuzyLQg7oJg
Simple network discovery automation

The example above shows two phases — getting the IP addresses, then gathering the specific data from these SNMP-activated hosts through a simple script.

The Device List

Compiling a list of active devices with a specific IP can be done a few different ways — you can ping the entire subnet (as the HLD stated all the IP addresses are from the 172.16/12 subnet), or you can use a Nmap command can make it more effective.

root@tom-linuxmint:~/lab# nmap -sn -n --host-timeout 2s 172.31.100.0/24 | grep Nmap 
Starting Nmap 7.60 ( https://nmap.org ) at 2018-12-31 08:58 CET
Nmap scan report for 172.31.100.1
Nmap scan report for 172.31.100.2
Nmap scan report for 172.31.100.3
Nmap scan report for 172.31.100.4
Nmap scan report for 172.31.100.5
Nmap scan report for 172.31.100.6
Nmap scan report for 172.31.100.7
Nmap scan report for 172.31.100.8
Nmap scan report for 172.31.100.9
Nmap scan report for 172.31.100.10
Nmap scan report for 172.31.100.11
Nmap scan report for 172.31.100.51
Nmap scan report for 172.31.100.52
Nmap scan report for 172.31.100.53
Nmap scan report for 172.31.100.54
Nmap scan report for 172.31.100.55
Nmap scan report for 172.31.100.60
Nmap scan report for 172.31.100.61
Nmap scan report for 172.31.100.62
Nmap scan report for 172.31.100.63
Nmap scan report for 172.31.100.101
Nmap scan report for 172.31.100.102
Nmap scan report for 172.31.100.103
Nmap scan report for 172.31.100.104
Nmap done: 256 IP addresses (24 hosts up) scanned in 2.02 seconds

This method uses ICMP echo without any protocol probe (TCP/UDP), so a much better and more effective way would be to check some specific protocol availability. For example, TCP/22 and TCP/23 can be used to test the Telnet and SSH port and UDP/161 to check SNMP port, as shown below:

root@tom-linuxmint:~/lab# nmap -sU -p 161 172.31.100.0/24 | grep Nmap
Starting Nmap 7.60 ( https://nmap.org ) at 2018-12-31 10:20 CET
Nmap scan report for 172.31.100.1
Nmap scan report for 172.31.100.2
Nmap scan report for 172.31.100.3
Nmap scan report for 172.31.100.4
Nmap scan report for 172.31.100.5
Nmap scan report for 172.31.100.6
Nmap scan report for 172.31.100.7
Nmap scan report for 172.31.100.8
Nmap scan report for 172.31.100.9
Nmap scan report for 172.31.100.10
Nmap scan report for 172.31.100.11
Nmap scan report for 172.31.100.51
Nmap scan report for 172.31.100.52
Nmap scan report for 172.31.100.53
Nmap scan report for 172.31.100.54
Nmap scan report for 172.31.100.55
Nmap scan report for 172.31.100.60
Nmap scan report for 172.31.100.61
Nmap scan report for 172.31.100.62
Nmap scan report for 172.31.100.63
Nmap scan report for 172.31.100.101
Nmap scan report for 172.31.100.102
Nmap scan report for 172.31.100.103
Nmap scan report for 172.31.100.104
Nmap done: 256 IP addresses (24 hosts up) scanned in 3.96 seconds

Nmap is checking to see if the UDP/161 is open or not since there isn’t any SNMP specific check with the community or version test. These outputs are returning the same set of IP addresses, but in the real network, these lists can be different since not all active devices can be managed through the SNMP.

Device Details

This BASH script uses the previous list of devices as an input data and processes each item as follows:

#!/bin/bash
filename='lab-active-devices'
echo Start
while read p; do
if snmpget -v2c -c labnet $p iso.3.6.1.2.1.1.1.0 | grep -q 'Cisco'; then
vendor="Cisco"
hostname=`snmpget -v2c -c labnet $p iso.3.6.1.2.1.1.5.0 | awk '{print $4}'`
ios=`snmpget -v2c -c labnet $p iso.3.6.1.2.1.1.1.0 | grep Software | awk '{print $9}'`
fi
echo "$p, ${hostname:1:-1}, $vendor", ${ios:1:-2}
done < $filename

The only function executed is checking SNMP OID for sysDescr to test if it’s a Cisco device or not. It can be extended for other vendors if needed, but it’s enough for this lab to distinguish between a Cisco and non-Cisco device. The function then uses sysName for the device hostname and again uses the sysDescr to get the IOS version. This approach is used only for this demonstration as an illustration on how to use SNMP framework and simple scripts — the key is to know what to get and how to represent it using known tools like scripting or post-process editing tools, (like office tools, for example).

The same mechanism can be used to create a network diagram, but the Nmap should check the whole IP space, and the scripts should access all of the devices, analyzing the directly connected subnets. Pairing the devices within the same subnets creates the baseline for the network diagram and should be extended with specific IPs and interface names.

Using this process, this list of devices was created in just five minutes (instead of the 45 minutes it took compiling it the manual way). Creating scripts to gather all of the data for the network diagram took around five more minutes, and the topology was built in approximately 25 minutes.

Using IP Fabric

Network discovery can be completed by a few tools that already exist, but so that you can understand the unique benefits of IP Fabric's platform, let’s take a look at the tool’s incredibly easy setup and deployment process. To get started, all you need to do is enter the credentials IP Fabric will need to access the network devices, and supply a few other details for use during the discovery process.

IP Fabric— Setting the access credentials for device access

If you’d like, you can set additional parameters. We’re going to use these in our example:

  • Settings-Advanced-Discovery-IP networks to include — 0.0.0.0/0
  • Settings-Advanced-Discovery-IP networks to exclude — 10.0.0.0/8
  • Settings-Discovery Seed-Starting point 172.16.1.5

Once that’s done, hit the play, sit back, and watch IP Fabric get to work (example shown below).

1* HIF8TekoFlI4DVfQ1eEKg
IP Fabric — Discovery process

The entire process is automatic, without any interaction from you needed, and IP Fabric saves all data that it generates for further analysis and graphical presentation.

The first part of the results that you should check is the inventory list (shown below). Compare the list IP Fabric generated to the one you created manually, to see if any differences exist. It shocks many users when they see results on the IP Fabric list that escaped their eye when they built the list manually.

1*ywWaJkGpbUHAG6F1IMNKBQ
IP Fabric — Inventory list

As you can see, the list shows a significant amount of network device details, including vendor information, management IP address, software version, and even additional information like uptime, memory usage, etc. Not only does this help us validate our assumptions, but it provides additional helpful information, which helps expand our knowledge base.

Network Diagrams

The next part of IP Fabric’s results that you should check is the network diagram graphic.

Screenshot 2023 08 23 at 16.24.00
IP Fabric — the network diagram (default view)

The diagram visually groups the devices based on site name (you can adjust the site naming convention in the discovery settings with regexp string). It’s not a diagram of the practical look of the network, but IP Fabric offers ways of modifying the diagram by clicking the cloud images, hiding site boundaries, showing (or hiding) the L2/L3 connections, etc. With these features, you can use IP Fabric to create a diagram closer to the real topology, like the one shown below.

Screenshot 2023 08 23 at 16.25.42

Now that we’ve covered how quick and easy it is to deploy and use IP Fabric, making it the obvious choice when discovering unknown networks, you’re ready to try it out for yourself.

Lastly, we’re going to delve into more great ways that IP Fabric can help simplify your work life, so keep an eye out for more parts of this series.

To learn more about how IP Fabric’s platform can help you with analytics or intended network behavior reporting, feel free to get in touch with the team, or try our self-guided demo!

Groupe de masques 26

Try IP Fabric

Take your time to experience our automated 
network assurance platform in peace.
Free Demo | Zero Obligation
Online  Demo

Network Discovery Part 2: Setting Forth into the Great Unknown

In this post, we looked at the network discovery process overall. Here, we'll dive into how exactly automated network assurance can change this process. Traditionally, you'd rely on a time-consuming manual process that will result in a High-Level Design (HLD) document, Low-Level Design document (LLD), access credentials, a list of devices with access information, and more. However, the IP Fabric approach can flip how you view this necessary information. Are static documents really an effective way of documenting a large and complex enterprise network? Why not rely on dynamically updated documentation that comprehensively captures your network state at a point in time, using no hours or effort from your engineers?

To contrast two methods of discovering the network - manual vs IP Fabric - let's use a simple High-Level Design doc as our case study. We'll assume:

  • The network contains about 20–30 devices with approximately 10–15 connected hosts
  • Two routers are like exit points for all the traffic, connected to the switching core on the LAN side. There is also a VPN block and a DC block connected to the same switching core to provide various functions.
  • All the devices are managed manually through SSH or TELNET, use local credentials, and use specific SNMP community string for management purposes
  • The whole IP addressing scheme is based on the private IP addresses, mostly from 172.16.0.0/12 and using other IPs from the RFC 1918. Additionally, 172.31.100.0/24 is allocated for the management loopbacks.

Now that we have all the information we need, let’s start  discovering the network.

Please note that this whole lab is virtual and based on the IOL devices; therefore the switch is identified as “linux_l2” and router as “linux-l3.”

The Manual Method

So that we can see how beneficial IP Fabric is, we’ll need to go over the traditional manual method of discovering a network.

The manual method is an old concept that shouldn’t be used on the kind of networks we’re dealing with — large and complex networks. However, it may very well be the method you're stuck with today. To start, use a device list that looks like this:

After that, we need to log into the first known device so that we can connect with other devices, starting with the ones closest to the center. Use commands to:

  • collect information on the vendor, device type and specific product ID
  • collect information on the interfaces and IP addresses configured locally, including management loopback
  • check the CDP/LLDP neighbor table and the details of each directly adjacent device

Every node needs to be checked, and every adjacent device should be noted for later examination. The short video below shows the beginning of this manual process.

1*eQBcxtQFMBq ZrpT9R qQ
Manual network discovery

It’s blatantly evident that this approach is very time-consuming and isn’t feasible for large, complex networks. When creating a proper network diagram, all active interfaces need to be documented, and each device needs to be drawn in relation to neighboring devices throughout the whole network.

Your mileage may vary, but analyzing all the active nodes and filling out the table above took us approximately 45 minutes, drawing the network diagram took somewhere around an additional 30 minutes.

Automate Whenever Possible

Today, businesses see the value in automating repetitive tasks to save time, which in turn cuts costs. There are plenty of methods that can be used to simplify the network discovery — you could, for example, use your own scripts and very simple tools like NMAP or BASH scripting, then use some management protocol, like SNMP (shown below).

1*q69BlBCBRSOhuzyLQg7oJg
Simple network discovery automation

The example above shows two phases — getting the IP addresses, then gathering the specific data from these SNMP-activated hosts through a simple script.

The Device List

Compiling a list of active devices with a specific IP can be done a few different ways — you can ping the entire subnet (as the HLD stated all the IP addresses are from the 172.16/12 subnet), or you can use a Nmap command can make it more effective.

root@tom-linuxmint:~/lab# nmap -sn -n --host-timeout 2s 172.31.100.0/24 | grep Nmap 
Starting Nmap 7.60 ( https://nmap.org ) at 2018-12-31 08:58 CET
Nmap scan report for 172.31.100.1
Nmap scan report for 172.31.100.2
Nmap scan report for 172.31.100.3
Nmap scan report for 172.31.100.4
Nmap scan report for 172.31.100.5
Nmap scan report for 172.31.100.6
Nmap scan report for 172.31.100.7
Nmap scan report for 172.31.100.8
Nmap scan report for 172.31.100.9
Nmap scan report for 172.31.100.10
Nmap scan report for 172.31.100.11
Nmap scan report for 172.31.100.51
Nmap scan report for 172.31.100.52
Nmap scan report for 172.31.100.53
Nmap scan report for 172.31.100.54
Nmap scan report for 172.31.100.55
Nmap scan report for 172.31.100.60
Nmap scan report for 172.31.100.61
Nmap scan report for 172.31.100.62
Nmap scan report for 172.31.100.63
Nmap scan report for 172.31.100.101
Nmap scan report for 172.31.100.102
Nmap scan report for 172.31.100.103
Nmap scan report for 172.31.100.104
Nmap done: 256 IP addresses (24 hosts up) scanned in 2.02 seconds

This method uses ICMP echo without any protocol probe (TCP/UDP), so a much better and more effective way would be to check some specific protocol availability. For example, TCP/22 and TCP/23 can be used to test the Telnet and SSH port and UDP/161 to check SNMP port, as shown below:

root@tom-linuxmint:~/lab# nmap -sU -p 161 172.31.100.0/24 | grep Nmap
Starting Nmap 7.60 ( https://nmap.org ) at 2018-12-31 10:20 CET
Nmap scan report for 172.31.100.1
Nmap scan report for 172.31.100.2
Nmap scan report for 172.31.100.3
Nmap scan report for 172.31.100.4
Nmap scan report for 172.31.100.5
Nmap scan report for 172.31.100.6
Nmap scan report for 172.31.100.7
Nmap scan report for 172.31.100.8
Nmap scan report for 172.31.100.9
Nmap scan report for 172.31.100.10
Nmap scan report for 172.31.100.11
Nmap scan report for 172.31.100.51
Nmap scan report for 172.31.100.52
Nmap scan report for 172.31.100.53
Nmap scan report for 172.31.100.54
Nmap scan report for 172.31.100.55
Nmap scan report for 172.31.100.60
Nmap scan report for 172.31.100.61
Nmap scan report for 172.31.100.62
Nmap scan report for 172.31.100.63
Nmap scan report for 172.31.100.101
Nmap scan report for 172.31.100.102
Nmap scan report for 172.31.100.103
Nmap scan report for 172.31.100.104
Nmap done: 256 IP addresses (24 hosts up) scanned in 3.96 seconds

Nmap is checking to see if the UDP/161 is open or not since there isn’t any SNMP specific check with the community or version test. These outputs are returning the same set of IP addresses, but in the real network, these lists can be different since not all active devices can be managed through the SNMP.

Device Details

This BASH script uses the previous list of devices as an input data and processes each item as follows:

#!/bin/bash
filename='lab-active-devices'
echo Start
while read p; do
if snmpget -v2c -c labnet $p iso.3.6.1.2.1.1.1.0 | grep -q 'Cisco'; then
vendor="Cisco"
hostname=`snmpget -v2c -c labnet $p iso.3.6.1.2.1.1.5.0 | awk '{print $4}'`
ios=`snmpget -v2c -c labnet $p iso.3.6.1.2.1.1.1.0 | grep Software | awk '{print $9}'`
fi
echo "$p, ${hostname:1:-1}, $vendor", ${ios:1:-2}
done < $filename

The only function executed is checking SNMP OID for sysDescr to test if it’s a Cisco device or not. It can be extended for other vendors if needed, but it’s enough for this lab to distinguish between a Cisco and non-Cisco device. The function then uses sysName for the device hostname and again uses the sysDescr to get the IOS version. This approach is used only for this demonstration as an illustration on how to use SNMP framework and simple scripts — the key is to know what to get and how to represent it using known tools like scripting or post-process editing tools, (like office tools, for example).

The same mechanism can be used to create a network diagram, but the Nmap should check the whole IP space, and the scripts should access all of the devices, analyzing the directly connected subnets. Pairing the devices within the same subnets creates the baseline for the network diagram and should be extended with specific IPs and interface names.

Using this process, this list of devices was created in just five minutes (instead of the 45 minutes it took compiling it the manual way). Creating scripts to gather all of the data for the network diagram took around five more minutes, and the topology was built in approximately 25 minutes.

Using IP Fabric

Network discovery can be completed by a few tools that already exist, but so that you can understand the unique benefits of IP Fabric's platform, let’s take a look at the tool’s incredibly easy setup and deployment process. To get started, all you need to do is enter the credentials IP Fabric will need to access the network devices, and supply a few other details for use during the discovery process.

IP Fabric— Setting the access credentials for device access

If you’d like, you can set additional parameters. We’re going to use these in our example:

  • Settings-Advanced-Discovery-IP networks to include — 0.0.0.0/0
  • Settings-Advanced-Discovery-IP networks to exclude — 10.0.0.0/8
  • Settings-Discovery Seed-Starting point 172.16.1.5

Once that’s done, hit the play, sit back, and watch IP Fabric get to work (example shown below).

1* HIF8TekoFlI4DVfQ1eEKg
IP Fabric — Discovery process

The entire process is automatic, without any interaction from you needed, and IP Fabric saves all data that it generates for further analysis and graphical presentation.

The first part of the results that you should check is the inventory list (shown below). Compare the list IP Fabric generated to the one you created manually, to see if any differences exist. It shocks many users when they see results on the IP Fabric list that escaped their eye when they built the list manually.

1*ywWaJkGpbUHAG6F1IMNKBQ
IP Fabric — Inventory list

As you can see, the list shows a significant amount of network device details, including vendor information, management IP address, software version, and even additional information like uptime, memory usage, etc. Not only does this help us validate our assumptions, but it provides additional helpful information, which helps expand our knowledge base.

Network Diagrams

The next part of IP Fabric’s results that you should check is the network diagram graphic.

Screenshot 2023 08 23 at 16.24.00
IP Fabric — the network diagram (default view)

The diagram visually groups the devices based on site name (you can adjust the site naming convention in the discovery settings with regexp string). It’s not a diagram of the practical look of the network, but IP Fabric offers ways of modifying the diagram by clicking the cloud images, hiding site boundaries, showing (or hiding) the L2/L3 connections, etc. With these features, you can use IP Fabric to create a diagram closer to the real topology, like the one shown below.

Screenshot 2023 08 23 at 16.25.42

Now that we’ve covered how quick and easy it is to deploy and use IP Fabric, making it the obvious choice when discovering unknown networks, you’re ready to try it out for yourself.

Lastly, we’re going to delve into more great ways that IP Fabric can help simplify your work life, so keep an eye out for more parts of this series.

To learn more about how IP Fabric’s platform can help you with analytics or intended network behavior reporting, feel free to get in touch with the team, or try our self-guided demo!

Groupe de masques 26

Try IP Fabric

Take your time to experience our automated 
network assurance platform in peace.
Free Demo | Zero Obligation
Online  Demo
SHARE
Demo

Try out the platform

Test out IP Fabric’s automated network assurance platform yourself and be inspired by the endless possibilities.

What would this change for your network teams?
Start live demo
 
 
 
 
 
We're Hiring!
Join the Team and be part of the Future of Network Automation
Available Positions
IP Fabric, Inc.
115 BROADWAY, 5th Floor
NEW YORK NY, 10006
United States
This is a block of text. Double-click this text to edit it.
Phone : +1 617-821-3639
IP Fabric s.r.o.
Kateřinská 466/40
Praha 2 - Nové Město, 120 00
Czech Republic
This is a block of text. Double-click this text to edit it.
Phone : +420 720 022 997
IP Fabric UK Limited
Gateley Legal, 1 Paternoster Square, London,
England EC4M 7DX
This is a block of text. Double-click this text to edit it.
Phone : +420 720 022 997
IP Fabric, Inc. © 2024 All Rights Reserved