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

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

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

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

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

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

We are excited to release a new Kentik AI feature called “Cause Analysis," part of our core Traffic Analysis portfolio. Designed to help network engineers more quickly understand the underlying network traffic contributing to network anomalies, this new interactive feature in Data Explorer uses data mining, AI, and Kentik's industry-leading context enrichment to instantly identify the most relevant and contributing factors (dimensions) of network traffic within a given time frame. It reduces the amount of time it takes to investigate sudden traffic changes, like spikes, increases and drops in relatively short time frames.

Our goal is to make it easier and faster for our users to quickly understand the most important characteristics of the traffic contributing to a change, like application, IP addresses or prefixes, ASNs or public cloud services. This analysis is done automatically upon user request without needing to select any flow dimensions in the Kentik Data Explorer and without expert level knowledge in traffic analysis. The results can easily guide a user to understand the cause of traffic changes and anomalies and to take appropriate further actions.

This feature is available for companies that have enabled Kentik AI.

Cause Analysis in Data Explorer

Cause Analysis in Data Explorer supports three user workflows:

Traffic analysis - to find the most contributing traffic dimensions in a single time selection window

In this workflow, a user is able to select a single time window on the graph and to invoke Cause Analysis. Currently the time window is limited to 2 hours.

The results of the analysis will be shown below the chart in an additional tab named “Cause Analysis” which will emphasize the most contributing factors on the traffic during the selected time window. A Kentik AI summary of the results is provided at the top of the panel. The lower part of the panel shows numerical results presented in a hierarchical table, which are produced by Kentik’s data mining algorithms.

The values of traffic rate and the percentages in this table are estimates and not the completely exact values. The intention of this feature is to efficiently emphasize the most contributing dimensions to help answer the question "what happened?".

The analysis considers selected traffic metric, e.g. Bits/sec, Packets/sec or Flows/sec.

Traffic comparison analysis - to find changes in traffic patterns between two selected time windows

In this workflow, a user is able to select two time windows on the graph and to invoke Cause Analysis, which will then show the most contributing factors to the traffic increase. This helps users quickly answer the question "what changed?" The system will first compare the two selected windows based on average traffic volume. Based on the results, it will further compare the window with lower average traffic to the window with higher average traffic, emphasizing which type of traffic significantly contributed to the increase. With this approach, it is irrelevant which time window will be selected first.

The results of the analysis will be shown below the chart in the tab called “Cause Analysis”. Kentik AI’s summary of the results is provided at the top of the panel. The lower part of the panel shows numerical results presented in a hierarchical table, which are produced by Kentik’s data mining algorithms.

Automatic detection and analysis of traffic changes

In this workflow, the system will automatically analyze time series results in Data Explorer and look for significant changes in the traffic that might be interesting to the customer. Those significant changes can be spikes, drops or sudden increases and decreases in traffic. On these changes, Kentik AI will perform analysis of the traffic difference before and after the change, trying to pinpoint which traffic contributed to the increase or decrease.

The workflow starts when a user clicks the button “Analyze” at the top of the time series chart or at the bottom of the query panel.

• The system will try to detect the most significant 5 changes (configurable)
• These changes will be marked in the chart
• The “Cause Analysis” panel below the chart will list the changes with the relevant details: type of the change, average traffic metric of the change and time of the change point.
• An AI summary of the change will be provided in the summary section
• Each change can be further visually expanded to show numerical results presented in the hierarchical table, which are results of Kentik’s data mining algorithms.

Cause Analysis in Kentik Insights

With this first release, Cause Analysis is also being integrated into the Device Traffic Increase Insight. The Insight is enriched with valuable information of the most contributing factors to the device traffic increase.

The system will automatically determine when the traffic increase started and perform analysis of traffic differences between traffic before increase and during detected increase. The results are presented below the time-series chart with a Kentik AI summary of the results and the relevant details. This information can help users determine what is a likely cause of such traffic increase on the particular device.

As always, we welcome your feedback as you start to use this new feature. Please reach out with any questions, concerns or feedback.

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.

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.

Feature Overview

NMS's device-centric alerting now includes the ability to use nested condition groups and Boolean logic when creating alert trigger conditions. 

Trigger logic using operators (ANY, ALL, or NONE) can now be combined and nested, which provides several key advantages, including:

1. More precise control over alert policies
2. Reduced alert noise
3. Better automation potential

This allows policy creators extremely granular control over determining what conditions cause an alert to fire, keeping focus on the alerts that are most meaningful to you, and minimizing noise. 

Here's what the starting alert conditions section looked like before:

And here it is now:

You'll notice you can now add "Condition Groups" and "Nested Condition Groups". These condition groups provide for Boolean logic in the alert trigger conditions - making Kentik NMS significantly more effective at managing complex network environments.

Key Workflows

Condition Groups

Condition groups are the "top level" layer. They can contain conditions and/or additional nested condition groups. Below is an example of a policy starting out with three condition groups. In this case, you can think of an implied OR operator between each of the red box condition groups. 

Nested Condition Groups

Nested condition groups exist in a hierarchy which can go four layers deep, each with their own operator, as shown here. This allows you to express complex decision-making processes clearly and efficiently.

Advanced Alert Policies

By using nested condition groups, NMS policy creators can now tune their alerts and notifications to only grab focus from network operators when doing so brings them critical network awareness.

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!!!