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.

Feature Overview

Adding event ingestion for real-time alerts and deeper network understanding

We’re excited to announce that Kentik NMS now supports SNMP Traps and syslog ingestion, giving network teams even greater flexibility and insight when managing modern infrastructure.

With this release, Kentik NMS adds support for two of the most widely used protocols for real-time network event communication. Whether it’s a hardware failure, interface status change, or critical software log message, you can now capture, query, and alert on these events natively within Kentik.

🛰️ SNMP Trap Support

SNMP Traps are a cornerstone of traditional network monitoring, allowing SNMP-enabled devices to push events without waiting for polling intervals. With Kentik’s SNMP Trap integration, you can:

• Receive SNMP Traps in real-time
• Filter and search trap events by name and OID
• Receive policy-based alerts and notifications
• Visualize trap events alongside other telemetry for faster root cause analysis

📜 Syslog Ingestion

Syslog messages are vital for capturing detailed system-level events across a wide range of devices. Kentik NMS now ingests and parses syslog data, enabling you to:

• Collect syslog events from routers, switches, firewalls, and servers
• Filter and search syslog events by name, severity, and message content
• Create alerts and notification policies based on syslog messages
• Visualize syslog events alongside other telemetry for faster root cause analysis

Why This Matters

These new ingestion capabilities allow network operators to centralize and correlate even more telemetry within a single observability platform. Whether you're troubleshooting outages, proactively monitoring infrastructure health, or securing your environment, Kentik NMS now has the signal coverage you need.

Key Workflows

Data Explorer

Query/browse traps and syslog events in Data Explorer:

Alerting

You can also bring your query context forward from Data Explorer into NMS's alert policy workflow to alert and send notifications when specific event conditions are met.

For example, let's say we're really interested when an SNMP traps of type "ciscoConfigManEvent" shows up. From the "Add NMS Alert Policy" workflow, we start by selecting a "Policy Type" of "Event" and then an "Event Type" of "SNMP Trap".

 
We then create an alert condition that will trigger a Major alert when a trap arrives of type "ciscoConfigManEvent", and configure a notification to email the interested parties when it occurs.

It's that easy.

Operability

We've also included some admin views to assist in troubleshooting and setup of the SNMP Trap and Syslog Server capabilities on the Universal Agent.

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 our future development.

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.

Feature Overview

Monitoring Templates are appropriate, customizable, data collection defaults - by Kentik. They can be applied to a set of entities (devices & interfaces) with a set of rules (filtering). With this new capability, Kentik Administrators can:

• Easily configure, apply and change monitoring targets and intervals across multiple devices at scale
• Prevent the polling of "admin down" interfaces, which will never be operational
• Stop polling virtual/stub interfaces that aren't "real"
• Manage Metric-per-Second ("MPS") licensing consumption (applies particularly to Streaming Telemetry)
• Control the fidelity of the data available to build graphs and other visualizations (1 minute polling vs 5 minute polling, for example)
• Influence the load created on devices by SNMP/ST data collection activities

Only Kentik administrators are able to access Monitoring Templates. 

Key Workflows

There are two ways to access Monitoring Templates in Kentik NMS. The first is by navigating to "NMS > Devices", and then using the "Manage" dropdown to select "Monitoring Templates".

The second way is when applying a template to an individual device by navigating to the "Edit Device > SNMP" tab, where there are navigational elements to also create a new template or access the Monitoring Templates settings page.

Note: Each device can only have one monitoring template assigned at a time.

Settings Page:

From the Monitoring Templates settings page, Kentik administrators can:

• View the list of preset and custom monitoring templates
• See how many and which devices are using which template
• Add, view, copy, edit or delete existing templates

Note: Devices that existed prior to October 2024 will not have a template applied, and will function as though they have the "Everything" preset, but will not show up on this settings page. New devices will automatically have the "Everything" template applied.

The Template Itself:

Templates start with a name, description and interface selection. Interfaces can be selected statically or dynamically. Only selected interfaces will be monitored.

Note: Monitoring Templates also supports Settings > Interface Classification configuration for dynamic interface selection.

