At Kentik, we believe that the future is insights and automation to empower humans—not replace them.

Kentik V4 focuses on proactive insights—both system-driven and custom user-defined, as well as interactive insights driven by humans. The new Quick Views offer convenient, built-in interactive visualizations for fast access to the most-used views. Custom Views & Data Explorer allow users to answer more sophisticated, interactive questions about the network—instantly—and at the full resolution as the data is collected.

V4 also makes managing networks significantly easier by adding use-case-specific workflows. This dramatically improves the learning curve for onboarding new networks, devices, and capabilities. We’ve reduced the time from signup to get real, useful insights from Kentik.

This new interface is much more than a new look with an overhauled UI, but also a transformation in how Kentik provides proactive advice and advanced troubleshooting capabilities. This change represents the beginning of Kentik’s transformation from a network monitoring product to an AIOps platform, turning your data into actionable insights.

Kentik V4 Highlights

Kentik V4 is built around a brand new AIOps Engine, that was designed to surface relevant, actionable and interesting events around your network traffic, health, security, and applications. This system empowers operators to efficiently identify, troubleshoot and resolve real issues on their networks- fast.

With V4, we took note of our customers’ feedback to design and build workflows that make time-consuming and repetitive tasks easy. We are kicking this effort off with the launch of two new modules:

• The Connectivity Costs module helps network operators keep track of their current and historical bandwidth costs- helping network operators gain visibility into their costliest applications, sites, and customers.
• We’ve also released our new Traffic Engineering module, which makes easy work of finding complex traffic groups when performing traffic engineering tasks.

We’ve also developed an innovative way for users to interact with their network data. V4’s new Quick Views module was designed from the ground up to present users with their infrastructure data elegantly and intuitively. While the beloved Data Explorer lives on for those that wish to limitlessly spelunk into flows, our new Quick Views module promises to deliver the same precision and flexibility you’ve come to expect from us, but without requiring expert-level knowledge of the Data Explorer.

Kentik V4 UI Design Overview

Your new Kentik landing page is shown in the screenshot below. There are 3 panels (left, middle, right) that serve different purposes:

• The Sidebar Navigation on the left is a menu to navigate around the portal.
• The Main Panel is a content display, with content related to the which menu item you click on.
• The Insights Sidebar on the right is one of the highlights of Kentik V4. It automatically notifies users of interesting or anomalous network conditions or traffic behaviors based on the patterns surfaced by our new Insights Engine.

Here are a few quick peeks to the New Kentik UI. Note that all aspects of the UI shown here are subject to change as the product evolves.

V4 Menu Walkthrough:

V4 Connectivity Costs Module:

V4 Network Map Module:

Conclusion and What’s Next

Kentik V4 is designed to guide users to discover hidden conditions in the network that would be very difficult for operators to find within with a huge volume of diverse network data streams—across both traditional and cloud infrastructure . With the Kentik V4 AIOps platform, customers can accelerate the network team’s efficiency, automate issue resolution, and create new business capabilities using these instant insights.

Kentik’s AIOps platform is available for early access to existing customers and will be GA in later 2019 with more comprehensive support for more use cases and functions, such as Capacity Planning, Container Networking Visibility, Subscriber intelligence, MyKentik Portal and much more.

For more information, please see the Knowledge Base V4 or contact our Customer Success team to get access to the preview.

Multi-Protocol Label Switching (MPLS), sometimes classified as a Layer 2.5 networking protocol, reduces router load by using packet labeling to avoid IP routing lookups. MPLS is known for providing benefits such as scalability, performance, better bandwidth utilization, reduced network congestion, and a better end-user experience. It’s been heavily used for implementing traffic engineering, segmenting multi-service networks as well as improving network resiliency via MPLS Fast Reroute.

With support for MPLS flow templates, Kentik can now collect and visualize label values applied to traffic coming in/out of interfaces. This gives operators greatly needed visibility to monitor or troubleshoot MPLS traffic by filtering or segmenting traffic based on labels.

The secret sauce enabling this capability is Kentik’s Universal Data Records, which allow us to rapidly add new data sources and data dimensions to the Kentik platform and address our customers’ ever-evolving network visibility challenges. Read our recent blog post for more background on Universal Data Records.

For Phase 1 of MPLS, we support MPLS flow templates in different flavors including Cisco and Juniper, with full support for policies and alerting.

