Interface Classification is one of the key components of Kentik Portal. It makes interface-based enrichments possible. 

• Network Boundary gives users an easy way to limit queries to traffic entering or exiting the network without the risk of double-counting.
• Connectivity Type adds both technical and business context to traffic moving into or out of these interfaces, making it easier to identify, for example, which interfaces are used for peering or transit at the network's edge.
• Provider (or Customer) automatically enriches any traffic on these interfaces with the name of the connected customer.

As Interface Classification is a load-bearing feature used throughout many of the portal workflows, including our AI Advisor (which relies on it to understand the tasks an interface performs), we have always kept the list of available values for Connectivity Types locked in.

Today we're adding three more values to Connectivity Types that our users have requested over the past years.

Management

Management Interfaces are quite self-explanatory. This Connectivity Type describes the port on a device that is connected to the Management network, which is the common network used to administer devices. It comes with the default Connectivity Type of “Internal” but can be set to “External” in the case of externally based OOB monitoring.

DDoS Mitigation: Cloud or Appliance

DDoS Mitigation Cloud or Appliance Connectivity Types are intended to classify interfaces that sit in front of a DDoS mitigation platform, whether it is an appliance-based internal solution (A10, Radware, Corero, etc.) or an external scrubbing DDoS Mitigation Cloud provider.

In one case, the default Network Boundary will be “Internal,” and in the latter, it will be “External.” The DDoS Mitigation: Cloud Connectivity Type pairs well with the Provider/Customer Interface Classification attribute, and users can programmatically set it using capture groups if a consistent Interface Description policy permits them to do so.

What's next ?

As we mentioned earlier, Interface Classification is tightly controlled, as it needs to provide consistent behavior across all areas of the Kentik Portal where it is utilized. This doesn't mean we are not open to suggestions from you regarding any additional required values, especially for Connectivity Types, that help better describe the taxonomy of your network.

Do let us know if you would like us to add more of these in the future.

In May 2025, we introduced a major update to Kentik Portal's search capabilities. Since it was well received by our users, we queued an iteration to make it even more useful to you. Back then, we had added: Favorites, Most Recent Dashboards and Saved Views, and categorized lists of result matching common Portal objects such as ASNs, Devices, Interfaces....

With the recent launch of Kentik AI Advisor, we’ve started weaving AI more deeply into the Kentik experience. This new release continues that journey—this time by bringing AI into how you move around Kentik.

We're excited to introduce Navigation to Search, infused with awesome Kentik AI Superpowers!

What is Navigation Search ?

Kentik Portal delivers broad set of screens and functionalities, more than the average Kentik user can memorize - while our Navigation menu has served us well all these years to present these in an orderly fashion to our users, a few elements have come into play:

• Users have gotten accustomed to functionalities provided by the Apps they use every day: amongst others, apps like "Spotlight" on MacOS, but also a large amount of SaaS apps have made it easier for users to navigate to functionalities or applications using a central search component
  
• AI has become the new popular kid in town, and users are now expecting to be able to prompt their way into navigating towards functionalities
• Portal functionalities have moved from one section of the portal to another section, with our users sometimes struggling to follow recent changes
• A lot of new customers have joined Kentik that aren't yet fully familiar with its broad array of screens and functionalities

This is where Search comes to the rescue: starting today, you can now leverage our newly updated Search feature to navigate to portal screens: whether this makes navigation faster for the Keyboard, or helps you orient yourself towards a screen/feature which name you don't fully remember, just enter what you are looking for and Search will fetch it for you and report it in the new Navigation section of the results, as shown below.

Additional cheat-code: this whole operation can be entirely piloted via keyboard shortcuts

1. CMD + / (MacOS) or CTRL + / (Windows or Linux) will spawn the search box
2. ↑ and ↓ keys will allow you to navigate the search results - while ← and → will let you switch between Favorites, Recents and Search Results tabs.
3. Enter will navigate to the selected result
4. Esc once will clear the search field, while Esc twice, will both clear the search field and leave the Search context

Great, but where's the AI in there?

Having heard this from more than one prospect or customer in the past, we have become increasingly aware that Kentik Portal packs more features than we're able to teach you in the course of a trial period. It's therefore not uncommon that our customers have a feature they've been toured that they want to use and simply can't find it anymore past the trial period in our dense feature set. 

Here's an example:

Your Kentik Solutions Engineer toured you around the "Connectivity Costs" feature, which allows you to enter your IP Transit Contracts and track your Transit costs in Kentik Portal.
Only you can't remember what the name of the workflow, you just remember that there was a very neat feature demo'd to you that allowed you to track these.

AI-Powered Navigation search to the rescue!

Another example: 

You remember being told that you needed to further classify your Interfaces in Kentik in order to get more accurate Data Explorer query results, but you just can't remember how the function is called and where to access it

Again, AI-Powered Navigation Search to the rescue!
Even better, we are showing the main Knowledge Base article for this feature as part of the Search Result displayed !

What about the Security aspects?

• Search will not return results that a user does not have access to (based on RBAC and UserLevel configuration)
• Each search action kicks multiple search jobs in parallel and appends results as they come back to the browser:
  • new: A basic search process against a dictionary of all Screens and their Title and Descriptions.
    👍 This process does not leverage AI and doesn't go through Prompting, it will yield results regardless to your company's enablement settings for AI
  • new: An AI search based on the same Site Map. For this process our Site Map contains a sample description paragraph for all the screens in Kentik Portal provided as additional context to the prompt
    🧠 This process is AI-powered, it is only enabled if your AI is enabled with your company.
  • the legacy database search against Object Instances such as Dashboards, Saved Views, ASNs, IPs, Sites, Devices ...
    👍 This process doesn't leverage AI and doesn't go through Prompting, it will yield results regardless to your company's enablement settings for AI

We're thrilled to announce a major granularity enhancement to Role-Based Access Control (RBAC) in Kentik. Gone are the days of broad, level-based access for Kentik Alerting and Protect. Build custom roles to define exactly who can create, view, update, or delete your critical alert policies, notification channels, and DDoS mitigations.

What's New?

We've rolled out a comprehensive set of permissions and custom roles specifically for Alerting and Protect. This update moves these modules into our modern RBAC framework, replacing the legacy user-level system for these features. 

You can now create custom roles with specific permissions for:

• Alerts: Control who can read, acknowledge, or clear alerts. 
• Alerting Policies: Manage permissions for creating, reading, updating, and deleting policies. 
• Notification Channels: Define who can create, read, and update notification channels. 
• DDoS Mitigation: Assign precise control over who can create, view, start, stop, and delete mitigations. 
• BGP Announcements: Manage who has the ability to view or withdraw BGP announcements. 

Why It Matters

This is a huge step forward for security and operational efficiency. By creating custom roles, you can ensure your team members have exactly the access they need to do their jobs.

• Enforce Least Privilege: Grant NOC operators the ability to acknowledge alerts without letting them change policies.
• Delegate with Confidence: Allow your network security team to manage mitigations without giving them full administrator access to your entire Kentik account.
• Streamline Workflows: Create roles like "Mitigation Authors" or "Alerting Policy Viewers" to match your team's specific responsibilities. 

Take control of your user permissions today!

Ready to fine-tune your team's access? Administrators can head over to the Manage RBAC Roles page in your Organization Settings. From there, you can click "+ Create a Role" to start building your own custom roles with these powerful new permissions! 

Your existing permissions within Alerting and Protect were all migrated to this new RBAC schema and existing role access will be unaffected by this update.

We're excited to see how you use these new controls to secure and streamline your network operations. As always, let us know if you have any feedback!

We're excited to announce a major enhancement to Kentik's Traffic Costs feature, giving you even deeper insights into where and how your network spend is occurring. Two months ago we released Traffic Costs, an industry-first automated workflow enabling customers to instantly calculate how much various slices of network traffic were contributing to connectivity costs. https://new.kentik.com/unveiling-hidden-network-costs-introducing-traffic-costs-1yRCxi

And now with this exciting enhancement, you can analyze traffic costs across multiple new, powerful dimensions. The original Source/Destination ASN, AS Group, and AS Path as well as the Customer Port traffic slices are still available, and now you can analyze network spend based on:

• CDN Provider: Understand costs by content delivery network to manage efficiency and performance, and negotiate better rates.
• OTT Service, Provider, and Category: Get granular visibility into costs by Over-the-Top (OTT) traffic, including specific services and content categories.
• Geographic Areas:  Break down costs by country, region, and city to identify cost drivers by location.
• IP/CIDR Blocks:  Attribute costs directly to specific IP addresses or CIDR ranges for precise accounting and planning.

You’ll see all the new dimensions listed under Create a New Estimate on the Traffic Costs page.

For example, in this screenshot we can easily calculate and see how much it’s costing my network to receive traffic from Netflix every month and deliver to my subscribers. 

And in this example, we’re looking at how much it’s costing my network to send traffic to Akamai each month. 

These new traffic slices provide the actionable intelligence you need to optimize network spend across the business, improve traffic engineering, and strengthen cost accountability.  Log in to the Kentik portal to explore the new capabilities today!

In this post, we'll be covering a feature that was delivered a while back but had the gem of a long-term project hidden in it – and now is the time to talk about it. I'm talking about our (now not so) recently released Kentik NMS product – let's get back to this in a short moment.

Over the years, Kentik has built a number of Agent binaries – each one to carry out a specific function as a Telemetry Agent for its own type of telemetry.

• kproxy lets you proxy flows from inside of your network to our public flow ingest cluster
• kprobe is used as a DNS tap to provide the magic mapping between DNS and Flow records to unlock OTT observability
• kbgp is a local BGP hub, which prolongs your BGP sessions towards our BGP ingest enrichment cluster
• ksynth is the Synthetic Monitoring agent you run (privately) or we run (publicly), which performs Synthetic Tests

You'll notice the one missing here is our SNMP poller: you now see it as what we call a "Capability" of the Universal Agent we released when we unveiled Kentik NMS.

In a nutshell, you install Universal Agent, enable the NMS capability on it and you're off to the races. Hang in there, this is what this post is all about!

Operability challenges of Telemetry Agents

Managing large fleets of telemetry agents always comes with operational complexities – let's lay out a few observations we've made over the years in that field. In everything that follows, "operability" is a key term.

Observable agents

As your Telemetry comes to rely on these agents, they quickly become a critical part of your infrastructure, and therefore now require to be observable – some examples here:

• If a Flow Proxy (currently named kproxy) becomes faulty, users need to be alerted. If they don't, they will assume the trough in their traffic charts is due to a network outage and waste valuable time troubleshooting the situation.
• The team in charge of running your telemetry systems is often a different team than the one building and running the network – while they may not be daily Kentik users, they need to monitor them in a scalable way and reduce the amount of integration work needed to operationalize them. 
• Agents running on a host (virtual or physical) can go wrong for multiple reasons: maybe the host itself is not doing well (i.e. it's not the Agent's fault), maybe the function the Agent performs is not doing well, but the host is doing just fine. In other words, users want self-serviceability when it comes to determining why agents are not doing their job.

Frictionless upgrade path

When running large infrastructure, the last thing engineers want to do is have to upgrade a large fleet of Agents: "if it ain't broke, don't fix it" is usually the governing principle. Operational realities require the upgrade path to be the most frictionless possible:

• Bug fixes can require upgrading a large fleet of agents – the task of upgrading a large fleet of agents therefore needs to be as frictionless as possible to maintain constant state of operation.
• Availability of new features requiring Telemetry Agent upgrades tend to be delayed in favor of the aforementioned conservative approach.
• Security updates to large Telemetry Agent fleets can get delayed because of upgrades deployment complexity – these are always critical, should always be seamless enough to not incur delays.

Agent proliferation vs. One-size fits all

With the rise of observability, agent proliferation in your infrastructure has been skyrocketing. Each new agent comes with its own upgrade track, bugs, security context... in other words, the operational complexity of one's telemetry setup increases exponentially with the number of agents required to operate one's infrastructure. All telemetry agents share common goals, requirements, and functions: they need to be deployed, monitored, and updated.

The first way that comes to mind to deliver these common functions is to collapse all agents into a single swiss army knife agent: the operational ease of this solution is appealing, but comes with a few significant drawbacks:

• All functions carried by the agent require eventual updates, and having many functions served by a single agent usually results in increasing the frequency at which these need to be updated – depending on the number of functions collapsed together, this often results in a significant increase of update pace, therefore operational tax.
• Each function performed by the agent comes with its own bugs and security weaknesses – collapsing multiple agents in one often result in increasing the bug and security risk per agent.

For the reasons above, the ideal setup is one where we can reap the benefits of both a single agent, while keeping multiple ones at the same time. Let's discuss our new approach to agentry in the next section!

Introducing Universal Agent

What is Universal Agent ?

"One Ring Agent to rule them all, One Ring Agent to find them, One Ring Agent to bring them all, and in the darkness Kentik Platform bind them"

With the aforementioned challenges in mind, our engineering team produced a modular design centered around a new deployable binary, named Universal Agent.

Universal Agent acts as a host governor module (literary pun intended), tasked with offering a common foundation to "capabilities" running under it: it acts as the sole controller towards our SaaS platform, handles the download and enablement of other agents (now named "capabilities"), handles under-the-hood update cadences for both itself and its governed capabilities, and collects/ships not only host-level metrics, but also specific metrics for each capabilities to the Kentik SaaS platform.

What benefits does Universal Agent offer ?

Operational peace of mind
Universal Agent is now the central piece of Kentik's Telemetry Agent strategy. Its setup process is trivial and its enrollment entirely driven by the Kentik Portal UI our users all know and love.

Furthermore, Universal Agent updates are transparently and gracefully managed "under the hood", and the same goes for any Capability run by the agent – little if no operator intervention is now needed to keep an Agent and its Capabilities up to date.

Central management & monitoring
The Settings > Universal Agents now becomes the central place where you will in turn manage your complete Kentik telemetry agent ecosystem. This interface lets you identify any agent or capability deployed on your network and its current running state.

Agent Observability
Each deployed Universal Agent reports host-level metrics, accessible directly from the Settings > Universal Agent screen

As a bonus, all agent host-level metrics are also available in Metrics Explorer under the /kentik/agent measurement tree without any extra work needed. Universal Agents have now become observable, with their vitals now available for dashboarding like any other NMS device.

One single binary to access all of our telemetry collection capabilities
Once it is deployed, Universal Agent gives instant access to all the telemetry functions we've ported over as "capabilities". These get installed and enabled upon simple click. While NMS was the initial capability we shipped Universal Agent with, our entire ecosystem of telemetry agents will follow over time and be integrated as a Capability.

Observability for each Agent Capability
Each enabled Capability comes with its own set of metrics, designed to describe its function. These metrics also get shipped for free to our NMS subsystem and displayed at Agent > Capability level in the Universal Agent Management UI. Again, as these metrics are being stored in our Metrics subsystem, they can be accessed via Metrics Explorer, but also alerted upon.

What's next ?

With this foundation built, we have already started producing new Capabilities leveraging this new model:

• Our newly released Syslog Server is one of these new capabilities
• As part of the same release, we also released a Trap Receiver capability

We've already started porting over our existing Agents to this new "Capability" model – watch this space for more announcements in that field real soon!

Lastly, we will be leveraging our brand new NMS Alerting platform in the very near future to provide automated alerts on Agents and Capabilities Health.

In many areas of the Kentik Portal, users can bundle-select multiple objects to apply common configuration to them. This is a common requirement as soon as your infrastructure reaches a size where you want to manage Cattle over Pets. 

A lot of functionality in Kentik Portal can be performed in batches:

• Bulk actions on Devices (labeling, plan assignment, archive/deletion, Site assignment, NMS Monitoring Template assignment...)
• Bulk actions on Interfaces (Assign Connectivity Type, Network Boundary, Provider/Customer, IX the interface is assigned to...)
• Bulk actions on Sites (Assigning Site Market, Site Type, corresponding PeeringDB Facility...)
• Bulk actions on Synthetic Agents and Synthetic tests (Labeling...)
• and many more areas in Kentik Portal

As we continue to strive to improve the ease of use and operability of our product for users with large herds of infrastructure, we've rolled out a completely new Bulk Edit UX in a limited scope of Kentik Portal to test the better UX with our users. Read on.

A pilot for the Device Screens

As of today, this new Bulk Edit UX is visible in two areas of the product:

• the Device Management screen /v4/infrastructure/devices
• the Device Details > Interfaces tab /v4/infrastructure/devices//interfaces

This new UX wiill appear at the bottom of the devices list as soon as you select two or more devices, for example:

...and will let you modify a certain number of the attributes for this device – more actions will be added to this bulk edit menu as we start hearing feedback from our users.

• Note how the left side of this also allows you to de-select these devices you've selected
• Whenever possible, the individual attribute change will display a search field to immediately find what to set the attribute to
• In the case of labels, where multiple selected devices may not have the same labels, a blue check will be displayed when all selected devices have this label on, whereas a [-] sign will show when only some of the devices have this label on, see below:
  

here all the selected devices have the "Arista" label

Whereas here only some selected devices have the Arista label on

This UX will also display in the Device Details page, as soon as more than one interface is selected:

What comes next

Depending on your feedback with this new UI, we will improve it as we go, but more importantly extend it to all other screens that currently contain bulk edit options in the legacy way we've done it. 

One of the key benefits of leveraging web components in our front-end stack is the ability to drastically reduce the time needed to port this new design over to other parts of the product!

This feature is a small one, but one that has been requested by a deceptively high amount of our users! A lot of screens in Kentik portal let the user scroll through a list of "Objects", and these list views are usually filterable by a variety of attributes that depend on the nature of the object: Interfaces, Devices, Sites, Synthetic Tests, Synthetic Agents... Users have asked us to make it quicker for them to select these objects using combination of labels. Read on !

About a year ago, we released an updated version of our new Role Based Access Control system that leveraged Labels in order to make management of permissions on labels a much more efficient task, where users were now able to apply permissions on collections of Objects (aka Dashboards, Saved Views, Synthetic Monitoring Agents, Synthetic Monitoring Tests, Devices, Credentials ...).
This made Labels in Kentik more valuable, useful, and central to the entire product.

One of the requests that kept coming back to us from our users was the ability for the user in these list-type screens to be able to better filter on either Intersection or Union of labels.
A simple way to look at it, a very common need that surfaced when we released the unified Traffic and NMS Device screens was, for instance: 

Show me all my Routers that both have CDN Caches connected to them AND are used to connect transit providers

A common way for our users to add this metadata to devices would be to leverage the flexibility of Labels – and our new UI allows them to narrow down the list of devices from the Device Management Screen using a logical AND expression in the filter as shown below.

Notice how the top-right of the Label input filter now contains an AND/OR selector ? 
This is how you do it: AND will Intersect all labels in the field, while OR will display the union of objects with the labels in the field.

Going back to our example, this is what it would look like in the Device Management screen:

Another pretty common ask was, for example:

Show me all the Synthetic Tests configured to be used in Production AND built to monitor Kentik Portal

...and in this case, users would also use a set of labels to describe which tests are used by the Production Team, and which tests are focused around monitoring Kentik Portal. Notice how we drink our own champagne in the screenshot below 😉

The Library module in Kentik Portal got a special treatment: remember how Kentik offers a lot of Preset Dashboards and Saved views ? (by the way, always peruse our library, a lot of the presets here have been built for our own needs, chances are every time you want to create a Dashboard or a Saved View, one of our Network Nerds over at Kentik has already produced something similar for you to use or steal inspiration from)

In this special case, the Library Label Filtering capability allows users to expand and contract two categories of labels: Kentik Presets and Your Own Company Labels, as displayed in the example below.

Hope you find this feature useful!

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.

As you've read in previous updates, we are progressively extending our RBAC capabilities towards an increasing number of Kentik Portal functionalities. This time around, we've added RBAC to Devices.
Read on as we explain how this works!

Previously on RBAC...

1. In November 2023, we released our initial RBAC capabilities, you can read about it here: https://new.kentik.com/role-based-access-control-is-live-3R1D68. The initial release covered RBAC management, Connectivity Costs, Synthetic Monitoring Agents and Synthetic Monitoring tests.
2. In March 2024, we both overhauled the admin UI for RBAC, and Label-based RBAC, extending its capabilities to dashboards and saved views based on Labels: https://new.kentik.com/label-based-rbac-and-more-2GBruo, so users could manage content in a centralized and more straightforward way. 
3. In May 2024, we extended RBAC capabilities to our Credentials Vault: https://new.kentik.com/rbac-extends-to-credentials-vault-1Yrrwc.
4. In November 2024, we linked SSO and RBAC. We introduced Role-Sets and SSO to RBAC attribute mapping, so that user groups read from your SSO Identity Provider could dictate and enforce RBAC permissions for groups of users.
   https://new.kentik.com/sso-to-rbac-attribute-mapping-30lFi8.

