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

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

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

Only Kentik administrators are able to access Monitoring Templates. 

Key Workflows

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

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

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

Settings Page:

From the Monitoring Templates settings page, Kentik administrators can:

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

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

The Template Itself:

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

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

Advanced Measurement Selection:

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

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

Feature Requests & Bugs

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

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

New Device Workflows

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

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

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

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

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

New Alerting Workflows

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

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

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

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

Quality Enhancements

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

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

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

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

This may be a minor, but a widely requested improvement on the device screen: all SNMP community and SNMPv3 passphrases are now obfuscated in the UI.

This complies with widespread company policies to never display passwords in a web UI.

See screenshot below

Kentik now supports SNMP collection of the CPU and Memory utilization for F5 BIG-IP devices. Some of the F5 BIG-IP devices do not support flow export features, which means that the collection of the SNMP metrics would require use of Kentik's kproxy with the “bootstrap_devices” option.

The general behavior of the Kentik’s SaaS ingest or Kentik’s Kproxy is that the SNMP metrics collection would only start once the flows are received from the certain device. This behavior can be limiting in some cases and can be changed by the use of the Kproxy’s Bootstrap devices feature. This feature is enable with the use of the-bootstrap_devices command line argument. This argument should provide the comma-separated list of devices’ IDs. For those devices, the Kproxy will start the SNMP metrics collection immediately, without waiting to receive devices’ flows. More information about the Kproxy CLI arguments can be found in our Knowledge Base article: https://kb.kentik.com/v0/Bd04.htm#Bd04-kproxy_CLI_Reference

The Kentik’s Kproxy will determine that the discovered device is F5 BIG-IP by looking for the “big-ip” string in the well-known SNMP sysDescr OID.

The Kproxy would monitor the following 4 Device “Components”, with the use of the SNMP OIDs described below:

• Name “Global”:
  • MemoryTotal [bytes] - OID Name: sysGlobalHostMemTotal, OID: .1.3.6.1.4.1.3375.2.1.1.2.20.2.0
  • MemoryUsed [bytes] - OID Name: sysGlobalHostMemUsed, OID: .1.3.6.1.4.1.3375.2.1.1.2.20.3.0
  • CPU [percentage] - OID Name: sysGlobalHostCpuUsageRatio5m, OID: .1.3.6.1.4.1.3375.2.1.1.2.20.37.0
• Name “TMM”:
  • MemoryTotal [bytes]- OID Name: sysStatMemoryTotal, OID: .1.3.6.1.4.1.3375.2.1.1.2.1.44.0
  • MemoryUsed [bytes] - OID Name: sysStatMemoryUsed, OID: .1.3.6.1.4.1.3375.2.1.1.2.1.45.0
  • CPU - value will be 0
• Name “Other”:
  • MemoryTotal [bytes] - OID Name: sysGlobalHostOtherMemoryTotal, OID: .1.3.6.1.4.1.3375.2.1.1.2.20.44.0
  • MemoryUsed [bytes] - OID Name: sysGlobalHostOtherMemoryUsed, OID: .1.3.6.1.4.1.3375.2.1.1.2.20.45.0
  • CPU - value will be 0
• Name “Swap”:
  • MemoryTotal [bytes]- OID Name: sysGlobalHostSwapTotal, OID: .1.3.6.1.4.1.3375.2.1.1.2.20.46.0
  • MemoryUsed [bytes] - OID Name: sysGlobalHostSwapUsed, OID: .1.3.6.1.4.1.3375.2.1.1.2.20.47.0
  • CPU - value will be 0

For each component  MemoryFree and MemoryUtilization are calculated from collected MemoryTotal and MemoryUsed metrics. Each component use standard Uptime which is collected at the device level from sysUpTime OID.

The support is available in kproxy starting from version v7.36.0. The example of the Data Explorer query is shown below:

The list of supported devices from which Kentik can collect CPU and Memory utilization is growing. Kentik now supports SNMP collection of the CPU and Memory utilization for Palo Alto Network devices. 

Palo Alto devices are using the standard HOST-RESOURCES-MIB, for CPU and Memory usage. The Kentik’s ingest/kproxy will determine that the discovered device is from Palo Alto by looking for the “palo alto” string in the well-known SNMP sysDescr OID.

For CPU:

• Component name is provided in the OID: hrDeviceDescr: .1.3.6.1.2.1.25.3.2.1.3.index
• CPU utilization is provided in the OID: hrProcessorLoad: .1.3.6.1.2.1.25.3.3.1.2.index

For Memory:

• Component name is provided in the OID: hrDeviceDescr: .1.3.6.1.2.1.25.3.2.1.3.index
• Memory utilization is provided from the SNMP table: hrStorageTable: .1.3.6.1.2.1.25.2.3

The support is available in kproxy starting from version v7.36.0. The example of the Data Explorer query is shown below: