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.

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.

When an alert is raised, it can be sent via notification channels including Email, Slack, PagerDuty and more. We now embed the “Dashboard” and “Data Explorer” links that are associated with that alarm in the Alerting Email Notification as shown below.

This allows the user to quickly jump to the appropriate view and reduce problem resolution times, rather than manually pulling up the needed reports. Dashboard and view links will soon be integrated into other alerting channels as well.

Differentiated services or DiffServ is a simple and scalable mechanism for classifying and managing network traffic and providing quality of service (QoS) on IP networks. DiffServ can be used to ensure performance for applications that require low-latency such as voice or streaming media, while providing simple best-effort service to non-critical services such as web traffic or file transfers.

Kentik now supports two dimensions for QoS attributes, “ToS” and “DSCP”.

For complete IP and BGP Routing Dimension support information, please see the IP and BGP Routing Dimension reference topic in the Knowledge Base.

Labeling network traffic with application names provides a way to contextualize network insights with application and security and security metadata which is a huge value for Ops teams. Kentik now supports Custom Application labels as well as an “Application” Dimension to standardize support for application names and labeling.

Custom Applications

Custom Applications provide the ability for customers to define their own custom application names based on combinations of Protocol, Port, IP Address, and ASN. The “Custom Applications” configuration options are found in the Admin >> Enrich Your Data menu.

The example below shows how you can define Google Hangouts as an application using Protocol/Port Number/ASN matching criteria.

The “Application” Dimension

We’ve also added an “Application” dimension in the “Application Context & Security” Group:

In the example below, you can see application names associated with various traffic sources. Built-in application names include:

• Well-known service names
• OTT applications
• Cisco NBAR and other vendor-specific applications (e.g., Palo Alto FW APP ID, Silver Peak, Gigamon, and more coming soon)
• Custom Applications you’ve defined (as described above)

For more on Custom Applications and the Application Dimension, refer to the Custom Application topic in our Knowledge Base.