Good news! We’re extending our existing VRF (Virtual Routing and Forwarding instances) support to include Nokia routers – so if you're using Nokia’s SAP/SDP interfaces, you’ll now get deeper visibility into your VRF traffic, just like you already do with other vendor gear in the Kentik portal. 

A couple of months ago, we announced expanded support for Nokia SAP/SDP – and this latest update builds on that momentum, further extending Kentik’s visibility and insights for Nokia-based networks.

A critical technology of modern networks, VRFs allow multiple, independent routing domains to co-exist within a single router or switch, each with its own set of interfaces, routing protocols, and forwarding policies. This segmentation enhances network security and performance  – especially in multi-tenant and -customer environments – helping isolate traffic, avoid conflicts, and support more efficient routing.

Nokia uses vendor-specific MIBs with their TiMOS OS, which has historically made full visibility a bit tricky. With this update, Kentik now pulls in enhanced flow data for Nokia VRFs, including support for BGP, IPv6, and Ultimate Exit path tracking. That means you can now see where your traffic is actually egressing – even across complex Nokia VRF deployments. 

If you're already using VRFs on Nokia, there's nothing extra to configure – just start using the standard VRF dimensions in Kentik and you’re good to go.

As always, reach out if you have questions or want help digging into your VRF data!

We are excited to announce the early access release of Traffic Costs, Kentik’s newest automated workflow that illuminates the cost of key slices of network traffic. This release is the latest extension of our platform’s network cost intelligence capabilities, enabling users to optimize network spend and maximize profitability. 

Read on to learn more! 

The network cost challenge

Traditionally, network cost analysis has been a complex, time-consuming, and often imprecise process — one that relies on manual analysis, disparate data sources, and cumbersome spreadsheets that drain valuable engineering resources. Yet for service providers and digital enterprises alike, this type of analysis is critical for improving both cost and operational efficiencies.

Therefore, it came as no surprise that one of the most frequently requested enhancements from our customers was for Kentik to tackle this industry-wide challenge with network cost intelligence capabilities.

We began addressing this need with the launch of Connectivity Costs — a powerful workflow that allows users to input their bandwidth contracts and associated interfaces with edge providers to model monthly network spend across upstream connections. More recently, we added backbone cost support to the workflow, giving customers a centralized view of total spend and Cost per Mbps across edge and backbone providers, sites, markets, and more. 

Connectivity Costs has quickly become one of our most successful and widely-used workflows. It also provides incredibly valuable data — giving visibility into the cost structure of any traffic flowing through the interfaces it tracks.

Naturally, the next step (and one our customers were most eager for) was to take this workflow to the next level and develop the ability to quantify the cost of any slice of traffic on the network. And that’s where things got really interesting...

Flow–based Traffic Costs

The reason it’s so difficult for network teams to quickly assess the cost of traffic slices comes down to the complexity of how traffic is measured and billed:

• Traffic is priced monthly using p9x calculations based on 5-minute SNMP samples.
• Traffic often traverses multiple interfaces, and the only way to understand where it went is through flow data.
• However, flow data is sampled and not precise enough for billing, while SNMP provides accurate volume but only at the interface level—not by traffic slice.

In other words: SNMP tells you how much traffic went through an interface, and flow tells you what traffic went through—but neither on its own gives you cost clarity at a granular level. And it gets more complicated – each edge interface is tied to a provider contract with a specific price (e.g., $/Mbps); but, those interfaces carry traffic from many sources—multiple OTTs, ASNs, applications, and customers—all at once. At the same time, a single ASN’s traffic may span multiple interfaces, each with its own cost structure.

This fragmented view makes it nearly impossible to get accurate cost insights without heavy manual analysis. As a result, vital cost data stays buried—forcing network teams to rely on spreadsheets, approximations, and best guesses.

Kentik’s Traffic Costs solves this problem at scale. It automates the entire process, combining flow with the SNMP and contract data from Connectivity Costs, to give you precise, per-traffic-slice cost analysis in just a few clicks.

How to access and use Traffic Costs

Kentik Traffic Costs combines the cost structure and traffic volumes of each interface with your contextually enriched flow data – drawing a complete picture of how traffic moves in and out of your entire network, isolating those traffic slices with precision, and then calculating aggregate costs for those traffic slices to and from specific networks. 

All Kentik customer accounts now have access to Traffic Costs. Users will see a new page selection under our platform’s Edge menu for Traffic Costs: 

From the main Traffic Costs page, users have the option to generate cost estimates for a particular Source/Destination ASN, ASN Group, or AS Path, or Customer Port, either selecting an entry from the dropdown or entering one to search.

An estimate on a particular AS Group, for example, shows the aggregated cost of all the flow-sampled traffic, no matter where it enters or exits your network.

Below the sankey chart for each estimate, you can see costs broken down by each path contributing to the total traffic slice cost. You can easily see which device and interface the traffic flowed through, the associated cost group, connectivity type and provider, as well as the cost/mpbs for ingress and egress traffic volumes. Our model takes into account the billing direction for your traffic profile, only calculating costs for traffic in the direction of your billing. 

Monthly tracking with snapshots

Since flow data is resource intensive and only retained for a finite period of time after ingest, Kentik offers a “Snapshot” feature to save Traffic Cost views. At the top of every query/estimate result is the option to save as a snapshot, so users can retain important cost views for tracking and sharing.

Users can also set up automated monthly snapshots to retain a longer-term view of their costs, where it’s important to have insights over time. 

All saved snapshots are available near the bottom of the Traffic Costs landing page, broken out by traffic cost slice. Additionally, users can see their entire Monthly Snapshot History for all traffic slices on the Traffic Costs landing page, making it easy to quickly identify month-over-month trend lines for various traffic slices. 

Top Use Cases & Benefits

We believe the use cases for Traffic Costs are incredibly powerful. Here are a few that stand out:

• Identify high-cost paths: Instantly surface routes and interconnects driving the most spend – helping you to develop action plans to optimize traffic engineering and interconnect agreements to reduce costs over time.
• Optimize content delivery costs: Cloud, content, and CDN providers can measure the cost per Mbps to deliver traffic to a specific destination network, enabling data-backed decisions around content delivery strategies and cost optimization.
• Improve profit margins: Tier 2 IP transit providers and managed service providers (MSPs) can instantly calculate how much a downstream customer’s traffic is costing them in upstream costs, and compare it against that customer's revenue—supporting more profitable pricing strategies and stronger negotiating positions during renewals.
• Eliminate manual toil: Replace hours of spreadsheet wrangling and data stitching with automated traffic cost insights – freeing engineering teams to focus on higher-impact work. 
• Track cost trends over time: With monthly cost tracking, measure the financial impact of peering optimizations or routing changes – and share progress across teams. 
• Democratize cost insights: Make network cost data accessible across the business – from finance to sales to leadership – to enable more accurate transit pricing, better contract negotiations, and data-backed decision making. 

See Traffic Costs in action

Watch this short demo video to see a quick walkthrough of Traffic Costs: 

Watch Demo Video

And that’s just the beginning!

This first iteration of Traffic Costs provides traffic dimensional slicing by Source/Destination ASNs and Customer Ports, but there’s much more to come! Here’s what we’re working towards on the horizon: 

• More granular traffic slicing. Calculate costs by specific CDNs, OTT services and providers, geographic regions or markets, and even by groups of internal or external IPs.
• Dynamic “what-if” pricing analysis. Model cost scenarios on the fly—like estimating the impact of a $0.05/Mbps price drop from a transit provider on total spend toward a specific network.
• Proactive budget tracking and forecasting. Stay ahead of spend with current-year budget monitoring, alerting, and predictive forecasting to keep you aligned with financial targets.

What else would you like to see in our Traffic Costs workflow? Let us know your experience and thoughts – we’d love to hear your feedback! 

For more information about Traffic Costs, check out the Kentik Knowledge Base. If you have questions, would like to see a demo, or would like hands on help to better understand Traffic Costs in your environment, contact your Kentik account team.

Introducing expanded insights into Nokia devices with SNMP Ingest for SAP VPLS Interfaces.

