The benefits of Universal Data Records aren’t limited just to troubleshooting and analytics. UDR also enables us to expand the range of conditions for which our alerting system can generate alarms and trigger mitigations.

As explained below, UDR dimensions and metrics are now supported when defining the data that will be evaluated by an alert policy, which is done in the Data Funneling pane of the Alert Policy dialog (Add or Edit).

• Dimensions: The key for a given policy (see About Keys) is set with the Dimensions selector. The selector now includes all of the dimensions that are supported via UDR, including dimensions for Cisco ASA, Palo Alto Networks firewalls, Silver Peak appliances, and Istio.

• Filters: UDR dimensions are now supported as well for the filters that are set with the Filters selector.

• Metrics: We now support UDR metrics, such as Initiator Bytes and Responder Bytes for Cisco ASA, when specifying primary and secondary metrics.

As you can see, UDR-enabled dimensions and metrics take Kentik to a new level in terms of being able to address the intricacies of your own particular network, and this capability is even more powerful now that it’s supported by our alerting system. For help with taking advantage of the device-specific dimensions made possible by UDR, please contact our Customer Success team.

A couple of months ago we announced our new Universal Data Records (UDR) architecture, which enables the Kentik Data Engine (our distributed big data backend) to flexibly allocate columns to the flow fields of diverse devices. We then announced three integrations based on UDR, one for Palo Alto Networks firewalls, one for Cisco Adaptive Security Appliances (ASA), and one for Istio service mesh (Beta). We’ve now added another new integration, this time for Silver Peak appliances running Virtual Acceleration Open Architecture (VXOA version 8.1.8 or higher).

These appliances analyze packets as traffic flows through, identify the application with which each packet is associated, and prioritize routing by applying application-specific rules. Our new integration will enable you to filter or group-by in Kentik Detect using the application names identified by Silver Peak and stored in KDE flow records.

If you have a Silver Peak appliance, here’s a quick look at how to use information from it in Kentik Detect:

• Step 1: From the Kentik portal’s Admin » Devices page, use the Add Device button at upper right to open the Add Device dialog, then add a new Silver Peak device. The Type field on the General tab should be set to Silver Peak VXOA.

• Step 2: In the Data Explorer sidebar, click in the Devices pane to open the Devices dialog (see Device Selector with Sidebar). In the Types list on the dialog’s sidebar, click Silver Peak VXOA to include the new device in the set of queried devices, then click Save to close the dialog.

• Step 3: Back in the main Data Explorer window, click Group by Dimensions in the sidebar’s Query pane to open the dimension selector. Now that a Silver Peak device is included in the selected devices, you’ll be able to choose a dimension from the Silver Peak VXOA section. To date the only available Silver Peak dimension is Application Name, which enables you to better understand the applications generating the traffic that flows through your Silver Peak appliances. Note that at this point this dimension would also be available for use in the Filtering pane.

• Step 4: The Application Name dimension can now be used in a query to correlate network traffic with specific applications. The sample Sankey diagram below, for example, shows traffic destined for applications such as Gmail, YouTube, and Splunk exiting via two Silver Peak devices (silverpeak_sf and silverpeak_hnl) to service providers Zayo and HNTEL.

For information or assistance with using Silver Peak dimensions, please contact our Customer Success team.

With Single Sign-On (SSO), a user can log in with a single ID and password to gain access to any of several related systems. It’s a convenient, centralized way to manage security and access control to applications. For the last couple of years we’ve supported SSO access to customer accounts on the main Kentik portal. Now we also allow Kentik customers to enable SSO for their My Kentik Portal tenants.

Customers who use this new feature will provision tenants on their existing SSO platform, so tenants will be authenticated at login using SSO instead of local user credentials. To configure tenant SSO, you’ll have to have an existing identity provider account or in-house identity management system (see SSO Config Prerequisites), and also be a Super Admin for your organization (see About Super Admin Users).

