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.

Connectivity Costs is one of our most successful workflows and it's always difficult to pick from the numerous feature requests open for it. This time around, we're adding Backbone Costs to the workflow, as it was one of the most demanded extensions. We took a bit longer than initially planned, because we had to completely modify the data model between providers and cost groups, and then migrate it. But, now it's here! Read on for the details. 

Workflow Terminology

In the entire workflow, we are going to refer to two types of costs: Edge Costs vs Backbone Costs. In our product terminology:

• Edge Costs: represent costs for interfaces facing the outside of your network – they are associated with Transit, IX, Peering, Direct Connects, etc....
• Backbone Costs: this is the new type of costs that this update workflow brings

The Edge Costs family represents costs at the edge of the network, i.e. to interconnect it to the rest of the internet. These are usually metered based on a price per consumed Mbps, with variations on the computation method and some amount of committed monthly bandwidth. Industry best practices require practitioners to evaluate these with a common measurement: Price/Mbps. This is what the initial releases of this workflow focused on.

Today, we're introducing Backbone Costs: This new family of costs represents portions of networks, most of the time points-to-points used to extend the network by renting physical infrastructure to a provider. Examples of these can be: Ethernet WDM Wavelengths, Dark Fiber Rent, Dark Fiber IRUs... Those links are rarely metered, usually have a fixed monthly rend, and practitioners do not want their costs computed as part of the Edge Cost/Mbps. Some of the reasons these links are traditionally excluded from Cost/Mbps computation are:

1. they very rarely come with a Committed Rate constraint
2. they don't depict interconnection costs, which Edge Costs do 

For the reasons above, we made the choice of treating these differently in the Connectivity Costs UX.

Changing the data-model to unlock new features

In the previous iteration of the workflow, the Connectivity Type attribute (Transit, IX, Free Peering, Paid Peering...) was an attribute of the Provider object – and it created multiple issues requiring this change.

This meant you could only have one Connectivity Type per Provider, which doesn't model reality: one may purchase both Transit and Point-to-Point backbone links from the same provider.

We wanted our users to be able to see costs for a given provider as a breakdown of "Edge Costs" and "Backbone Costs", but also at a global level, where we heard from our customers that they wanted to compute the budget for Edge Costs and Backbone Costs separately.

We went ahead and rebuilt the data-model behind the workflow, and while in Rome, we added a few Cost Group Attributes that our users had been asking for, and migrated our entire customers data set behind the scenes, as well as the computations that use it.

You'll notice that the Connectivity Type attribute is now part of the Cost Group object, and you'll also notice that we've added useful attributes such as Circuit ID (particularly useful for point-to-points) as well as Contract ID to back-reference the vendor contract in the object.

How are Backbone Cost Groups different ?

As mentioned earlier, Backbone Costs aren't pulled into monthly Cost/Mbps computations; therefore, we had to split every screen between Edge Costs and Backbone Costs, which you will notice on numerous screens:

Both the Connectivity Costs landing page and Providers pages now show a split of both – you'll notice the split on the top header strip.

On the Providers landing screen cost chart, you'll be able to look at cost either by provider (without Edge vs. Backbone split) or by "Edge vs Backbone" where you can now see the split evolving every month.

Additionally, the summary tables on both the Provider landing screen and on Provider details screen are now split in two: an Edge Costs table, and a Backbone Costs table.

The screenshot below shows these two tables in the case no Edge Costs are registered, for compactness.

Changes in the Provider Configuration screen

As we tested the feature with a sample set of customers, we realized the average number of Edge Cost Groups (aka transit contracts or such) could be dwarfed by the number of point-to-point links. Because of this, we had to re-think the Provider Configuration summary screen and make it more scalable. This included some changes such as increasing the density of cards displayed on that screen, adding search, and filtering screens – see for yourself below.

What does the future hold?

There's a lot more changes sprinkled throughout the workflow that aren't discussed in this article and we'd love to hear your thoughts and feedback after you've taken it for a spin, so let us know what you think.

There's more in our back pocket around costs that'll be released in the months to come, so stay tuned, because it's going to get really exciting real soon!!!

Feature Overview

Together at last! We've made major improvements to how devices are viewed and managed on the Kentik platform by unifying multiple device management, performance detail, and traffic analysis pages into a unified devices experience. We've combined our three different "Device Listing/Admin" pages and two different "Device Details" pages, bringing forward the best of each.

Happy Valentines Day, from Kentik!

Unified Device Administration

These three previously separate sections of the platform have been combined into one:

• Settings > Network Devices: where previously we managed "flow source" devices
• NMS > Devices: were previously we managed "NMS" device performance
• Network Explorer > Devices: where we showed aggregate traffic from multiple devices

Unified Device Details

We also combined and refined these two previously separate Device Details pages into one:

• NMS > Devices > (device_name): which provided performance information
• Network Explorer > Devices > (device_name): which provided for traffic analysis

Main Benefits

This is the initial step in a broad reaching project to make our NMS and Flow experiences more cohesive with a focus on the reality that there aren't "Flow devices" and "NMS devices", there are simply "devices we collect data from."

The most obvious key benefits are:

• One single, centralized, collection-protocol-agnostic place to administer all devices, providing a more seamless experience when investigating network traffic and/or device performance
• One single search capability: instead of NMS Devices and Networking Devices, universal search capability now returns only one single result, better aligning with reality
• For each device, we also now display all data in a single tabular place

Key Workflows

The changes in this new set of features center around three workflows: navigation, administration, details.

Navigation Changes

As part of this unification, we’ve re-wired multiple navigation links:

• Top Talkers > Devices → now leads to /infrastructure/devices where it used to lead to /core/quick-views/devices/
• Settings > Devices → now also leads to /infrastructure/devices
• NMS > Devices  → now leads to /infrastructure/devices
• Any Metrics Explorer or Data Explorer device link now leads to /infrastructure/devices/

These endpoints are not changing for now:

• /settings/interfaces still exists, while /infrastructure/devices//interfaces now offers an improved (more filtering, more powerful), list of interfaces narrowed down to the
• /nms/interfaces for now remains as a single, global interfaces screen for all NMS devices, while /infrastructure/devices//interfaces now offers an improved (more filtering, more powerful), list of interfaces narrowed down to the

Unified Device Administration

This screen becomes the singular place where users browse their inventory and add/remove devices from their Kentik experience. It presents the following characteristics:

• Two main tabs: “Traffic” and “Manage”

  • Traffic corresponds to our well known Network Explorer /core/quick-views/devices traffic related, top-talker screen
  • Manage corresponds to the merged and improved /nms/devices  and /settings/devices screens
• Three distinct “View Modes”, each corresponding to a column arrangement within the main Manage tab:
  • Monitor is a default column-set focused around performance monitoring
  • Admin is a default column-set focused around Kentik administration
  • Custom lets the user select and organize the specific columns they want 
• More powerful filtering and grouping options

Unified Device Details

• Overview - performance and vitality summary of the device
• Interfaces - filterable, searchable, data-rich list of all interfaces on the device 
• Connections - filterable, searchable, data-rich list of LLDP/manual topology connections
• Traffic - enriched traffic flow and "top talker" information for the device
• Hardware - vitality information from device components, such as fans and power supplies 
• BGP Neighbors - peer AS names, session states, local and remote IPs, and summary info
• Telemetry - New! This tab highlights data collection methods and if they're working or not

Feature Requests & Bugs

This is a new feature and we're actively seeking your feedback and ideas to make it better. Reach out through your customer success rep or directly to the Kentik NMS Product Manager (Jason Carrier, jcarrier@kentik.com) if you'd like to influence the future development of this feature.

As part of our constant efforts to secure Kentik Portal, we are updating our SSO capabilities to more recent and secure server-side code. 
Evolving SAML2 standards now require Identity Provider users to configure their Identity Provider’s Public Signing key (x.509) for each Service Provider SAML2 app they govern. 

⚠️ This security upgrade of our SSO/SAML 2.0 Backend requires us to make IdP Public Signing Keys (x.509 certificates) mandatory for our SSO Users.
On March 31st, Kentik accounts without this configuration will be able to SSO into Kentik Portal: "SSO Enabled" Accounts will still be able to login via user/password, while "SSO Required" accounts will not be able to access Kentik Portal at all (save for their SuperAdmin users).

All accounts with SSO configured and an IDP Signing key configured will be migrated transparently between now and March 31st.

Read on for the instructions if you are using SSO with Kentik.

How do I know if my company needs to update my SSO configuration ?

The first thing you need to know is that SSO Configuration in Kentik Portal can only be modified by users with a SuperAdmin user-level - traditionally, the first user to open a Kentik account for your company will be the SuperAdmin and the only one able to create other SuperAdmins moving forward. 

SuperAdmins is the only class of users who can login with User/Password credentials even when SSO is "Required": the reason for this special privilege is that at least one person in the company (ideally not too many) need to be able to disable SSO in case of a major Identity Provider failure that would prevent your users to login to Kentik.