This update significantly enhances Kentik's visibility into Nokia networks by adding krpoxy support for SNMP collection of utilization metrics from logical Service Access Point (SAP) and Service Distribution Point (SDP) VPLS interfaces on Nokia Layer 2 devices. Previously, accessing this critical data required navigating vendor-specific MIBs outside of the standard IF-MIB. Now, Kentik simplifies this process.

How it Works:

Kentik's kproxy server now automatically performs an snmpwalk of the necessary vendor-specific MIBs to gather interface index information and dynamically create corresponding interfaces within Kentik. This eliminates the need to build custom configurations and provides immediate access to performance data.

How to Access:

1. Navigate to Settings > Networking Devices in the Kentik portal.
2. Add your Nokia Layer 2 devices.
3. Once the devices are active, the new SAP/SDP interface dimensions will be available in the Data Explorer's dimensions selector. These new dimensions will only be visible for accounts with active Nokia Layer 2 devices.

Benefits:

• Improved Network Visibility: Gain deeper insights into the performance and utilization of Nokia VPLS services over time.
• Simplified Monitoring: Native dimensions eliminate the need to custom configurations
• Enhanced Troubleshooting and Analysis: Leverage granular data to quickly identify and resolve performance issues affecting Nokia-based VPLS services.

Understanding Nokia SAPs and SDPs:

To provide context, here's a brief overview of the key concepts involved:

• Service Access Point (SAP): A SAP represents the customer interface point for a service on a Nokia 7450 ESS or 7750 SR OS device, a local entity uniquely identified by Physical port, Encapsulation type, and Encapsulation identifier (ID)
• Service Distribution Point (SDP): An SDP acts as a logical connection, directing traffic between Nokia 7450 ESS/7750 SR devices via a unidirectional service tunnel. The SDP terminates on the remote router, which then forwards packets to the appropriate egress SAPs. A distributed service comprises at least one SAP on a local node, one SAP on a remote node, and an SDP binding the service to the service tunnel.

As you may or may not know, the CDN Analytics module in our Premier platform edition leverages a powerful and constantly evolving engine to detect all CDN IPs around the world and assign them to CDNs it knows about. The number of CDNs our engine is able to detect, as well as the precision with which it can identify their IPs inside or outside of your networks, keeps improving over time as it learns.

Two new CDNs covered by our CDN detection engine!

This time around, our engine has learned of two new CDNs: EdgeNext and Netskrt. EdgeNext is a commercial CDN with a strong focus and footprint in Asia. Netskrt is a software/appliance-based CDN that specializes in last-mile caching for broadband ISPs, often referred to as a "Cache Embedding CDN" - they are one of these new-gen CDN Providers in providing technology for last mile caching but also match-making Content Providers with Broadband Providers (Qwilt is another one of them)

As you can see in the CDN Analytics workflow UI, this takes our engine from an impressive 60 CDNs detected to 62!

The special treatment Embedded CDNs get in our workflow

Embedded CDNs are identified as such by our engine, which attempts to auto-detect IP ranges of such embedded caches on your network based on Interface Classification (Connectivity Type, and Provider attributes of your interfaces).

If your Interface Classification is configured thoroughly and sets interfaces to Connectivity Type = Embedded Cache with an Interface Provider = "netskrt" then our CDN engine will pick them up and automatically classify the IP Range they're on as CDN IPs, associated in this case to the Netskrt CDN Name.

If your embedded caches are on network devices that aren't exporting flow and SNMP data to Kentik, we also give you the opportunity to manually enter them and help make this engine smarter, via CDN Analytics > Configuration > Additional Embedded Caches.

Beyond these capabilities, one of the key aspects of embedding CDNs is how much offload they yield, i.e. how much upstream bandwidth they help you save – in other words, how efficient are they. For every new embedded CDN we add, we also add CDN Analytics landing page widgets to display this offload percentage.

This iteration is no exception – we've added both Qwilt and Netskrt widgets to your landing page. To enable/disable these widgets, go to CDN Analytics > Configuration > Landing Page and see for yourself which ones you want activated.

If, like Pokemon, you gotta catch 'em all, your CDN Analytics workflow landing page can look a little like this:

Take this feature for us spin and let us know if you like it !