See the table below for details of the newly-added MPLS dimensions:

The following Sankey diagram depicts an overview of the MPLS traffic flowing end-to-end within an example network, including values for MPLS attributes of the traffic.

For more information on MPLS Template Support, please contact our Customer Success team.

While we are embracing cutting-edge technologies such as Streaming Telemetry, our core focus has always stayed on solving our customers’ problems.

SNMP is still a widely-used protocol in network operations for managing and monitoring network devices and their functions. Now, with Kentik’s first phase of SNMP support, our customers can observe many more aspects of network devices than before: discovering devices on the network based on IP ranges or subnet, collecting information such as network devices’ OS, version, name, management IP, interface metadata, VRF settings, processors and much more.

With this additional visibility, Kentik makes it easier for operations teams to get a comprehensive picture of the devices in their infrastructure. These features support many use cases including capacity & utilization planning, and more efficient network troubleshooting.

As a network engineer, there are many problems that can be solved with detailed SNMP visibility, including:

• You can see SNMP base interface stats per interface and other Interface Classification dimensions
• You can visualize the capacity of an interface over time
• You can aggregate capacities from all backbone logical interfaces.
• You can a__ggregate the inbound and outbound utilization__ of an interface or group of interfaces

Phase 1 primarily supports a basic set of SNMP metrics such as Interface metrics, which are very similar to the list mentioned above in Streaming Telemetry. Available interface metrics include: Input Bit Rate, Input Packets, Out Bit Rate, Input Errors, Output Errors, Input Discards, Output Discards, Input Multicast Packets, Output Multicast Packets, Input Broadcast Packets, and Output Broadcast Packets. See screenshot below:

We offer a 5-minute resolution on standard polling in this initial release. In the future, we’ll support more polling rates based on the use cases and requests we see from customers.

Collecting SNMP data from the Kentik platform is flexible. Kentik can directly poll your devices from our SaaS platform, or you can use the latest kproxy agent running on any local host to act as an SNMP polling proxy.

In subsequent phases, we will support an ever-increasing part of the SNMP OID tree including full interface metrics and interface metadata. We’ll also provide full alerting capability over SNMP data.

For more information, please see the SNMP OID Polling topic in our Knowledge Base, or contact our Customer Success team.

Streaming Telemetry is not a new term anymore, yet adoption is still in very early stages. In short, it is a technology that provides a new approach for collecting network device metrics in which data is streamed from the devices continuously, as opposed to periodic polling like SNMP. Streaming telemetry is a more scalable and flexible way of exposing metrics from your infrastructure.

Our recent blog post on the subject explains what Streaming Telemetry is, discusses how to maximize the value of it, and shares Kentik’s vision of leveraging this new technology.

We believe that Streaming Telemetry can improve efficiency for network operators in use cases like detecting problems, troubleshooting issues, planning for networking capacity and much more.

Kentik ingests streaming telemetry data at scale, the same way we handle other types of data we ingest like NetFlow. Then with enrichment and machine learning, we surface potential problems, using both built-in and custom user-defined detection methods. We help network teams swiftly and accurately respond to incidents, proactively recognize and prevent issues from impacting service and business, and allow them to focus on optimization rather than firefighting.

The first phase of Kentik’s support for streaming telemetry, offers:

• Direct collection of telemetry data
• Interface classification support
• Juniper “gNMI” JTI with UI support
• Interface metrics with including metrics: Input/Output Unicast/Multicast/Broadcast BitRate/Packets/Errors/Discards (see screenshot below)

As an example, we can now use streaming telemetry data to view statistics and visualizations of network ingress and egress traffic, via which interfaces, with connectivity types and so on.

In subsequent phases, we will support more vendors (e.g., Cisco Dial-Out for ASR), add full interface metrics, provide more sample interval options, provide full alerting on metrics and state changes, and much more.

Please contact our Customer Success team if you want to get a preview of this early version of Streaming Telemetry support.

Kentik has always supported metric options to count unique source and destination IPs in each row of a query response. We’ve now added a new metric that shows the average bit rate (Mbps) per unique IP. This metric is particularly useful to examine if and when an issue is arising. Here are a couple of examples:

• Find the Average Mbps per Destination towards subscribers in a specific last mile aggregate of their traffic. The aggregate can be easily described in a Custom Dimension matching traffic based on a set of CMTS or DSLAM local loop aggregators, or even more simply just a Site.
• To look at traffic towards subscribers for a given Internet Access Plan. The Plan aggregation level can also be a Custom Dimension based on CIDRs. In this case, users are assigned to specific CIDRs in the IPAM based on their plan.

This “Bitrate Per IP” can be found in the Data Explorer under both “Source IPs” and “Destination IPs”:

This feature works best when paired with Kentik’s ability to detect Over The Top (OTT) services, to display Average/Max/95-99p of the Bitrate for each individual OTT service. For video-based OTT services, we now have a scalable way to calculate Average Bitrate across subscriber sets. As a result, ISPs are now able to track subscriber experience for important content sources.

Let’s look at an example content provider (OTT Service) that has their own CDN and also embeds caches within the ISP network. We’ll compare performance (Mbps per subscriber) for traffic sourced from On-Net Caches vs the OTT service’s CDN.

First, we use filters to set these criteria:

Second, we’ll use a Filter-Based Dimension to compare two time series: Traffic from embedded local caches vs Traffic served from the Content Provider’s own Network and off-net caches (i.e., long-tail content):

Lastly, we’ll select the new “95th Bitrate by Destination IP” metric:

The resulting chart below clearly confirms the assumption that the video traffic coming from On-Net Embedded Caching Servers has a higher Bitrate than the long tail traffic coming from Off-Net Caching Servers in Content Provider’s CDN.

For more information, please contact our Customer Success team.

Why Syslog? Syslogs that are generated by network devices (e.g., switches/routers, firewalls, SD-WAN appliances, etc.) are essential data about the traffic, including applications, SSIDs, overlay information and so on. It’s something beyond what Netflow delivers. It’s especially important to analyze for people who handle security-related operations.

Kentik is a platform that ingests a large volume of data from diverse data sources. Flow is just one of them, and we keep adding additional data types for enrichment and correlation. Syslog is on the list and we just finished Phase 1 support, including:

Cisco ASA Firewall Syslog (Flow ID, Message, Severity, Message ID)

Juniper Routers’ Packet Forwarding Engine (PFE) Syslog (Message, Subtype, Interface, Event)

General Syslog (chfAgent) chfAgent is Kentik’s Netflow proxy agent, to enable encrypted transport of flow from users’ organizations’ network devices to the Kentik Platform. Now via the same chfAgent, you can ingest general Syslog data as well. Note that it’s a beta feature and the Kentik team is happy to work with you to gain value from this for your business.

For more information, please see the Cisco ASA Syslog Dimensions, Juniper PFE Syslog Dimensions and chfagent Syslog Parsing topics in our Knowledge Base, or contact our Customer Success team.

BGP is the routing protocol that makes the internet work—it is the language spoken by routers on the Internet to determine how packets can be sent from one router to another to reach their final destination.

However, route leaks and hijacks happen semi-frequently and usually result in part of the internet being unreachable.

An improved routing security mechanism is needed to make the Internet routing world safer. Enter RPKI…

Resource Public Key Infrastructure (RPKI), defined by RFC6480, is a cryptographic method that was designed to sign BGP route prefix announcements with the originating AS number. One way to think about what RPKI: RPKI is to BGP is what DNSSEC is to DNS. It offers a way to validate the origination of BGP prefixes against an official, signed list of prefixes by origin ASN.

Kentik has now integrated RPKI support via new dimensions, to allow users to precisely determine what would happen to the existing network traffic if they were to turn on RPKI validation on their networking equipment.

More details about these dimensions:

RPKI Validation Status: Contains the full RPKI state for a given flow, including the values shown in the table below:

RPKI Quick Status: Tells how traffic is going to behave globally by aggregating the RPKI validation Statuses. See the table below:

Furthermore, using RPKI dimensions with multiple other dimensions can provide a very detailed picture of potentially invalid or malicious traffic, to help network operators make informed decisions about turning on/off RPKI Route Validation selectively. For example, you can cross check with connectivity types, such as PNIs, IX peerings, transit and so on; or cross check with Routers and Sites; or cross check with end customers’ IDs.

For more information, please see our blog post with an introduction to RPKI, our blog post with a technical walkthrough of how RPKI features can be used in Kentik, and the BGP Dimension Reference in our Knowledge Base and look for “RPKI”, or contact our Customer Success team.

