Kentik - Network Observability
Product Updates
More Product Updates

May/June 2019

It’s time to welcome the summer! As usual, let’s walk through all the exciting new features that the Kentik product team brought to the platform in May and June 2019.

As part of showcasing Kentik’s support for Cisco devices at the Cisco Live conference in June, we’ve added new integrations with Cisco NBAR, SDWAN vEdge, Meraki and Cisco IOS XR forwarding status.

In addition to the Cisco integration efforts, we also added a new RPKI dimension, support for adding Syslog as a data source and new Mbps per Unique Source/Destination IP metrics.

Cisco NBAR Integration

Network-Based Application Recognition (NBAR) is a feature in Cisco devices (including routers, firewalls, wireless controllers, etc.) that provides intelligent network traffic classification. It is a classification engine that can recognize a wide variety of applications, including web-based applications and client/server applications that dynamically assign TCP/UDP port numbers.

With Kentik’s Universal Data Records (UDR) architecture, we quickly developed new dimensions that are associated with NBAR including: Application name, Application category, Application subcategory, Application group, Application traffic class and Application business relevance. These Dimensions are available for NBAR-enabled devices:

That means if the flow source is from a Cisco NBAR-enabled product such as ISR or ASR routers, ASA firewall or wireless LAN controller, Kentik can ingest the NBAR-related fields from the flow record and show those as NBAR dimensions in the Kentik UI. Also, Kentik’s existing Application dimension will inherit the value from the Application Name field in the NBAR data.

This support allows Kentik customers to understand traffic consumption and distribution among the applications that are running.

Furthermore, Kentik’s alerting engine also fully supports these new NBAR dimensions. You can define an Alert Policy based on metrics for any NBAR dimension.

For more information, please see the About Applications topic in our Knowledge Base, or contact our Customer Success team.

Cisco SDWAN vEdge Netflow Template 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.

Cisco Meraki MX Netflow Template Support

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]( "Kentik KB: Cisco Meraki Metrics") topic in our Knowledge Base, or contact our [Customer Success team]( "Contact Customer Support").

Cisco IOS XR Forwarding Status Support

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.

RPKI Dimension

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 Validation StatusValue Description
RPKI UnknownNo Route Origin Authorization (ROA) has been found to associate with the routes being analyzed.
RPKI ValidThere is a valid Route Origin Authorization (ROA) found for that destination prefix, and the BGP announcements for it are announced by the correct, authorized ASN.
RPKI Invalid
  • Valid covering prefix
  • Unknown covering prefix
The validation state of the prefix is invalid, but there is a larger supernet or covering route that is RPKI Valid or RPKI Unknown that would be used to forward traffic to the destination prefix.
Prefix length out of boundsTraffic under this label will be dropped in case of strict route validation.
Incorrect Origin ASNThe preferred BGP route for a specific prefix isn’t originated by the ASN specified by the ROA.
Explicit ASN 0The RPKI standard allows statically defining prefixes that shouldn’t at all be trusted. A Route Origin Authorization (ROA) with ASN = 0 means that any traffic coming from that prefix and all the prefixes contained in it as per maxLength will be considered explicitly invalid.

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

RPKI Quick StatusCorresponding RPKI Validation StatusRoute Validation Behavior
RPKI UnknownRPKI UnknownWill be forwarded
RPKI ValidRPKI ValidWill be forwarded
RPKI Invalid - Covering Valid/Unknown
  • RPKI Invalid - Valid Covering Prefix
  • RPKI Invalid - Unknown Covering Prefix
Will be forwarded
RPKI Invalid - Will be dropped
  • RPKI Invalid - Prefix Length Out of Bounds
  • RPKI Invalid - Incorrect Origin ASN
  • RPKI Invalid - Explicit ASN 0
Will be dropped
Empty valueEmpty valueUndetermined behavior:
  • The prefix may be in a static route
  • The prefix may be a /32 or /31
  • No AS_Path info available

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.

Syslog Support

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.

New Metrics: Mbps per Unique Source/Destination IP

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.

Join the Kentik Slack Community
Be part of a community of Kentik users who can help you along the way.
Join Now
We use cookies to deliver our services.
By using our website, you agree to the use of cookies as described in our Privacy Policy.