When we launched CDN Analytics, the only CDNs that were offering ISPs to embed caches in their networks were limited: Netflix, Akamai, Facebook and Google.
Since then, numerous additional CDNs have released their programs to embed caches and our Service Provider customers have been asking for more of these indicators on the landing page.

With this update, we are adding a whole lot of new CDNs which we can compute offload for, and users can now determine which one they want displayed on the landing page for CDN Analytics.

Embedded CDNs 'A La Carte'

How do we compute offload ?
For the reference, Offload for an embedding CDN is the measurement of how efficient they are at serving content from the last mile out of embedded cache vs how much content they pull from outside of the user's network - which is less cost and performance effective.
A high ratio means a better outcome for the embedding ISP, but is tightly linked to the nature of the CDN: pure-play CDNs only have to store their own content in the ISP's last mile, while Commercial CDNs store content of multiple Content Providers competing for popularity, meaning lower ratios are in this case expected.
The formula we use to compute offload is to look at peak time for each CDN, and compute the ratio of {"Mbps from Embeds to Subscribers" / "Mbps from OnNet + OffNet to Subscribers"}

A new tab appears in the [Configuration] panel for the CDN Analytics screen that surfaces all the Embedding CDNs

• that we detected (via interface classification)
• that our users manually declared (via this same config screen)

and we’re allowing users to selectively enable them on the landing page, see for yourself:

...with a CDN Analytics landing page that now looks like this

Embedding Cache Analytics Guided Mode Dashboard

On each vignette for each Embedding CDN, we’ve added a link to a newly created preset dashboard that presents, as a guided mode dashboard, an in-depth analysis of how the CDN functions in terms of:

• cache fill (internal and external)
• cache offload (on-net and off-net)

This new dashboard replaces the existing one in our Presets section and it's now really comprehensive for users to understand how each embedding CDN behaves when it comes to long-tail and cache-filling, as you can see on the screen grab below:

If you remember back in May 2023, we released our initial version of a PeeringDB integration - more details here: https://new.kentik.com/we-now-integrate-peeringdb-data-akabK

The theory

PeeringDB contains a directory of most of the registered Internet Exchanges (IXes), as show in an extract below.
 For each one of them, their data contains the IP Ranges, v4 and v6.

 For each interface that we poll on your devices using SNMP or Streaming Telemetry, we get information such as the IP Addresses configured. Using the aforementioned IX IP Range data, we are then theoretically able to match any interface to an Internet Exchange from Peering DB based on its IP Address.

What does it look like in the product ?

We've added a somewhat magic rule, which we have decided to call a Kentik-managed Rule in our Interface Classification UI. This rule is a bit special compared to the other ones in the stack:

• It cannot be edited by users
• It can only be enabled/disabled by users
• It sits on top of the rules stack, which means that it will always be evaluated first to bypass any user defined rule (because for each interface, the algorithm exits on first match)
• This rule checks the IP Addresses, and looks the IP address up in all the IP Ranges from all the IXes in PeeringDB, if a match is found
  • it sets the interface to Connectivity Type = IX
  • it sets the interface to Network Boundary = External
  • it sets the Interface Provider to the name of the IX from PeeringDB
  • it establishes the mapping between this IX and the PeeringDB Exchange in the PeeringDB integration configuration so you don't have to

Here's an example of what Interface Classification Test UI for this rule will look like in case of matches

Existing Customers vs New Customers

Obviously a lot of you may already have their interfaces well classified, and most likely you used dynamic regex matching on their descriptions to get your IX classifications going.
As we didn't want to disrupt your existing setup, we have adopted what we think are reasonable defaults to roll the feature out:

• Existing customers will have the PeeringDB rule disabled by default
  -> up to them to enable it if they would like
• New customers will always have the PeeringDB rule enabled by default

But wait, there's more...

As an additional freebie, we've modified the Interface Provider field for any custom rule that sets an interface as IX: you can now choose to keep your own provider naming, or can select the actual PeeringDB name for the internet exchange - in this case the field will offer a typeahead that directly looks up values from the PeeringDB exchange names, as showcased below.

There are still a lot of features that we plan on implementing relying on the PeeringDB dataset, so watch this space, and don't hesitate to give us feedback !

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: