Good news everyone, another version of the IP Fabric platform is officially out. We have added more freedom to users in terms of platform configuration and above all, the intent-based network verifications can now be visually represented directly in the diagrams.
This greatly helps in many scenarios when specific part of the network is of interest. For example, one of the frequent scenarios in troubleshooting is finding an issue on the path. Now all paths between any two endpoints can be visually verified for a presence of an issue in an instant.
This includes paths with significant complexity, such as paths including Stack, FEX, vPCs, VXLANs, WAN accelerators, Lightweight Wireless and others.
Imagine troubleshooting a path for a performance issue, and trying to narrow down a problem, because it’s not feasible to check everything at once. Techniques such as resolving a balancing hash for a particular flow were utilized to know which link to focus troubleshooting on. These techniques were necessary to narrow down the issue, but not in finding the underlying cause. Well, now it is feasible to check all path elements at once, and see all affecting issues.
Now it’s even possible to “Check everything at once”. Not surprisingly there will be a lot of red.
Of course, any intent verification group can be displayed separately. For example here we want to see only specific routing table entries which have routing redundancy issues in our datacenter.
Or here we want to visually verify device security hardening for compliance checks, and suddenly see that one of our devices has AAA Authentication configured with method "none" allowing privileged access without any authentication.
Visualization is available for any type of Intent verification, and can be combined with visual snapshot comparison. Here we verify neighborship compliance, and once we see that there is an issue with OSPF neighbors, we compare Monday's network state with the network state at Sunday, to see if the network has changed.
This visual issue representation is available for any type of Intent-Based Verification which can be associated with a link or a device.
The intent-based networking (IBN) or intent-based verification (IBV) buzz word has been around quite some time. However, to this day, not every engineer from security or network operations is familiar with the concept. Apart from that, people with diverse backgrounds may have a different understanding of the approach.
The goal of any computer network is to transfer information based on multiple variables. The Intent-Based Networking (IBN) is focused on network automation and better aligning networks with operational goals or 'intent'. Intent is what we want networks to do. It differs from classical monitoring goals in that we can express advanced operational concepts or even business goals. In classic monitoring we might have checks such as "IP address X must be reachable" while 'operational intent' could be "Authorized users must be able to redundantly reach application servers".
Verifying reachability via ICMP from the monitoring center is one thing, but verifying specific path availability and parameters from a specific set of sources to specific set of destinations is significantly more complex and has usually required a lot of manual effort to complete. This is extremely important to understand, because 'intent' advanced next level of visibility and shifts operational notion from "up/down" to predictive analytics.
As networks move towards IBN, the IP Fabric platform is here to help automate a significant part of the process.
In the platform, we have already created the Assurance Engine that is capable of tracking protocol inconsistencies or providing feedback on network health. The IPF administrators have the power to create their own system-wide controlling mechanisms that fit their needs for IBN.
We decided to take this powerful feature to another level, and with version 3.3. we have introduced Intent-Based verification for the diagrams. Imagine you are viewing any available network topology or the end-to-end path, while you can apply any previously defined IBN rule directly.
In the new version, the platform collects and analyzes DHCP Snooping information for supported devices. The information includes normalized configuration and state, including trusted ports, option82 and the binding database amongst other parameters. You can find the new DHCP snooping tables at /technology/security/dhcp-snooping/configuration-v4 in the platform
The VLAN summary information is now compiled from the network specifically from VLAN point of view. Previously VLAN information was compiled and available only from point of view of the Spanning Tree Protocols, however VLANs without any STP association were not available in the platform. Now any VLAN that exists in the network can be found, analyzed, and visualized, even if it is suspended, broken, or exists on a single device without any STP capabilities. Definitive VLAN information can be found at /technology/vlans/device-detail in the platform
Detailed SSID radio information was already available for mapping each SSID on each wireless Access Point in the Network. This information was present for each unique AP-SSID pair, and therefore was inherently presented from the AP point of view. In this release we have added SSID summary table which provides information from the point of view of SSID, and should help in consistency verifications of SSID deployments in the network. The table is located at /technology/wireless/radios/ssid-summary in the platform
With a single double-click (all clap for an amazing self-contradiction) one can ungroup the links in diagrams. So far it was only available with the help of the 'group/ungroup' button in the protocols menu.
Every release we tend to update the vendor list per requests from our customers and IPF version 3.3 is not an exception. We’ve seen a somewhat surprising venture of Mikrotik platforms into enterprise environments, primarily for advanced routing and MPLS capabilities, so we have added support for the Mikrotik platform. Please keep in mind that Mikrotik routers require longer session timeout, otherwise they will be not discovered.
The Extreme routers and switches have been among supported vendors for some time but not the Enterasys devices which Extreme has acquired back in 2013. Starting with 3.3, the basic discovery has been added.
Discovery attempts to contact devices using Telnet or SSH, which is useful especially for very large networks or networks with significant history. There is always an occasional forgotten device with Telnet enabled which IPF platform could help to identify. However, not everyone is particularly happy by having Telnet sessions around with every discovery. In the new version, the Telnet can be disabled for discovery.
Transceivers on NX-OS platform are now available in the inventory, for the ASA the support for system-defined object groups was added and much more.
Big thanks to our supporting customers, who are constantly helping us to improve the platform. Full details of the release could be found in our Release Notes.
If you have found this article resourceful, please follow our company’s LinkedIn or Blog, where there will be more content emerging. Furthermore, if you would like to test our platform to evaluate how it can assist you in managing your network more effectively, please let us know through www.ipfabric.io.
Good news everyone, another version of the IP Fabric platform is officially out. We have added more freedom to users in terms of platform configuration and above all, the intent-based network verifications can now be visually represented directly in the diagrams.
This greatly helps in many scenarios when specific part of the network is of interest. For example, one of the frequent scenarios in troubleshooting is finding an issue on the path. Now all paths between any two endpoints can be visually verified for a presence of an issue in an instant.
This includes paths with significant complexity, such as paths including Stack, FEX, vPCs, VXLANs, WAN accelerators, Lightweight Wireless and others.
Imagine troubleshooting a path for a performance issue, and trying to narrow down a problem, because it’s not feasible to check everything at once. Techniques such as resolving a balancing hash for a particular flow were utilized to know which link to focus troubleshooting on. These techniques were necessary to narrow down the issue, but not in finding the underlying cause. Well, now it is feasible to check all path elements at once, and see all affecting issues.
Now it’s even possible to “Check everything at once”. Not surprisingly there will be a lot of red.
Of course, any intent verification group can be displayed separately. For example here we want to see only specific routing table entries which have routing redundancy issues in our datacenter.
Or here we want to visually verify device security hardening for compliance checks, and suddenly see that one of our devices has AAA Authentication configured with method "none" allowing privileged access without any authentication.
Visualization is available for any type of Intent verification, and can be combined with visual snapshot comparison. Here we verify neighborship compliance, and once we see that there is an issue with OSPF neighbors, we compare Monday's network state with the network state at Sunday, to see if the network has changed.
This visual issue representation is available for any type of Intent-Based Verification which can be associated with a link or a device.
The intent-based networking (IBN) or intent-based verification (IBV) buzz word has been around quite some time. However, to this day, not every engineer from security or network operations is familiar with the concept. Apart from that, people with diverse backgrounds may have a different understanding of the approach.
The goal of any computer network is to transfer information based on multiple variables. The Intent-Based Networking (IBN) is focused on network automation and better aligning networks with operational goals or 'intent'. Intent is what we want networks to do. It differs from classical monitoring goals in that we can express advanced operational concepts or even business goals. In classic monitoring we might have checks such as "IP address X must be reachable" while 'operational intent' could be "Authorized users must be able to redundantly reach application servers".
Verifying reachability via ICMP from the monitoring center is one thing, but verifying specific path availability and parameters from a specific set of sources to specific set of destinations is significantly more complex and has usually required a lot of manual effort to complete. This is extremely important to understand, because 'intent' advanced next level of visibility and shifts operational notion from "up/down" to predictive analytics.
As networks move towards IBN, the IP Fabric platform is here to help automate a significant part of the process.
In the platform, we have already created the Assurance Engine that is capable of tracking protocol inconsistencies or providing feedback on network health. The IPF administrators have the power to create their own system-wide controlling mechanisms that fit their needs for IBN.
We decided to take this powerful feature to another level, and with version 3.3. we have introduced Intent-Based verification for the diagrams. Imagine you are viewing any available network topology or the end-to-end path, while you can apply any previously defined IBN rule directly.
In the new version, the platform collects and analyzes DHCP Snooping information for supported devices. The information includes normalized configuration and state, including trusted ports, option82 and the binding database amongst other parameters. You can find the new DHCP snooping tables at /technology/security/dhcp-snooping/configuration-v4 in the platform
The VLAN summary information is now compiled from the network specifically from VLAN point of view. Previously VLAN information was compiled and available only from point of view of the Spanning Tree Protocols, however VLANs without any STP association were not available in the platform. Now any VLAN that exists in the network can be found, analyzed, and visualized, even if it is suspended, broken, or exists on a single device without any STP capabilities. Definitive VLAN information can be found at /technology/vlans/device-detail in the platform
Detailed SSID radio information was already available for mapping each SSID on each wireless Access Point in the Network. This information was present for each unique AP-SSID pair, and therefore was inherently presented from the AP point of view. In this release we have added SSID summary table which provides information from the point of view of SSID, and should help in consistency verifications of SSID deployments in the network. The table is located at /technology/wireless/radios/ssid-summary in the platform
With a single double-click (all clap for an amazing self-contradiction) one can ungroup the links in diagrams. So far it was only available with the help of the 'group/ungroup' button in the protocols menu.
Every release we tend to update the vendor list per requests from our customers and IPF version 3.3 is not an exception. We’ve seen a somewhat surprising venture of Mikrotik platforms into enterprise environments, primarily for advanced routing and MPLS capabilities, so we have added support for the Mikrotik platform. Please keep in mind that Mikrotik routers require longer session timeout, otherwise they will be not discovered.
The Extreme routers and switches have been among supported vendors for some time but not the Enterasys devices which Extreme has acquired back in 2013. Starting with 3.3, the basic discovery has been added.
Discovery attempts to contact devices using Telnet or SSH, which is useful especially for very large networks or networks with significant history. There is always an occasional forgotten device with Telnet enabled which IPF platform could help to identify. However, not everyone is particularly happy by having Telnet sessions around with every discovery. In the new version, the Telnet can be disabled for discovery.
Transceivers on NX-OS platform are now available in the inventory, for the ASA the support for system-defined object groups was added and much more.
Big thanks to our supporting customers, who are constantly helping us to improve the platform. Full details of the release could be found in our Release Notes.
If you have found this article resourceful, please follow our company’s LinkedIn or Blog, where there will be more content emerging. Furthermore, if you would like to test our platform to evaluate how it can assist you in managing your network more effectively, please let us know through www.ipfabric.io.
