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

What's New?

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

You can now create custom roles with specific permissions for:

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

Why It Matters

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

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

Take control of your user permissions today!

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

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

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

Ever wonder exactly what measurements Kentik NMS collects for a specific device model before you actually add it? Planning a rollout and need to verify support for your entire network inventory? Thinking of adding a new device model to your environment and wondering if we already support it?

We're excited to announce the new NMS Device Support Explorer, a powerful tool that gives you unprecedented transparency into Kentik’s monitoring capabilities. Know precisely what data you’ll get from every device in your network.

With the NMS Device Support Explorer, you can now:

• Instantly Verify Support: Search our entire library by Vendor, Model, or even the SNMP sysOID to confirm full support for your hardware.
• See Every Measurement: Get a granular, model-specific list of every measurement we collect—from interface stats and CPU utilization to temperature, BGP peers, and more.
• Streamline Planning: Accelerate your onboarding and network expansions by planning with certainty, knowing exactly what types of data you'll have from day one.

This level of transparency into the NMS platform itself isn't just a feature; it's a reflection of our philosophy. The NMS Device Explorer is unique to Kentik and is only possible because of our state-of-the-art architecture and OpenConfig-inspired data modeling. We don't just show you your network's data—we give you unparalleled understanding of it.

[Explore device support in our Knowledge Base]

Don't see the measurements you need listed for your devices?

Submit an NMS New Metric Request from our portal.

🔓 Unlocked: More Power and Flexibility for Custom Webhook Headers!

Get ready to level up your integrations! We've heard your feedback and have supercharged our Custom Webhook notification channels. Gone are the days of being restricted in how you format your headers.

Previously, Custom Headers were limited to 

Authorization and headers prefixed with x-. We're excited to announce that we've removed this limitation, giving you far more freedom and flexibility!

What's New?

We've enhanced our Custom Webhook notifications to support a much broader range of HTTP headers. You can now send notifications with virtually any custom header required by your third-party systems, internal tools, and automation scripts. The only headers we restrict are standard ones that could conflict with the HTTP connection itself.

This means you can now seamlessly integrate with services that require specific header formats for authentication, routing, or metadata without needing complex workarounds.

Why It Matters

This update is all about making your life easier and your integrations more powerful.

• Ultimate Flexibility: Integrate Kentik alerts with an even wider universe of applications and services. If your endpoint needs a X-Custom-Auth-Token, My-App-Identifier, or any other unique header, you can now add it directly.
• Streamlined Automation: Simplify your incident response playbooks. Send alerts with the exact headers your systems expect, making your custom scripts and downstream tools more robust and easier to maintain.
• Enhanced Security: Securely pass custom API keys, tokens, or other authentication data in the precise header format required by your infrastructure.

Get Started!

Putting this new flexibility to work is easy:

1. Navigate to 
   Settings > Notification Channels in the Kentik portal. 
2. Click 
   Add Notification Channel and select 
   Custom Webhook, or edit an existing webhook channel by clicking the pencil icon.
3. In the 
   Custom Headers section, click the + Add button and input any key-value pair you need for your custom headers. 

That's it! We can't wait to see the powerful and creative integrations you build with this new capability. Happy automating!

In a previous announcement, we introduced Universal Agent as a foundational piece of software to further operationalize and unify our collection of telemetry agents under a single umbrella. With the benefits of this approach, we are hard at work porting all of our existing collection agents towards this new paradigm as Universal Agent Capabilities. 

Today, we will be talking about our OTT Service Tracking DNS tapping agent, and how as an existing OTT Service Tracking user you can migrate these DNS taps at no operational cost and start benefiting as early as today from their highly improved operability. Read on!

OTT Enrichments, how do they work?

Firstly, let's review how Kentik's OTT Service Tracking functionality works. Contrary to DPI (Deep Packet Inspection) which requires you to deploy DPI hardware at your network edge to map your subscribers' consumed applications, Kentik offers a creative, lightweight, and operationally and financially efficient method to perform the same task: users deploy a DNS Tapping Agent, in addition to exporting network flow telemetry from their devices, and our True Origin engine maps DNS query responses to traffic based on an ever-growing library of domain name patterns to directly color this flow telemetry with OTT describing attributes – OTT Service, OTT Category, OTT Provider.

Until today, the DNS tap collection was instrumented via our former host monitoring agent kprobe in a specific mode that did not export host telemetry, but only DNS query/responses. The drawbacks of this legacy approach are:

• kprobe is not observable in Kentik Portal, both from a DNS tapping activity metrics standpoint and an out-of-the box alerting standpoint
• kprobe upgrades are manual, requiring deployment for each new version
• combining host monitoring and DNS tapping in the same telemetry agent introduces a shared bug surface between two very different functions
• in cases where kprobe couldn't be installed on a DNS resolver, deploying it as a DNS tap required a complicated launch command

Taking a hard look at these constraints, we are now happy to offer a much more operable and easy-to-deploy solution via a new Universal Agent capability, so let's look at the benefits now!

So what's new ?

Trivial deployment of DNS taps, under the hood upgrades

