Upon popular request, we've added a new agent to the Kentik platform – Kentik BGP proxy (kbgp) – which enables BGP enrichment of flow data to internal network devices without requiring global IP connectivity. Before kbgp, customers could only establish BGP sessions with devices with an assigned public IP address. Via kbgp, BGP enrichment can now extend to flow data generated from all internal areas of your network, further enhancing network troubleshooting for on-prem and campus environments. Read on for details!

Kentik BGP proxy (kbgp) is a Kentik agent that can proxy BGP peering sessions between customer devices inside the customer’s network and Kentik over the Internet. The kbgp is deployed inside the customer’s private network. The customer devices are able to establish BGP peering with the kbgp, which will multiplex and relay BGP packets in real time to Kentik. The result would be the same as if the devices are peering directly with Kentik.

The functionality is achieved similarly to the functionality that is performed by kproxy, which collects flows locally inside the customer’s network and securely exports them to Kentik inside an HTTPS tunnel.

Without kbgp, customer devices can only establish BGP sessions with Kentik over the Internet, which requires that the customer device has a public IP address assigned. With the use of kbgp, multiple registered devices can have BGP peering with a single kbgp. The BGP session packets are carried over a secure gRPC session to Kentik, where the BGP session is logically established and the data is transferred. kbgp does not store any BGP state or BGP routes, making this agent lightweight and requiring very few resources.

The image below shows the logical diagram of kbgp usage inside a customer’s network

The key benefits of deploying kbgp in a Kentik-monitored network include:

• Kentik will be able to add BGP context to the flow data from internal network devices that don't have global IP connectivity
• The BGP data is secured and encrypted during the transfer from the customer's network to Kentik

At the moment, kbgp does not appear under the Kentik Agents section in the Settings menu, but we are actively working on a way to display the agent within the UI. For more information about the kbgp installation, configuration, and troubleshooting, please check out our kbgp KB article and let us know your feedback in the comments. 

Following multiple requests from our Kentik Market Intelligence users, we have just added additional Network Level metrics and visualizations that will help our users more precisely gauge the size of the Network (Autonomous System) they are investigating.

Read on for more details!

More Customer / Provider analytics history

First, we are now showing a history of provider and customer counts by month over the past 12 months. For instance, it can come in handy to notice a decrease in the number of providers for a given network, as it may create an opportunity for you to insert yourself as a new provider.
Noticing a sudden increase in the number of customers in a given region will also show KMI users the prospecting efforts of the network they are looking at are bearing fruits in a specific region.

Even more interesting, the charts displayed on this page are all governed by the top-level filter on the page, meaning that Customer Count by month can be narrowed down to any specific market you'd like to dive into.

IP / Prefix metrics additions

Another addition revolves around quantifying the size of any network's transit customer cone. The simplest metrics used in this case are often the density of the IP Address Space transited (for a Transit Provider) or Originated (for a Retail Network). These are now displayed (put in perspective with those of your own configured network) as depicted in the screenshot below:

Beyond the plain count of IPs, we are also showing a histogram of both Originated and Transited prefixes by prefix length, which can be a good indication of the size of the currently viewed Networks' customers. Again, these are also governed by the top-level filters on the screen.

Ranking history

Lastly, as most of you noticed on the landing screen, we have always kept a 12-month rolling history of rankings for all the ASNs in our dataset. Although we have only been displaying it for the "Ranking over time" top panel on our landing page, we've always had this data in store.

We are now offering it in the "Rankings" tab of any ASN's Network Detail page, as you can see below – again, this data and the rankings are governed by the top-level filters, which can be set on each screen. This means you can instantly assess how well any given network has been doing over the past 12 months in any market of your choice!

As Connectivity Costs is one of our most in-demand workflows, we've spent some extra time this quarter to address a much-requested change from our users: Billing Cycle Day and Contract End Dates have now been moved down from the Provider level to the Cost Group level within the provider. Read on.

Billing Cycles and Contract End dates are now a Cost Group level attribute

