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!

Kentik added support for 6PE technology and BGP IPv6 Labeled-Unicast address family to be used for Flow enrichment.

The IPv6 Provider Edge (6PE) is the technology that enables isolated IPv6 networks to communicate using MPLS LSPs over an IPv4 MPLS backbone network.

The diagram below demonstrates the typical scenario for the use of the 6PE technology. CE routers which are at the border of the IPv6 islands, advertise their IPv6 routes to the 6PE routers of the MPLS network. These PE routers are the only dual-stack routers, which support both IPv4 and IPv6. The 6PE router advertise the received IPv6 routes to other 6PE routers using MP-BGP session over IPv6 Labeled-unicast address family. These route have:

• Original IPv6 route received from CE
• Inner MPLS label value, which would be used in the 6PE router’s data-plane to encapsulate packets toward IPv6 island’s networks.
• Next-hop with the IPv6-mapped IPv4 address which is in the form of “::FFFF:<IPv4-address>”.
  • The mapped IPv4 address is the address of the advertising 6PE router.
  • It determines the Outer MPLS label which will encapsulate IPv6 packets inside the MPLS network

To perform enrichment based on the 6PE information, Kentik’s user should establish the BGP session with the IPv6 Labeled-unicast AF between their 6PE router and Kentik. Based on the received IPv6 LU routes the Kentik’s ingest layer would be able to enrich the Flow’s received from those 6PE routers. All “standard BGP” dimensions would be populated, but more specifically:

• The “Next-hop IP” dimension will be populated with the next-hop IPv4-mapped IPv6 address from the received route
• Based on the IPv4-mapped address, the Kentik ingest would identify the next-hop 6PE router and populate “Ultimate-Exit Device” dimension and based on that, the other “Ultimate-Exit” dimensions.

Additionally, to instruct the use of Labeled-unicast routes, a user needs to select additional configuration for 6PE routers in the Kentik.  At the Settings → Devices page, select the 6PE router device and “Edit device”, then at the BGP Tab, at the “BGP route selection” drop-down menu select the option  “VPN table, fallback to Labeled-Unicast table, fallback to Unicast table”.

The example of the Data Explorer output with the 6PE BGP next-hop dimensions is shown below:

Kentik has added a new configuration option, which determines how the BGP routes are selected for flow enrichment process. To make the whole process clear enough we should start with the basics.

BGP sessions

BGP session between customer’s router and Kentik can be established over:

• IPv4
• IPv6

Since these are “Multiprotocol BGP” sessions, for each of the sessions, it is possible to enable multiple Address Families, for example: Unicast, Multicast, Labeled-unicast, L3VPN, Flowspec, etc.

These Address Families are defined with AFI (Address Family Identifiers) and SAFI (Subsequent Address Family Identifiers) attributes. They are regulated by IANA and the exact values can be found on the following links:

• IANA AFI numbers: https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml
• IANA SAFI numbers: https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml

The Kentik side of the BGP peering with customer’s devices will be enabled with the Unicast, Labeled-Unicast and L3VPN families by default. For the BGP “IPvX” session from the Kentik side will have the following AFs enabled:

• “IPvX” unicast
• IPv4 and IPv6 labeled-unicast
• “IPvX” L3VPN - (IPv6 L3VPN address family is not used)

Received routes from each of these address families are stored in the separate route table, which is check during the Flow enrichment process.

NOTE: IPv6 VPN routes are received, but not used for the enrichment

The Flowspec address family will be enabled only if the customer explicitly enable it in the device configuration on the Kentik portal.

BGP attributes enrichment process

Assignment of the “Route Prefix/LEN” dimension

The assignment of the Src and Dst Route Prefix is the following:

• Src and Dst Route Prefix dimensions are first populated from the Flow information using Src and Dst Mask field from Flows - if applicable.
• Src and Dst Route Prefix will be overwritten further in the ingest processing if there is a matched BGP route.
• The way to know if the Src or Dst Route Prefix is coming from flow or BGP is by observing other BGP route attributes:
  • if the Route prefix originates from the flow information the dimension “Next-hop AS Number” will be “0 - -Reserved AS-,ZZ” and the dimension “AS Path” will be empty.
  • if the Route prefix is overwritten by the BGP information, the BGP related dimensions such as “Next-hop AS Number” and “AS path” will be populated

VRF metadata collection

As the part of the SNMP interface discovery process, Kentik SaaS or Kentik kproxy will perform the VRF discovery and interface association. This information about the VRFs is collected over SNMP using MPLS-L3VPN-STD-MIB, if the device supports it. The devices from Cisco and Juniper Networks support this MIB. We have also developed support for for Nokia’s proprietary MIBs.

For each VRF, Kentik collects:

• Name
• Description
• Route Distinguisher (RD)
• Route Target (RT)
• Interface association

BGP route matching process

The enrichment of the BGP/Route related Flow dimensions is performed as a result of matching the Flow’s IP address against the BGP route received from customer’s device over BGP sessions. The default behavior of the matching process is the following:

• Flow’s Src interface is checked if it is assigned to the VRF.
  • If the source interface is in the VRF, flow’s Dst IP address is looked-up against the BGP VPNv4 routes with the RD associated with the source interface’s VRF:
    • If there is a route match, the route will be assigned to the flow
    • If there is no match, or there is no BGP VPNv4 table at all, or even no L3VPN AF established as part of the BGP peering, the match will not be found and BGP route dimensions are not populated.
  • If the source interface is not in the VRF, flow’s Dst IP address is looked-up against the “global” BGP table containing Unicast IPv4/IPv6 AF routes.
• The same process is performed for flow’s source IP address route lookup, based on the destination interface association with the VRF.

BGP route selection configuration

To address some additional scenario’s that we have seen in the customer’s network, Kentik added the configurable option to influence the BGP route selection process related to which BGP routes will be used for matching process.

This configuration is available at the Settings → Devices → Edit Device dialog → BGP Tab.

At the dialog, there is a new drop down menu called “BGP Route Selection” with the following three options:

• VPN table for VRF interface, Unicast table for non-VRF interface (default option)
• VPN table, fallback to Unicast table
• VPN table, fallback to Labeled-Unicast table, fallback to Unicast table

The following table describes the behavior of each configuration option:

By popular demand, we've added a new dimension named Site Market in Kentik Portal. It allows our users to group sites within Markets and use this new dimension in all parts of the product to filter, or group by.

When is this feature useful?

We've heard many times the situation where having multiple PoPs in the same metropolitan area makes it difficult to pivot Guided Mode dashboards around.
For instance, it is not uncommon that large networks have multiple PoPs around Los Angeles, say LAX1, LAX2, ..., LAXN. Most of the time these networks want to consider all of these as a single Metro: enters Site Markets, slap a "Los Angeles Metro" Site Market Label on all of these and you can now use it as a Dashboard Guide Mode parameter !

With its Ultimate Exit Site Market, and its special "Site Market doesn't equal Ultimate Exit Site Market" large networks are going to be able to perform useful queries telling them when traffic form one of their peers isn't hot-potato'ed and carried at higher cost over long distances. 

How can I configure the feature?

You can navigate to Settings > Manage Sites where you'll notice the new Site Market attribute. You can create a new Site Market on the spot or pick an already existing one.

From the Manage Sites screen, you can even Bulk assign Site Market to sites, which obviously comes in handy the first time you discover the feature.

When first configuring your Site Markets, you can also leverage the filters on the Site screen to quickly select all those without a Site Market, which together with the aforementioned feature really helps moving faster.

The Manage Site Markets screen

Additionally, Site Markets now have their own Settings screen, which can be found here:

Custom Geos vs Site Markets

There is a misleading parallel between Custom Geos and Site Markets, so let's take a look at these:

• Custom Geos: map a Source Geo and Destination Geobased on
  • GeoIP data from Source IP and Destination IP
    and
    Custom Geo to Country mapping from the Custom Geo user configuration
• Site Markets: map a Site Market based on
  • Site to Site Market mapping from the Site Market user configuration

The main differences are:

• Site Market is a superset of Sites when Custom Geo is a superset of countries
• Site Market is not directional (green column in Data Explorer's dimension selector), while Custom Geo exists in Source and Destination variants

Using Site Markets

Site Market dimensions are available in both Data Explorer Dimensions and Filters, and come with their "Ultimate Exit" pendent: Ultimate Exit Site Market is mapped from Ultimate Exit Site using the users' Site Market groupings from the configuration screen.

Finally, the Site Market filter comes with a very useful operand saying "Site Market doesn't equal Ultimate Exit Site Market" which will help networks identify traffic that does not stay local (and is therefore more expensive to transit - we trust this feature will be very useful to large Service Provider networks.

Enjoy and let us know what you think about the feature!

Kentik Market Intelligence gets a couple useful improvements added.

KMI will now let you export rankings and customer/provider lists as a CSV file.
Additionally, we've added a "density chart" on top of the KMI landing page before the ranking table.

The  KMI landing page has been updated with what we call a Density Chart: the usual table-chart we all know and love did not really convey the idea of the actual distance between consecutive networks in the ranking. This new widget has been added on top of the ranking table and places Networks on the line based on how far they are from each other in terms of KMI score.
(check out this article out if you want to understand how KMI score are computed)

Based on popular demand from our KMI customers, we've added a functionality to download the CSV data from both the landing page, and any given network's detail page:

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

In the back scenes, Kentik's OTT Service Tracking workflow leverages an engine, aptly named True Origin. This engine correlates DNS Query/Response data with network telemetry to provide a scalable, affordable DPI-lite type of service.
You can learn more about it here.

While this is something that we rarely spend time talking about, our OTT detection engine, a broadband provider’s favorite, keeps on learning and evolving as time goes by, and the amount of DNS hostname patterns that it is able to detect the underlying service for keeps on increasing constantly.

Over the month of October 2021, the True Origin engine has learned to classify an additional ~1,000 new hostname patterns to match flow with DNS queries. This month, its improvements were centered around Vietnam, Denmark, Sweden and Germany.