KProxy has long been a trusted ally in maintaining network visibility across complex and restricted environments. As we look toward the future of network intelligence, we are excited to help you scale even further by integrating these proven capabilities into a more unified and automated platform experience.

See What’s New

With last week’s release of Flow Proxy as a native capability within the Kentik Universal Agent, we are now officially setting a sunset date for the standalone KProxy binary: May 1, 2027.

We’re sharing this roadmap a full year in advance to ensure your team has a clear and supported path to the next generation of flow collection. This transition moves the robust traffic forwarding you've relied on into a "set-it-and-forget-it" capability model. By consolidating into the Universal Agent, you’re moving toward a more streamlined, single-agent architecture that simplifies your entire telemetry stack.

Why It Matters

Transitioning to Flow Proxy allows you to leverage a modern, high-performance architecture while building on the reliable foundation KProxy established.

• Unified Agent Management: Instead of managing KProxy as a separate standalone service, you can now handle everything through the Universal Agent. This means one binary to maintain, one service to monitor, and a much cleaner operational footprint.
• UI-Driven Control & Visibility: We’ve moved configuration out of local text files and into the cloud. You can now deploy, tune, and scale your Flow Proxy settings directly from the Kentik Portal, giving you faster response times and better oversight.
• Enhanced Security Standards: The integrated Flow Proxy brings FIPS support to your traffic forwarding. This ensures your telemetry meets the highest security and compliance standards required for modern regulated environments without any additional configuration complexity.

Get Started!

The future of network intelligence is unified, and the path forward is simple. We recommend all users begin migrating their KProxy instances to the Universal Agent Flow Proxy capability to start taking advantage of these integrated features today.

Dive into the KProxy Migration Guide to map out your move, or jump into the Kentik Portal to enable Flow Proxy on your existing Universal Agents. Let’s get your network ready for 2027.

Onboarding network devices shouldn't require a complex flowchart to determine which agent polls for what data. We understand that juggling "NMS devices" versus "Flow devices"—and facing the performance penalty of "double polling" where multiple agents hit the same device—has been a source of friction and unnecessary complexity. 

What’s New?

We’re thrilled to announce a major evolution in how the Kentik Universal Agent (UA) collects device telemetry. Instead of a product-focused "NMS" capability, all SNMP and Streaming Telemetry (ST) collection will be handed by a Unified SNMP/ST capability.

Previously, the Universal Agent’s "NMS" capability focused on full monitoring (as well as ICMP-only devices), while a separate Kproxy agent (outside of the UA) handled SNMP polling for flow enrichment (as well as flow ingest). This often led to redundant polling and confusing configurations when polling devices for both flow enrichment and device monitoring.

The "NMS" capability has evolved into the SNMP/ST capability. This single, powerful capability now handles both Full Monitoring (NMS) and Flow Enrichment. For more details on these distinctions, check out the Detailed Migration Scenarios section of the KProxy Migration Guide. This update works hand-in-hand with our new UA Flow Proxy capability, allowing you to consolidate everything under the Universal Agent framework, eliminating the need for standalone Kproxy installations and streamlining your "Kentik devices" onboarding process.

Why It Matters

This unification isn't just a rename; it is a fundamental architectural improvement designed to reduce overhead and simplify your workflow.

• Eliminate "Double Polling": By consolidating monitoring and enrichment into a single capability, we stop the inefficient practice of having both Kproxy and the Universal Agent poll the same device. This significantly reduces CPU load on your network gear and improves overall performance.
• Simplified Onboarding & Management: We're eroding the need to decide between an "NMS device" or a "Flow device." You simply configure the SNMP/ST capability based on your collection needs. Whether you just need Flow Enrichment (requires Flow license) or Full Monitoring (requires NMS license), it is now handled by a single, logical agent configuration.
• Faster Time to Value: Deploying new devices is faster and less prone to configuration errors. You get immediate visibility without the "support tax" of maintaining disparate agent binaries.

Get Started!

Ready to streamline your device telemetry? For a detailed breakdown of the migration paths and new configuration options—including Flow Enrichment vs. Full Monitoring—check out the KProxy Migration Guide in the Kentik Knowledge Base.

Managing disparate agent binaries across your network shouldn't be a manual chore that slows down or complicates your visibility. We know that deploying agents in remote sites or restricted environments often feels like a balancing act between security requirements and operational simplicity.

What’s New?

We’re thrilled to announce that the power of KProxy is now natively integrated into the Kentik Universal Agent! This update brings the trusted secure traffic forwarding agent you rely on directly into our Universal Agent. Instead of managing standalone KProxy installations via command line, you can now deploy, manage, and scale your flow collection as a simple "capability" within the Universal Agent. This integration allows the agent to receive, process, and forward NetFlow, sFlow, and IPFIX telemetry to the Kentik platform with more control and less friction than ever before.

Why It Matters