Tenant SSO is activated in the Kentik Detect portal on the Admin » My Kentik Portal page. At the bottom of the My Kentik Portal Settings pane (below the Save button) you’ll see the “info” notice shown below. Click the My Kentik Portal Single Sign-on Settings link.

In the resulting My Kentik Portal Single Sign-on page (shown below) fill in the fields as described in the KB topic Tenant SSO Settings.

For assistance with getting SSO correctly configured for your tenants (or your own organization), please contact our Customer Success team.

My Kentik™ Portal is a built-in feature of the Kentik platform that enables curated, self-service network traffic visibility for downstream customers (solution brief here). Because we’re strongly committed to supporting features not only through our portal but also via APIs, we’ve now introduced the My Kentik API.

Providing an initial set of four methods, the My Kentik API enables Kentik customers to programmatically manage settings for their My Kentik Portal tenants. Development work is ongoing to achieve full parity with the functionality that’s available in the Kentik portal via the My Kentik Portal page.

The following methods are available now, and can be tested with the V5 API Tester for our US and EU clusters:

• Tenant List (GET): Returns an array that contains information about all tenants
• Tenant Info (GET): Returns a tenant object containing information about an individual tenant
• Tenant User Create (POST): Creates a tenant user object and Returns information about that individual tenant user
• Tenant User Delete (DELETE): Deletes a tenant user from the system

For more information, please see the My Kentik API topic in the Kentik Knowledge Base or contact our Customer Success team.

Last month, we announced VRF Awareness Phase 1, including new dimensions associated with VRFs (virtual routing and forwarding). We’ve now added support for VRF attributes in the Interface methods of our Device API, which you can experiment with in our API tester (EU customers will find the tester here). The new parameters for these methods give you programmatic control of VRF attributes associated with each interface.

If SNMP polling is enabled in your Kentik instance, the VRF attributes of each interface would normally be discovered automatically as Kentik polls the VRF MIB (refer to our KB topic on Kentik-polled SNMP OIDs to see the OIDs we poll). But with VRF support in our Interface methods you can now programmatically define or redefine mappings (including RT/RD related data) between physical interfaces and the VRFs to which they belong. This could be particularly useful in the following situations:

• If your Kentik instance doesn’t use SNMP polling.
• If you have SNMP polling enabled on your device, but either:
  • Your device doesn’t support the VRF MIB.
  • The device SNMP policy doesn’t allow polling the VRF OIDs.
• If you want your VRFs to appear in Kentik Detect with names that are more human-readable than the names retrieved from SNMP.

The new parameters in the Interface methods of the Device API support both of the following cases:

• Interface creation: VRF parameters have been added to the Interface Create method.

• Interface updating: VRF parameters have also been added to the Interface Update method.

For additional information, please contact our Customer Success team.

Another data source we’ve recently integrated with KDE using Universal Data Records is Istio, which is an open source “service mesh” that integrates tightly with Kubernetes. You can learn more in our recent Kubernetes Networking 101 blog post, but basically, service meshes were invented to allow operations teams to deploy monitoring, security, failover, etc. in a cloud-native environment without developers needing to change their code. Istio’s insight and control layer lets you secure, connect, and manage the applications that make up a distributed microservices architecture for hybrid and multi-cloud deployments. It’s currently one of the most popular service mesh architectures, and it enjoys strong backing from Google, Lyft and IBM.

With Kentik’s new integration, you can now ingest Istio metrics data into KDE. That allows you to view the connectivities and status of components and services within an application in the context of the underlying network infrastructure that delivers them, even if the application is spread across multiple physical, hybrid, or multi-cloud infrastructures. If one component fails, you can now observe the impact on the big picture.

One fundamental component of the Istio control plane is called “Mixer.” This layer provides operators with rich insights and control over service behavior without requiring changes to service binaries. Kentik integrates with Istio via a backend plugin that acts as a data receiver for Mixer. While metrics from Mixer can be exported to a number of different tools, Kentik is the only solution that fuses Mixer metrics with flow data, which is key to understanding how the application and its supporting infrastructure affect each other.

