As Connectivity Costs is one of our most in-demand workflows, we've spent some extra time this quarter to address a much-requested change from our users: Billing Cycle Day and Contract End Dates have now been moved down from the Provider level to the Cost Group level within the provider. Read on.

Billing Cycles and Contract End dates are now a Cost Group level attribute

The main pet peeve our users had was that it is pretty common to have multiple IP Transit contracts with the same provider with a different billing date and contract end date. This was indeed a design flaw on our end when we initially released the workflow, and we're pleased to announce we have now corrected it.

All provider contract dates have been transferred to the child cost group objects within all providers and you can now modify them at will at a cost group level.

Let's see what it looks like, as the impacts on the Connectivity Cost workflow UI are multiple.

The new Cost Group Settings panel now contains Billing Cycle Start Date and Contract End Date fields. 

These are now visible on the cost group cards within a provider.

Provider Cards in the Provider Management screen now display these dates as part of each Cost Group entry.

The landing page Calendar Side panel now shows cards that correspond to cost groups, instead of providers, when it comes to Invoices Due and Contract Expiries. 

On the Provider Details Screen, cost groups with a Billing Cycle Date in the past are displayed in solid color, while the ones with a Billing Cycle Date in the future are displayed as estimates with a striped color. 

All Cost Group entries on the Provider Details table now show a progress bar displaying how far from the Billing Cycle Date each Cost Group is at the time of viewing, with a color that varies as we get closer to the billing date.

Download the entire SNMP Sample Set for Billing reconciliation

What do you do when the Kentik cost displayed at the end of your billing cycle doesn't match your providers' invoice? Generally, you enter a dispute which requires you to provide your own calculation together with the SNMP 5min samples it's based on.

We have made this possible in this addition to the Cost Group side panel in a providers' screen, where in the click of a button, the entire set of data samples for all interfaces (In and Out) gets generated as a CSV file for you to look at, also containing interface names, descriptions, device...

...and wait, there's more

While at it, we've also made the "Suggested Provider" right-side panel collapsible for those of our users did not want to see it in the Manage Providers screen:

Following through with the recent release of our PeeringDB integration, we've sat with our users and collected their feedback, which lead to a few granular improvements – read on!

Access PeeringDB records from any ASN anywhere in Kentik Portal

In a lot of places in the Kentik portal, we're displaying ASNs: Data Explorer queries, Network Explorer, Kentik Market Intelligence, etc...There's a common set of actions users always want to perform when it comes to an ASN: look at their footprint via PeeringDB, look at their ranking in a specific market via KMI, and so on.

We've altered the way we displayed these ASNs in the product so that you can always get to PeeringDB or KMI in a click, see for yourself:

Making PeeringDB easier to map with Kentik Sites

As we watched users configuring their PeeringDB mappings to Kentik Sites, we noticed that oftentimes, they didn't know the exact PeeringDB facility name to look for, and more than anything referred to them by their address. The lookup field in the Site mapping functionality in "Settings > Manage Sites" now displays the address and will also autocomplete based on users' address input, see below:

As one of our most used workflows, we keep seeing a constant stream of feature requests for the Edge > Connectivity Cost workflow. We just added a metric tonne of granular features, with more to follow shortly, read on!

Site Market breakdowns are here

Since we've released the Site Market capability (collections of sites), a lot of our users have mentioned that their approach to Cost Tracking should ideally rely on Site Markets.

The rationale behind this is that bandwidth costs most of the time rely on large geographic zones: prices within the same zone will usually be in a similar range, and blending them altogether is an unrealistic approach due to these sometimes large local variations. This is now a reality with the new "Site Markets" breakdown on the landing page:

These Site Markets also now have their own details page, as well as reports and subscriptions!

More CIR pricing tiers

Some of our customers let us know that they have contracts with plateaus that have more than 3 tiers, so we extended this capability all the way up to 5 tiers so they could accurately model their transit contracts.

Granular additions

• An indication of the currently selected month has been added everywhere necessary - it used to be tricky to remember which month was selected when scrolling down pages, so we've fixed that:

• 

  We've also made sure Mbps are used instead of auto-greek prefix when displaying details of a cost group's interfaces, since it's the unit used for billing.
  

  

More changes are coming later this month – we will update the article accordingly!

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!

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.