The main pet peeve our users had was that it is pretty common to have multiple IP Transit contracts with the same provider with a different billing date and contract end date. This was indeed a design flaw on our end when we initially released the workflow, and we're pleased to announce we have now corrected it.

All provider contract dates have been transferred to the child cost group objects within all providers and you can now modify them at will at a cost group level.

Let's see what it looks like, as the impacts on the Connectivity Cost workflow UI are multiple.

The new Cost Group Settings panel now contains Billing Cycle Start Date and Contract End Date fields. 

These are now visible on the cost group cards within a provider.

Provider Cards in the Provider Management screen now display these dates as part of each Cost Group entry.

The landing page Calendar Side panel now shows cards that correspond to cost groups, instead of providers, when it comes to Invoices Due and Contract Expiries. 

On the Provider Details Screen, cost groups with a Billing Cycle Date in the past are displayed in solid color, while the ones with a Billing Cycle Date in the future are displayed as estimates with a striped color. 

All Cost Group entries on the Provider Details table now show a progress bar displaying how far from the Billing Cycle Date each Cost Group is at the time of viewing, with a color that varies as we get closer to the billing date.

Download the entire SNMP Sample Set for Billing reconciliation

What do you do when the Kentik cost displayed at the end of your billing cycle doesn't match your providers' invoice? Generally, you enter a dispute which requires you to provide your own calculation together with the SNMP 5min samples it's based on.

We have made this possible in this addition to the Cost Group side panel in a providers' screen, where in the click of a button, the entire set of data samples for all interfaces (In and Out) gets generated as a CSV file for you to look at, also containing interface names, descriptions, device...

...and wait, there's more

While at it, we've also made the "Suggested Provider" right-side panel collapsible for those of our users did not want to see it in the Manage Providers screen:

Following through with the recent release of our PeeringDB integration, we've sat with our users and collected their feedback, which lead to a few granular improvements – read on!

Access PeeringDB records from any ASN anywhere in Kentik Portal

In a lot of places in the Kentik portal, we're displaying ASNs: Data Explorer queries, Network Explorer, Kentik Market Intelligence, etc...There's a common set of actions users always want to perform when it comes to an ASN: look at their footprint via PeeringDB, look at their ranking in a specific market via KMI, and so on.

We've altered the way we displayed these ASNs in the product so that you can always get to PeeringDB or KMI in a click, see for yourself:

Making PeeringDB easier to map with Kentik Sites

As we watched users configuring their PeeringDB mappings to Kentik Sites, we noticed that oftentimes, they didn't know the exact PeeringDB facility name to look for, and more than anything referred to them by their address. The lookup field in the Site mapping functionality in "Settings > Manage Sites" now displays the address and will also autocomplete based on users' address input, see below:

As one of our most used workflows, we keep seeing a constant stream of feature requests for the Edge > Connectivity Cost workflow. We just added a metric tonne of granular features, with more to follow shortly, read on!

Site Market breakdowns are here

Since we've released the Site Market capability (collections of sites), a lot of our users have mentioned that their approach to Cost Tracking should ideally rely on Site Markets.

The rationale behind this is that bandwidth costs most of the time rely on large geographic zones: prices within the same zone will usually be in a similar range, and blending them altogether is an unrealistic approach due to these sometimes large local variations. This is now a reality with the new "Site Markets" breakdown on the landing page:

These Site Markets also now have their own details page, as well as reports and subscriptions!

More CIR pricing tiers

Some of our customers let us know that they have contracts with plateaus that have more than 3 tiers, so we extended this capability all the way up to 5 tiers so they could accurately model their transit contracts.

Granular additions

• An indication of the currently selected month has been added everywhere necessary - it used to be tricky to remember which month was selected when scrolling down pages, so we've fixed that:

• 

  We've also made sure Mbps are used instead of auto-greek prefix when displaying details of a cost group's interfaces, since it's the unit used for billing.
  

  

More changes are coming later this month – we will update the article accordingly!

While Kentik does a great job of showing any network where their traffic goes or comes from, one outcome remains unsolved: determining where and how to interconnect with any candidate network once traffic warrants it.
Until now, this was accomplished by referencing an outside data set, namely PeeringDB.