Advanced Measurement Selection:

The Advanced Measurement Selection workflow allows administrators to granularly choose which metrics will be collected from devices with the template applied.

Although Monitoring Templates are an "SNMP" tab setting on the device presently, we've also included (for now) some Streaming Telemetry settings. If the "Specify streaming telemetry intervals" option is enabled, a new "Streaming telemetry interval" column will be available on the template.

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.

Feature Overview

We're excited to announce our new device-based alert-policy-creation workflow which provides a simpler, more powerful approach to creating intent-based alerts and notifications. Our now-deprecated "Up/Down" policies only allowed alerting on present states, "up" or "down" for example. The new system understands state changes and allows for multi-measurement comparison.

Specifically, Kentik users can now:

• Alert on entity state changes
  ex: BGP transitions from “established” to “active or “idle”
• Alert on multi-measurement threshold breaches
  ex: laser temp and fan-speed high, where int desc is “X”
• Enjoy Alert Manager Support for notifications, suppressions, silencing, acknowledgements, clearing and alert detail views

Key Workflows

Where to Start

From the Alert Policies Management page, users will notice the first change when adding new alert policies. These new "NMS" type alerts entirely replace our now-legacy "Up/Down" policy type. "Up/Down" policies that existed prior to release of this new feature still exist, and are editable. However, it is no longer possible to create alert policies of this type. Our new "NMS" alerting capabilities are better in every way.

Adding a new policy: General

The General section of the "Add NMS Alert Policy" workflow allows you to put a name and description on the policy, as well as control whether or not it's enabled.

Adding a new policy: Target & Filter Settings

The "Target & Filter Settings" section of the "Add NMS Alert Policy" workflow allows users to set their intent. This field defines what "entity" or custom measurement the user wishes to drive a notification against and grab their attention. Currently supported "entity" types are BGP Neighborships, Components, Devices, and Interfaces. The selected "Target Type" will control what "Measurements" are available to alert against.

The "Edit Devices" button will open a dialog box to determine which devices the alert policy should apply to.

Adding a new policy: Activate & Clear Settings

This new NMS alerting system will only support a single severity level per policy for now. We intend to expand this in the future. From this screen, users can also toggle acknowledgement and manual clearance requirements, set notification channels, and tune activation and clearance delay.

The part of the new system we're most excited to share is our Alert Conditions workflow! This allows users to build sentence-style conditions with advanced logic to build out complex and specific alert criteria. At least one trigger condition is required. The measurement determines what metric is available. Condition dropdowns allow for construction of readable sentences. Threshold and state conditions can be stacked. It's a massively flexible system, and this is just our first release. In the near future we intend to add support for "nested Boolean", or "compound expression" conditions.

Managing Alerts

There are essentially no changes in terms of how and where to manage this new type of alert. NMS device-centric alerts work just like traditional Kentik alerts in that they are viewed from the Alerting page, have Alert Detail sub-views, and can be suppressed, silenced, acknowledged, commented on, or cleared.

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.

We've introduced the Alerting Overview to help you manage your network health. We recognized that customers needed a clear way to spot patterns, assess risks, and share progress with stakeholders using their alerting data. By providing an interactive view of how the shape of alert volume change over time, you can pinpoint recurring issues, address them quickly, and avoid future disruptions. The new page is designed to provide an executive-level source of truth for the overall shape of historical alert data, making it easier to identify and prioritize problems from a macro view. This means you can adapt faster, keep stakeholders better informed, and maintain higher service quality. The new dashboard highlights:

• Alerts by Type (NMS, Traffic, Protect, and Cloud)
• Most Triggered Policies
• Monthly Alert Trends by Severity
• Alerts by Site

You can also filter the report by quarter and source alert type.

And easily export reports to PDF for convenient sharing.

To access the new Alerting Overview, go to the Alerting page and click the Alerting Overview button.

This new feature may seem small because its UI surface is constrained within lesser-used screens, but it packs a whole lot of punch under the hood. Let's dive into the details of Kentik Portal authentication – the good, bad, and challenging aspects – because there's a lot of new things to unpack today.

