IP Fabric Overview

The IP Fabric network infrastructure management platform provides on-demand network discovery, advanced analytics, and detailed engineering visibility. The lightweight discovery capabilities (through SSH or telnet) quickly detect the current network state, including detailed data for each address and port. A network model of gathered data reconstructs the topologies for each switching and routing protocol to enable a cross-technology analysis of upstream and downstream relationships. Dependencies and dependents are calculated for each network element, allowing analysis to represent each aspect of the network in the context of productivity impact on the downstream hosts and on network devices, while the immediate productivity impact of performance and capacity is calculated for each user and every element.

Architecture

A distributed system of micro-service components resides within IP Fabric VM, all based around a multi-model database with a mathematical network model at its core. Operating system-level controls provide high availability, security and log collection. The kernel-level bidirectional traffic shaper and application-level worker flow control mechanisms provide comprehensive traffic management and automatically respond to any sign of network congestion to ensure that only freely available bandwidth is utilized. The user interface is available on port 443 of the VM's IP address through any modern web browser and on any screen. Table output can be exported into CSV format for further processing, and selected reports are exportable into Word format.

Operational Requirements

Hardware Requirements

The IP Fabric platform runs on any x64 CPU with following instructions: avx,popcnt,sse,sse2,sse4.1,sse4.2,sse4a,ssse3. The system runs in at least 4 parallel threads, but scheduling can handle operations even down to a single thread. IP Fabric uses less than 4GB of RAM when idle, and an additional 12GB of RAM is required for collected network information. The base installation requires 80GB of HDD space and an additional 50MB per device for the network.

Minimum requirements are:

The following table represents the recommended hardware requirements for optimal performance of the platform based on the number of network infrastructure devices in the network.

Network Connectivity Requirements

During the snapshot operations, the user can control network bandwidth limit which never exceeds an aggregate of set bandwidths in any direction to provide an additional safety measure.

IP Fabric should be connected to a network that has direct connectivity to managed devices. Jumphost server can also be set-up and used. (Jumphost server requires an installation of SSH Python version 3.6+.)

Inbound flows:

Outbound flows:

Internet connectivity is used to check product updates, upgrades, setup support VPN, send error reports, and submit support tickets.

Network Access Credentials Requirements

Network Device Access

IP Fabric accesses network-infrastructure devices via CLI (command-line interface) using SSH or TELNET protocols. All device interaction is accounted on the platform and only "read-only" or "operator" group privilege level 1 credentials are required.

The following list contains an example of commands used for Cisco IOS:

terminal length 0
show version
show inventory
show etherchannel summary
show interfaces [status|switchport]
show ip int [brief]
show ip vrf
show ip arp
show ip route
show ip cef
show ip access-list
show cdp neighbors detail
show lldp neighbors detail
show mac address-table
show spanning-tree [detail|mst|summary]
show standby [brief]
show vrrp [brief]
show vlan brief

In the beginning, IP Fabric fingerprints the device using the "show version" command (or equivalent) to identify a vendor and a system version. A "terminal length" command is optional but highly recommended, as it greatly improves the speed of the device interaction, reduces the load on the network and the device, and improves collection precision.

Additional Device Access

Since firewalls do not follow privilege levels, it may be necessary to explicitly specify the commands allowed for each user. The following list specifies the exec-mode commands needed for firewall discovery.

show version
show interface
show route
show arp
show context
terminal pager 0

Turning off paging greatly improves the speed of the discovery and allows a terminal pager command, making it highly recommended although not mandatory. The commands can be allowed through the central TACACS or RADIUS access control system, or they can be configured locally on a device. The following example adds the necessary commands to a privilege-1 user:

privilege show level 1 mode exec command interface
privilege show level 1 mode exec command arp
privilege show level 1 mode exec command route
privilege show level 1 mode exec command context
privilege cmd level 1 mode exec command terminal

List of all commands used for CLI discovery can be found in this feature/vendor matrix.

Staging vs Production Deployment

IP Fabric is a complex solution with multiple moving parts. We thoroughly test every release before it is made available to our customers. Testing comprises of the automated unit testing on the code level and automated tests run against various physical and virtual lab environments. These emulate complex networks with many devices from multiple vendors. Despite these efforts, issues can still arise after deploying a new version of IP Fabric to the customer's environment. For example, it is not feasible to replicate the entire network or a combination of particular device models.

Therefore, we suggest 2-stage deployment of the new IP Fabric releases for complex or critical implementations. The first stage is staging deployment, used to verify the functionality of the new release within the customer's environment.

The second stage is the deployment to the production / live environment. The staging environment's sizing follows the suggestions mentioned above for a standard deployment. We don't provide special staging builds. These are regular production builds, which are just deployed separately not to potentially disrupt the day-to-day use of IP Fabric within the organization.

We suggest that you make staging as close as possible to the final production environment. The staging environment should discover the same devices as the production (e.g., there is only a limited value if the staging environment "sees" only 500 network devices, while the whole network consists of thousands of devices). On the other side, it is perfectly fine to provision the staging environment dynamically if your deployment environment allows it. Also, a typical "acceptance test" on the staging environment lasts only a couple of days to verify overall functionality.