Kentik has released a new Alerts reporting feature that lets you choose the type of Alerts (including DDoS) that you are interested in, along with the retention period (up to 90 days) and then either export this data or choose to schedule and subscribe to this report. 

This is version 1 of reporting for Alerts. This feature was suggested by our customers and provides initial reporting functionality around alerts. We plan to enhance this in future releases with more types of data, visualizations and analytics.

Example: I want to create a report of all my DDoS alerts (attacks) grouped by policies for the last 30 days.

Start by using the filter to apply the alert types, the retention period, summarization, grouping, etc. This is the main configuration of the report. Whatever you see here in the view is how the report will be created and viewed.

Then under the "Actions" drop-down in the upper right corner of the portal UI, you can choose to export this data directly or choose to set up a subscription to create a new report, say Monthly, and deliver it by email.

Fill out all of the desired subscription information and click "Subscribe"

We are happy to announce a new Health Map by Site Alerts Widget that can be configured and viewed from within the Kentik Observation Deck Dashboard. This is the first of many new widgets planned to be developed to give the Enterprise a tailored view of your networks and Infrastructure  

This new widget supports customers needing a type of NOC (Network Operations Center) view and status (Health) of their current locations based on Kentik Alerts. The User can then react quickly and take action on their most critical alerts.

Clicking on a site either in the map or the table will drill down into that specific location and display all the current alerts based on the filter settings. 

To see a brief setup video click on the link below and follow the guide in the video.

This quarter we started working on supporting the OCI cloud.

The first iteration of the work will include the cloud map showing all the basic OCI cloud networking objects, such as regions, VCN (OCI equivalent of VPC), Subnets, On-prem assets, and VPN links. 

Kentik is happy to announce new support for AWS Transit Gateway (TGW) flow logs.

Many customers prefer to rely on TGW flow logs instead of VPC flow logs as the primary source of traffic information about their AWS environments.

A Transit Gateway typically interconnects different VPCs and other gateways (Direct Connect, VPNs, etc.) In this case, the TGW sits at a central point of a customer’s AWS network, observing all the traffic passing through, and can serve as a single flow log generation point. For many customers, that should reduce the cost of flow log generation, and allow for analysis and detection of performance-impacting issues that span multiple environments.

Previous Kentik Cloud releases required customers to enable flow logs at the VPC level for every monitored VPC. That often led to duplication of flow data, as one flow can be observed across many VPCs, generating the same flow record in each. Since AWS charges customers for the volume of the flow records generated, this added unnecessary cost.

Some VPCs may still require enablement of flow log generation at the VPC level to see traffic that may not go through the TGW; for example, when VPC-to-VPC peering is configured, or when Direct Connect or VPN terminates inside the VPC rather than a TGW.

Please contact your CSE or account team with any questions you have.

We are happy to announce that the Azure Express route is supported for your Data Explorer queries. 

With the help of new dimensions such as ExpressRoute Circuit name, ExpressRoute Peering Type, as well as Gateway Type, which will support Express Route Gateways as a value, you will be able to use Data Explorer and filter out traffic flows that are going through the particular Express Route Circuit.

This feature will be handy not just in troubleshooting when something doesn’t work but also for:

• Cost attribution: ”Which instances consume this Express Route most?” 
• Monitoring: ”Which applications are impacted by Express Route outage?”
• Capacity planning: "What is the current Express Route load?"

Currently, we support standalone Express Routes that are terminated in VNET. Support for Express Routes terminated on vWAN Hubs is coming soon!

We are excited to announce Version 1.0 of Kentik Map for GCP, which provides an analogous experience to the AWS and Azure maps in Cloud.

While the concept is largely the same, there are some differences in the GCP map organization compared to our AWS and Azure maps based on the way resources are organized in GCP.

For example, in contrast to the AWS topology map, which groups VPCs by region, the GCP map groups regions by VPC. Each region has its subnets listed beneath it.

The searchable GCP map displays traffic and routing data for the resources shown. We enable support for historical views back into your topology and metadata in GCP.

Visualizations from the GCP map include:

• VPN gateways with associated on-prem and cloud routers, networks, regions, subnets, interconnect attachments, and VM interfaces
• Static link paths for on-prem routers and external VPN gateways
• Traffic links generated from subnets and internet types
• Aggregated regional traffic classified as inbound, outbound, or internal

In the coming months, we will continue building GCP observability to achieve parity with our AWS and Azure offerings, adding functionality such as security group support. 

Our platform aims to provide customers full support for all clouds with a consistent user experience. Kentik Cloud abstracts away the differences in cloud network interfaces to maintain cohesive multi-cloud workflows in the Kentik Portal.

Setup instructions for the GCP Map are here in our Knowledge Base.

Users can now:

• Export their Alert data in .csv format
• Configure whether to put all available columns in their export or only those that they have configured to show in the admin table (integration is seamless)
• Configure whether to export only the amount of data that they have currently loaded in the ui OR to export a fixed number of rows (up to the first 2000 rows)