Single Sign-On is the modern way of managing access to a broad set of company-wide applications in a structured and more secure way, centralizing access control for all of these applications in the Identity Provider (IdP)  companies have chosen.

When login happens in Kentik using SSO, the Identity Provider presents claims to the Service Provider (in our case Kentik Portal) for each user (user attributes) in a standardized format named SAML2. Each company has a different pre-existing way to define user groups and rely on their IdP to do so.

With this SSO to RBAC attribute mapping feature, Kentik makes it easier and more flexible to leverage your current IdP configuration of user groups to enforce Kentik Portal permissions.

Let's dive in.

UserLevel vs RBAC

As Kentik Portal moves to a full RBAC permissions model, many areas are still governed by our legacy UserLevel permission model: we have three types of users, each one with a set of implicit permissions – Member, Admin, and SuperAdmin. For all areas of Kentik Portal that aren't governed by RBAC, UserLevel applies:

• Members generally have View only rights
• Admins have Update/Create/Delete rights 
• SuperAdmins are a special case: they are Admins who have the additional power to login using password authentication, even when SSO is required – there needs to be at least one per company, but the lesser the better to keep risk surface as low as possible.

As we progressively extend the surface of portal areas that are governed by RBAC, these areas will not be covered by UserLevels anymore – but in the meantime, we maintain both.

What our users have been asking for

Many customers with a large Kentik user-base have asked for RBAC permissions to be controlled centrally from their Identity Provider, which implied the following requirements:

• Kentik Admins want to control RBAC permissions directly through their SSO Identity Provider, as managing users at scale requires a centralized approach and dedicated tool outside of Kentik's User Administration page. Additionally, not all users want or need to enforce RBAC permissions via SSO – some are OK with using Kentik Portal's User Management capabilities, meaning both methods need to co-exist.
• Kentik Admins want to leverage their existing IdP configuration without modifications. Typically, the SSO team prefers to not create new groups for Kentik, but instead use existing groups. 
• Some SSO IdPs allow users to belong to multiple groups. This usually results in nested User Groups being presented to authentication by the IdP, and Kentik SSO needs to accommodate this reality.
  This is typically the case for more complex SSO Setups bridging LDAP or ActiveDirectory user groups into SSO->SAML2.
• For whatever user attribute key handed out in the SAML2 payload, Kentik Admins don't want to have to create specific values to match what Kentik's Service Provider (SP) end of SSO expects – they want to use existing ones and map them.
• Kentik Admins want to be able to forbid access to Kentik Portal for users that aren't in specific groups (instead of defaulting to Member as our current system does).

Introducing SSO Attribute Mapping

To satisfy the requirements captured in the previous section, we've updated the SSO configuration screens quite drastically to present these new functions.
If you don't see the Company Settings menu entry below, you are not a SuperAdmin and therefore cannot access the SSO settings.

As you can see, there are two sections – one for UserLevel SSO enforcement, and the other for RBAC SSO enforcement, since both will coexist for some time.

• The configuration for UserLevel enforcement configuration aspects have changed to this new model
• We've added an RBAC role-set mapping section. Rightfully you're asking, "But what's a Role set ?" – hang on, we'll get to that later ;)

In both of them, the Kentik Administrator can configure the key, which will be presented by their IdP to the Kentik Service Provider end of SSO: the authentication engine will look for the key and its value(s) in the SAML2 assertion presented by your IdP. Upon successful match of the key value, the subsequent UserLevel or Role-Sets will be assigned to the user based on this rule:

• By default, if no key is configured, Kentik Portal will use portal-local user settings for UserLevel or Role-Sets: this is the most common case where you don't want your SSO IdP to dictate user permissions
• If a key is configured, then Kentik Portal will evaluate the value in this key against the mapping table below it:
  • If the configured key isn't found or if the value for this key isn't present in the mappings, then the authentication process will turn to the default setting, as displayed below for UserLevel
    
    