The process for using Istio metrics in queries is pretty much the same as described above for Cisco ASA:

• Add an Istio device via the Admin » Devices page.
• Select an Istio device in the Devices pane of Data Explorer.
• Select an Istio metric as a filtering or group-by dimension as shown below.

Among the various ways that you can use the Istio dimensions is to build a Sankey diagram like the one below, which maps service-to-service flow between the microservices that are using Istio within an application.

Descriptions of the Istio fields supported by Kentik can be found in our Knowledge Base topic on Istio Dimensions. For more information about using Istio with Kentik Detect, contact our Customer Success team.

In January’s Product Update, we announced our new Universal Data Records architecture, which enables the Kentik Data Engine (our distributed big data backend) to flexibly allocate columns to the flow fields of diverse devices. Our first integration using this new approach was to support the ingest of flow data from Palo Alto Networks firewalls for enhanced operational and security intelligence.

In February we added another integration, this time with Cisco Adaptive Security Appliances (ASA). This latest implementation includes:

• Support for the full ASA NetFlow template in group-by and filtering dimensions, Dashboards, and Data Explorer.
• Support for ASA fields in Alert Policy filters.
• Support for ingest of ASA flows both directly and via our Netflow Proxy Agent (chfagent).

Now let’s take a look at the workflow involved in putting ASA data to use in Kentik Detect.

Step 1.

In the Add Device dialog (accessed via the Admin » Devices page), add an ASA as a new device. Make sure to set the Type control to Cisco Adaptive Security Appliance.

Step 2.

In Data Explorer, use the device selector (accessed via the Devices pane in the sidebar) to include the ASA in the set of queried devices.

Step 3.

After you add an ASA in the Devices pane you can open the dimension selector — either for group-by in the Query pane or for ad hoc filters in the Filtering pane — to see and choose ASA-specific dimensions. These dimensions will help you to understand significant events in a flow, and track flow state changes over time.

Putting these new ASA dimensions to work in Kentik Detect will help you to better understand aspects of your traffic — top denied countries, applications, IPs, paths and so on — that are key for robust infrastructure security. One way to take advantage of these dimensions is to build a security-focused dashboard like the one shown below.

You can also use ASA dimensions in the filters that you use for alert policies (see the Data Funneling topic in the KB), which means that you can generate alerts based on firewall events such as unexpected denied traffic.

For more information, please refer to the Kentik Knowledge Base topic on Cisco ASA Dimensions, or contact our Customer Success team.

Like Remote Trigger Blackhole (RTBH), Flowspec is a means of using BGP to respond defensively to a DDoS attack. But while RTBH is a blunt instrument, dropping all traffic toward the victim's IP address, Flowspec lets you respond to attacks with surgical precision. It offers a greater range of possible mitigation actions and it’s also far more granular in terms of defining which traffic is affected by those actions.

Based on IETF RFC 5575, Flowspec works by distributing a “flow specification” that can be read by any routing system that supports MP-BGP. The Flowspec defines a filter for matching traffic based on certain packet properties (IP, ports, protocol, etc.) as well as an extended community value that specifies actions to take on matching packets (drop, forward, rate-limit, etc.).

Kentik’s support for Flowspec-based DDoS mitigation is integrated directly into our powerful anomaly detection and alerting system, enabling our customers to leverage the built-in traffic filtering capabilities of their existing network hardware. For our initial “preview” phase of Flowspec support, the following Flowspec capabilities are now implemented in Kentik Detect:

• Manual Flowspec mitigation
• Flowspec mitigation from alarms
• Programmable Flowspec mitigation via “Infer From Alarm”

Flowspec Setup

The workflow for Flowspec setup is detailed in our Knowledge Base topic on Configuring Flowspec Mitigation, but here’s an overview of the process:

• Configure devices for Flowspec
• Enable Flowspec in Kentik device admin
• Create a Flowspec mitigation method
• Specify Flowspec conditions and actions
• Create a Flowspec mitigation platform
• Link the method to the platform