Screenshots

While Kentik does a great job of showing any network where their traffic goes or comes from, one outcome remains unsolved: determining where and how to interconnect with any candidate network once traffic warrants it.
Until now, this was accomplished by referencing an outside data set, namely PeeringDB.

PeeringDB is a non-profit organization providing a platform for networks to declare their footprint, as well as the conditions under which they evaluate peering requests from other networks. Since the early 2000s, this platform has been widely adopted by the peering community and is recognized as one of the inevitable tools at the core of any Strategic Peering planning activity.
The service it provides is considered by most a public utility and Kentik wants to honor the relentless efforts they've invested in keeping this community platform up and evolving it throughout the years.

Roping in the dataset from PeeringDB into Kentik, contextualizing it with traffic data and leveraging it to streamline the entire strategic decision process of peering is the goal we aim to achieve with this integration.

What is PeeringDB, and how is it used?

How is it useful?

Each network is identified by its unique ASN in PeeringDB, and its records contain:

• The policy they follow to evaluate peering requests (traffic constraints a network needs to fulfill to be eligible to peer with them)
• The list of Internet Exchanges they are present at
• The list of Facilities (data centers) they are present and if they are willing to peer

To interconnect, networks need to ensure they check all the policy boxes listed by the target network but also decide on a common footprint to physically connect at - think of it as an address book or yellow pages of peering. 

PeeringDB shortcomings

Traffic Analysis to Footprint evaluation is a siloed, noncontinuous path

Every network has its own traffic analysis system (Kentik being one of the more modern and prominent ones). Network Telemetry (Netflow, SFlow, IPFIX) is used to determine the list of ASNs where it makes strategic sense to interconnect with, as well as the IN:OUT traffic ratios shared with these networks. PeeringDB doesn’t have this data for their registered networks, but Kentik customers have it in the portal. This means the path from Flow Telemetry to Peering metadata isn’t continuous: users switch context from their flow tool to PeeringDB.

PeeringDB isn’t tailored to display common footprint easily

Once traffic profiling TO and FROM a network indicates a target for peering, the next step is to evaluate the common footprint. While PeeringDB makes it easy to browse the details of footprint or policy for any given registered network, computing the common overlap of IXes and Data Centers still requires the user to have their full network map in mind.

Kentik’s PeeringDB integration

In a nutshell

This extension to the ASN quick-view page makes these frequent tasks easier:

• Evaluate the details of TO and FROM traffic of any ASN towards yours, including traffic mix and volumes, as well as ratios, and evaluate them against the other network's policy
• Evaluate the common footprint overlap between your network and this ASN
• Support strategic planners in the decision to deploy at certain Data Centers or IXes
• Identify the NOC and Peering contacts for this Network when available

Configuring the integration

Using the PeeringDB integration starts with users configuring it (in the “Integrations” section) of Kentik Portal. Two options exist: the Kentik user network is either already a PeeringDB registered member or isn’t.

1. If it is, Kentik will help users create mappings between their PeeringDB “Facilities” (Data Centers) and “Exchanges” (IXes), as already configured by the users as “Sites”, and as “Connectivity Type == IX”.
   
   
2. If the Kentik user network is not already a PeeringDB user, it will let them do the reverse: link their “Sites” and “Connectivity Type == IX” to existing PeeringDB “Facilities” and “Exchanges” based on address and name matching. This can be done via both the "Settings > Manage Interfaces" and "Settings > Manage Sites" screens.

Leveraging the integration

Once the integration is configured, Kentik’s engine has a key to decipher any network’s footprint with a common language. It will display it in a human-readable form for users to visually and efficiently consume.

To make this per-ASN data available from multiple entry points in Kentik Portal, we have chosen to add it to ASN Quick-View pages. These pages are templated and dynamically generated to show users' traffic details around any ASN (TO or FROM). 

Accessing the PeeringDB View

Clicking on any ASN entry in either Network Explorer or Data Explorer will take the user to the ASN Quick View page, where the PeeringDB tab contains the target functionality:

Additionally, the quick-view pages follow an easy-to-memorize URL format, allowing users to get there easily:
http://portal.kentik.(com|eu)/v4/core/quick-views/asn/<AS_Number>

Yet another way to access this data is to use the Universal Search capability in Kentik Portal at the top right of the screen), which will auto-detect ASNs entered as a search term:

Quick-View pages will be deep-linked throughout Kentik Portal:

• Kentik Market Intelligence gets a new button on any Network Details page to access these records:
  
• Any ASN returned as part of a Network or Data Explorer query already leads to the ASN Quick-View page where this new PeeringDB info tab appears.

Anatomy of the PeeringDB screen

The PeeringDB tab of an ASN Quick-View page contains the following elements:

Left-Side Panel: Metadata

A left-side Panel with contextual information both from Kentik and PeeringDB around this ASN