As of today, all Universal Agents deployed offer a new capability aptly named DNS OTT Tap which replaces kprobe's legacy role of conveying DNS query/responses to our flow ingest clusters for OTT-related flow enrichments. Installing it will download the capability's core binary and enable it.

Once the capability is enabled, users will be able to configure the few parameters, and the Universal Agent host will keep the OTT DNS Tap capability in its latest version without any further operational attendance needed.

Easy promiscuous mode

You can now select a specific host interface to capture DNS queries and responses. In addition, if you’re using port mirroring, port spanning, or tunneling to send this traffic from the server-facing port to another host, you can enable Promiscuous Mode on that interface to capture it, as shown in the diagram below.

OTT DNS Tap metrics

Every Universal Agent capability comes with its own set of metrics. The OTT DNS Tap is no exception to this principle: clicking on the capability [Details] button will show two charts – one for the amount of DNS query/response funneled by the capability to Kentik's ingest clusters, and a second on the number of query/responses discarded, to monitor for any issue related to the capability's specific job.

As can be seen on both screenshots, both metrics are instantly available in Metrics Explorer for further reporting, so that administrators of the DNS Tap fleet can quickly troubleshoot. Here's an example of a single Metrics Explorer query showing the number of query/responses per seconds that an entire fleet of DNS Taps is performing:

At last, we've improved the [Configuration] screen of our Service Provider > OTT Service Tracking workflow to now include all deployed OTT DNS Taps with their agent status health. 

What does the migration path to the OTT DNS Tap Universal Agent Capability look like?

The process to switch from a standalone kprobe setup to Universal Agent's OTT DNS Tap capability couldn't be safer and simpler. It consists of the below steps:

1. On each DNS server where kprobe is currently running on, deploy Universal Agent. (Knowledge Base Article)
   The process is trivial: enter the command line on the server's shell and follow the instructions until Kentik Portal offers you to register the newly detected agent.
2. Once Universal Agent is installed successfully on the DNS server, install the OTT DNS Tap capability. (see Knowledge Base entry here)
3. Configure the OTT DNS Tap capability to your liking – default settings should cover most of the installs.
4. At this point both kprobe and the OTT DNS Tap will be sending the same data to Kentik's DNS ingest cluster, and it does not affect the OTT enrichment data at all.
5. Verify that the OTT DNS Tap capability is receiving DNS Query/Responses from the capability's drawer in the Universal Agent UI. (see screenshot in the OTT DNS Tap metrics paragraph in this post)
6. 🎓 Congratulations, you are done: you can now safely uninstall kprobe and proceed to the next DNS server.

The simplicity of the migration path relies in the fact that both kprobe and the new Universal Agent capability can coexist without causing any OTT Flow enrichment issues.
👌 So, go ahead and migrate your kprobe instances right away and benefit from the improved observability of our Universal Agent as soon as today!

Note: if any doubt whether the kprobe instance running on a DNS server is used as a Legacy DNS Tap or to generate host flow telemetry, the following command on the host will help disambiguate - if it yields any result, then there's a kprobe running on this instance needing to be replaced with a Universal Agent OTT DNS Tap capability:  ps auxw | grep kprobe | grep dns

What comes next ?

In one of our next releases, we'll be adding out-of-the-box alerting for both Universal Agents and capabilities, sending you notifications whenever your fleet of telemetry agents is encountering issues.

In addition, we have a really neat slate of improvements that we are also going to bring to life in the near future, amongst others: new agents such as Flow Proxy (fka kproxy) will be ported over under Universal Agents, as well as some large scale deployment options, and also an initial set of HA (High Availability) options – so watch this space!

We're thrilled to announce a significant upgrade to the Knowledge Base (KB), designed to help you find information about Kentik’s powerful Network Intelligence features more efficiently than ever before. While you'll still access the KB at https://kb.kentik.com, we've made substantial enhancements to deliver a truly new and improved experience.

What's New and Improved?

So. Many. Things.

Search

We wanted an easier path to Kentik product knowledge, so we added these search enhancements:

• Search the entire KB at once: Platform, Portal, and in the near future, API documentation
• Search with natural language questions

Streamlined Access to Information

Navigating the KB is now easier than ever:

• The redesigned “Explore Articles” sidebar simplifies your learning and troubleshooting journeys. 
• The “In This Article” table of contents now has an improved layout and automatically highlights where you are in the article.
• Next/Previous Article buttons, Feedback, and Related Articles at the bottom of every article
• Recently Modified, Recently Created, and Most Viewed article lists on the home page

A Modern, Intuitive Experience

It might have been overdue, but we think you’re gonna love these:

• Refreshed look and feel
• More variety of visual elements like callouts, accordions, tabs, and videos
• Ability to copy code blocks with a single click
• Choice of Dark/Light/Auto themes

We are committed to continuously improving your experience with Kentik, and this Knowledge Base evolution is a key part of that commitment. Dive in and explore the enhanced capabilities  at https://kb.kentik.com and let us know how it goes!

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

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

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

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

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

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

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

Coming Wednesday (July 16, 2025):

