The feature I’ve been waiting for since the beginning of my Network Engineering career is finally here: Dynamic Change Monitoring. It’s finally possible to know the answer to the age-old question “What has changed in the network since yesterday?” and actually get a definitive response instead of the usual “Nothing has changed”. And not just the configuration change management, but I’m happy that we’re the first in the market to offer the overall network state change management — whenever a network path changes, if somebody plugs in a new SFP, if a network port goes up or down, or if IP address is starts being served by a new gateway due to a convergence event, the IP Fabric platform will report the change. It’s great for performing the changes as well because I can now perform a pre-change scan, in-flight scan, and post-change scan, and verify that pre-change and post-change do not differ or that they contain only the desired differences, validating change goal.
Dynamic change monitoring is not the only big improvement in version 2.0. Having had a number of large scale production deployments we’ve had a chance to listen to insightful feedback and significantly improve usability, add highly desired features, all the while simplifying product architecture to be able to deliver features more quickly. So here are some of the highlights from the big 2.0 release:
Now a single action discovers, analyzes, and calculates changes in the network. Based on a schedule or on demand, network insight is as current as you need it to be. The single combined action greatly simplifies usability, as it eliminates guesswork if a new discovery is necessary or not. From experience, we’ve found out that networks are so dynamic, that they need rediscovering every single time the network state is collected.
We strive to support all enterprise network infrastructure managed devices, model years from 1997 or 2017 and made by Cisco or anyone else. For version 2.0 we’ve added a driver system, where each vendor family only has to have a family driver for the IP Fabric platform to be able to talk to the whole family. We’ve also added support for HPE Comware v5 and v7 based switches such as 55xx and 59xx, Riverbed WAN accelerators running RiOS, and Cisco SG300-series SMB switches. Paradoxically, the Cisco SG300 had the most complex driver, because a number of key pieces of information are missing from the basic outputs, and multiple detailed outputs have to be painstakingly combined for a meaningful result.
While we started with Routers and Switches, our ultimate goal is to cover the end-to-end transmission path from the source to destination, which includes additional types of forwarding equipment. Wireless is omnipresent, so we’ve added WLC and AP support, so now wireless users connected to lightweight APs can be traced just as easily as wired users. We’ve also added firewalls and WAN accelerators. And because many users are connected through IP Phones, and IP phones are an important part of network infrastructure, we’ve added those as well.
We strive to support all major Enterprise networking technologies and protocols, and although we have some road ahead of us, we’ve expanded VDC, vPC, and FEX support with StackWise, PoE, and Optical Attenuation, added support for QoS classes and applied service policies, improved ACL workflows, and added many smaller improvements, like support for DMVPN tunnels.
Networks follow graph theory, and graphs are naturally visual, so it is not a surprise that diagramming and visualization capabilities are a big draw, for both the customers and internal teams alike. In version 2.0 we’ve moved from simple diagrams to a fully-fledged diagramming UI, which enables to display protocols or features on demand and show network topology from highest overview to the deepest. One of the great additions is persistent diagram saving feature, which stores the diagram layout even across multiple discoveries runs.
This one is my favorite. Network protocols create topological neighborship to form a forwarding domain and networks paths. Changes in protocol neighborships signify changes in the network topology. Changes in network topology connectivity may inadvertently affect network behavior and can affect a number of users. Tracking connection changes enables to quickly pinpoint non-administrative and administrative changes affecting topology and network paths, user connectivity, and performance, redundancy, resiliency and service availability. Along with configuration management changes, four types of changes are currently tracked: devices, network neighborships (CEF, ARP, RIB, STP, CDP/LLDP), modules and part numbers, and IP addresses. Changes can be displayed for any time interval for which the platform has collected network state information. Changes between last month and last week can be displayed just as easily for last week vs today.
Many other improvements have made it into the big 2.0 release, and although not all are polished, they are functional and can provide value out of the box. User interface now has integrated search, Live Support VPN option, and a status page. Users can now change their password, and we’ve added the enterprise-grade user management system with roles. We’ve added more granularity for CLI interaction, such as a hard limit on a maximum number of parallel sessions. There are also Jumphost, and REST API, and actually much more than can be covered in one post. We’ll be coming back introducing each major feature in more detail, but if you can’t wait, you can always contact us or requests a trial.
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
Not only network documentation takes a lot of time and effort to create, but it also becomes outdated as soon as you hit save and seems to always require an update at the time you need it most. So how can you document your network effectively?
Every change in the network, either intended or unintended, usually requires documentation update. A good approach is to split the documentation into several documents according to sites that the network is organized into. The changes then affect only the site-related document. Having the history of design documents enables to track the network changes in time.
When the network is larger and the administration is delegated to multiple teams it may not be easy to keep the documentation updated according to the same standards in all sites. There may be network operation tasks with higher priority than documentation and there are definitely more favorite tasks for administrators than routine documentation.
IP Fabric provides an easy way how to keep the per-site Low-Level Design Documents updated with all of the detailed information, and always current even if the network changes rapidly. A generic document template keeps documentation look and feels consistent, while dynamic tags populate all of the required information from each of the network state snapshot, including overview site diagrams, physical layer information, information about switching and routing, management, and security.
A fully prepared document is generated with a click of a button at the time when it is required, for the current or historic state. No routine manual activity is required to create the documents as those are generated automatically according to pre-defined templates. Diagrams, tables, and explanatory text are included, just like in any manually created Low-Level Design document.
If you’re interested to see how the IP Fabric platform can help you with your documentation needs, contact us for an online demo or a trial in your network. Also, we’re hiring!
