There are many elements that contribute to the availability of services delivered across any network. Redundancy in the topology, coupled with resilience in the configuration are key. Routing protocols are used to manage that redundancy and failover to backup traffic paths should a failure occur in the active path. For this to work successfully, it is vital that the environment remains as stable as possible and is not subject to constant change. IP Fabric can help you by analyzing routing protocol stability and pinpointing issues.
As we know, the stability of BGP peering can cause performance problems with large networks. Events such as link failures can trigger sequences of updates along paths in the network - this can cause:
As an example of this, consider that the Internet routing table has reached such a size that it never actually fully converges. This is a symptom of the churn - the number of updates and withdrawals - caused by link events within and between ASs which of course occur around the clock!
BGP is usually used in an enterprise to connect together networks that are managed by different organizations or different parts of the same organization. It follows then that once established, the connections should stay up and remain so. Fluctuations in that connectivity have the potential to have far-reaching consequences and so it pays to keep track of the stability of that peering.
But how do we measure that stability? In particular, we might address this by focussing on two particular elements. For each BGP peering relationship in the network we might look to answer two questions:
In order to check that manually, a network analyst might have to
Or you could spend the time to write the scripts and develop the tooling to automate the process so you can repeat the checks at regular intervals.
Alternatively, you could give the job to IP Fabric.
IP Fabric analyses configuration and operational state of the devices in the network records them in a vendor-agnostic form in its database, then runs 120+ standard validation checks and presents the results on the product dashboard. These checks include identifying BGP peering across platforms and vendors and checking the relationships for the length of the establishment of peering:
and for current state:
Clicking through the dashboard on peerings in an active state shows a table of the details for those peerings, and you have all the details to hand.
Taking a step further, click through the site location in the table to see the topology with the peering in question from the "live" documentation:
Next, we focus on BGP topology by disabling all other protocols and enable the BGP Compliance intent verification check.
We can see that the platform has highlighted the problem with L64R7. IP Fabric presents information on the problematic peering with L64R4 when we select the router in question. The implication here is that L64R4 is not configured to peer with L64R7.
It is apparent that the peering appears to be configured in one direction and not the other from the arrows in the diagram. From the table, it looks like an IP address doesn't appear to be assigned to the peering. On inspecting the routers we can see that L64R7 looks fine:
but the peering is disabled on L64R4:
And so IP Fabric has allowed us to drill down and reach the conclusion far quicker than going through a process of having to extract the detail, analyze it and troubleshoot manually.
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.
Ever since engineers started operating computer networks, they started to use network analysis tools to measure performance, calculate risks and improve visibility. As technologies in general evolved, so did the tools for their administration. However, it has become quite common that many operators stick to old-fashioned Command-Line Interface (CLI) only and avoid any automation.
Don't get me wrong, there's nothing wrong with being capable of using CLI. I believe that every network or system administrator should be familiar with the approach. CLI is fast, self-explanatory and very output oriented. The problem lies in scalability. One person is capable of running multiple CLI sessions at a time, but the attention span dedicated to each one is low. As a matter of fact, multiple CLIs are not a type of network analysis tools when it comes to
Rather than viewing one output at a time, we should be getting a bigger picture. The only way is to implement automation. There are many ways of doing that. First, we can start with automation scripts for data collection. However, that may come at a cost of utilizing network engineers for building scripts. Or secondly, we can choose from many available platforms on the market. The second options comes at a cost as well, as we are paying fees for the software.
Because there are many available platforms on the market already. Let's focus on the main features that every one of them should include.
If the provided network analytics platform comes with automated network discovery, it's a good job done already. The most important is always up to date information. If the discovery is completely automated, one can be sure they will never lose track of new devices.
Each network vendor is more than happy to provide its users with their own management platform. That's great, however, most of the times it only works for one specific vendor! There's no best vendor for all services. You can have datacenter firewalls from Juniper, web secured with F5, distribution network running on Arista and core on Extreme. The flexibility is the key here and to manage 5 separate systems for one complex network is not an option, it's cumbersome.
The network analysis tool should be able to provide security and compliance feedback. It should automate data collection and verification at the same time. It's great to have all data but without proper analysis, it's lacking the finish line.
From any network tool, the admin should be able to easily export data in multiple formats. It can be either CSV, JSON or any Image format for diagrams. It's critical for teams to collaborate and proper export options can elevate that greatly.
The IP Fabric platform provides multiple export formats and two main automated documents on the fly.
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 observe how it can assist you in more efficiently managing your network, please write us through our web page www.ipfabric.io
To begin with, IP network gateway redundancy has become a very standard high availability solution. In IP Fabric's platform it’s described as First Hop Redundancy Protocol (FHRP) feature that currently umbrellas HSRP, VRRP and GLBP protocol.
I have prepared a little scenario in our virtual lab with a LAN switched network protected by a firewall that is forwarding all traffic out with a default static route towards virtual VRRP gateway. The virtual gateway is created with the help of two Juniper boxes, vMX and vSRX in packet mode with no security policies defined (functions as a router).
After successful discovery with IP Fabric version 2.2.5 we will confirm correct VRRP setup by using diagrams and by slightly modifying our view.
There’s a simple ring topology consisting of 6 routers total (3 of them are SRX, that are considered correctly as device with firewall capabilities, specifically static1r16, static1r17 and static1r18, but all act as routers). Other three routers in the ring are vMX routers.
First, I would like to verify that VRRP is operational and correct virtual gateway is active. In IP Fabric in diagram Options panel we check ‘Show FHRP’ and if configured properly, both gateways would pop-up on the diagram. Afterwards, by simply navigating to FHRP yellow button in diagram, we would discover further VRRP setup, which seems to be correct. Router static1r18 is supposed to be the primary gateway. It’s closer towards exit points and it has greater link capacity with LACP interface compared to router static1r17.
We are currently seeing only IP related connections between routers, there’s single area OSPF as primary IGP protocol, with static routing already mentioned above (originating from static1fw56–1, pointing towards VRRP gateway). Well, let’s verify that.
There’re more options about how to obtain routing information in IP Fabric, but we can go directly from our current diagram. We simply click the firewall node on screen and all information are there. In the routes panel we only filtered all routes for ‘S’ (static routes). We verified next hop IP and interface, route metric and it seems we are good to go!
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.
This week we released IP Fabric version 2.2.5 which focuses on improvements of network diagram workflow, significantly improving the depth of information provided in the diagram tooltips, and improving readability of the End to End path diagrams. We’ve also added pseudo-STP links, or MAC edges, to correctly interconnect Layer 2 and Layer 3 when discovery protocol is not present between the devices. This release also adds support for GLBP protocol, support for multi-context Cisco ASA firewalls, support for discovery of ExtremeXOS devices, wireless support for HP830/850, and many other improvements and fixes as detailed in the release notes.
Clicking on a device or link in the network diagram now opens a detailed tooltip with information about the object. Information is contained in tabs of each window, and tabs depend on what functions the device is performing and what protocols it is running. For routers there is naturally more Layer 3 information, including ARP and active routing table entries. For switches there is much more Layer 2 detail, such as switchports and MAC address table entries.
Wireless controller tooltips contain information about APs, firewalls about zones, and so on.
Clicking on a protocol link also opens a window with specific details relevant for the protocol, such as virtual ports and switchport details for the STP link
Or routes and for the routed links
Switching tab to the Managed IP on the routed link shows active IP addresses on both sides of that link.
More time can now be spent in network diagrams and going through the detail without leaving the diagrams by managing tooltip windows. These can be resized, moved, or minimized as needed, and can be referred to later by clicking on the window icon in the bottom right corner of the browser window.
We haven’t focused exclusively on the diagrams, and the Discovery interface has been improved to include information about encountered errors during parsing of device output, grouping issues by error types and enabling to click through to specific output that caused a problem for IP Fabric. This enables to quickly spot issues such as missing authorization for a specific command, or inappropriate timeouts for very long command outputs.
The discovery connectivity report itself has also been improved to include not only successful and failed attempts, but also skipped attempts when an IP in queue was found to be belonging to one of the discovered devices, or halted attempts when device being discovered was found to be discovered in parallel by another process (simultaneous duplicate discovery). A complete CLI output log is also available for each attempt.
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.
If a user reports that a certain application is not working for them, especially after a migration or a change, how do you verify the connectivity?
Finding a path in a complex network can be hard enough by itself, having to map active switching and routing forwarding and balancing decisions, but additionally mapping security decisions of all the L2 and L3 filters take days if the network is complex enough, especially if multiple Zone Based firewall clusters are involved.
In this example we’ll see how IP Fabric can help you with a migration of a warehouse telemetry app that is publishing data from sensors to the secured servers from one port to another, verifying all forwarding parameters of end to end connectivity.
We can find the telemetry endpoints by looking at the network map of the warehouse.
To understand topology better we can see where the site is connected to the transit, group forwarding topology into layer 3 and layer 2 islands, and then finding a specific endpoint connected to a switch that is far from the site’s edge, and using it in the End to End path lookup dialog window.
Alternatively, we can simply type part of the DNS name or an address, and find endpoint that way, which we’ll do for the server.
Looking at the path reveals a number of balancing and filtering decisions of interest, including layer 2 filters, wan edge filters, missing path redundancy within the site, and the filter on the Zone based firewall cluster.
We can see that this particular flow would be allowed signified by the green arrow, and the matching decision at every point can be drilled down to reveal the detail of the policy.
Changing the port to 443 reveals that this traffic would not be allowed, and connectivity would not be possible, so policy on the firewall will need to be updated for the migration.
We can save path lookup result to refer to later or share with the team, and export the image for reporting purposes.
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.
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:
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
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!