This evolution of the Flow Proxy capability isn't just about consolidation; it's about making your life easier and your network more secure.

• Centralized UI Configuration: Say goodbye to manual configuration files. You can now deploy and tune your Flow Proxy settings like listening ports directly from the Kentik Portal.

• FIPS Support for Regulated Environments: For our customers in highly regulated industries, this update introduces FIPS support, ensuring your traffic forwarding meets the stringent security standards required for compliant implementations.
• Simplified Enrichment: Easily associate all flow data with specific Kentik Sites during setup, ensuring your data is organized and actionable the moment it hits the platform.

Get Started!

Ready to streamline your device telemetry? For a detailed breakdown of the migration paths and new Flow Proxy configuration options check out the KProxy Migration Guide in the Kentik Knowledge Base.

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!

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!

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!

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.

Today, we're sharing the first step in a journey to seamlessly integrate Kentik NMS with our Flow platform. This is just the beginning of a series of iterations that will bring them together in a more cohesive and powerful way.

Read on as we show you a new and easy way to visually correlate NMS charts with Traffic data.

Metrics Explorer vs. Data Explorer

A novel take on an existing type of product, Kentik NMS' approach relies on taking advantage of what made our Flow Telemetry platform a hit: open exploration using Metrics Explorer, the little brother of our award-winning approach you know and love in Data Explorer. In other words, while Data Explorer is the business intelligence (BI) platform to your Network Traffic data, Metrics Explorer is the BI platform to your SNMP or Streaming Telemetry data.

When we launched Kentik NMS, our goal was to marry an NMS with world-class Traffic Analysis to provide our customers with the most cutting-edge and useful network observability platform available. To that end, we’ve learned a lot about how our initial users were using it and took some notes:

• Not everyone who's gained NMS Metrics Explorer expertise is comfortable with Data Explorer, especially given the latter is beyond feature-rich because of years of successive improvements
• A lot of troubleshooting workflows follow the same pattern: identify a peak or a trough on a chart, then inspect traffic to investigate what factors might be contributing to this pattern –  rinse, repeat... – very often an iterative process

Correlation, Causation, AI, and the Network Engineer

Recent days have marked the rise of ML/AI where every product (and Kentik is no exception) will show you machine learned insights about something you did not know about your network. 

Additionally, we get reminded more often than not that correlation does not equal causation, as absurdly illustrated in the meme below:

Yet, years of practitioner experience in this industry tell us that a vast majority of network troubleshooting activities always end up in trying to identify a bump or a trough on a chart by looking at other charts to identify a probable root cause.

In this process, the network engineer is always better equipped when they can leverage a UI/UX that makes it easy for them to quickly eyeball multiple charts on top of each other, with a perfectly aligned time range.

So, we took a few simple use cases and iterated to provide a UI that helps the network engineer correlate SNMP and Traffic charts together:

• "A port on a device is running hot, what could be the reason?"
• "What could be the reason behind the CPU of this router peaking?"

Often times, what we noticed was that the right tool was more about allowing users to quickly iterate through hypotheses, going from one finding to the next, quickly ruling out dead ends. With this as the target user methodology, we came up with the small but powerful capability described in the next section.

Introducing the Metrics Explorer bottom drawer

In Metrics Explorer, you may now notice a little kebab menu at the end of each row. If your query yields a Site, Device, or Interface, you will now be offered with a contextual menu which allows you to summon a traffic breakdown for that specific row:

Selecting any of these entries will summon the "Dimensions Selector", allowing the user to choose any set of up to 8 traffic dimensions to break traffic down for this Site, Device, or Interface – here's an example selecting Source IP and Destination IP for this device. As you can see:

• a bottom drawer opens up with a nested Data Explorer traffic query that's perfectly lined up with the Metrics Explorer one to facilitate visual correlation
• this drawer can either be minimized, discarded, or a new tab can be opened with this very query pre-populated by clicking "Open in Data Explorer"
• discarding the bottom drawer to replace with a new set of traffic query dimensions is also pretty straightforward, allowing for fast-paced troubleshooting iteration

Tell us what you think! What's next?

This feature tested pretty well with our field teams, but we're curious what you think of it! Let us know how we can make it better in future iterations.

We've already started thinking of other areas where we want to bring this traffic inspection bottom drawer:

• Add it to the Capacity Planning workflow so that users could directly look into the reason for why an interface is facing imminent congestion
• Bringing it into the NMS Device screen: it has an "Interfaces" tab, which would definitely benefit from the ability to inspect traffic breakdown for any interfaces here
• ... and then what about the reverse? What about being able to see the CPU traffic chart for a Traffic Breakdown that has the Device name in it?

Stay tuned for near future announcements around our plans to bridge our NMS and Flow Analytics worlds together!

Kentik is excited to announce an enhancement to our telemetry ingest capabilities with the support for IPFIX Information Element (IE) 315. Let’s dive into how this Information Element is used and why users should care about it.

Understanding the Flow Collection and Export Process