• Traffic information TO and FROM this ASN leveraging Kentik network telemetry - with all the traffic information to quickly identify if traffic matches the requirements of this ASN: Traffic volumes IN and OUT, Traffic Ratios, connectivity mix (Peering, Transit, IX…)

• PeeringDB peering information around this ASN: policy details, ratio and footprint requirements…

Main Panel: Footprint Explorer

A Main view to identify common footprint

This view will offer two different angles on identifying a common footprint: Map View or Table View, with the user able to toggle between both or view both at the same time.

The Map will display Exchanges and Facilities with different icons, these will be grey if not in common, and blue if in common.

Tooltips will give more information when the user hovers over these icons.

A Data-Table listing either Facilities (Sites) or Exchanges (IXes)

This component is a tabular version of the map visualization that sits above it. It is also controlled in real-time by the filters at the top of the main section of the screen. Exchanges and Facilities for the currently viewed network stand behind two tabs, each containing a different data table

Another useful feature is that the Exchange tab allows users to expand any IX row to list the Facilities in it - think of the use case where the user Network is colocated at a given facility, but hasn’t contracted with the IX(es) available at that facility.

Main Panel: Central filter

Both the Map View and the Table view are controlled by a set of filters allowing the user to refine the geographical scope for which they are looking for common footprint, all filters AND’ed together:

• Type:
  allows the user to reduce the view to either Facilities, Exchanges or both
• Country:
  is a multi-select list letting the users select a set of countries to narrow down the search to (note the map will zoom in and out of focus to match the footprint selected by this multi-select)
• Common:
  that allows users only to display the common footprint, be it Facilities or Exchanges

Common Peering Facilities will be noted with a blue checkmark in the data-table at the bottom, as well as for common Exchanges.

Additionally, Exchanges where the user's network isn't present, but which span across Facilities where the user's network is present will appear with a light blue checkmark:

Exchange entries in the data-table can be expanded into the list of the Facilities that the exchange spans across

Right-side retractable panel: Facility/IX ASN explorer

To create an even more cohesive exploratory workflow, clicking on any Facility or Exchange in the main screen (and on the map) will unveil a side panel containing both details around the Facility/Exchange, but most importantly, a list of all the ASNs available, together with the useful metadata to evaluate on the fly if more candidate ASNs are present.

 To make the list even easier to navigate, additional filters have been added (exclusively for this panel) around the Peering Policy’s constraints, as well as the Traffic Ratio Type, and a free text search field.

Futures

In the future, Kentik will be putting the PeeringDB dataset to work on even more advanced use case, think of it:

• How much time would Strategic Network Planners save, when deciding on global deployments, which Site or Internet Exchange they should deploy to?
  Think of being able to ask Data Explorer:

“Show me all the ASNs and the associated traffic that I am reaching via Transit and that are available at this exchange with an open peering policy”

• Beyond that, think of an insight that would scan your Top ASNs IN and OUT daily and advise which IXes you should deploy to peel traffic off of your Transit upstreams. Or even tell you if you are at an IX and are not peering with ASNs there that you should?

Truth is, this PeeringDB integration is only the 1st step towards further automating peering operations of Global Networks - let us know what you think, because we're pretty excited about these next phases!

We added this feature to allow manual mitigations to be added to each tenant by the landlord. This allows each tenant to use manual mitigations.

Capabilities:

• Allow landlords to assign manual mitigation to a tenant
• Allow the landlord to view and filter mitigations by the tenant
• Add read-only mitigation view for tenant's mitigations
• Allow landlords to add mitigations to tenant policies config (exclude this from package config)

Mitigation Table Tenant Filtering Behavior:

• When mitigations load, tenant mitigations are hidden by default
• Clicking "Show Tenant Mitigations" includes tenant results in landlord results
• When tenant mitigations are enabled, "Group by Tenant" and the "Tenant" table column become available
• Filtering by tenant(s) will return OR of tenant results for corresponding IDs
• Disabling Tenant results clears selected tenants

Creating Manual Mitigation

New Manual Mitigation Below

Assigning a Tenant

Landlord: Filtering Tenant Mitigations

Showing tenant mitigations, grouped by the tenant

Tenant mitigations, filtered to "Test Tenant A"

Tenant: Landing Page:

We are happy to announce the support for the Azure vWAN service in Kentik Maps and Data Explorer, with dimensions for vWAN hubs.

On Kentik Maps, vWAN components are shown in two places:

1. vWAN service is depicted as a global object located between your On-prem and Cloud deployments on the map. It allows you to quickly access the details, such as deployed vWAN Hubs and VPN sites with tunnels configured under that vWAN service.
   
2. Inside the Azure region, the vWAN hub is shown as a component deployed next to the VNETs from that region. The hub can be expanded to show all the gateways, route tables, and peerings configured. 

In addition, Data Explorer now has Ingress and Egress Virtual Hub dimensions that allow you to see precisely which virtual hubs were used by your traffic flow on their way to their destination.

vWAN service support will be a significant aid in troubleshooting your global cloud network deployments.