Version 3.7.0: Enhanced security model and reducing friction for automation workflows
To grasp any technology in a standard manner, first the right command set has to be found. The command set provides initial ingredients in raw form, which have to be processed. The processing extracts and structures the variables in a unified network model. This is the spice of our recipe, the secret sauce which allows users to express their business and operational intent across all vendors families thorough a standardized network model. Now IP Fabric adds more flavor with security and improved automation workflows.
Let me present some of the updates coming with the new version.
A new model for IPSec
Until now, IPSec information was available for Cisco IOS only. IP Fabric could read the IP data from other vendors and simulate the application path when the tunnel was used as a routed interface, but detailed IPSec information was not captured.
In 3.7.0, gathered information about IPSec tunnels was greatly expanded, enabling to filter and observe parameters such as local and remote gateways, encryption and authentication types used in proposals, NAT traversal settings and more. Now it’s easy to continuously validate compliance for issues such as weak encryption, troubleshoot keepalives or tunnel port filtering, check profile consistency and more.
In addition, this level of detail is now available not only for Cisco IOS, but also for Cisco ASA/Firepower, Fortinet FortiGate, Juniper SRX, Palo Alto, and Mikrotik RouterOS vendor families.
Security Policies for Palo Alto and Checkpoint
Collecting zone firewall policies is essential for fully understanding security in the application path simulation. IP Fabric already supported zone-based security policy collection, structuring and simulation for Cisco firewalls, Juniper SRX, and Fortinet FortiGates. Starting with the version 3.7.0 IP Fabric adds support for Checkpoint Gaia and Palo Alto firewalls.
This expands capability of security validation, which allows for reading policies from security orchestration tools such as Tufin and validating if network actually performs as expected.
Apart from being used in end-to-end path simulation and testing, all security policies are stored in the database with every snapshot for quick exploration, audit, validation, and documentation purposes.
For the Checkpoint, the policy collection is performed via API from the management server, if it’s available.
API usability improvements for enhanced automation workflows
A key feature of any automation process is to remove any possible friction points. The authentication process is an important part of that, so version 3.7.0 introduces API Tokens. A new Setting menu item “API Tokens” lets you add application-specific API tokens, with unique authorization and expiration settings. This feature helps significantly with building both short term and long term API integrations.
Webhooks are “user-defined HTTP callbacks”. Their main purpose in IP Fabric is to notify operations and security teams about occurring snapshot and intent rule events automatically.
Webhooks allow you to build or set up integrations, which subscribe to certain events on the IP Fabric platform. When one of those events is triggered, the platform automatically sends an HTTP POST payload to the webhook’s configured URL. Webhooks can be used to send notifications to messaging tools of your choice or update an external issue tracker. You’re only limited by your imagination.
We’ve also prepared a Slack integration and posted it on our public GitHub repository. With this sample code we show how webhooks can be used to trigger actions which result in data being presented in end user chat dialogue.
Technologies & Vendors support
Collecting transceivers data
Extending vendor support is a standard part of every major release. One of the most prominent additions in 3.7.0 is reintroduction of Transceiver state collection. This was previously removed due to issues on multiple vendor platforms that could cause undesired behavior (like a reload) after executing the show command.
For this reason, the collection of transceiver state data will remain disabled by default, but can now be enabled by the user prior to any collection using the new options in the discovery settings (see below).
MPLS & VXLANs for Huawei
As further indication that the IP Fabric platform is no longer an enterprise-grade tool only, we’ve added MPLS & VXLAN visibility for Huawei devices. We include standard MPLS forwarding data with L2 and L3 VPNs. With more and more service provider features, it’s already assisting various network service providers to map and understand their networks.
System & Discovery enhancements
Disable/Enable tasks for discovery
To add more flexibility for the user, individual tasks for specific network devices can now be disabled during the discovery process. The ‘task’ in the IP Fabric is any technology or protocol we tend to discover and map into the database. For example “OSPFv2” task collects information about OSPFv2 on various platforms. Another example is a “Transceiver” task which collects Transceiver state information from various platforms. User can now disable specific task processing to speed up the discovery process, or enable tasks for those risky commands such as Transceiver information collection.
Custom SSH and Telnet ports
Not all of the networks run default ports for the SSH and Telnet servers. Some subnets just have to have that SSH moved to 8022 or another non-standard port because of flurry of connection attempts or another specific reason. To support these specific environments version 3.7.0 adds support for custom SSH and Telnet ports, which can be configured per subnet. In SSH/Telnet tab of Advanced settings it’s now possible to create a list of subnets and use a combination of include and exclude rules to match your specific environment settings.
Other improvements and bugfixes
Many additional improvements and bugfixes have been made for various protocols and vendor families. One notable area are Cisco ACI path lookup improvements, now supporting diverse set of scenarios, including L2 VXLANs with multiple tunnel endpoints and default gateway on non-ACI edge switch. This enables for having a full service overview when ACI is involved. For a complete list of changes please refer to release notes.