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/

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!

As hinted in one of our last updates about password complexity constraints, starting on June 1st, 2023 users relying on plain password authentication will be required to rotate their password at regular intervals.

Between tomorrow (May 9th, 2023) and June 1st, 2023, users whose preferred login method is currently plain password authentication will see this warning appear upon login, which will not show again once discarded.

This will only apply to password-authenticated users - the following authentication methods will not be impacted:

• SSO users
• 2Factor Users (TOTP or Yubikey)

Kentik recommends using these preferred, stronger authentication methods.

However, companies will still be allowed to change this setting via the Settings > Access & Security > Authentication & SSO screen if they so desire.

In this config screen, SuperAdmins will be allowed to:

• Select a different frequency between 90, 120, 180 and 365 days
• Completely disable password expiration (not advised)

As asked by our users, password reset will prevent users from re-using any of the five previous values.

We have Improved search bar results for Alerting by adding duration and tenant, as well as dimensions and metrics. In the screenshot below, searching for 209 brings up the ASN# with 209 under the dimensions column.

Overview

Now under the Mitigations Page, we show Archived Mitigations as part of the status filter behavior.

Previous behavior

• The initial load of the mitigations table excludes "Archived" mitigations (all statuses but archived are checked)
• In the filter sidebar, clicking "Clear all" did not clear the status selections.
• Even if you manually unselected all status filters, we still excluded Archived mitigations in UI. The only way to include "Archived" mitigations was to manually select the filter

Current Behavior:

• The initial load of the mitigations table still excludes Archived mitigations ("Active", "Failed", and "Waiting" are selected by default)
• But clicking "clear all" actually deselects all status selections for you.
• Having all statuses deselected now has the same behavior as having all statuses selected: Archived mitigations are now included in the result set.

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:

Kentik now supports the collection of the NetFlow and IPFIX timestamp fields (starting kproxy v7.38.0). The additional 3 fields are available to be viewed in the Raw Flow Viewer:

• Flow Start - Timestamp of the flow start
• Flow End - Timestamp of the flow end
• Duration - Calculated duration of the flow as Flow Start - Flow End

NetFlow v5 and v9

In the case of the NetFlow v5 and v9, Start and End Flow timestamps are calculated using System Uptime and Unix Seconds fields from the NetFlow header and the following fields from Flow records:

IPFIX

In the case of the IPFIX, the timestamps are determined in the following two ways:

1. Using flowStartSysUpTime, flowEndSysUpTime and systemInitTimeMilliseconds fields:

   ID	Name	Type	Description	Units
   21	flowEndSysUpTime	unsigned32	The relative timestamp of the last packet of this Flow. It indicates the number of milliseconds since the last (re-)initialization of the IPFIX Device (sysUpTime). sysUpTime can be calculated from systemInitTimeMilliseconds.	milliseconds
   22	flowStartSysUpTime	unsigned32	The relative timestamp of the first packet of this Flow. It indicates the number of milliseconds since the last (re-)initialization of the IPFIX Device (sysUpTime). sysUpTime can be calculated from systemInitTimeMilliseconds.	milliseconds

   Both fields in the description refer to the additional field which is equivalent to the SysUpTime:

   ID	Name	Type	Description	Units
   160	systemInitTimeMilliseconds	dateTimeMilliseconds	The absolute timestamp of the last (re-)initialization of the IPFIX Device.	milliseconds

   
   

2. Using some of the IPFIX-specific fields for the flow start and flow end timestamps. Not all device’s IPFIX implementation used these fields, but if they are present, they are preferred and used:

   ID	Name	Type	Description	Units
   150	flowStartSeconds	dateTimeSeconds	The absolute timestamp of the first packet of this Flow.	seconds
   151	flowEndSeconds	dateTimeSeconds	The absolute timestamp of the last packet of this Flow.	seconds
   152	flowStartMilliseconds	dateTimeMilliseconds	The absolute timestamp of the first packet of this Flow.	milliseconds
   153	flowEndMilliseconds	dateTimeMilliseconds	The absolute timestamp of the last packet of this Flow.	milliseconds
   154	flowStartMicroseconds	dateTimeMicroseconds	The absolute timestamp of the first packet of this Flow.	microseconds
   155	flowEndMicroseconds	dateTimeMicroseconds	The absolute timestamp of the last packet of this Flow.	microseconds
   156	flowStartNanoseconds	dateTimeNanoseconds	The absolute timestamp of the first packet of this Flow.	nanoseconds
   157	flowEndNanoseconds	dateTimeNanoseconds	The absolute timestamp of the last packet of this Flow.	nanoseconds
   158	flowStartDeltaMicroseconds	unsigned32	This is a relative timestamp only valid within the scope of a single IPFIX Message. It contains the negative time offset of the first observed packet of this Flow relative to the export time specified in the IPFIX Message Header.	microseconds
   159	flowEndDeltaMicroseconds	unsigned32	This is a relative timestamp only valid within the scope of a single IPFIX Message. It contains the negative time offset of the last observed packet of this Flow relative to the export time specified in the IPFIX Message Header.	microseconds

sFlow

sFlow is packet sampling technology, which means that there is no flow, hence no flow start or flow end time.

sFlow also does not contain any timestamp, so the behavior is the following:

• Flow Start: save the time of arrival/processing of the sFlow packet
• Flow End - same as Flow Start
• Duration - 0

Raw Flow Viewer

In the Raw Flow Viewer, these additional flow timestamps need to be selected as Dimensions to be shown in the output, as shown below:

Users will not be able to edit the Methods and Platforms sections if associated active mitigations are using them. This will prevent users from disrupting any active mitigations that are in use. Edit capability returns when mitigations are not active.

Pages Impacted

• Mitigations (Protect & Settings)

Users now have an overview of which notifications are being used and the components of the service they are notifying on

• Users can now find out details about the usage of the notifications and navigate to them by clicking on the associations under the column "Used By"
• We show relevant and viable associations in the details (dead associations that are no longer applicable are filtered out)

• Users can remove associations directly from the notification edit modal