Once we’ve created a Flowspec we can use it in a couple of different ways. The most common application would be to deploy an automated Flowspec mitigation, which means that we assign the mitigation to a threshold in an alert policy (as shown above), so the mitigation is triggered when the threshold’s conditions are met. Alternatively, you can deploy the Flowspec mitigation manually as described in Start a Manual Mitigation.

For more information, please see our blog post Kentik Takes a Leap Forward in DDoS Defense and the Flowspec Mitigation Knowledge Base topic. To discuss the benefits of Flowspec, or to enable Flowspec support for your organization, please contact the team at Kentik Customer Success.

Kentik Data Engine (KDE) ingests and enriches flow records from routers, switches, and firewalls, as well as flow logs from cloud providers. This unaggregated data on individual flows is the basis for our comprehensive analytics functionality, including charts, graphs, tables, and dashboards. While those views are extremely useful, we’ve also given customers the option to directly view, filter, and export the raw underlying data in the Raw Flow Viewer (Analytics » Raw Flow; see the Raw Flow article in our Knowledge Base). We’ve now extended this functionality with Raw Flow Views for dashboard panels.

A Raw Flow View allows raw flow output to be embedded into a dashboard. Panels based on Raw Flow Views can inherit the devices, filters, and time range specified for the dashboard on which they live. Such panels are particularly useful on dashboards that are linked to Kentik alert policies, providing more traffic detail when investigating an alarm.

You can add a raw flow panel to a dashboard with a few easy steps:

1. Create or Edit a dashboard. When you click the Edit Mode button, you’ll see Raw Flow View as one of the options available in the Add A Dashboard Panel pane.

2. Click the Add button in the Raw Flow View card, which will open a configuration window where you can customize your query and get a preview of raw flows.

3. Click the Add Dashboard Panel button to add the panel to the dashboard.

For further information about the Raw Flow View, please contact our Customer Success team.

Virtual routing and forwarding (VRF) is a technology that allows multiple routing table instances to co-exist within the same router at the same time. Because Internet service providers (ISPs) often take advantage of VRFs to create separate virtual private networks (VPNs) for customers, the technology is also referred to as VPN routing and forwarding. With VRF support in Kentik Detect, you no longer need to manually map interface names and descriptions to VRF names and IDs (which are hard to read, troubleshoot, and support). Instead, flow data is enriched with VRF identifiers as it’s ingested into the KDE, enabling the use of VRF attributes to filter or segment network traffic in your Kentik queries.

The first phase of our VRF implementation includes support for Cisco L3VPN, Cisco VRF-lite, and Juniper L3VPN. As shown in the screenshot below, there are eight new dimensions associated with VRF support: source and destination VRF Name, VRF Route Distinguisher, VRF Route Target, and VRF Extended Route Distinguisher.

Our new VRF functionality enables multiple use cases:

• An enterprise network can verify that VRF-lite network partitions are functioning correctly (e.g. to ensure there is no traffic leaking).
• An infrastructure/network planner can see inbound or outbound traffic at the Provider Edge (PE) segmented by VRFs.
• A network operator can see all traffic associated with a specific Route Distinguisher (RD) or verify the names of the VRFs that are associated with a specific RD.
• A network operator can get alerts for changes (e.g. increase/decrease) in traffic volume per customer using VRF IDs to distinguish customers at the PE

The screenshot below shows a Sankey graph and table with all of the details about how VRFs map to interfaces on network devices. With this view, network teams can accelerate troubleshooting and easily answer questions about how traffic maps to VRFs.

As shown below, the new VRF dimensions are also supported in Alert Policies.

As we extend our VRF capabilities going forward we’ll be able to provide an even richer set of insights for analytics and visibility, including deeper integration with per-VRF BGP routing data and Kentik’s existing Ultimate Exit feature. For more information, please see the listing of VRF dimensions in our Knowledge Base, or contact our Customer Success team.