In previous releases we provided the option to include network layer data in web tests by enabling ping and trace route in HTTP(S) and Page Load tests. This allowed us to quickly correlate application and network metrics to identify the root cause of an application's performance or availability issues.

Expanding on our cross layer visibility we can now include BGP data in web tests as well. Allowing us to further improve the time it takes to identify the root cause of issues as originating in either the application, network or routing domain.

Where previously you would need to create a separate BGP Monitor test you can now examine the same BGP data in an adjacent tab on the results page itself. No need to jump between test views!

When included, BGP data will be visible as an additional tab in the test results page.

Putting it altogether, we can now analyze all layers of information relevant to a target application's health on the same screen, including

Application metrics and Network Ping metrics in the Results tab.

Network Trace metrics in the Path View tab.

To add BGP data to an HTTP(S) or Page Load test turn the switch to "Enable bgp monitoring" (disabled by default) and enter the necessary details as you would for a regular BGP Monitor test including health options for Allowed ASN(s), RPKI status and Reachability (Advanced Options). 

Refer to the KB for more details on configuring BGP Monitor tests.

Building on our existing BGP monitoring capabilities – Event Tracking, Hijack Detection, Route Leak Detection and RPKI Status Check – we majorly enhanced our BGP monitoring feature set (under Synthetics) with new visualizations that track BGP Reachability and the BGP AS Path.

See the related blog posts, Introducing BGP Monitoring from Kentik and Why You Need to Monitor BGP, or watch the video (webinar) Why you should monitor BGP and where to start for useful overview information.

To get started: click Menu > Synthetics > BGP RouteViewer (we automatically pull in your AS and Prefix info for you) and click the blue  "Start Monitoring" button. 

Or go to Synthetics > Test Control Center > Add Test > BGP Monitor to create your own test

Reachability tracking

We help you track changes in the reachability of your prefixes from hundreds of vantage points all over the internet and will alert you when any of them become unreachable. You need to be sure that traffic from your ASes can make its way to your customers and the service providers you depend on.

AS path change tracking

Frequent changes in the path that BGP route announcements take between ASes can be a sign of instability. Monitoring for these changes and getting alerted as soon as they occur is a key part of ensuring service reliability.

AS path visualization

Fast troubleshooting of issues requires being able to visualize data to find trouble spots quickly. We give you a 10,000-foot view of changes in BGP routes over time — an indispensable tool!

March 2022 comes with a flurry of new Synthetic Monitoring feature updates. Amongst others:

• A new top-level location for the BGP route viewer page
• Multiple enhancements to the synthetics Performance Dashboard

BGP Route Viewer Page

Similar to the State of the Internet page, we have moved the BGP Route Viewer tab into a separate top-level page. We recently introduced BGP performance monitoring as part of the Kentik Network Observability Cloud, and want to give this feature more visibility as many customers requested it. If you’d like to learn more about this feature and its use cases read the blog post, Introducing BGP monitoring from Kentik.

Performance Dashboard enhancements

We continue to enhance the Performance Dashboard moving it more towards being a true dashboard. The updated widgets include: The incident log (width), the Test Status Summary pane (styling and location), the Recently Added Tests (styling and location), and Agents and Credits (styling and location).

KMI is a new service provider workflow that uses the global routing table to classify the peering and transit relationships between ASes and to identify the providers, peers, and customers for any AS in any geography. KMI estimates the volume of IP space transited by ASes in different geographies and produces rankings based on that volume, thereby enabling users to compare ASes in various markets.

This new workflow is available to all Kentik users with Premier Edition or with the service provider add-on available for the Kentik Pro Edition. This new workflow does not require any configuration and is immediately usable, as it relies on public routing data from a large number of BGP vantage points all around the world.

As routing data gets crunched on a daily basis, it can now be consumed via a simple interface allowing our users to decrypt how networks are connected to each other, what any network’s customer base looks like or what their providers and peers are.

KMI uses the global routing table to classify the peering and transit relationships between ASes and to identify the providers, peers, and customers for any AS in any geography.

Additionally, KMI scores and ranks any network against the size of their customer base in any subdivision of markets, as well as per customer base type such as retail, wholesale or backbone. KMI can now serve as a public, neutral and objective benchmark to score and rank all networks.

Here are a few pointers to get you started with KMI:

• Product page: Kentik Market Intelligence
• Blog post: Launching a labor of love, Kentik Market Intelligence
• Press release: Kentik Market Intelligence launches to benchmark the internet
• Knowledge Base article: Details about how the neutral, objective scoring and ranking algorithm works

This December, a few top demands make it to the synthetics product area, amongst others: 

• App Agents get the traceroute and ping data back-ported from the legacy Private Agents
• BGP Monitor tests are made easier to navigate by allowing you to switch between the prefixes being monitored
• All existing Notification Channels are now available to synthetic tests

Ping and trace in page load tests

You are now able to run ping and traceroute on the App Agents. As a first step in the rollout, we have enabled UI changes to be able to run this as part of the Page Load test (the only test that uses the App Agents today).

