Today we’re announcing the release of IP Fabric 2.2.4. A network security oriented release, the new version enables you to troubleshoot the paths through firewall clusters, to have deeper insights into routing convergence and redundancy, or to prepare or verify migration changes to 802.1X among other enhancements.

We’ve started by improving the user interface to End to End path lookup, simplifying to the usual combo of source and destination parameters. Typing hostname or IP or MAC address into the source or destination fields looks up the endpoint as you type, greatly simplifying the experience while keeping the most frequently used endpoint identification parameters. The previous lookup tables were much richer in information, but practically the additional information was more related to host location than end to end paths, and therefore seldom used.

Simplifying the user interface was necessary to add L4 parameters of protocol and port, which are now used to calculate the resulting security decision though all of the access-lists or zone-based firewalls on the path. This enables to better troubleshoot complex paths throughout the network. For example, when a user reports that they are not able to access an app on a specific port, you can instantly check if they are allowed to access an app in the first place, and how all do possible paths look like from source to destination, including whether might be an issue with load balancing or missing path symmetry. Of course, to be able to do that, we have to have not only model of routing, but also of traffic filtering mechanisms. These have now been expanded to support zone-based firewalls and clusters.

The cloud represents transit outside of administrative domain, such as MPLS carrier or DMVPN, usually a WAN. There is a missing path towards R3, and weird routing going on at R6 that should also be looked at. The WAN routers have egress and ingress filtering on the path that is permitting the communication (green color), however the cluster itself is dropping the packets (red color), so while the routed and switched path is built correctly, the traffic from this particular source/destination combination will never reach it’s destination.

Security rules for path visualization enable drill-down to the zone firewall policy details

Path lookup was quite useful even in preparation of this demo. The connectivity to the end hosts wasn’t working, and the traceroutes from various points seemed to end in the MPLS cloud. Plotting the end to end path in IP Fabric immediately showed that the route at the source is missing, since the path stopped on the ingress router.

From there it was a matter of checking the cumulative routing table using routing lookup for the particular destination, which showed that no BGP routes can route these prefixes.

This pinpointed the problem to redistribution, since IGP had the route and BGP didn’t, and led to a quick fix.

Other improvements in this release include improved 802.1x analytics, addition of STP guard tables, and usability improvements such as DNS resolution for hosts and voice VLANs for IP Phones.

However not all of the improvements were aimed squarely at analytics, as we’ve also added support for LDAP authentication to the platform, so you won’t have to remember the additional password.

LDAP authentication supports Open LDAP or Microsoft AD.

We’ve also added restrictions per subnet for authentication credentials, so they can be specified more granularity for extensive administrative domains. The full list of changes is in the release notes at https://docs.wordpress-625423-2416527.cloudwaysapps.com/releasenotes.html. If you have IP Fabric installed, you can perform online or offline upgrade through the administrative interface following the guide.

If you’re interested in learning more about how IP Fabric’s platform can help you with analytics or intended network behavior reporting, contact us through our website, request a demo, follow this blog or sign up for our webinars.

Enterprise networks should never have Single Points of Failure (a.k.a SPOF) in their daily operation. SPOF in general is an element in a system which, if stopped, causes the whole system to stop.

Single failure (or maintenance or misconfiguration) of any network device or link should never put a network down and require manual intervention. Network architects know this rule and design the networks like that — placing redundant/backup devices and links which can take over all functions if the primary device/link fails.

But the reality is not always pleasant, and today’s operational networks can include SPOFs without anyone explicitly knowing. The reason is that even though the original design put all SPOFs away, the network may have evolved in the meantime, and new infrastructure may have been connected to it.

For example:

• An application which was not important at the beginning (and thus was connected to the network by single link and single switch only) may have gained large significance for the business today. The dependency among the applications can be complex and if only one in the critical chain is SPOF, then whole chain of applications fails.
• Mix of two redundant network infrastructures — for example after new company acquisition — could not be redundant as the original components. The networks may not have taken into account during the original design that other connected networks may be needed to be redundant as well.
• Or there may have been one network failure which was not noticed and have put part of the network out of the operation — and created set of SPOFs. The network may continue to work (because the redundant design mitigated one failure) but is not ready for second and subsequent failures.

Part of the network operation activities should take into account that SPOFs may appear unexpectedly. This require advanced skills and lot of time to go trough routine settings and outputs if the networks is still resilient and high available. It also requires expensive disaster-recovery exercises to be performed regularly.

IP Fabric helps with finding of non-redundant links and devices in the network in its diagrams section.

It does not matter if the SPOF is Layer 2 switch or Layer 3 router — those are all in the critical chain of application uptime. Device and links which form SPOF will be highlighted.

Additionally, networks with many small sites have automatic grouping of small sites into redundant and non-redundant groups in IP Fabric. Groups allow to easily spot sites with non-redundant transit connectivity.

If you’re interested in learning more about how IP Fabric’s platform can help you with analytics or intended network behavior reporting, contact us through our website, request a demo, follow this blog or sign up for our webinars.

Many devices such as IP phones, wireless access points, IP cameras or even small switches may be powered via the data Ethernet cable (by one of the PoE standards). This approach saves a lot of issues with separate electric power infrastructure and eases device manageability (e.g. hard reset of the distant malfunctioning phone has never been easier before). Nevertheless, this approach in large scale requires appropriate operational tools.

What is the number of PoE powered devices? What is the PoE class (and what is the respective power reserved and actually drawn) of each device? Is the power supply of the feeding device (Ethernet switch in most cases) adequate for the actual and future need of the endpoints? How much redundancy do I need if one of the power supplies fail?

Quick answers to those (and other PoE related) questions may be essential in the time of planning and in the time of power outage or hardware failure. IP Fabric can provide those answers with the usual filtering and sorting aids that its user interface offers.

Statistics per switch and per port are available. A network engineer can easily decide which devices or endpoints should be focused on (and for example turned off if needed) without leaving its desk and without extensive on-site troubleshooting.

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

UPDATE: We've published an updated post on this topic here: Generate Powerful Business-Level Reports. Please see this post for the most up-to-date information!

Overall state of the network often must be presented in condensed form to managers and non-it personnel. How can you create the reports focusing mostly on the risk and impact of the network state to users and applications?

The users of the network are interested in slightly different outputs than network engineers. Will I be still able to connect to my online application/data repository even if something breaks? If there is something going on in the network, what impact it has on my job and the work I need to do? Those kinds of reports are not easy to create from the engineering point of view as they require correlation of different inputs from the network, such as the assessment of redundancy, number of the user connections and the possible known risks.

A network-wide analysis report that IP Fabric creates without the need for manual input assists IT management in responding to user questions above and helps in focusing on what network issues must be mitigated first. The summary information and perceived risks are included in the document as well.

When done manually, such documents take weeks to prepare and incur significant costs, prohibiting frequent reanalysis. With IP Fabric, Network Analysis Report document can be generated instantaneously with a single click of a button for the current network state or any previous network snapshots, providing reports at the time they are needed.

If you’re interested in business-level network analysis reports for your network sign up for a trial or an online demo. Also, we’re hiring!