The flow collection process of network devices consist of three stages:

1. sampling of the packets: selective capturing of the network packets to reduce data volume
2. aggregation and caching: flow metadata and counters stored in device’s flow cache table
3. export of the expired flows: sending flow data to a flow collector

During packet sampling, the information from the packet headers and device’s interfaces are extracted to form a unique identifier (key) for each flow in the flow cache table. New packets that match an existing flow key will increment flow’s byte and packet counters, while unmatched packets will trigger a creation of the new flow record. 

Flows are exported to the collector based on two conditions:

• the inactive-timeout period: no new packets have been detected for a flow, which means that the flow is inactive. 
• the active-timeout period: current state of flow counters is exported even though the flow is still active.

The Evolution of Flow Collection in Modern Networks

At the time when the flow collection technology was developed, traffic volumes were significantly lower and network devices could “afford” to capture and export data of all traffic flows. However, with today's networks where hundreds of devices are handling traffic at gigabits or terabits per second throughputs, complete flow capture has become impractical. To effectively manage these traffic volumes, the sampling has become a reality in most use cases with typical sampling rates ranging from one in a few hundred to one in several thousand packets.

For near real-time traffic analysis, users would generally set inactive-timeout at 15 seconds and active-timeout at 60 seconds. For DDoS detection use cases, these counters can be configured even with lower values. Given the high sampling rates and rapid flow expiration, the effectiveness of traditional flow caching on network devices is now questionable. 

According to the research performed by Juniper Networks, with the flow sampling in the range of 1:1000s and active-timeout of 60 seconds, it is expected that around 90% of the exported flows will have only 1 packet matched. In such environments, the flow caching process on network devices does not bring much benefits. An alternative approach of directly exporting packet headers to a collector seems more effective and this is where IPFIX IE 315 comes into play. 

Introducing IPFIX IE 315

IPFIX IE 315, known as dataLinkFrameSection, carries a sample of the network packet headers, starting from the L2 protocol header up to a maximum sample length determined by the network device capabilities. This capability varies by vendor and device models, but typically supports sampling of 64 to 160 bytes. 

The typical IPFIX flow data record includes: ingress and egress interface index, flow direction, and the length and data of the sampled frame. 

Vendor support

Juniper Networks

Juniper Networks offers support for IPFIX IE 315 through its IMON (Inline Monitoring) feature. It is supported on MPC10E and MPC11E linecards for MX-series devices, MX304, linecards LC480 and LC9600 for MX10K and certain line cards for PTX10K. The feature is implemented in hardware, so there is a minimal delay and no restrictions in the volume of exported data. It supports export of 64 to 126 bytes of packet’s header. More information about the implementation, configuration and support on devices can be found in Juniper’s technical documentation. 

The flow data record includes the following IPFIX IEs:

Cisco

Cisco supports IPFIX IE 315 on its NCS 5000 and ASR 9000 devices. It uses slightly different flow records with IPFIX IE 410 (sectionExportedOctets) to store the length of the sampled frame section and does not include flow direction field. The size of exported frame is up to and including L4 header, to the maximum of 160 bytes that can be exported.

The flow data record includes the following IPFIX IEs:

Benefits of using IPFIX IE 315

The approach of IPFIX IE 315 shifts the packet decoding and metadata extraction work from a network device to a flow collector. This reduces the processing requirements on network devices and eliminates the need for maintaining a flow cache table, leading to lower CPU and memory usage and potentially simpler hardware designs. Moreover, the immediate export of packet samples enhances the detection time of DDoS attacks.

Support in Kentik

Kentik Flow ingest on the SaaS supports use of the IPFIX IE 315, with the Kentik’s default Device Type “NetFlow-enabled device”. The feature is also available on Kentik kproxy version 7.43.0 and it supports both Juniper and Cisco implementations.

We are happy to announce the general availability of Azure Firewall logs as a datasource following its initial introduction in May.

Customers can consolidate flow records generation by using Azure Firewall as the primary source of flow information sent to Kentik. The ingest process is identical to the one used for NSG flow logs and requires customers to store records in their storage accounts.

Customers can filter traffic flows traveling through a particular firewall in the Data Explorer by using the “Logging Resource Category” and “Logging Resource Name” dimensions and then excluding NetworkSecurityGroupFlowEvent (NSG flow logs):

Note: Azure Firewall flow logs don’t have traffic throughput information, so users must choose flows/s as the metrics instead of bit/s. This will create a visualization similar to the graph shown above, and allow Kentik to see flows going through the firewall. With these metrics, customers can determine the relative load of the Azure Firewall and attribute flows to the firewalls.

For customers seeking traffic throughput information from Azure Firewall Logs, the Azure team has advised using “Fat Flows”. However, at the time of publishing this announcement, the Fat Flows feature is in preview and unavailable for API ingestion. Once it is fully supported in the API, Kentik will add “Fat Flows” support.