• If a key is configured, and a match is found in the mapping table, then users will be assigned a UserLevel and Role-Set corresponding to the match
• If a key is configured, and multiple matches are found in the mapping table, then users will be assigned:
  • The highest UserLevel matched 
  • A set of permissions that corresponds to the union of all permissions listed in the Role-Sets that are mapped against these values

Let's look at the example below

1. Kentik Portal is expecting the key named kentik_userlevel from the IdP
2. if this key shows up with admin or guest values, the user's UserLevel attribute will be re-written on the fly to Administrator or Member
3. If no key is found, or if the user comes with a value that's different from the mapped ones (admin and guest), the default configuration will apply and the user will be denied access based on the configuration above.

Got it, now what are RBAC Role-Sets ?

Think of Role-Sets as operational sugar to manage user RBAC permissions more easily. In a nutshell, Role-Sets are collections of RBAC Roles. This new concept is introduced in the updated RBAC configuration screen.

The idea behind Role-Sets is that Admins usually want to be able to compose freely with RBAC Roles and Permissions – we realized it would make the Attribute Mapping very noisy if we were to ask our users to map multiple roles to a single Role key value, so we decided to offer an additional level of granularity by allowing users to group multiple RBAC roles in a Role-Set.

The new "Role-Sets" tab in this screen lets you configure these 

And the User Properties (in Company Settings > User Management) now let you assign both Roles and Role-Sets to users.

That's all folks!

As you can see, this feature packs quite a bit of punch and hopefully helps you more efficiently and cohesively manage Kentik Portal security according to moderns SSO standards !

Please let us know what you think – in parallel, we'll keep porting more and more portal areas over to RBAC out of the existing UserLevel model (another big announcement coming your way on that front, stay tuned).

Now, in the "Wait, there's more..." section, here are interesting stats around what SSO IdPs our customers are currently using – and this is the top5 ones we are testing these capabilities against.

We are thrilled to announce the general availability of Kentik Journeys, a flagship user experience of our Kentik AI family of features. You can enable this innovative tool directly through the Kentik AI configuration switch in your portal.

What is Kentik Journeys

Kentik Journeys offers a dedicated space for iterative network exploration and troubleshooting, leveraging a conversational interface powered by Kentik AI. Traditionally, network engineers have relied on network monitoring systems to browse and analyze data charts, refine queries, and repeat this process until they identify and resolve network issues. With Kentik Journeys, this process becomes more streamlined and efficient, thanks to the power of AI.

Checkout our Blog for What's New with Kentik AI to get more information about the nice features we added recently.

How to Enable Kentik AI

Kentik Journeys is part of Kentik AI feature set which can be enabled at the Organization level by users with Super Admin role in the Kentik Portal.

• For organizations which have already accessed Journeys in Preview, the Kentik AI switch is turned on by default — no changes required from your side.
• For organizations which have not enabled Journeys in Preview, the Kentik AI switch is turned off. 

Enabling Kentik AI

• Go to Journeys page on (US|EU) portal
• If Kentik AI is enabled in your organization you will be able to use it immediately
• If Kentik AI is not enabled yet:
  • If you are Member or Admin user, you will see the information to contact your Super Admin user for enabling Kentik AI
  • If you are Super Admin user, you will find the link to the Kentik AI settings page, where you can enable it. 
  • In rare case when your organization does not have Super Admin users, you will find the "Request Access" button to submit support request for enabling Kentik AI, after which our Product Support team will reach out to you with further details. 

Kentik AI settings page

• Kentik AI settings page is visible only to organization's Super Admin users (US|EU)
• The page is available through Organization settings icon on the top right side of the portal
• Simply toggle the Kentik AI switch to turn its features on and off
• See which Kentik AI features are available for your organization
• Read relevant Data Privacy and Security information related to the use of Kentik AI

We are excited to see how Kentik Journeys will transform your network exploration and troubleshooting. For any questions or assistance, please reach out to our support team.

We're thrilled to share the enhancements we've added to Kentik NMS over the past six months. Your feedback and continued support have been instrumental in driving our newest product forward. Here's a summary of the key updates:

New Device Workflows

