Kentik - Network Observability
Product Updates
More Product Updates

February 2019

The Kentik engineering team had another busy month in February, pushing on multiple fronts to help solve our customers’ most challenging problems. We expanded our DDoS mitigation capabilities by adding built-in support for BGP Flowspec. We grew the range of devices from which we can ingest flow data by adding support for the Cisco Adaptive Security Appliance (ASA) and Istio metrics (currently in Beta). And we added VRF attributes to our interface API. Now let’s take a more detailed look…

Mitigation with BGP Flowspec

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 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.

Cisco ASA Integration

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:

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.

Istio Support (Beta)

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.

VRF Attributes in the Device API

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:

For additional 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.