We are excited to announce powerful new enhancements to our NMS product, bringing more security and flexibility to your SNMP data collection. You now have access to stronger encryption for SNMPv3, better polling setting defaults and advanced controls to fine-tune polling behavior for every device in your network.

Enhanced SNMPv3 Security

Security is paramount, which is why we’ve added support for the following, more secure SNMPv3 protocols:

• Authentication Protocols: SHA-512 & SHA-128
• Privacy (Encryption) Protocol: AES-256

SHA (Secure Hash Algorithm) and AES (Advanced Encryption Standard) are both cryptographic algorithms, but they serve different purposes. SHA is a hashing algorithm used for creating a unique fingerprint of data, while AES is an encryption algorithm used to scramble data so it can only be read with a key.

This allows you to secure your network management traffic with the latest standards.

Important: Please note that these new security protocols are available for NMS data collection performed by the Universal Agent (UA). They do not apply to KProxy-based flow enrichment.

A Look Ahead: Our Unified Agent Strategy

The Universal Agent (UA) is the future of data collection at Kentik. Our long-term plan is to consolidate all SNMP and Streaming Telemetry collection into the Universal Agent, which will handle both NMS metric collection and flow enrichment. Features such as our topology maps, capacity planning, cost analysis, and traffic engineering are currently powered by our KProxy agent only, but will be served by Universal Agent’s NMS capability in the future. By focusing our development on the UA, we can deliver enhancements like these new security protocols more quickly and efficiently. It will also importantly resolve issues with double-polling currently caused by separate agents for flow enrichment and NMS collection. 

Granular Control Over Polling

Now available when configuring NMS Monitoring Templates, Polling Options gives you gives you the flexibility to fine-tune polling behavior, balancing performance and speed of telemetry to your specific needs:

• Max OIDs per Request: Adjust the number of OIDs (Object Identifiers) the agent requests at one time. This applies to SNMP v2c and v3 only.
• Request Retries: Set how many times the agent will retry a failed request.
• Timeout: Define how long the agent will wait for a response before timing out.
• Parallel Requests: Control the number of simultaneous polling requests (workers) for a single device.

Sensible New Defaults

Based on extensive real-world testing, we’ve also updated the default polling configuration for both existing and newly added devices. Our new approach favors pulling more data in a single request while reducing the number of parallel requests. This has proven to be a more efficient method for the vast majority of network hardware.

Why We Made This Change

Every network is unique, and some devices can be more sensitive to polling than others. While our default settings are designed to work brilliantly for most hardware, these new controls give you the power to ease the polling impact on devices with limited resources or unique configurations. It’s all about providing a powerful, flexible monitoring solution that adapts to your environment.

We're Here to Help!

Not sure what settings are right for your devices? Our Product Support team is ready to assist you in optimizing your new polling configurations. Please don't hesitate to reach out for guidance.

Laying the foundation for class-specific Device Details

Kentik NMS is getting smarter about how we meet the observability needs of the kinds of devices you're monitoring.

Until now, all Device Details pages looked the same—whether you were viewing a router, switch, firewall, or even a server or UPS. This one-size-fits-all approach helped us get the feature out the door, but we know it’s not how network operators think or work.

Why this matters

When troubleshooting or planning, operators expect different insights from different devices:

• Routers: You care about routing tables, interface health, BGP sessions.
• Switches: You want to see port status, VLAN memberships, trunk links.
• Firewalls: You’re hunting for ACLs, session counts, and threat logs.

That’s why we’re introducing device “classes”—clear, functional groupings like Router, Switch, Firewall, Server, and more. These classifications will allow Kentik NMS to tailor what data we highlight on each Device Details page, surfacing the most relevant insights first.

What’s new today

This release introduces:

✅ New class icons for fast visual identification
✅ Device classifications across all NMS and Flow-enriched devices
✅ Vendor logos added to the Vendor column in the Devices table

These changes enhance both the navigation experience and the visual consistency across the product.

Class icons uniquely represent the 12 devices classes we found more prevalently on our platform: Router, Switch, Firewall, Load Balancer, SD-WAN Gateway, Wireless Controller, Access Point, Server, UPS, PDU, Optical Transport, and Storage Array. In the future, we'll be adding the ability for admins to change the assigned device class, and create their own custom classes!

Classifications have been added most conspicuously to the Devices and Device Details pages, making identifying a device's base functionality much easier. Classification happens automatically based on the SysObjectID-derived make and model, and some AI magic. Previously, a device's icon was driven by a mixture of the Flow device type or device vendor. As not to lose the value, the vendor icon has been added to the vendor column.

🔜 Coming soon: Rich, class-specific views that show the right metrics, tables, and visualizations based on what kind of device you're looking at.

Why it’s better

• Less clutter: Device icons are now consistently based on a single characteristic - function class.
• ‍Instant recognition: Icons + vendor logos = less scanning, faster decisions.
• More context: Classes unlock tailored data views for each device type.

This is just the first step in a bigger journey to make Kentik NMS a truly intelligent network observability platform. Let us know what you think—and what you want to see next!

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.

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!