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.
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.
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:
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.
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:
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).
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 Status||Value Description|
|RPKI Unknown||No Route Origin Authorization (ROA) has been found to associate with the routes being analyzed.|
|RPKI Valid||There 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.|
||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 bounds||Traffic under this label will be dropped in case of strict route validation.|
|Incorrect Origin ASN||The preferred BGP route for a specific prefix isn’t originated by the ASN specified by the ROA.|
|Explicit ASN 0||The 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 Status||Corresponding RPKI Validation Status||Route Validation Behavior|
|RPKI Unknown||RPKI Unknown||Will be forwarded|
|RPKI Valid||RPKI Valid||Will be forwarded|
|RPKI Invalid - Covering Valid/Unknown||Will be forwarded|
|RPKI Invalid - Will be dropped||Will be dropped|
|Empty value||Empty value||Undetermined behavior:|
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.
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.
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:
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.