Week commencing 1st June 2020, and another minor release - IP Fabric 3.5.2 - is ready for deployment! Let's sum up what the latest release has to offer.
The 3.5 version started with multicast support with routing capabilities and the impressive distribution tree simulation in diagrams. The new 3.5.2 release adds information about PIM Rendezvous Points (RPs) and IGMP Snooping state. Now engineers can fully analyze multicast forwarding across LAN and WAN. IGMPv2 and IGMPv3 protocols are supported on multiple vendor platforms.
The Cisco Firepower support was introduced in mid-2019 with basic discovery features. IP Fabric version 3.5.2 is a significant milestone in the Cisco Firepower platform capability. We have now introduced full support for AAA, ACLs, NAT, and Object Groups, to mention but a few features.
Security is inevitably a critical part of any infrastructure and we continue to develop IP Fabric's capabilities in that area. On the roadmap for later in 2020 is a major release to address network security specifically. Expect to see significantly enhanced support for other vendors' firewall platforms, and for new network security features in general!
IP Fabric discovery is already fast, but we feel we can always make it faster! Up to now, every time IP Fabric created a snapshot it automatically attempted to discover any new nodes beyond those it already knew about.
In version 3.5.2, you can now limit a new snapshot to only update already-discovered network devices. This prevents IP Fabric from firing up the discovery algorithm that detects new devices on the network. This capability of locking the discovery scope is a huge improvement for large scale networks. Let's see how it works.
Previously the standard discovery process started with already-discovered devices. IP Fabric would then attempt to connect to unknown endpoints using the discovery algorithm.
As of version 3.5.2, if we know that our inventory is complete, we can simply tell IP Fabric not to search for new nodes. This prevents the system from spending additional time on testing more and more IP addresses as possible new devices. We then enable the discovery of new devices when we know that changes have been made. Alternatively, we use it when we're explicitly wanting to check our online inventory is up to date.
Note that we can now also modify the methods that the discovery algorithm uses to find and identify neighbors in the topology. This is helpful for optimizing the discovery, for example, if we are certain, that one of the methods is not supported in our network devices or is not configured.
In 3.5.2, you can also see our commitment to continue to improve support for multiple network vendors. Changes to feature support and improvements are evident for:
More details at IP Fabric Release Notes.
There are some BIG updates coming over the next couple of major versions in the platform, due over the coming months. Keep coming back to wordpress-625423-2416527.cloudwaysapps.com and follow IP Fabric on LinkedIn for more information as it drops!
Network documentation is a very complex and thorough topic - there are many guidelines, theories and even books that can help us with the process of creating and maintaining proper documents describing the network. The concept and execution may vary, but the purpose of the documentation should be unique - to represent the current state and settings of the network and all of the respective components. Let’s skip the document’s life cycle stages, like where to store the documents, how long the information should be stored for, how to track the changes etc., as there is much to cover on this topic. What is most important, is knowing what to document from a networking point of view, and how to represent the data.
Ideally, the network documentation should enable reconstructing the network from scratch. In case a change is being planned, state information is necessary to plan the change correctly. In the event that the active network device goes down due to an unforeseen event, it is crucial that the network can be reverted to its previous state. And if elements of a new network should incorporate elements from the network, being able to accurately document the corresponding detail levels is particularly important.
It goes without saying that the network engineer should be able to understand the documentation corresponding to their network without unnecessary complications. Being able to fetch the device list, understanding how they are interconnected and configured, and being able to verify all of this information is essential. Although the structure of the individual documents may vary, the common approach should be adhered to – describing the network based on the Open Systems Interconnection (OSI) model.
This chapter should cover the device list, including the hardware modules, the software versions, applied patches and other hardware/software details. Documenting the device location, rack plan and physical access details is optional. The core of this section is to document the physical cabling – interface names, transceiver and cable types. IP Fabric provides all information under the Inventory section – Device list, OS versions, List of interfaces with many details.
1 - Device Inventory
The second OSI layer describes the logical rather than physical connections. It means that segmentation can follow the physical cabling but it can extend the connection by using Virtual-LANs (VLANs), the port aggregation (EtherChannel, Port-Channel, Aggregated interfaces), different types of Spanning-Tree (STP) or use proprietary concept like Fabric Path etc. All this information are important to be able to understand how the network is functional from the logical point of view. If desired, it may document the logical settings of the devices like stacks - Virtual Switching System or Stack-Wise Virtual, VDC or vPC. The format of the documented data has to be carefully considered - there are plenty of methods such as network diagrams, tables, lists or configuration snippets.
IP Fabric collects lot of details and all the data are presented in a standardized and comprehensible way. Network diagram (per site) is showing protocol-level connections and technology section provides table overview of L2 specific topics.
2 - Network L1/L2/L3 diagram
Describing the network layer should be the most critical and most extensive aspect of the network documentation, as it should cover the elements such as:
IP addressing is a subject of a separate document and specific IP Address Management (IPAM) tool may be used (free or paid) - it should cover all the network subnets configured within the network. It depends on the capabilities of the IPAM to store all the details, but from the best practice approach it should list the network subnet, the configured IP address, device and interface name. Ideally, IPAM should track the history of the changes to see when and what changes have occurred. However, most of the tools available on the market require manual database maintenance.
Routing can be simplified using few static routes within one flat routing domain, but also can be very complex and structured by using several dynamic routing protocols like EIGRP, OSPF or BGP with complex redistribution on several places within the routing domain. Therefore, it should be documented to an appropriate detail level to in order to provide network behavior insight, and enable the possibility of building the website from network documentation alone.
IP Fabric excels in this area by collecting all the data mentioned above automatically, and more; IP addresses are listed in Managed IP overview and any IP can be verified against the device/interface name, including DNS name or other few additional settings. It can be also used as an initial input to the IPAM tool - just to export all the data to the CSV format and import the values to the IPAM. Collecting the list of IP addresses and IP networks is not the core of the IP addressing management - that’s only a list of values that are being used across the whole network. That said, proper comprehension and routine updates will serve the IPAM as needed.
The fourth layer of OSI model helps securing the traffic. The control plane security means securing the data needed to establish the network functionality - routing protocols, FHRP, device management etc. It should be covered in the appropriate part based on the control protocol, e.g. securing the dynamic routing protocol or FHRP should be covered in the previous chapter, securing the device management in the chapter covering the accessing the device (Telnet, SSH, SNMP) and so on.
Data plane filtering is the core of this section - it refers to the core concept of how the production data (user data) is being filtered, and should be documented first; it can then extend to the details and provide a very detailed view of the individual access-lists statements. Another concern is, how far need you dig into the details? It depends on the complexity of the implementation as well as the corresponding security policies that can limit the amount of information that may be presented.
IP Fabric provides a coherent Access-List (ACL) overview, which also serves the ability to check the A-B path verification for specific traffic. Just enter the source and destination IP address in the network, then the traffic type - Internet Control Message Protocol (ICMP) or TCP/UDP and source/destination port in the second case.
3 - Vieving Access-Lists in the tolopolgy
The application layer is often excluded from the network documentation, but the process is changing and applications are more and more often a focal point of the new network principles and approaches. For this article and this chapter especially, the application layer description should include all the application we need to control, manage and monitor the network. Standard tools for device management are still Telnet/SSH with some corporate identity management (TACACS or Radius), and specific tools based on GUI front-end are more popular nowadays.
The network documentation process should incorporate the previous examples, but not be limited to them. There are many technologies, concepts, and network functions and it is very difficult to maintain an up-to-date overview of all such documents, especially when it comes to vast enterprise networks. Therefore, automating the process of collecting network data and subsequently creating the corresponding documents has proven to be a substantial advantage. IP Fabric eliminates the need for manual low-level design documentation; IP Fabric provides a detailed network overview for each business location, including topology visualization. Automatically generated, always available & up-to-date.
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.
If you’re a network engineer chances are pretty likely you’ve encountered some form of this situation. You get a new job (either assigned to a new customer or a one-off) and are immediately expected to execute a specific task within the network without any previous knowledge of it.
Sound familiar?
The thing is, navigating these situations effectively requires having accurate information for performing network changes and troubleshooting issues reported by the end user. Having the right info is also vital to being a part of the engineering process related to the network’s growth and evolution.
Questions that must be asked: How do you become aware of the network’s blocks, learn all the functions, and work effectively during the “on-boarding” phase? The truth is, the answers to these questions are actually more complicated than they may appear.
Over the years, I have supported lots of networks and many customers — everything from smaller networks with just a few sites across a country, larger ones covering several countries, to enterprise networks with sites worldwide. Personally, I have found that the approach to initial discovery is nearly the same with most networks regardless of size.
To start, it’s highly recommended to obtain a very high-level of information covering lots of sources.
These include but are not limited to:
Let’s cover each bullet and try to find the optimal way to discovering the unknown networks.
Reaching out to experienced colleagues is one of the most valuable ways of gaining a great initial view of any network. When a team has been working on a network for some time, they are an excellent resource for information; capable of providing technical background from their hands-on experience during the implementation and troubleshooting process.
Keep in mind; however, that is some cases, although an engineer might be great at their job, it doesn’t necessarily mean they’ll be a good teacher. There may be particular facts concerning the network that they forget to relay because for them the information isn’t important to their job.
“I thought it was pretty obvious…”
I’ve heard this exact sentence a million times, and it’s always been due to the fact that it’s tough for experienced colleagues to remember and explain all of the functions, blocks, and overall behavior.
This is the trickiest section, as documentation can either be a highly valuable source of information (if it’s up to date) or can cause a lot of pain and headaches in the case that it hasn’t been updated for a while.
There are few attributes of proper documentation, so let’s name some of them:
Since we could easily spend hours and days talking about documentation, I’m going to move on to the other topics. I’ll return to documentation in a later series.
This is the best way to get in touch with the reality of the network (as opposed to something said by a colleague or written in the documents). Utilizing monitoring tools offers a view of the actual state of the network’s devices and functions.
An excellent place to start is to go through the tools that are running and collecting a lot of data , such as network inventory to check the specific vendors and architecture and IPAM (IP Address Management). You want to focus on the structure of the network, monitoring features including alarms, and database issues in order to identify the common problems reported by different types of users, etc.
There are plenty of tools that can be run for network discovery and create automated reports, supplying an excellent source for additional information when getting started.
In other words, the approach here is about deploying monitoring tools to acquire the desired data — and that’s my point. It doesn’t matter if I’m using my own scripts (PERL, PYTHON or VBS) or some existing software, the primary goal is to go through the network, collect specific sets of data, and be able to analyze all of the outputs.
Without any doubts, having hands-on experience is the most valuable and reliable resource for information. Yes, this is a slow process since it doesn’t rely on any documents or anyone’s advice. The truth is, though, that by going through different types of devices, different blocks, parts of the network — just to see the configuration and the features being used, you learn so much first-hand. The only requirement needed is access and login to the devices.
For many smaller companies, access is usually available immediately. With larger companies and global enterprises, the process of obtaining the necessary credentials can take days if not weeks. The reasoning for this is that the administration and processes of these companies use a centralized solution to control access, such as RADIUS or TACACS+…
This is the first part of my series exploring how to become more familiar with networks from scratch. To better understand this process, I have built a small lab environment with a lot of features for testing the network discovery process without relying on pre-existing documentation or advice from colleagues.
During this series, I intend to show you the various approaches , manual work, some scripting tips, and use IP Fabric software to illustrate the differences between each method we use.
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.
The latest 2.2.8 version released very recently again brought new powerful features and updates to our customers. IP Fabric is continuously gathering feedback and request from customers and one of them was to be able to work with more network devices and vendors, specifically devices from Arista Networks.
I have been in the networking field for almost 10 years now. I started with Cisco (as majority of network techs), then shifted to Juniper and played with other switches and routers along the way (not mentioning firewalls or other equipment) like HPs, Netgear, VyOS, MRV and more, but I have honestly never ever tested equipment made by Arista before. So I am feeling a bit excited by stepping into unknown.
I am not about to let you dive through our process in detail, there are technical parts in the IP Fabric process that should be kept under the hood for special reasons. However it logically involves studying provided materials related to new technologies in detail, testing classic routing and switching topologies from start and devices’ interaction capabilities with our systems. We also work with subject matter experts and domain experts to guide us through the process.
Luckily for me I may say there may be undeniable resemblance when it comes to command line interface to other vendor that we already support. I am not gonna mention which one it is, but you can test on your own. And that is saving us some time, so we don’t have to reinvent the whole wheel in regards to device discovery. Arista Networks was founded in 2004 by former Cisco engineers, their boxes run on linux based Extensible Operating System (EOS). And I praise it a lot, it has python library included, you can jump to bash and play along as you like as in any linux environment. I haven’t tested their Json-RPC yet, but I am probably about to. I’d say the whole EOS concept is very clean and open and of course you can run your own scripts. There’s also vEOS on the market for cloud environment.
All good for now, I am very happy to announce this little teaser for next release and stay with us!
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.
As a follow-up for previously published tips for first network discovery, we’ll get into some of the details about using basic authentication features and some troubleshooting tips when it discovery itself fails.
Configuring network infrastructure access is mandatory in IP Fabric from the start and we cannot begin discovery without it. We have to have username and password at least. While enable password is optional, so is setting up various credentials per subnet, but can be a great help when not all devices are properly prepared for TACACS+ or other.
One of many great features are Connectivity Report and Error Summary console. When used together, troubleshooting becomes an easy part of every discovery. The Error Summary provides us with information related to network command failure, timeout issues and help us furthermore investigate why certain command did not provide convenient output etc. On the other hand, the Connectivity report is focused primarily on connectivity issues and is even logging successful attempts.
In my current modified view, I wanted to see a list of currently discovered devices with no issues. I am able to download CLI Output, which was seen by IP Fabric and more.
We are going to check if order of multiple username entries matters. The lab is similar to what we had in previous article tips. In the first test, I properly introduced credentials to IP Fabric with USER789, which is the same one I’m using on my network right now. First set is being applied for subnet 10.241.255.0/24. Second username is completely incorrect and shouldn’t be able to connect to device with IP 10.241.255.10.
I purposely filtered networks to be included, narrowed it down to only 10.241.255.56/32, to have a straight result. As we can see in following report, device was successfully discovered, which means USER789 was used for mentioned subnet.
Let’s see how to troubleshoot improper authentication in place by completely deleting only the first user (USER789) in the list and let’s try to run discovery again. Unfortunately, IP Fabric wasn’t able to see any device. The best is to check with ‘Connectivity report’. From the output is very easy to determine, what’s gone wrong, as ‘Authentication error’ speaks for itself!
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.
One of the features that’s included in IP Fabric's platform from the beginning of time is variability of network discovery inputs. First of all is Discovery Seed, which creates an entry point for discovery. Another functional feature is Filtering, which narrows down to what to include and what to exclude from discovery and analysis. But few things first. For successful discovery we need to have proper licensing in place and valid authentication settings which is not covered in this article.
It’s an optional feature, but will help significantly with defining network discovery start-point. If not set, algorithm will begin from the current default gateway, which in many cases is not the best scenario. In my lab, I know there’s a subnet 10.241.255.0/24, that I’d like to discover. In the menu it can be found in Settings > Discovery Seed.
With only this setup, IP Fabric was able to discover 24 devices in the lab, all within subnet 10.241.255.0/24. But we can also apply the filtering. By navigating to Settings > Advanced, we can define IP scope in greater detail by including or excluding networks or single IPs.
By applying the filter, I managed to discover only 20 network devices instead of 24, all within 10.241.255.0/25 subnet only. More networks can be easily applied to either Discovery seed or subsequent filter. And there’s even more interesting options that elevate IP Fabric versatility. Few to mention could be authentication per subnet, defining the trace route scope or site separation types (defined by Routing and Switching domain or by RegEx based on hostname). SSH and Telnet basic values can be played with like authentication failure retries or login timeout value and more.
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.
Discovery of existing IP network devices and links is essential to proper network management and control. How can you perform the discovery with the minimal initial information required?
While you are approaching an existing network that you know very little of, you usually spend a lot of time getting as much information as possible before you even look at and touch the network itself. You can study the documentation (if any), get the inventory lists, try to understand the topology and design, downloading configurations, gather IP ranges, ask for administrator privileges, etc. This can be a cumbersome process even if all involved people cooperate. And usually, the responsible people will not be happy about granting full access to the network for the discovery.
You can apply brute force reconnaissance methods as well — such as blindly scanning whole private IP ranges or trying to contact any IP address that goes around in your packet scanner. However, this is not something that you would like to see in a business critical network.
With the IP Fabric platform, you can start the network discovery right away without wasting any time or threatening your network by using a single set of read-only network access credentials only.
You do not need to define any seed devices or scanning ranges in most networks. You do not even need the full privileges as you are gathering operational data for the discovery only.
Discovery algorithms of the IP Fabric platform can use as little of initial information as available and still produce valid and useful results to support the proper network management and control.
If you have found this article resourceful, please follow our company’s LinkedIn or Blog. There will be more content emerging. Furthermore, if you would like to test our platform to observe how it can assist you in more efficiently managing your network, please write us through our web page www.ipfabric.io