As we've said before, the entire migration of our legacy UserLevel model (Member, Admin, SuperAdmin) into RBAC is going to take some time, but we're constantly adding to its coverage.

What does RBAC for Devices look like ?

In your RBAC Role creation UI, you can now see this additional area of permissions, allowing you to enable permissions throughout the portal related to Devices exporting telemetry to Kentik.

With the unification of NMS and Flow management screens released in February 2025, these Device-level permissions apply to both NMS and Flow devices, see the announcement here: https://new.kentik.com/nms-flow-unified-device-experience-makes-them-better-together-2xzqg.

When configuring RBAC permissions around devices, the View, Update, and Delete permissions can be scoped to specific labels. For instance, if a certain team should only have View access to edge and core devices, your permission set should look like this:

Effectively, this means that users assigned to this role — assuming no other assigned role grants broader access (since we union permissions across all roles) — will only be able to see devices with the edge and core labels,  which, among other things, imply:

• Any Dashboard or Saved view they will access will only include data from devices with these two labels, even if the dashboard or saved view initially contains All Devices
• When on the unified Device Management screen, these users will only see core and edge devices listed, even if there are more of them
• Users will only be able to see the interfaces in the Settings > Interfaces screen corresponding to the devices that they have permissions to view (therefore the same Interface screen will contain more interfaces for device-unrestricted users than one with restrictions)
• For any Network Explorer view that contains device breakdowns, those of a user with device restrictions will only include data from those devices (therefore the same screen will look different from that of a user with permissions to all devices)
• Any Device API call will be bound to the same permissions as that of the user whose API token is issued to make the API call: in other words, API and Portal permissions for devices are the same for a given user
• The Capacity Planning workflow will exclusively use the permissions of a given user to display capacity: if a capacity group contains interfaces from devices a user isn't allowed to see, they won't be displayed in the Capacity Group details (again the same screen will look different depending on the Device Permissions of the user)

As an exception, Connectivity Costs is unaffected by Device RBAC for now. Users will be able to see all connectivity costs, including for interfaces that belong to devices they are not permitted to view. If they click on these interfaces, then they will be blocked from accessing further details for that device.

How do UserLevels map to Device RBAC permissions?

Prior to Device RBAC rollout, device permissions where somewhat rudimentary:

• Member users could only View devices
• Admin users could View, Create, Update, Delete devices
• SuperAdmin users had the same permissions as Admins

For the sake of backwards compatibility, the Member, Admin and SuperAdmin Kentik-Managed Roles have been updated accordingly

Admin, SuperAdmin Kentik-Managed Role

Member Kentik-Managed Role

When a more fine-grain approach is needed, Kentik-Managed Roles can be removed from users and replaced with more elaborate ones. For now, Kentik-Managed Roles are intended to provide continuity between UserLevels and RBAC.

Please note:

A user with Device Create permissions can create a device with any label they want. If they only have Device View access to a restricted set of device labels, this means that not assigning a label at device creation time, or assigning one they can't View devices for, will prevent them from being able to see the device.
We will be remedying this in a short term update where any Create permission will be able to come with a default set of allowed labels, together with making labels mandatory (showing only the ones a user has access to) at Device Creation time.

What's next ?

Based on your feedback, our next RBAC extensions will be:

• "Add" type permissions to be label-compatible:
  • Configure which labels a user is allowed to attribute to a device at creation time
  • Make label assignment mandatory for users with Label-based permissions to avoid cases where users create devices they can't eventually access because of label-restricted permissions.
• MyKentik Portal RBAC: leverage labels to determine which user has create/edit/delete access to which Tenants

If there are different areas of Kentik Portal that you'd like to see rolled-up into our RBAC capabilities, please let us know !

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.