Enhanced Network Visibility: Monitor Nokia SAP/SDP Logical Interfaces with Kentik

Introducing expanded insights into Nokia devices with SNMP Ingest for SAP VPLS Interfaces.

This update significantly enhances Kentik's visibility into Nokia networks by adding krpoxy support for SNMP collection of utilization metrics from logical Service Access Point (SAP) and Service Distribution Point (SDP) VPLS interfaces on Nokia Layer 2 devices. Previously, accessing this critical data required navigating vendor-specific MIBs outside of the standard IF-MIB. Now, Kentik simplifies this process.

How it Works:

Kentik's kproxy server now automatically performs an snmpwalk of the necessary vendor-specific MIBs to gather interface index information and dynamically create corresponding interfaces within Kentik. This eliminates the need to build custom configurations and provides immediate access to performance data.

How to Access:

1. Navigate to Settings > Networking Devices in the Kentik portal.
2. Add your Nokia Layer 2 devices.
3. Once the devices are active, the new SAP/SDP interface dimensions will be available in the Data Explorer's dimensions selector. These new dimensions will only be visible for accounts with active Nokia Layer 2 devices.

Benefits:

• Improved Network Visibility: Gain deeper insights into the performance and utilization of Nokia VPLS services over time.
• Simplified Monitoring: Native dimensions eliminate the need to custom configurations
• Enhanced Troubleshooting and Analysis: Leverage granular data to quickly identify and resolve performance issues affecting Nokia-based VPLS services.

Understanding Nokia SAPs and SDPs:

To provide context, here's a brief overview of the key concepts involved:

• Service Access Point (SAP): A SAP represents the customer interface point for a service on a Nokia 7450 ESS or 7750 SR OS device, a local entity uniquely identified by Physical port, Encapsulation type, and Encapsulation identifier (ID)
• Service Distribution Point (SDP): An SDP acts as a logical connection, directing traffic between Nokia 7450 ESS/7750 SR devices via a unidirectional service tunnel. The SDP terminates on the remote router, which then forwards packets to the appropriate egress SAPs. A distributed service comprises at least one SAP on a local node, one SAP on a remote node, and an SDP binding the service to the service tunnel.

As you may or may not know, the CDN Analytics module in our Premier platform edition leverages a powerful and constantly evolving engine to detect all CDN IPs around the world and assign them to CDNs it knows about. The number of CDNs our engine is able to detect, as well as the precision with which it can identify their IPs inside or outside of your networks, keeps improving over time as it learns.

Two new CDNs covered by our CDN detection engine!

This time around, our engine has learned of two new CDNs: EdgeNext and Netskrt. EdgeNext is a commercial CDN with a strong focus and footprint in Asia. Netskrt is a software/appliance-based CDN that specializes in last-mile caching for broadband ISPs, often referred to as a "Cache Embedding CDN" - they are one of these new-gen CDN Providers in providing technology for last mile caching but also match-making Content Providers with Broadband Providers (Qwilt is another one of them)

As you can see in the CDN Analytics workflow UI, this takes our engine from an impressive 60 CDNs detected to 62!

The special treatment Embedded CDNs get in our workflow

Embedded CDNs are identified as such by our engine, which attempts to auto-detect IP ranges of such embedded caches on your network based on Interface Classification (Connectivity Type, and Provider attributes of your interfaces).

If your Interface Classification is configured thoroughly and sets interfaces to Connectivity Type = Embedded Cache with an Interface Provider = "netskrt" then our CDN engine will pick them up and automatically classify the IP Range they're on as CDN IPs, associated in this case to the Netskrt CDN Name.

If your embedded caches are on network devices that aren't exporting flow and SNMP data to Kentik, we also give you the opportunity to manually enter them and help make this engine smarter, via CDN Analytics > Configuration > Additional Embedded Caches.

Beyond these capabilities, one of the key aspects of embedding CDNs is how much offload they yield, i.e. how much upstream bandwidth they help you save – in other words, how efficient are they. For every new embedded CDN we add, we also add CDN Analytics landing page widgets to display this offload percentage.

This iteration is no exception – we've added both Qwilt and Netskrt widgets to your landing page. To enable/disable these widgets, go to CDN Analytics > Configuration > Landing Page and see for yourself which ones you want activated.

If, like Pokemon, you gotta catch 'em all, your CDN Analytics workflow landing page can look a little like this:

Take this feature for us spin and let us know if you like it !

When we launched CDN Analytics, the only CDNs that were offering ISPs to embed caches in their networks were limited: Netflix, Akamai, Facebook and Google.
Since then, numerous additional CDNs have released their programs to embed caches and our Service Provider customers have been asking for more of these indicators on the landing page.

With this update, we are adding a whole lot of new CDNs which we can compute offload for, and users can now determine which one they want displayed on the landing page for CDN Analytics.

Embedded CDNs 'A La Carte'

How do we compute offload ?
For the reference, Offload for an embedding CDN is the measurement of how efficient they are at serving content from the last mile out of embedded cache vs how much content they pull from outside of the user's network - which is less cost and performance effective.
A high ratio means a better outcome for the embedding ISP, but is tightly linked to the nature of the CDN: pure-play CDNs only have to store their own content in the ISP's last mile, while Commercial CDNs store content of multiple Content Providers competing for popularity, meaning lower ratios are in this case expected.
The formula we use to compute offload is to look at peak time for each CDN, and compute the ratio of {"Mbps from Embeds to Subscribers" / "Mbps from OnNet + OffNet to Subscribers"}

A new tab appears in the [Configuration] panel for the CDN Analytics screen that surfaces all the Embedding CDNs

• that we detected (via interface classification)
• that our users manually declared (via this same config screen)

and we’re allowing users to selectively enable them on the landing page, see for yourself:

...with a CDN Analytics landing page that now looks like this

Embedding Cache Analytics Guided Mode Dashboard

On each vignette for each Embedding CDN, we’ve added a link to a newly created preset dashboard that presents, as a guided mode dashboard, an in-depth analysis of how the CDN functions in terms of:

• cache fill (internal and external)
• cache offload (on-net and off-net)

This new dashboard replaces the existing one in our Presets section and it's now really comprehensive for users to understand how each embedding CDN behaves when it comes to long-tail and cache-filling, as you can see on the screen grab below:

If you remember back in May 2023, we released our initial version of a PeeringDB integration - more details here: https://new.kentik.com/we-now-integrate-peeringdb-data-akabK

The theory

PeeringDB contains a directory of most of the registered Internet Exchanges (IXes), as show in an extract below.
 For each one of them, their data contains the IP Ranges, v4 and v6.

 For each interface that we poll on your devices using SNMP or Streaming Telemetry, we get information such as the IP Addresses configured. Using the aforementioned IX IP Range data, we are then theoretically able to match any interface to an Internet Exchange from Peering DB based on its IP Address.

What does it look like in the product ?

We've added a somewhat magic rule, which we have decided to call a Kentik-managed Rule in our Interface Classification UI. This rule is a bit special compared to the other ones in the stack:

• It cannot be edited by users
• It can only be enabled/disabled by users
• It sits on top of the rules stack, which means that it will always be evaluated first to bypass any user defined rule (because for each interface, the algorithm exits on first match)
• This rule checks the IP Addresses, and looks the IP address up in all the IP Ranges from all the IXes in PeeringDB, if a match is found
  • it sets the interface to Connectivity Type = IX
  • it sets the interface to Network Boundary = External
  • it sets the Interface Provider to the name of the IX from PeeringDB
  • it establishes the mapping between this IX and the PeeringDB Exchange in the PeeringDB integration configuration so you don't have to

Here's an example of what Interface Classification Test UI for this rule will look like in case of matches

Existing Customers vs New Customers

Obviously a lot of you may already have their interfaces well classified, and most likely you used dynamic regex matching on their descriptions to get your IX classifications going.
As we didn't want to disrupt your existing setup, we have adopted what we think are reasonable defaults to roll the feature out:

• Existing customers will have the PeeringDB rule disabled by default
  -> up to them to enable it if they would like
• New customers will always have the PeeringDB rule enabled by default

But wait, there's more...

