Meet us at Cisco Live Las Vegas 2024

Today, it is our pleasure to announce new version of our IP Fabric platform. Version 2.4 is in a general availability release that extends our product capability in technologies usually found in datacenter and network edge environments, namely VXLANs and Multi-protocol BGP address families.


Features — Protocols and Technology Support

VXLAN

For customers using Virtual eXtensible LAN overlays in their datacenters, we are adding support for this technology in both Diagrams and Technology Tables. The platform provides with information about Virtual Tunnel Endpoints (VTEP) in the network, their peers, configured interfaces and VXLAN VNI.

1*yPXywPUzbP2evUk68BsPtA
VXLAN Topology in Diagrams

Flow export

To support traffic recording efforts of our clients we are introducing support for global Flow Exporter overview and configuration verification. Regardless if the technology used is NetFlow, Flexible NetFlow, IPFIX or sFlow, we now provide you with detailed overview of the devices configured for traffic exporting. Additional details provide information about all the configured collectors and interfaces used for exporting traffic to them.

1*1nZAGNZUKF bBNJfi0FPSA
Flow Export Overview with drill-down details

Simple Network Management Protocol

Although the Simple Network Management Protocol is one of the oldest network protocols, it is still widely used in network management for network monitoring. However, there are some risks associated with use of this protocol. First, when this protocol was created in 1980's, the idea was, that it will be used also for network configuration and second, there are well known community names for both read-only and read-write access to the devices. Last issue is, that except the last version of the protocol — version 3, there is no way to ensure authentication and privacy of the messages. Our tool can help you to improve the security of your network in couple ways — within seconds you can identify devices that are still using well-known public/private communities, find the devices that are using some non-standard communities and get rid of legacy SNMP protocol versions 1 and 2 completely, replacing it with SNMPv3. Of course, if you are using SNMP traps, we provide you with overview of all the SNMP Trap hosts configured on your gear as well.

1*dzLSP5RKEKR6f37zawPWYA
Global SNMP community verification

Logging

All devices are generating amount of logging messages that can be stored locally on the device or, ideally sent to a central syslog servers or SIEM systems for correlation of events. Our tool again arms you with a visibility into what syslog servers are configured and where, so you can easily clean up the legacy servers configurations and ensure that the proper servers are in place, so that you don't miss any message your device wants to tell you.

1*tB3NeXSgLAJU2F7cL ZK6w
Syslog server IP verification

Further improvements

We have worked hard on network discovery, where we improved detection of various platforms. The Diagrams now load much faster then ever before, especially in big network environments. Last, but not least, we now support BGP address families, where we provide with a new Technology table with all address family sessions configured along with their state.

For those interested in serious automation with our platform, we have published documentation of our platforms' API. You can find it here.

If you’re interested in learning more about how IP Fabric’s platform can help you with analytics or intended network behavior reporting, contact us through our website, request a demo, follow this blog or sign up for our webinars.

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:

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:

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:

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

Documentation is a critical part of any project or technical environment. If we don’t jot down some important information along the way, we end up repeatedly asking the same basic questions over and over again, completely draining our team members. We’ve heard from many team members that have admitted that the most annoying part of their day is answering those same repetitive questions day after day.

Manual updates are history

To begin with, when it comes to documenting computer networks (or other similar systems) we tend to use programs like draw.io or Visio. These programs are fantastic for outline ideas during the creative process of designing a new network. Furthermore, tools like these help us visualize our concepts, present them to others, then easily update those ideas as they evolve into a more cohesive plan.

For these tasks, these tools are great, but when the environment goes live… we quickly discover that we need something more.

Content updates to documentation can be a pain to maintain, especially for some of the more extensive networks — and the larger the network, the more changes an organization seems to want to make per day.

One solution to this issue is to appoint a dedicated team member (or, depending on the size of the network, an entire team) with the task of maintaining documentation. Whether they’re frequently updating the documentation themselves, or pushing the engineers to update the documentation after each update, this becomes quite the labor-intensive task.

Automation Simplifies

Before we built the IP Fabric platform, we knew that there had to be some way to save time during time-consuming network operations processes. After simplifying that process through automation, we then took that same logic and turned our sights on the documentation process. Hence, we added a feature to the platform that gathers more than 1000 parameters from a single network device.

Now, on top of generating breathtaking interactive network diagrams, the platform can generate low level design documents. After every discovery snapshot, the platform creates a report that includes all the information needed for an audit, including device inventory details, physical layer, data-link layer details, routing and switching details.

LLD Download example
LLD Download example

These documents full of fancy diagrams can be generated whenever needed, and can easily be modified or compared to previous versions. This feature is an excellent timesaver for any Network Engineer or Network Engineering Manager, which helps them become a much more productive team member. Instead of wasting time working on mundane tasks, they can focus on tasks that create value. For example, examining overall network architecture, increasing stability, or having some spare time to enjoy their cup of coffee.

Low Level Design document digest
Low Level Design document digest

If you’re interested in learning more about how IP Fabric’s platform can help you with analytics or intended network behavior reporting, contact us through our website, request a demo, follow this blog or sign up for our webinars.

Companies are spending big money on defensive measures against the outside attackers — investing into Next-Generation Firewalls, Intrusion Prevention Systems and Proxies. The inner network, however, was considered safe place, where nothing bad can happen.

This understanding has thankfully changed in recent years, especially with rise of mobility technologies allowing employees to work anywhere and concepts like Bring Your Own Device (and some major incidents as well, of course). Today's network administrator has to think about various types of devices connecting to the internal network and policy, how to treat them to keep the internal network and business critical systems safe.


Solution

Solution to this problem is to deploy network wide 802.1 x protocol, that allows the user to access the network just if he is able to authenticate himself using a username and password, or a valid certificate issued by the company. Various options are available and listing all the details would be worth a book.

It is not always straightforward deployment, as these types of projects tend to be slow and need proper user testing, because otherwise the users won't be able to work at all. Usually there are user machine issues that need to be rectified temporarily by disabling the 802.1 x protocol authentication on the switchport of the affected user and after couple days, no one knows, where the security is applied and where it is not.


Verification

With IP Fabric's platform, finding information about the ports secured by 802.1 x protocol is easy, and you can specify verification to tell you which network edge ports, connecting to end stations, are open and which are secured properly. For example, simple verification could do this:

Setup is actually trivial, with the most complicated part being the selection of what is physical and what is virtual interface. Good news is, that we've configured this already for you. The actual outcome of this verification looks like this:

802.1 x protocol Interfaces Verification
802.1x Interfaces Verification

Instead of manually verifying every interface or developing custom script for every platform out there, hundreds of hours of engineering time can be saved using this continuous verification instead. Also, it can be used as an evidence of how the 802.1 x protocol rollout project is proceeding and that the network is properly secured and there are no open interfaces, that would render your network insecure.

This will ensure the setup of the Interfaces on all devices in the network. In regards to the other part — RADIUS server configuration — this was covered in one of the recent articles, so you may check it out to create similar specific rules that will configure IP Fabric to verify your specific AAA needs consistently in a matter of seconds.

If you’re interested in learning more about how IP Fabric’s platform can help you with analytics or intended network behavior reporting, contact us through our website, request a demo, follow this blog or sign up for our webinars.

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