PeeringDB is a non-profit organization providing a platform for networks to declare their footprint, as well as the conditions under which they evaluate peering requests from other networks. Since the early 2000s, this platform has been widely adopted by the peering community and is recognized as one of the inevitable tools at the core of any Strategic Peering planning activity.
The service it provides is considered by most a public utility and Kentik wants to honor the relentless efforts they've invested in keeping this community platform up and evolving it throughout the years.

Roping in the dataset from PeeringDB into Kentik, contextualizing it with traffic data and leveraging it to streamline the entire strategic decision process of peering is the goal we aim to achieve with this integration.

What is PeeringDB, and how is it used?

How is it useful?

Each network is identified by its unique ASN in PeeringDB, and its records contain:

• The policy they follow to evaluate peering requests (traffic constraints a network needs to fulfill to be eligible to peer with them)
• The list of Internet Exchanges they are present at
• The list of Facilities (data centers) they are present and if they are willing to peer

To interconnect, networks need to ensure they check all the policy boxes listed by the target network but also decide on a common footprint to physically connect at - think of it as an address book or yellow pages of peering. 

PeeringDB shortcomings

Traffic Analysis to Footprint evaluation is a siloed, noncontinuous path

Every network has its own traffic analysis system (Kentik being one of the more modern and prominent ones). Network Telemetry (Netflow, SFlow, IPFIX) is used to determine the list of ASNs where it makes strategic sense to interconnect with, as well as the IN:OUT traffic ratios shared with these networks. PeeringDB doesn’t have this data for their registered networks, but Kentik customers have it in the portal. This means the path from Flow Telemetry to Peering metadata isn’t continuous: users switch context from their flow tool to PeeringDB.

PeeringDB isn’t tailored to display common footprint easily

Once traffic profiling TO and FROM a network indicates a target for peering, the next step is to evaluate the common footprint. While PeeringDB makes it easy to browse the details of footprint or policy for any given registered network, computing the common overlap of IXes and Data Centers still requires the user to have their full network map in mind.

Kentik’s PeeringDB integration

In a nutshell

This extension to the ASN quick-view page makes these frequent tasks easier:

• Evaluate the details of TO and FROM traffic of any ASN towards yours, including traffic mix and volumes, as well as ratios, and evaluate them against the other network's policy
• Evaluate the common footprint overlap between your network and this ASN
• Support strategic planners in the decision to deploy at certain Data Centers or IXes
• Identify the NOC and Peering contacts for this Network when available

Configuring the integration

Using the PeeringDB integration starts with users configuring it (in the “Integrations” section) of Kentik Portal. Two options exist: the Kentik user network is either already a PeeringDB registered member or isn’t.

1. If it is, Kentik will help users create mappings between their PeeringDB “Facilities” (Data Centers) and “Exchanges” (IXes), as already configured by the users as “Sites”, and as “Connectivity Type == IX”.
   
   
2. If the Kentik user network is not already a PeeringDB user, it will let them do the reverse: link their “Sites” and “Connectivity Type == IX” to existing PeeringDB “Facilities” and “Exchanges” based on address and name matching. This can be done via both the "Settings > Manage Interfaces" and "Settings > Manage Sites" screens.

Leveraging the integration

Once the integration is configured, Kentik’s engine has a key to decipher any network’s footprint with a common language. It will display it in a human-readable form for users to visually and efficiently consume.

To make this per-ASN data available from multiple entry points in Kentik Portal, we have chosen to add it to ASN Quick-View pages. These pages are templated and dynamically generated to show users' traffic details around any ASN (TO or FROM). 

Accessing the PeeringDB View

Clicking on any ASN entry in either Network Explorer or Data Explorer will take the user to the ASN Quick View page, where the PeeringDB tab contains the target functionality:

Additionally, the quick-view pages follow an easy-to-memorize URL format, allowing users to get there easily:
http://portal.kentik.(com|eu)/v4/core/quick-views/asn/<AS_Number>