As an additional freebie, we've modified the Interface Provider field for any custom rule that sets an interface as IX: you can now choose to keep your own provider naming, or can select the actual PeeringDB name for the internet exchange - in this case the field will offer a typeahead that directly looks up values from the PeeringDB exchange names, as showcased below.

There are still a lot of features that we plan on implementing relying on the PeeringDB dataset, so watch this space, and don't hesitate to give us feedback !

Upon popular request, we've added a new agent to the Kentik platform – Kentik BGP proxy (kbgp) – which enables BGP enrichment of flow data to internal network devices without requiring global IP connectivity. Before kbgp, customers could only establish BGP sessions with devices with an assigned public IP address. Via kbgp, BGP enrichment can now extend to flow data generated from all internal areas of your network, further enhancing network troubleshooting for on-prem and campus environments. Read on for details!

Kentik BGP proxy (kbgp) is a Kentik agent that can proxy BGP peering sessions between customer devices inside the customer’s network and Kentik over the Internet. The kbgp is deployed inside the customer’s private network. The customer devices are able to establish BGP peering with the kbgp, which will multiplex and relay BGP packets in real time to Kentik. The result would be the same as if the devices are peering directly with Kentik.

The functionality is achieved similarly to the functionality that is performed by kproxy, which collects flows locally inside the customer’s network and securely exports them to Kentik inside an HTTPS tunnel.

Without kbgp, customer devices can only establish BGP sessions with Kentik over the Internet, which requires that the customer device has a public IP address assigned. With the use of kbgp, multiple registered devices can have BGP peering with a single kbgp. The BGP session packets are carried over a secure gRPC session to Kentik, where the BGP session is logically established and the data is transferred. kbgp does not store any BGP state or BGP routes, making this agent lightweight and requiring very few resources.

The image below shows the logical diagram of kbgp usage inside a customer’s network

The key benefits of deploying kbgp in a Kentik-monitored network include:

• Kentik will be able to add BGP context to the flow data from internal network devices that don't have global IP connectivity
• The BGP data is secured and encrypted during the transfer from the customer's network to Kentik

At the moment, kbgp does not appear under the Kentik Agents section in the Settings menu, but we are actively working on a way to display the agent within the UI. For more information about the kbgp installation, configuration, and troubleshooting, please check out our kbgp KB article and let us know your feedback in the comments. 

Following multiple requests from our Kentik Market Intelligence users, we have just added additional Network Level metrics and visualizations that will help our users more precisely gauge the size of the Network (Autonomous System) they are investigating.

Read on for more details!

More Customer / Provider analytics history

First, we are now showing a history of provider and customer counts by month over the past 12 months. For instance, it can come in handy to notice a decrease in the number of providers for a given network, as it may create an opportunity for you to insert yourself as a new provider.
Noticing a sudden increase in the number of customers in a given region will also show KMI users the prospecting efforts of the network they are looking at are bearing fruits in a specific region.

Even more interesting, the charts displayed on this page are all governed by the top-level filter on the page, meaning that Customer Count by month can be narrowed down to any specific market you'd like to dive into.

IP / Prefix metrics additions

Another addition revolves around quantifying the size of any network's transit customer cone. The simplest metrics used in this case are often the density of the IP Address Space transited (for a Transit Provider) or Originated (for a Retail Network). These are now displayed (put in perspective with those of your own configured network) as depicted in the screenshot below:

Beyond the plain count of IPs, we are also showing a histogram of both Originated and Transited prefixes by prefix length, which can be a good indication of the size of the currently viewed Networks' customers. Again, these are also governed by the top-level filters on the screen.

Ranking history

Lastly, as most of you noticed on the landing screen, we have always kept a 12-month rolling history of rankings for all the ASNs in our dataset. Although we have only been displaying it for the "Ranking over time" top panel on our landing page, we've always had this data in store.

We are now offering it in the "Rankings" tab of any ASN's Network Detail page, as you can see below – again, this data and the rankings are governed by the top-level filters, which can be set on each screen. This means you can instantly assess how well any given network has been doing over the past 12 months in any market of your choice!

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!

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!