Lastly, stay tuned for more news concerning chfAgent as it now embeds both an RPKI validator and an RTR-speaking server, that can be leveraged by routers to perform route validation based on the aggregated global list of ROAs.

Forwarding Status refers to the action that a router or network device took on a flow or packet stream. Certain devices (including Cisco IOS XR) include a field that indicates which action was taken, such as ACL deny, dropped due to policers on the system, unroutable traffic, or Weighted Random Early Detection (WRED), which can illustrate when congestion issues have caused traffic drops on certain interfaces.

Kentik now supports this “Forwarding Status” field in IPFIX flows for Cisco IOS XR devices, which means that the 6-bit forwarding status code of the flow is now one of the traffic attributes that the Kentik Platform ingests (see table below).

For more information, please see the IOS XR Dimensions topic in our Knowledge Base, or contact our Customer Success team.

Cisco Meraki MX series is a security & SD-WAN appliance-based product line for distributed sites, campuses or datacenter VPN concentration. It offers capabilities such as SD-WAN, application-based firewalling, content filtering, web search filtering, intrusion detection and prevention, web caching, 4G cellular failover and so on. It aims to maximize network resiliency and bandwidth efficiency in this era of WAN traffic explosion.

For the first phase of Meraki integration, we leveraged the Universal Data Records (UDR) architecture (which we previously used for integrating with Cisco ASA Firewall, Palo Alto Networks Firewalls, Silver Peak and various security and SD-WAN appliances) to support the Meraki MX Netflow Template, so we can ingest Meraki-specific flow fields into Kentik. New capabilities include:

• Dimension - Source IP/CIDR: Initiator of the conversation
• Dimension - Destination IP/CIDR: Responder in the conversation
• Metrics - Out Bytes: Number of bytes leaving the MX for this flow
• Metrics - Out Packets: Number of packets leaving MX for this flow

With this kind of visibility, you can now analyze who is initiating conversations __to and from__ various parts of your network. For example: - Internal resources in a corporate network should not usually get connections originating from the internet, and/or - Resources in your DMZ should not usually initiate conversations to the internet

For more information, please see the [Cisco Meraki Metrics](https://kb.kentik.com/Da06.htm#Da06-Cisco_Meraki_Metrics "Kentik KB: Cisco Meraki Metrics") topic in our Knowledge Base, or contact our [Customer Success team](mailto:support@kentik.com "Contact Customer Support").

SD-WAN is no longer an unfamiliar term — it aims to solve the challenges of an unprecedented explosion of WAN traffic that cloud adoption brings, specifically management complexity, unpredictable application performance, and data vulnerability.

Cisco offers a solution to fulfill these SD-WAN promises including cost reduction via transport independence across the Internet, MPLS, or 4G LTE; improvement of business application performance and increased agility; optimization of user experience and efficiency, and lastly, to simplify operations with automation and cloud-based management.

However, SD-WAN technology does not usually provide the comprehensive visibility that’s needed to see the entire infrastructure, with both underlay and overlay context. Kentik, with first-class support for getting visibility into the data center, edge, cloud environments, as well as DDoS protection capability, naturally fits this role.

In the following example, we have branches and data centers connected via an SD-WAN Fabric through vEdge, and we’ll use VPNs to separate the traffic of different business teams.

With support for the vEdge NetFlow template, Kentik can easily map out real-time traffic for both the underlay and overlay networks of the SDWAN infrastructure and the applications that are carried on it.

The following Sankey diagram shows the details of the overlay traffic that flows out of Branch 1 of the SD-WAN environment.

We can tell that:

1. The branch1 traffic is configured in vpn10,
2. It carries application traffic including voice, browser, ping, etc.
3. The traffic exits through both Internet and MPLS transport
4. The traffic enters the 2 Data Centers as well as Branch 2

Now if we examine the voice traffic we find that it flows through both Internet and MPLS connections. This could represent a potential misconfiguration, assuming that voice traffic is supposed to traverse the MPLS transport only.

We are not stopping here! Going forward, we have more work to do on the vManage API integration for tighter Cisco SDWAN visibility support.

For more information, please see the Cisco SDWAN vEdge Dimensions topic in our Knowledge Base, or contact our Customer Success team.