Yet another way to access this data is to use the Universal Search capability in Kentik Portal at the top right of the screen), which will auto-detect ASNs entered as a search term:

Quick-View pages will be deep-linked throughout Kentik Portal:

• Kentik Market Intelligence gets a new button on any Network Details page to access these records:
  
• Any ASN returned as part of a Network or Data Explorer query already leads to the ASN Quick-View page where this new PeeringDB info tab appears.

Anatomy of the PeeringDB screen

The PeeringDB tab of an ASN Quick-View page contains the following elements:

Left-Side Panel: Metadata

A left-side Panel with contextual information both from Kentik and PeeringDB around this ASN

• Traffic information TO and FROM this ASN leveraging Kentik network telemetry - with all the traffic information to quickly identify if traffic matches the requirements of this ASN: Traffic volumes IN and OUT, Traffic Ratios, connectivity mix (Peering, Transit, IX…)

• PeeringDB peering information around this ASN: policy details, ratio and footprint requirements…

Main Panel: Footprint Explorer

A Main view to identify common footprint

This view will offer two different angles on identifying a common footprint: Map View or Table View, with the user able to toggle between both or view both at the same time.

The Map will display Exchanges and Facilities with different icons, these will be grey if not in common, and blue if in common.

Tooltips will give more information when the user hovers over these icons.

A Data-Table listing either Facilities (Sites) or Exchanges (IXes)

This component is a tabular version of the map visualization that sits above it. It is also controlled in real-time by the filters at the top of the main section of the screen. Exchanges and Facilities for the currently viewed network stand behind two tabs, each containing a different data table

Another useful feature is that the Exchange tab allows users to expand any IX row to list the Facilities in it - think of the use case where the user Network is colocated at a given facility, but hasn’t contracted with the IX(es) available at that facility.

Main Panel: Central filter

Both the Map View and the Table view are controlled by a set of filters allowing the user to refine the geographical scope for which they are looking for common footprint, all filters AND’ed together:

• Type:
  allows the user to reduce the view to either Facilities, Exchanges or both
• Country:
  is a multi-select list letting the users select a set of countries to narrow down the search to (note the map will zoom in and out of focus to match the footprint selected by this multi-select)
• Common:
  that allows users only to display the common footprint, be it Facilities or Exchanges

Common Peering Facilities will be noted with a blue checkmark in the data-table at the bottom, as well as for common Exchanges.

Additionally, Exchanges where the user's network isn't present, but which span across Facilities where the user's network is present will appear with a light blue checkmark:

Exchange entries in the data-table can be expanded into the list of the Facilities that the exchange spans across

Right-side retractable panel: Facility/IX ASN explorer

To create an even more cohesive exploratory workflow, clicking on any Facility or Exchange in the main screen (and on the map) will unveil a side panel containing both details around the Facility/Exchange, but most importantly, a list of all the ASNs available, together with the useful metadata to evaluate on the fly if more candidate ASNs are present.

 To make the list even easier to navigate, additional filters have been added (exclusively for this panel) around the Peering Policy’s constraints, as well as the Traffic Ratio Type, and a free text search field.

Futures

In the future, Kentik will be putting the PeeringDB dataset to work on even more advanced use case, think of it:

• How much time would Strategic Network Planners save, when deciding on global deployments, which Site or Internet Exchange they should deploy to?
  Think of being able to ask Data Explorer:

“Show me all the ASNs and the associated traffic that I am reaching via Transit and that are available at this exchange with an open peering policy”

• Beyond that, think of an insight that would scan your Top ASNs IN and OUT daily and advise which IXes you should deploy to peel traffic off of your Transit upstreams. Or even tell you if you are at an IX and are not peering with ASNs there that you should?

Truth is, this PeeringDB integration is only the 1st step towards further automating peering operations of Global Networks - let us know what you think, because we're pretty excited about these next phases!

Today, we are adding a set of new endpoints related to various workflows in the Kentik Portal. 

Read on!

The first thing to know before we get into the details is that you can always access our API sandbox from the navigation menu here:

We have recently added a set of previously unreleased endpoints to our v6 API, all can be visible at the following URLs in the portal:

• https://portal.kentik.com/v4/core/api-tester/ on the US SaaS Cluster
• https://portal.kentik.eu/v4/core/api-tester/ on the EU SaaS Cluster

These new endpoints cover three main areas of functionality:

• Custom AS Groups CRUD functionality
  This new endpoint set only covers the management of these AS Groups. Ongoing work is scheduled for the Data Explorer Query API to be compatible with AS Group rollups, but the release date isn't yet set.

  

• Workflow APIs

  • for Capacity Planning
    The set of endpoints we’ve added to Capacity Planning is for now exclusively centered around viewing either a summary of all capacity plans or details of specific plans. 
    

    

    

  • for Kentik Market Intelligence
    This set of API endpoints allows users to either get any ranking with any Customer-base type in any market or get customers and providers of any given network in any given local market.

    
    

    

Important note
The sandbox shown in the article is the one of the v6 of our API. We still have a v5 API which still covers a large amount of legacy unmigrated endpoints - the testing UI for them is located here:
https://api.kentik.com/api/tester/v5

Our CDN Analytics workflow relies on a detection engine which both takes into account your own Kentik configuration (via Interface Classification) and its constant scanning of the internet to detect IPs from CDN Servers out on the Internet. In this release, we added means for our users to help it better detect, or take into account undetected CDN caches that they are embedding in their networks.

Important note: New configuration possibilities offered by this workflow update are highly advanced - if you feel like you need to use this feature, please seek advice from your Customer Success Engineer.

Understanding Kentik's CDN detection engine

Kentik enriched flow data includes src_cdn and dst_cdn fields, and these are accessible in Data Explorer as well as the namesake workflow CDN Analytics, they are also leveraged within the OTT Service Tracking workflow. 

Values for these flow columns come from Kentik’s special sauce: every day a complex engine runs and evaluates multiple data-sets to map as many IPs as possible to CDNs. src_cdn and dst_cdn are then populated in flow records using this global (<IP>,<CDN>) mapping table.

Datasets used by the engine for classification

CDNs can be a mix of servers either hosted on the CDN’s own network infrastructure, or inside of other networks. While servers hosted on the CDN’s own infrastructure are somewhat easy to detect, last mile embedded caches aren’t, because they’re addressed with the embedding broadband ISP’s address space.

The CDN detection engine uses a combination of the methods below, when it runs every day:

• Internet Scans data
  Determines how public CDN cache server IPs are detected, as well as a portion of last mile embedded caches.
  This process is not detailed in the present article.
• Kentik Customer data
  This mechanism helps with detecting IPs of embedded caches that are not identified by the previous datasets.
  This detection mechanism is based on a customer’s Interface Classification accuracy.
  The engine pulls and inspects all interfaces whose Connectivity Type is set to Embedded Cache and look at the Provider value for the interface. We perform a loose match with the Provider field then assigns the interface's subnet to the CDN that has been matched with our database.

This example shows an Interface Classification Rule which will result in the associated interfaces' subnets to be picked up by the CDN detection engine and associated to a CDN.

Corner cases for Embedded Cache detection

While this approach has shown good results, some customer setups make it difficult to entirely (or sometimes correctly) detect Embedded Cache IPs. The examples below detail such corner cases.

Situation #1

Here, the interface tagged Embedded Cache is actually a /31 or /30 point-to-point subnet to connect with another Network Device on which the Embedded Caches are located, with the aggravation that this Network Device is not sending Flow Telemetry to Kentik.

In this case, two things will happen:

1. the engine will mislabel the /30 or /31 to a CDN if its provider field is set and matched (this happens for Facebook FNA caches, CDN77 caches... which often come with a router shipped with the caches by the CDN provider)
2. the engine will be missing the Caching Server Subnet below for not having any Interface Classification from the non-kentik-registered router.

Situation #2

This situation is pretty similar to the previous one, with the additional complication that the interface sending flow data is not tagged as Embedded Cache by the Interface Classification rules.

In this instance above, the CDN Engine cannot detect the subnet where the cache servers are, because it doesn't have an Embedded Cache interface to pickup the subnet from.

Solving for these situations: the new CDN Analytics configuration screen

Inspecting and amending CDN Engine detected cache entries

To remedy both of the aforementioned situations, the Configuration button in the CDN Analytics workflow will allow for fine grain additional configuration.

The first tab of this configuration screen, Detected Embedded Caches, will:

• List all the subnets detected from Interface Classification and the associated Provider values, as well as the CDN that's been assumed from the Provider value
• Let the user disable those that are tagged Embedded Cache but whose subnet is not a cache subnet (example of Situation #1)
• Add a CDN Provider to any interfaces labeled Embedded Cache where the Provider value hasn't been set, therefore which the CDN Engine couldn't make a CDN attribution decision on.

Manually declaring undetected Embedded Caches

To also address the situations of having caches behind non-Embedded Cache classified interfaces, and therefore undetected by the CDN Detection Engine, users have the option to manually declare CIDR blocks and assign them to CDNs, via the Additional Embedded Caches tab of this configuration screen.

Entries in this configuration section will now be picked-up with every daily run of the CDN Detection Engine and will be added to the global  (<IP>,<CDN>) dataset in use by all our customers.

Understanding how the CDN Analytics workflow leverages your Network Telemetry

Bolting src_cdn and dst_cdn values into your enriched flows is not the only thing that needs to happen for your CDN Analytics workflow to display accurate data.

The workflow needs to inspect the right flow data from your Network Devices to deliver a cohesive analysis of the CDN traffic that not only enters your network, but also is generated from embedded caches within it. To do so, this workflow uses this generic filter:

As you will notice, this filter will work perfectly as long as all of the Embedded Caches in your network are connected to a router exporting flow data to Kentik. When this is not the case, the flow data to include will simply not be collected by Kentik from the interface facing the cache. 

it is important to understand that mapping Cache Server IPs and selecting all the cache related flow telemetry are two aspects that need to work for the CDN Analytics workflow to display accurate results.

In the previously discussed Situation #1 and Situation #2, flows coming from the cache servers will not be considered by the filter displayed above, therefore we need ways to add these to the filter-set that regulates what flows the CDN Analytics workflow will consider.

Tuning the CDN Analytics workflow to include non Embedded Cache traffic

Let's go back to Situation #2

Now we want the CDN Workflow to include traffic from the Caching Server Subnet to the data it will display in its analysis. This will be done by using the Advanced Filtering section of the CDN Analytics configuration options:

As you can see in the screenshot above, traffic from eth0/0/1 on the edge-01 network device coming from the Cache Subnet would not normally be caught by the default filter, adding it modifies the CDN Analytics behavior to include it now.

Connectivity Costs is one of the workflows in the Edge module that seems to be the most successful with our users. It allows users to centralize the financial modeling of their Transit, Peering and IX contracts in one place, and track costs for each of these throughout the month, and every past month.
For a refresher on this workflow, take a minute to read this blog post from 2021 on Why and How to Track Connectivity Costs.

Today, we add quite a few highly anticipated features to it, read on!

Landing page calendar drawer now collapsible

The drawer with the invoice and contract expiry schedule is now collapsible, which was a common request from users whose contract dates are always the same: it can now be hidden, and the preference will stick for each user.

Dynamic Interface Selection

In the previous iteration of Connectivity Costs, interfaces has to be manually selected and added to the relevant Cost Group in order to bind them to a contract and financial model. For networks with a vast footprint, these external facing interfaces keep coming in and out of the picture, and users demanded to be able to manage this part of the configuration more efficiently. This is now done: from the already popular Capacity Planning workflow, we have ported the Dynamic and Static Interface Selector module into Connectivity Costs.

In addition, we've improved it significantly to make things even easier to maintain - amongst others, users can now assign interfaces in a cost group based on:

• Interface Name and Description regular expressions
• Device Names, including regular expressions (comes in handy if a portion of your device names is Site or Function related - think edge-01_ams01 for an Edge Router in Amsterdam)
• Device Labels, allowing you to exclusively focus on specifically tagged devices
• Last but not least: users can now choose between Logical Only interfaces, Physical Only interfaces, or both - for instance, depending on which of the physical or logical part of an Aggregate logical interface your SNMP accounting is going to come from

Interface or Group level additional costs expressed in any currency

Users can add Cost Group level (monthly or yearly) costs to their cost groups, but can add Interface Level costs as well. Until now, the currency of the parent Cost Group would be used to evaluate these additional costs into the daily computations.

With this release, users can now select the currency for both. Here's an example of where it comes in handy: optional interface charges are often used to document cross-connects. Our customers also tend to use local providers in whichever area they are sourcing bandwidth from. This often results in Bandwidth as documented in the Cost Group financial model being expressed in the local currency, and data-center cross connects (usually from a global data-center contract) expressed in another currency. Problem solved !

While at it, we made the Interface-Level UI for adding/editing costs more usable, see for yourself - in the example below, the cost group is in dollars and the interface charges for the cross connect in Euros. 

New Computation Methods

Based on feedback from our users, we also added a few new computation method flavors as to how our engine should compute monthly invoices. To the existing Peak of Sums and Sum of Peaks we added two new models:

• Peak of Sums (Multiple interface sets)
• Peak of Sums (Max of In and Out)

And to make sure our users select the right one when configuring a cost group, we also gave better in-UI explanations of how each computation method works in the back-scenes:

What comes next ?

In future quarters, we are going to both extend the workflow to deal with non-edge costs, and also create functionality for users who have documented their costs into the workflow to be able to price any slice of their traffic.

Stay tuned, and in the meantime do let us know what you'd like to see next in this workflow !

Early this year we launched Kentik Market Intelligence to spell out the internet interconnection ecosystem for you. It crunches large amounts of public BGP routing data, and scores and ranks all networks in any market based on the size of their customer base.

With this new release, we've added a significant feature set: Kentik Market Intelligence Insights. 

KMI Insights? Tell me more...

Insights are the relevant news items around the networks and markets you care about. When crunching the billions of BGP dump entries multiple times a day, our platform now identifies interesting insights that get contextualized in the KMI UI, coloring them with the networks involved and the market they are observed in.

Sample insights can be: <This provider> added <this transit customer> within <this geography> for instance, or any network adding new providers, as well as rank changes and changes in routing announcements between two networks.

Each insight comes with a certain amount of mandatory attributes: 

• A Customer Network: as identified in the Provider/Customer ASN relation we crunch with every run
• A Provider Network: as identified in the Provider/Customer ASN relation we crunch with every run
• A Market: the market this insight applies to
• Insights type:  as explained before, our engine classifies insights based on their nature (see list in the screenshot above)
• Magnitude: an arbitrary 1-5 value that helps order these insights from most important to least important, which is most often correlated with the change in prefix score, either plus or minus, between two networks

All these attributes have two purposes: helping the Kentik Market Intelligence UI display them in context (see further down this announcement), and allowing users to slide and dice these insights and tailor them to any subset they'd like to keep track of.

Contextualized insights

A new "Top insights" panel now appears on the right side of the landing page, it can be collapsed/expanded using the top right [insights] toggle.

The landing page will display unfiltered insights, ordered by magnitude, and this list of insights will by default follow the market filter used on the landing ranking screen.

This side panel can be configured to include or exclude specific types of insights, or to extend the period covered by the insights.

When navigating to any Network Details screen, the insights right-side panel will be displayed on the "Overview" tab for this network, and filtered to focus on the investigated network.

Track Networks and Markets that matter to you !

A while back, we introduced Observation Deck, which is a place for every user to compose their landing page with the areas of network visibility that specifically matter to them, based on widgets from specific workflows and areas of the product.

Kentik Market Intelligence now has its first widget and it's powerful!

In the future, we will add more KMI-related widgets to the Observation Deck so that you can embed widgets showing rankings and visualizations from KMI.

We hope you'll enjoy this update as much as we do. Please send us your feedback on it, we'd love to hear what you think!