If you are a SuperAdmin, the SSO config screen will be located at 

• https://portal.kentik.com/v4/settings/authentication/sso-settings if your account is on our US SaaS Cluster
• https://portal.kentik.eu/v4/settings/authentication/sso-settings if your account is on our EU SaaS Cluster

Or you can just look for the SSO Settings tab in the screen "Authentication & SSO"

On this screen, you'll now if your company uses SSO if this field is either set to Enabled or Required. "Enabled" means your users can login both via SSO or User/Password, if "Required" they can log only via SSO.

Next on the same screen, just look for the field depicted below:
if it is empty, this means you do not have the signing key for your Identity Provider configured and will need to configure it before March 31st, 2025.

If that is the case, your SuperAdmin users should have already been presented with a prompt to perform this change when logging into Kentik Portal.

Where can I find this IdP Public Signing Key ?

First you need to find a co-worker who has access to your Identity Provider's Admin interface. Typical Identity Providers are: Okta, Microsoft Entra ID (formerly ADFS), OneLogin, Ping Identity, Duo Security, Google Suite...

In this Identity Provider, you will have one configuration per App registered for SAML2 authentication - find your Kentik Portal application configuration.

From this point, the easiest is for you to find a way to download what is often referred to as "Identity Provider Metadata Configuration File".
If you open this xml file with a text editor, you will find your Identity Provider's x.509 signing key between these tags:

Just copy paste its content in Kentik Portal's SSO "IDP Public Signing Key (X.509 cert)" field and save your SSO configuration.

IMPORTANT NOTE:
Depending on your text editor, the Copy/Paste action may insert unwanted characters that will make the configured key malformed and make authentication fail.
This lifesaving online tool will strip this Cert string from all it's undesirable characters before you can safely paste it in your Kentik Portal SSO Configuration.

Additional notes

You may wonder: "Do I really need to do this ? What am I getting out of this ?"

• If your company accesses Kentik via SSO and you don't have an IdP Signing key, this change is mandatory.
• Remember that your local SuperAdmin will always have access to Kentik Portal with a user/password type of credentials, and will be able to disable SSO if your users are locked out
• The new backend code we are replacing the current SSO Engine with follows the most recent industry security practices, therefore making your Kentik Account more secure
• Our previous SSO login workflow did not carry the URL context forward: if you came in unauthenticated with a full URL from Kentik Portal, the SSO engine would log you in and send you to the homepage configured in your user profile: with this new code, we're carrying the inbound URL throughout the login process and landing you on the desired inbound URL. (which is specially useful when a coworker hands over a Data Explorer query hash and you haven't logged in yet).

If you require help with this configuration, our dedicated support team will help you at 🛟 support@kentik.com
If by March 31st you are locked out of Kentik Portal and your friendly SuperAdmin co-worker is not available to help, our Support Team can also help you too.

This update may not seem like a groundbreaking one, but as a user who uses Data Explorer 24/7, this one has been on my bucket list for a long time, and I'm unreasonably excited about it.

Read on!

Have you ever selected a large number of dimensions in Data Explorer, and been surprised to see the chart's Hover Tooltip cover the entire chart?

It used to drive me crazy... and while this wasn't mentioned by our users as an annoyance often, I'm pretty sure many people accepted it as an immutable reality that was never gonna change.

The screenshot below used to make me curse 🤬 even more than when I had to read text written with the Comic Sans font - and anyone who knows me enough knows how angry I get at the bare mention of this typeface...
Believe it or not, but there's an actual chart behind this tooltip on the screen grab below!!!

... and the main reason was that our charting library required so many technical contortions to get the tooltip to freely overflow out of the embedded chart that we could never find the necessary amount engineering cycles to fix it.

You will now be glad to hear that we have fixed this, and also provided a first round of layout efforts to make said Tooltip more legible. As you can see, the tooltip can now travel outside of the chart embed and take as much real estate as it needs from both the data table below, and the query panel as well, always leaving the currently-hovered part of the chart visible.

Laugh at me all you want, but every now and then, you get to fix one of your own nightmares and it feels very good - today is one of those days. :)

The story of how this came up is also a glorious one: during our weekly Product Design office hours, one of the designers teamed up live with one of our engineers and decided they were going to fix this LIVE during the meeting. Granted, it eventually took more than this live coding session in front of everyone, but it was a marvel of collaboration and ownership to watch, so tip of the hat to these two employees reading this article who'll know who they are, I'm pretty sure a lot of our users will be delighted!

Hope you enjoy the new tooltip as much as I do.