BGP Monitor aggregated prefixes and prefix selector filter

Based on feedback from certain customers we realized that the BGP test results were noisy and it was hard to get a high level view of the number of changes and prefixes involved before digging into the details. We have made three changes to address this:

• We are aggregating the result set by prefix and grouping them into collapsed groups.
• The header for each group indicates the total number of BGP events grouped by type (Announcements, Withdrawals and Unexpected Origin events).
• A prefix selector on the top right allows users to easily filter down to a specific prefix and doing so only shows events for that specific prefix over the selected time range.

Support for all notification channel types in Synthetics

When we added support for alerts and notifications in Synthetics about a year ago, we supported Slack, email and JSON/webhook. We did the work necessary to support and template all the other notification types and have exposed them in the UI.

RPKI validation in BGP Monitor

We’ve added optional RPKI validation to the BGP Monitor test. When enabled (also the default) we will query the RPKI database and report the RPKI status in the result set.

New App Agents

We released a new set of agents that will enable tests at the application layer. These are what we’re calling “App Agents” and they are capable of running a full headless Chrome browser instance. These agents will enable us to offer our customers tests like Page Load tests and Transaction tests. When used in conjunction with our rich network layer functionality, these new agents and test types will allow network engineering and network operations teams to quickly determine if the issue is at the network layer or at the application layer.

Full Browser Page Load Test

We activated the Page Load Test type that performs a full browser page load using the new App agents.

• The new test type can be set up by clicking “Page Load” under “Web Tests”
• Agent selection uses the new App agents but this is seamless to the end user.
  • Once in the test setup, clicking the “edit agents” button will only display the App agents in the list (that is currently a subset of all locations but growing to include all currently supported locations).
• The test set up is similar to the HTTP or API test except:
  • It performs a full browser page load (while the HTTP test stops after the page contents are retrieved using a GET)
  • Only includes GET option (since it is a page load). Does not include ping and trace alongside the page load (we have plans to support that in the future).
• The results are presented in a similar fashion to the HTTP or API test, with the following differences:
  • Table columns include new “DOM Processing Time” and “Navigation & App Cache” that are specifically relevant to the time taken for the browser to load and display the contents of the page respectively

BGP Route Viewer

BGP Route viewer is the first of a series of capabilities planned to help proactively monitor BGP-related conditions that can impact performance. In response to customer requests and feedback, we have developed a comprehensive roadmap for BGP monitoring, and we believe our solution will have significant performance advantages over alternative solutions.

The first part of Kentik’s solution is BGP Route Viewer. BGP Router Viewer appears as a tab along with the existing SaaS and Cloud Performance tabs. For customers who have entered prefixes in their Network Classification settings, we will automatically load BGP update data for those prefixes in this tab. For customers who have not entered any prefixes in their Network Classification settings, we will show an interface that allows you to do so and give you the option to save the entered prefixes to the Network Classifications page.

HTTP Stage Timing and Charts

With the new Page Load tests, results can be plotted in a time series along with HTTP stages and the timing for each stage. This new view helps network teams isolate network layer issues from HTTP layer issues.

Major Path UX Overhaul

The (traceroute driven) path experience has been one of the most valued features of Synthetics and while it works well, we felt like we could go back and revisit the design holistically after having added a bunch of small and big features iteratively since it first launched (back in November). The updates we made can be summarized in two main buckets:

1. Improve the overall usability of the product/feature by:
   • Reducing the number of clicks to do things (like setting the thresholds and other config knobs)
   • Reducing the quantity of information presented on default load (intelligently collapsing things to reduce information overload)
   • Reducing the amount of whitespace used so it is more compact and requires less or no scrolling
   • Preventing the path from exceeding the bounds of the page
   • Avoiding the side pane (which required knowing that one should click and would cover a third of the path when open)
   • Remove the ping-driven health timeline, as this data does not necessarily correlate with latency seen on the path and can lead to confusion.
2. Support collapse/group by sites. This has been requested by a few customers, particularly ones that run tests within their own network and find the ASN option of less use (everything collapsed into their ASN). Having the ability to group by sites lets these customers know if a path change caused traffic to go through a different site instead of the expected/desired one.

Here is a list of the main changes:

• 
• Health timeline is removed from path tab. It was ping-results driven and could confuse users when it showed issues, but no issues were present in the path. (The path is trace-probe driven, which may not show the same issues for short-lived spikes.)
• 
• All group/collapse functions (ASN, left/right) have been rolled into one main “Group by” selector and the option to group by “Sites” has been added.
• Copy for geodistance-based latency comparison has been improved and helper text/icon added.
• Option to “Reset” everything back to default quickly has been added.
• 
• The ASN legend has been moved below the path UI and is displayed in a line, moving the path higher up in the page and reducing the amount of whitespace.
  
• The main path trace visualization has received the most significant overhaul and results in a much less overwhelming and much more fluid experience than before. Highlights include:
  • 
  • Extra effort has been put into avoiding overlapping traces that cross other traces and make the overall UI very busy and confusing.
  • You can hover over any node (without needing to click) and it will show you all the information available.
    
  • Similar to the node hover, hovering over an agent (source) or target will show you all the information cleanly organized in sections, and will give you a link to view the raw traceroute output. There is also an option to quickly collapse nodes for this or other agents with just one click, right there.
  • 
  • Previously we would only show latency for (red) links that exceeded the threshold and packet loss for (red) nodes that exceeded that threshold. Now this information is shown for all nodes and links. In cases where the metrics exceed the threshold, a red font is used to highlight. Further, previously high packet loss nodes were identified with a full red circle, which was confusing if there was an ASN with a similar color. Now this is made clearer with a red border.
    
  • 

Density Grid Groups Dashboard

In response to customer feedback, we have added a new type of visualization option under Synthetics in the dashboards (library) portion of the product. One of the key use cases is customers who set up DNS servers by zones and want to see a global view of the performance of their whole DNS infrastructure.

• Select “Add” a “Synthetics Test View” dashboard element and then pick the new “Density Grid Group” allows you to multi-select any tests configured in the system that are of type “DNS Grid” or “Network Grid.”
• Select a few tests and save the widget to display agents in the first column and then test results aggregated by target in the columns to the right of that.
• For each cell in the results, each square represents that specific agent hitting one DNS server to resolve the specific target.
• A holistic view lets the user quickly pinpoint any issues from a large number of DNS servers distributed across the world.
  

9 New LATAM Global Agents

We deployed nine new global agents throughout LATAM, improving our coverage in the region and increasing count from four agents to thirteen.

BGP is the routing protocol that makes the internet work—it is the language spoken by routers on the Internet to determine how packets can be sent from one router to another to reach their final destination.

However, route leaks and hijacks happen semi-frequently and usually result in part of the internet being unreachable.

An improved routing security mechanism is needed to make the Internet routing world safer. Enter RPKI…

Resource Public Key Infrastructure (RPKI), defined by RFC6480, is a cryptographic method that was designed to sign BGP route prefix announcements with the originating AS number. One way to think about what RPKI: RPKI is to BGP is what DNSSEC is to DNS. It offers a way to validate the origination of BGP prefixes against an official, signed list of prefixes by origin ASN.

Kentik has now integrated RPKI support via new dimensions, to allow users to precisely determine what would happen to the existing network traffic if they were to turn on RPKI validation on their networking equipment.

More details about these dimensions:

RPKI Validation Status: Contains the full RPKI state for a given flow, including the values shown in the table below:

RPKI Quick Status: Tells how traffic is going to behave globally by aggregating the RPKI validation Statuses. See the table below:

Furthermore, using RPKI dimensions with multiple other dimensions can provide a very detailed picture of potentially invalid or malicious traffic, to help network operators make informed decisions about turning on/off RPKI Route Validation selectively. For example, you can cross check with connectivity types, such as PNIs, IX peerings, transit and so on; or cross check with Routers and Sites; or cross check with end customers’ IDs.

For more information, please see our blog post with an introduction to RPKI, our blog post with a technical walkthrough of how RPKI features can be used in Kentik, and the BGP Dimension Reference in our Knowledge Base and look for “RPKI”, or contact our Customer Success team.

Lastly, stay tuned for more news concerning chfAgent as it now embeds both an RPKI validator and an RTR-speaking server, that can be leveraged by routers to perform route validation based on the aggregated global list of ROAs.

In the last couple of months, we announced VRF Support Phase 1 and Phase 2.

• Phase 1 enabled VRF awareness for Cisco L3VPN, Cisco VRF-lite, and Juniper L3VPN. There are eight new dimensions associated with phase 1 VRF support: source and destination VRF Name, VRF Route Distinguisher, VRF Route Target, and VRF Extended Route Distinguisher.
• Phase 2: Enabled VRF dimensions in alerting policies, and an API for managing VRF attributes.

Now in Phase 3, we’ve added a new capability that really sets Kentik apart: per-VRF correlation of traffic with BGP routing data. This gives customers complete visibility into end-to-end traffic flows across L3VPN topologies, including BGP paths and Ultimate Exit attributes.

A quick recap on Kentik’s patented Ultimate Exit technology: Ultimate Exit enables end-to-end network visibility by tagging traffic at the point of ingress with egress attributes like Site, Device, Interface and more. This enables engineering, architecture and product teams to cut costs (e.g., peering) and to more accurately estimate the cost of carrying any set of traffic for any given customer. For more information about Ultimate Exit, please refer to this blog post, or the Using Ultimate Exit topic in Kentik Knowledge Base.

Examples of VRF Support

The following examples show how traffic in the VRF named “acme” enters and exits the network. VRF dimensions can be combined with any other dimension to uncover additional detail.

For more VRF visibility support information, please see VRF Dimensions in the Knowledge Base, or contact our Customer Success team.