• Topology Connections: We now show “Connections” on the “Device Overview” screen and “Interface Details” drawer. LLDP connections are automatically detected. Manual connections can be added where LLDP is not in use and are marked with an “M”:

• Device Dependencies: NMS can now detect when one device is downstream from another. When the upstream device goes down and the downstream device does not respond, the upstream device is marked as down while the downstream device(s) are marked as unobservable. This makes it easy to differentiate which device is down and needs your attention vs which devices simply is not responding due to the down device. The first place you will see this is in the status of a device:

Additionally, alerts configured to trigger when a device goes into status down will not trigger for these devices, of course. This is the default and will greatly improve the signal-to-noise ratio when alerting on downed devices. If for some reason you do want to alert for these devices, you can configure the alert to trigger for devices in status down or status unobservable. 

To enable this functionality, you must specify the “Closest Network Device” for the NMS agent by navigating to Settings > Universal Agents (NMS), selecting an agent in the table, and clicking edit:

• Unobservable due to agent down: In the event that an NMS agent goes down, all devices being monitored by that agent will be marked as Unobservable. Mousing over the status label will display a notice indicating that the device is down because the agent is down, and will indicate the name of the down agent.
• ICMP-only devices: Sometimes you don’t have SNMP access to a device but still want to monitor it. NMS now supports this use case with "ICMP only" devices. Add these devices by going to "Menu > NMS > Devices" and clicking "Add Devices" in the top right. At the prompt, select "PING ONLY". Doing so provides up/down status and latency:
  
  
  
  
  
• API for Device CRUD and Query: To better serve the largest and most complex networks in the world, you can now use the Kentik API to create, read, update, and delete (CRUD) NMS devices. You can also now run Metrics Explorer type queries via API. To make it easier, Metrics Explorer can show you the API query for any query you’ve done in the UI.

New Alerting Workflows

• Acknowledge Active Alerts: Alerts can now be acknowledged even while they are active. This is a common practice to indicate to the rest of the team that someone is aware of the issue and is taking action. The name of the acknowledger will be noted an a comment can optionally be added. Users can also choose to automatically acknowledge additional occurrences of the same alert ("auto-ack"), for situations like a flapping link.

• Silence Notifications: Notifications can be "silenced" and "unsilenced" from the Alerting page with the push of the button. Alerts will still trigger and can be seen in the UI, but notification channels will not be executed. By selectively silencing notifications for alerts, network admins can better manage focus and reduce noise to their team.
  
  
  
  
• Suppress Alerts: You can now prevent an alert policy from triggering all together by using suppress alerts from the Alerting page. 

Supressed alert policies will not trigger, and so alerts will not show up on the alert list and, of course, notifications will not be executed. You can see all configured Alert Suppressions on the Alert Suppressions page in Settings. From this page, users can view, create, edit, and delete Alert Suppression Patterns.

• State Alerts: State alerts were previously limited to out-of-the-box supported entities - Devices, Interfaces, and BGP neighbors only. You can now configure state alerts for any metric, including custom metrics. Another way to think about this is that threshold alerts alert when a metric is less than or greater than a value (or baseline) whereas state alerts alert when a value is equal to a certain value, for example the number 3 which corresponds to an interface being down.

Quality Enhancements

• Status Bugs: In very specific scenarios, devices were incorrectly marked as down. While most customers were not affected by this bug, those that were had instances where many devices were reported down but were not really down.
• SNMP Polling Efficiency: Several bug fixes involving SNMP timeouts, conflicting statuses and agent stability.
• Query Performance: In an effort to reduce the amount of time it takes to load some of the more complex NMS pages, we've made query optimizations to backend improve performance. While there's still room for improvement, we think you'll already notice the difference.
• Other Bugs: We addressed numerous issues relating to usability, reliability and predictability - especially where alerting is concerned.

In addition to the software changes above, you will find a great deal more information about NMS available in the knowledge base. These articles will help you get the most out of Kentik NMS.

We are committed to continuously improving to meet your needs and exceed your expectations. We encourage you to explore these enhancements and send us your feedback!

Thank you for being a part of the Kentik community. Stay tuned for more exciting updates soon.