Yet, we are scoring another milestone with our latest 4.1.0 release. The IP Fabric platform version 4 is different in many tones. It took more than a year of parallel development of new topology maps alongside new vendors and technologies in standard releases. Taking a sabbatical for anyone who's participated in the year-long development process would not be unaccountable at all, I can imagine.
As already mentioned, the main focus for the major release was new topology maps in IP Fabric. Let's briefly talk about that. The IP Fabric automatically collects a lot of parameters from the network with its discovery capabilities on a regular basis. The platform can represent the data in many ways (GUI, JSON, CSV, ..) by using filters and sorting algorithms. The visual representation of any network protocol relationship is essential for humans to understand things quickly. That's where the need comes from.
Our former topology maps were acceptable form but with many identified limits. Version 4 is to address prominent issues with performance and usability.
The upgrade in performance is the crucial element for usability in new maps, and there's no question about it. Since all calculations are now processed mainly on the back-end, the improvement is beyond question. To observe a couple of thousands of network elements in one map is no longer an issue.
This feature is a game-changer compared to previous layout options. Imagine managing a large map out of 500 individual network elements. The automated layouts allow users to manipulate topology maps with predefined layout algorithms very quickly and with comfort.
The end-to-end path simulation is a flagship when it comes to troubleshooting with IP Fabric. The simulation capabilities cover traditional IP space, VXLANs or Cisco ACI, and security policies or access-lists inspection.
With the version 4 update, we decided to simplify the path topology and provide more complex data on demand at the same time. How did we do that? Network engineers can inspect the topology map and additionally observe header encapsulation data with the new path inspector.
Starting with the IP Fabric version 4, the new maps have full API support. That opens many new doors, such as Chat-bot integrations by fetching the end-to-end path's SVG over API or simply automating topology map documentation with API scripts regularly.
The intent-based networking has been with us for some time, but what does it mean for IP Fabric users? How can anyone create and test any intent in the platform? Everything in the platform is based on data we collect from network devices.
With the intent rules, we allow users to create compliance practices applied to any data we collect (management protocols, their different metrics, or the number of received routes in the routing table, etc.). In the new maps, we can overlay the intent across any map or path simulation to get results instantly based on the observed part of the network.
New code to create new topology maps means an empty canvas for more exciting features in the future! Few to mention would be searching topology maps with custom attributes, simulating the path to the AWS networks, and more.
The Viptela SD-WAN is a segmented network overlay that uses encryption for security, enforces controller policies, and integrates with third-party services. Alongside cloud networks (AWS, Azure, GCP) or Cisco ACI, it's another software-defined network using controller, compared to traditional networks with always available Command-Line Interface (CLI).
To collect data successfully, IP Fabric needs API access to Viptela's controller. The latest update supports the reading of standard protocols and technologies (BGP, OSPF, EIGRP, FHRP, IPSec, ACLs, management protocols).
For IP Fabric automation enthusiasts, this has been a long-awaited feature and we clearly apologize for the delays. To set the stage for the rest of the community. Different vendors have different naming conventions. That's the main reason why IP Fabric uses an internal interface standardization function during the discovery process. It is to ensure we are creating accurate protocol links in topology maps or correct matches for the intent rules (MTU).
To enable broader integration capabilities with other systems, that may use different (original) interface names, we added a new column into the interfaces > inventory table called 'Original Name'. The endpoint will serve as a translation point for IP Fabric's interface names to the original interface names.
If you have found this article helpful, please follow our company’s LinkedIn or Blog, where more content will be emerging. If you would like to test our solution to see for yourself how IP Fabric can help you manage your network more effectively, please contact us through www.ipfabric.io.
Yet, we are scoring another milestone with our latest 4.1.0 release. The IP Fabric platform version 4 is different in many tones. It took more than a year of parallel development of new topology maps alongside new vendors and technologies in standard releases. Taking a sabbatical for anyone who's participated in the year-long development process would not be unaccountable at all, I can imagine.
As already mentioned, the main focus for the major release was new topology maps in IP Fabric. Let's briefly talk about that. The IP Fabric automatically collects a lot of parameters from the network with its discovery capabilities on a regular basis. The platform can represent the data in many ways (GUI, JSON, CSV, ..) by using filters and sorting algorithms. The visual representation of any network protocol relationship is essential for humans to understand things quickly. That's where the need comes from.
Our former topology maps were acceptable form but with many identified limits. Version 4 is to address prominent issues with performance and usability.
The upgrade in performance is the crucial element for usability in new maps, and there's no question about it. Since all calculations are now processed mainly on the back-end, the improvement is beyond question. To observe a couple of thousands of network elements in one map is no longer an issue.
This feature is a game-changer compared to previous layout options. Imagine managing a large map out of 500 individual network elements. The automated layouts allow users to manipulate topology maps with predefined layout algorithms very quickly and with comfort.
The end-to-end path simulation is a flagship when it comes to troubleshooting with IP Fabric. The simulation capabilities cover traditional IP space, VXLANs or Cisco ACI, and security policies or access-lists inspection.
With the version 4 update, we decided to simplify the path topology and provide more complex data on demand at the same time. How did we do that? Network engineers can inspect the topology map and additionally observe header encapsulation data with the new path inspector.
Starting with the IP Fabric version 4, the new maps have full API support. That opens many new doors, such as Chat-bot integrations by fetching the end-to-end path's SVG over API or simply automating topology map documentation with API scripts regularly.
The intent-based networking has been with us for some time, but what does it mean for IP Fabric users? How can anyone create and test any intent in the platform? Everything in the platform is based on data we collect from network devices.
With the intent rules, we allow users to create compliance practices applied to any data we collect (management protocols, their different metrics, or the number of received routes in the routing table, etc.). In the new maps, we can overlay the intent across any map or path simulation to get results instantly based on the observed part of the network.
New code to create new topology maps means an empty canvas for more exciting features in the future! Few to mention would be searching topology maps with custom attributes, simulating the path to the AWS networks, and more.
The Viptela SD-WAN is a segmented network overlay that uses encryption for security, enforces controller policies, and integrates with third-party services. Alongside cloud networks (AWS, Azure, GCP) or Cisco ACI, it's another software-defined network using controller, compared to traditional networks with always available Command-Line Interface (CLI).
To collect data successfully, IP Fabric needs API access to Viptela's controller. The latest update supports the reading of standard protocols and technologies (BGP, OSPF, EIGRP, FHRP, IPSec, ACLs, management protocols).
For IP Fabric automation enthusiasts, this has been a long-awaited feature and we clearly apologize for the delays. To set the stage for the rest of the community. Different vendors have different naming conventions. That's the main reason why IP Fabric uses an internal interface standardization function during the discovery process. It is to ensure we are creating accurate protocol links in topology maps or correct matches for the intent rules (MTU).
To enable broader integration capabilities with other systems, that may use different (original) interface names, we added a new column into the interfaces > inventory table called 'Original Name'. The endpoint will serve as a translation point for IP Fabric's interface names to the original interface names.
If you have found this article helpful, please follow our company’s LinkedIn or Blog, where more content will be emerging. If you would like to test our solution to see for yourself how IP Fabric can help you manage your network more effectively, please contact us through www.ipfabric.io.
