This new feature may seem small because its UI surface is constrained within lesser-used screens, but it packs a whole lot of punch under the hood. Let's dive into the details of Kentik Portal authentication – the good, bad, and challenging aspects – because there's a lot of new things to unpack today.

Single Sign-On is the modern way of managing access to a broad set of company-wide applications in a structured and more secure way, centralizing access control for all of these applications in the Identity Provider (IdP)  companies have chosen.

When login happens in Kentik using SSO, the Identity Provider presents claims to the Service Provider (in our case Kentik Portal) for each user (user attributes) in a standardized format named SAML2. Each company has a different pre-existing way to define user groups and rely on their IdP to do so.

With this SSO to RBAC attribute mapping feature, Kentik makes it easier and more flexible to leverage your current IdP configuration of user groups to enforce Kentik Portal permissions.

Let's dive in.

UserLevel vs RBAC

As Kentik Portal moves to a full RBAC permissions model, many areas are still governed by our legacy UserLevel permission model: we have three types of users, each one with a set of implicit permissions – Member, Admin, and SuperAdmin. For all areas of Kentik Portal that aren't governed by RBAC, UserLevel applies:

• Members generally have View only rights
• Admins have Update/Create/Delete rights 
• SuperAdmins are a special case: they are Admins who have the additional power to login using password authentication, even when SSO is required – there needs to be at least one per company, but the lesser the better to keep risk surface as low as possible.

As we progressively extend the surface of portal areas that are governed by RBAC, these areas will not be covered by UserLevels anymore – but in the meantime, we maintain both.

What our users have been asking for

Many customers with a large Kentik user-base have asked for RBAC permissions to be controlled centrally from their Identity Provider, which implied the following requirements:

• Kentik Admins want to control RBAC permissions directly through their SSO Identity Provider, as managing users at scale requires a centralized approach and dedicated tool outside of Kentik's User Administration page. Additionally, not all users want or need to enforce RBAC permissions via SSO – some are OK with using Kentik Portal's User Management capabilities, meaning both methods need to co-exist.
• Kentik Admins want to leverage their existing IdP configuration without modifications. Typically, the SSO team prefers to not create new groups for Kentik, but instead use existing groups. 
• Some SSO IdPs allow users to belong to multiple groups. This usually results in nested User Groups being presented to authentication by the IdP, and Kentik SSO needs to accommodate this reality.
  This is typically the case for more complex SSO Setups bridging LDAP or ActiveDirectory user groups into SSO->SAML2.
• For whatever user attribute key handed out in the SAML2 payload, Kentik Admins don't want to have to create specific values to match what Kentik's Service Provider (SP) end of SSO expects – they want to use existing ones and map them.
• Kentik Admins want to be able to forbid access to Kentik Portal for users that aren't in specific groups (instead of defaulting to Member as our current system does).

Introducing SSO Attribute Mapping

To satisfy the requirements captured in the previous section, we've updated the SSO configuration screens quite drastically to present these new functions.
If you don't see the Company Settings menu entry below, you are not a SuperAdmin and therefore cannot access the SSO settings.

As you can see, there are two sections – one for UserLevel SSO enforcement, and the other for RBAC SSO enforcement, since both will coexist for some time.

• The configuration for UserLevel enforcement configuration aspects have changed to this new model
• We've added an RBAC role-set mapping section. Rightfully you're asking, "But what's a Role set ?" – hang on, we'll get to that later ;)

In both of them, the Kentik Administrator can configure the key, which will be presented by their IdP to the Kentik Service Provider end of SSO: the authentication engine will look for the key and its value(s) in the SAML2 assertion presented by your IdP. Upon successful match of the key value, the subsequent UserLevel or Role-Sets will be assigned to the user based on this rule:

• By default, if no key is configured, Kentik Portal will use portal-local user settings for UserLevel or Role-Sets: this is the most common case where you don't want your SSO IdP to dictate user permissions
• If a key is configured, then Kentik Portal will evaluate the value in this key against the mapping table below it:
  • If the configured key isn't found or if the value for this key isn't present in the mappings, then the authentication process will turn to the default setting, as displayed below for UserLevel
    
    
• If a key is configured, and a match is found in the mapping table, then users will be assigned a UserLevel and Role-Set corresponding to the match
• If a key is configured, and multiple matches are found in the mapping table, then users will be assigned:
  • The highest UserLevel matched 
  • A set of permissions that corresponds to the union of all permissions listed in the Role-Sets that are mapped against these values

Let's look at the example below

1. Kentik Portal is expecting the key named kentik_userlevel from the IdP
2. if this key shows up with admin or guest values, the user's UserLevel attribute will be re-written on the fly to Administrator or Member
3. If no key is found, or if the user comes with a value that's different from the mapped ones (admin and guest), the default configuration will apply and the user will be denied access based on the configuration above.

Got it, now what are RBAC Role-Sets ?

Think of Role-Sets as operational sugar to manage user RBAC permissions more easily. In a nutshell, Role-Sets are collections of RBAC Roles. This new concept is introduced in the updated RBAC configuration screen.

The idea behind Role-Sets is that Admins usually want to be able to compose freely with RBAC Roles and Permissions – we realized it would make the Attribute Mapping very noisy if we were to ask our users to map multiple roles to a single Role key value, so we decided to offer an additional level of granularity by allowing users to group multiple RBAC roles in a Role-Set.

The new "Role-Sets" tab in this screen lets you configure these 

And the User Properties (in Company Settings > User Management) now let you assign both Roles and Role-Sets to users.

That's all folks!

As you can see, this feature packs quite a bit of punch and hopefully helps you more efficiently and cohesively manage Kentik Portal security according to moderns SSO standards !

Please let us know what you think – in parallel, we'll keep porting more and more portal areas over to RBAC out of the existing UserLevel model (another big announcement coming your way on that front, stay tuned).

Now, in the "Wait, there's more..." section, here are interesting stats around what SSO IdPs our customers are currently using – and this is the top5 ones we are testing these capabilities against.

We are thrilled to announce the general availability of Kentik Journeys, a flagship user experience of our Kentik AI family of features. You can enable this innovative tool directly through the Kentik AI configuration switch in your portal.

What is Kentik Journeys

Kentik Journeys offers a dedicated space for iterative network exploration and troubleshooting, leveraging a conversational interface powered by Kentik AI. Traditionally, network engineers have relied on network monitoring systems to browse and analyze data charts, refine queries, and repeat this process until they identify and resolve network issues. With Kentik Journeys, this process becomes more streamlined and efficient, thanks to the power of AI.

Checkout our Blog for What's New with Kentik AI to get more information about the nice features we added recently.

How to Enable Kentik AI

Kentik Journeys is part of Kentik AI feature set which can be enabled at the Organization level by users with Super Admin role in the Kentik Portal.

• For organizations which have already accessed Journeys in Preview, the Kentik AI switch is turned on by default — no changes required from your side.
• For organizations which have not enabled Journeys in Preview, the Kentik AI switch is turned off. 

Enabling Kentik AI

• Go to Journeys page on (US|EU) portal
• If Kentik AI is enabled in your organization you will be able to use it immediately
• If Kentik AI is not enabled yet:
  • If you are Member or Admin user, you will see the information to contact your Super Admin user for enabling Kentik AI
  • If you are Super Admin user, you will find the link to the Kentik AI settings page, where you can enable it. 
  • In rare case when your organization does not have Super Admin users, you will find the "Request Access" button to submit support request for enabling Kentik AI, after which our Product Support team will reach out to you with further details. 

Kentik AI settings page

• Kentik AI settings page is visible only to organization's Super Admin users (US|EU)
• The page is available through Organization settings icon on the top right side of the portal
• Simply toggle the Kentik AI switch to turn its features on and off
• See which Kentik AI features are available for your organization
• Read relevant Data Privacy and Security information related to the use of Kentik AI

We are excited to see how Kentik Journeys will transform your network exploration and troubleshooting. For any questions or assistance, please reach out to our support team.

Today, we're sharing the first step in a journey to seamlessly integrate Kentik NMS with our Flow platform. This is just the beginning of a series of iterations that will bring them together in a more cohesive and powerful way.

Read on as we show you a new and easy way to visually correlate NMS charts with Traffic data.

Metrics Explorer vs. Data Explorer

A novel take on an existing type of product, Kentik NMS' approach relies on taking advantage of what made our Flow Telemetry platform a hit: open exploration using Metrics Explorer, the little brother of our award-winning approach you know and love in Data Explorer. In other words, while Data Explorer is the business intelligence (BI) platform to your Network Traffic data, Metrics Explorer is the BI platform to your SNMP or Streaming Telemetry data.

When we launched Kentik NMS, our goal was to marry an NMS with world-class Traffic Analysis to provide our customers with the most cutting-edge and useful network observability platform available. To that end, we’ve learned a lot about how our initial users were using it and took some notes:

• Not everyone who's gained NMS Metrics Explorer expertise is comfortable with Data Explorer, especially given the latter is beyond feature-rich because of years of successive improvements
• A lot of troubleshooting workflows follow the same pattern: identify a peak or a trough on a chart, then inspect traffic to investigate what factors might be contributing to this pattern –  rinse, repeat... – very often an iterative process

Correlation, Causation, AI, and the Network Engineer

Recent days have marked the rise of ML/AI where every product (and Kentik is no exception) will show you machine learned insights about something you did not know about your network. 

Additionally, we get reminded more often than not that correlation does not equal causation, as absurdly illustrated in the meme below:

Yet, years of practitioner experience in this industry tell us that a vast majority of network troubleshooting activities always end up in trying to identify a bump or a trough on a chart by looking at other charts to identify a probable root cause.

In this process, the network engineer is always better equipped when they can leverage a UI/UX that makes it easy for them to quickly eyeball multiple charts on top of each other, with a perfectly aligned time range.

So, we took a few simple use cases and iterated to provide a UI that helps the network engineer correlate SNMP and Traffic charts together:

• "A port on a device is running hot, what could be the reason?"
• "What could be the reason behind the CPU of this router peaking?"

Often times, what we noticed was that the right tool was more about allowing users to quickly iterate through hypotheses, going from one finding to the next, quickly ruling out dead ends. With this as the target user methodology, we came up with the small but powerful capability described in the next section.

Introducing the Metrics Explorer bottom drawer

In Metrics Explorer, you may now notice a little kebab menu at the end of each row. If your query yields a Site, Device, or Interface, you will now be offered with a contextual menu which allows you to summon a traffic breakdown for that specific row:

Selecting any of these entries will summon the "Dimensions Selector", allowing the user to choose any set of up to 8 traffic dimensions to break traffic down for this Site, Device, or Interface – here's an example selecting Source IP and Destination IP for this device. As you can see:

• a bottom drawer opens up with a nested Data Explorer traffic query that's perfectly lined up with the Metrics Explorer one to facilitate visual correlation
• this drawer can either be minimized, discarded, or a new tab can be opened with this very query pre-populated by clicking "Open in Data Explorer"
• discarding the bottom drawer to replace with a new set of traffic query dimensions is also pretty straightforward, allowing for fast-paced troubleshooting iteration

Tell us what you think! What's next?

This feature tested pretty well with our field teams, but we're curious what you think of it! Let us know how we can make it better in future iterations.

We've already started thinking of other areas where we want to bring this traffic inspection bottom drawer:

• Add it to the Capacity Planning workflow so that users could directly look into the reason for why an interface is facing imminent congestion
• Bringing it into the NMS Device screen: it has an "Interfaces" tab, which would definitely benefit from the ability to inspect traffic breakdown for any interfaces here
• ... and then what about the reverse? What about being able to see the CPU traffic chart for a Traffic Breakdown that has the Device name in it?

Stay tuned for near future announcements around our plans to bridge our NMS and Flow Analytics worlds together!

We've improved readability and information density in the "Connections" widget on the "Device Details" page. The device and interface have been broken into two lines in the "Remote End" column, and we've included the "Boundary" and "Connectivity" types in a new "Classification" column, similar to how this information is shown in the Settings > Interfaces table.

Previous version:  

New version:

Note: Device names have been masked.

As one of the most-used components in Kentik Portal, we're always reluctant to change the Navigation menu and interrupt our users' habits. We're making an exception today, and bringing what we hope will be welcome changes to the Navigation menu. Read on.

Summary of Changes

As can be seen in (3) we've moved your recently viewed Dashboards and Saved Views to the bottom right side of the navigation menu, with the intent of some day removing it altogether – its functionality has been ported to the search bar, which allows you to directly access a longer list of recently viewed content (see this article).

Where these recents used to be located, you'll notice two unfolding menu entries now: "Top Talkers" and "Settings", as displayed in (1), we'll get to that.

Lastly, we noticed a significant portion of our users did not realize some navigation category headers in the central panel were clickable links to Status/Summary screens. To help make this more obvious, we've now used a standard link coloring on them, as can be seen in (2).

New Expandable Top Talkers Menu

Upon hovering on the "Top Talkers" item in (1), the central panel will update with a list of available Top Talker aggregate views. Up until now, these have been rather hidden in our UI, and the only way they could be accessed was:

1. by navigating to them in Network Explorer,
2. as a Favorite Page for the users who have already favorited them (meaning they appear right away in the Search results empty state), or
3. by clicking on a well hidden drop-down menu in the Network Explorer landing page as depicted below

With this release, we are now making them available directly from the Navigation menu. Hovering on the "Top Talkers" item in (1) will swap the navigation central panel to a list of these available Aggregate Pages – see screenshot below:

New Expandable Settings Menu

As we were designing the Top Talker's menu UX, we also looked at product usage analytics and confirmed that one of the most-used screens was the Settings screen. Knowing this screen is barely a list screen, we decided to save our users multiple clicks a day by using the same paradigm and populate the central navigation panel with all available Setting screens directly from the navigation menu – see screenshot below:

What do you think?

We hope these small changes will make your Kentik Portal experience even more efficient without disrupting your familiar navigation patterns. What do you think ?

Today, we add a small (yet mighty) change to our Universal Search capability that may make a huge difference with your users. As you've read in previous feature announcements, we started a long-term project to overhaul our search capabilities and bring them to a more modern standard. 

Earlier this year, we also launched Journeys AI in preview – an innovative natural language-driven troubleshooting workflow that has already empowered Kentik users to ask complex, iterative questions of their infrastructure and receive comprehensive visualizations and insights without needing to master Data Explorer or Metrics Explorer. 

Now, we're bridging these two awesome capabilities together. 

Initially, Universal Search would only fetch answers to atomic terms: a specific ASN, IP or Device, or a dashboard name you are looking for. Now, you can enter a full sentence and kick-start a Journey directly from the search bar.

Let's look at it in action. In the example below, I want to know if there's any SSH traffic inbound to my network (which, well... is obviously a potential security hazard). Instead of jumping into Data Explorer and forge a query to figure it out, I'm simply going to ask the Search bar Show me ssh traffic inbound to my network and the search bar will immediately offer to start a Journey directly from it.

Upon clicking on this entry, I'll directly land in Journeys AI, with a visualization answer to my query, and the immediate ability to further refine this query:

My next step could be to ask Journeys AI to break it down by Device and Source countries, to immediately zero in on potential danger. I'll enter Break it down by Device and Source Country and ask it to display as a sankey for easier understanding: 

With this new integration, getting from question to insight is easier than ever—letting you troubleshoot faster and focus on what really matters. We can't wait to see how you use it!

Request access to Journeys AI

Ready to start using Journeys AI? If your team is interested in joining our preview, simply head over to the Journeys AI page in Kentik's portal and request access for your company!

Cloud Network Management

• Azure

  • In March, dynamic path computing in Azure Map was introduced, allowing for easier cross-subscription searches.
  • April brought Azure VNET Peering path computing, improving route visualization and destination extraction for complex hub-and-spoke topologies, with enhanced path filters and dynamic subscription loading.
  • The Azure Entity Explorer widget now includes additional data for Azure Application Gateways and Load Balancers

• GCP

  • This spring saw the introduction of custom dimensions for GCP metadata labels, simplifying data organization.
  • In April, we added GCP NAT Gateway and GCP Metrics integration into the GCP topology map, allowing for detailed entity data and on-demand metrics.
  • In May, historical metrics collection for GCP Cloud Export was introduced, enabling users to analyze past GCP element metrics.
  • In July, support for Google Cloud Firewalls was added, providing easy troubleshooting of denied traffic under the "Details" sidebar for each VPC.

Oracle Cloud Infrastructure (OCI)

• This spring, we introduced directional and non-directional gateway configurations in OCI topology for improved network management.
• In May, OCI Dynamic Routing Gateways were visualized in the topology map, enhancing connectivity insights.
• When configuring an OCI export, you can now select multiple child Compartment IDs 

Hybrid Cloud Connectivity and Cloud Core Management

• Kentik Weather Map: In May, hybrid cloud connections from on-premise to CSPs were visualized, providing insights into traffic between on-premise and cloud environments.

Kentik Weather Map

• Cloud WAN: August introduced enhancements to the cloud core network, enabling customers to inspect details of entities in the cloud WAN map via the details drawer.

Cloud WAN enhancements

AWS:

• In May, AWS flow log collection was improved with the ability to specify subfolders within S3 buckets, allowing for better log organization and management.

One of Kentik Portal's time tested assets has always been its capabilities around Network Analytics, and more specifically the Dashboarding and Reporting capabilities it offers. Around the same time last year, we augmented our Subscriptions engine with capabilities around naming generated report files, and more granularly selecting TO, CC and BCC recipients for these reports to be sent. Rewind back another year to 2022, we created a UX pattern across Kentik Portal for users to easily configure these reports in a cohesive interface under the now famous Share button.

We're at it again this year, but have completely rebuilt the foundations of the backend systems which generate these reports and send them to you, so read on !

What did we set off to improve?

At first, let's see how Report Subscriptions used to work: based on user configuration of these reports would be run once a day in our SaaS and on-prem clusters. 

The implementation that served us well for all these years was a sequential one: once a day, a job would run, collect all the reports from the entire installed base and queue them up to be generated and sent sequentially.

While robust, this implementation presented the following drawbacks we weren't fans of:

• While once a day works for a set of customers in a narrow geography, reports configured by users located around the world would get generated at times that weren't in line with these users' time zones, hence receiving subscription emails at unpractical times. Since some of these reports were based on look-back windowed analytics, all look-backs were dependent on the time at which the reports were being generated, going back to the previous point. As an example, midnight Pacific would correspond to mid-day in Singapore, so our Singaporean users wanting a one-day report from midnight to midnight would actually only be allowed to configure a one-day report from 3pm to 3pm, which didn't exactly line up with the activities of their users.
• The job running all our tenants' subscribed reports sequentially could occasionally fail or choke on a single report generation, causing the rest of the queue to be further delayed until we could unblock the queue.
• As we monitored the amount of reports generated every day, we also started monitoring the duration required for the main daily job to run. In the most recent runs, the report generation would hum along for about 7 hours to generate and send all reports.
  -> again, this had an impact on not only the time at which they would be sent, but also made the look-back windows undesirably elastic (i.e. less predictable)

What does the new Report Subscriptions system look like now ?

As we release new Report Subscription engine to our customers, we can confidently tackle current and future challenges thanks to a new design:

• Users can now set the UTC time at which they desire their reports to be generated and sent
  
  
• Our report generation frequency has been made granular to the 30min time-slot (because believe it or not, some time-zones are 30min granular)
  
  
• As a by-product, these generated report subscriptions can now be made to match precisely local windows of network activity to the exact desires of our users
• Moving from a single monolithic job in every SaaS cluster, we also added the notion of parallelization: multiple workers would trigger under the same scheduled job that would expedite the generation process
  • As a data-point, after migrating all of our users' Report Subscriptions to the new engine we kept the initial time the single job would run at as the configured time for all of them, and instead of lasting 7 hours, parallelization reduced this time to 5min !!!
• As an additional byproduct, reports generation is now much more scalable because it is smoothed throughout the day, but also any failing report does so more gracefully because of 1) parallelization, and 2) we took this opportunity to instrument this new system more thoroughly than the legacy one.

... but wait, there's more

For those keen on the last minute "But wait, there's more..." gimmick made famous by Apple's product keynotes, we figured we may slip in to this vintage a few additional features that our users had also been asking for:

• Ability to set a Dashboard or Saved View lookback window to: "This Month" (i.e. month to date, regardless what day of the month it is)
• Ability to set a Dashboard or Saved View lookback window to: "Last Month"

So, what do you think?

More often than not, some additional capabilities don't make it to the release time. As upsetting as it usually is to the Product Manager working on the feature set, we rely on iterations, and whatever capability doesn't make it right now will eventually find its way into the product in a future release if we hear our customers asking for it. This time around, we wanted to directly implement Time-Zones in the Subscription Target time configuration, but couldn't fit it in our busy schedule. What this means is that users will still incur the one time mental cost of computing the UTC time equivalent to configure a subscription's schedule, but this also means that Schedule times will need to be manually changed twice a year for those users whose country follows Daylight Savings.

Once you get to take this feature for a spin, we'd love to hear your thoughts about where you'd like us to take it in the future, and remember, if history repeats itself, we will probably be evolving Report Subscriptions for another round next summer ;) 

We're thrilled to share the enhancements we've added to Kentik NMS over the past six months. Your feedback and continued support have been instrumental in driving our newest product forward. Here's a summary of the key updates:

New Device Workflows

• Topology Connections: We now show “Connections” on the “Device Overview” screen and “Interface Details” drawer. LLDP connections are automatically detected. Manual connections can be added where LLDP is not in use and are marked with an “M”:

• Device Dependencies: NMS can now detect when one device is downstream from another. When the upstream device goes down and the downstream device does not respond, the upstream device is marked as down while the downstream device(s) are marked as unobservable. This makes it easy to differentiate which device is down and needs your attention vs which devices simply is not responding due to the down device. The first place you will see this is in the status of a device:

Additionally, alerts configured to trigger when a device goes into status down will not trigger for these devices, of course. This is the default and will greatly improve the signal-to-noise ratio when alerting on downed devices. If for some reason you do want to alert for these devices, you can configure the alert to trigger for devices in status down or status unobservable. 

To enable this functionality, you must specify the “Closest Network Device” for the NMS agent by navigating to Settings > Universal Agents (NMS), selecting an agent in the table, and clicking edit:

• Unobservable due to agent down: In the event that an NMS agent goes down, all devices being monitored by that agent will be marked as Unobservable. Mousing over the status label will display a notice indicating that the device is down because the agent is down, and will indicate the name of the down agent.
• ICMP-only devices: Sometimes you don’t have SNMP access to a device but still want to monitor it. NMS now supports this use case with "ICMP only" devices. Add these devices by going to "Menu > NMS > Devices" and clicking "Add Devices" in the top right. At the prompt, select "PING ONLY". Doing so provides up/down status and latency:
  
  
  
  
  
• API for Device CRUD and Query: To better serve the largest and most complex networks in the world, you can now use the Kentik API to create, read, update, and delete (CRUD) NMS devices. You can also now run Metrics Explorer type queries via API. To make it easier, Metrics Explorer can show you the API query for any query you’ve done in the UI.

New Alerting Workflows

• Acknowledge Active Alerts: Alerts can now be acknowledged even while they are active. This is a common practice to indicate to the rest of the team that someone is aware of the issue and is taking action. The name of the acknowledger will be noted an a comment can optionally be added. Users can also choose to automatically acknowledge additional occurrences of the same alert ("auto-ack"), for situations like a flapping link.

• Silence Notifications: Notifications can be "silenced" and "unsilenced" from the Alerting page with the push of the button. Alerts will still trigger and can be seen in the UI, but notification channels will not be executed. By selectively silencing notifications for alerts, network admins can better manage focus and reduce noise to their team.
  
  
  
  
• Suppress Alerts: You can now prevent an alert policy from triggering all together by using suppress alerts from the Alerting page. 

Supressed alert policies will not trigger, and so alerts will not show up on the alert list and, of course, notifications will not be executed. You can see all configured Alert Suppressions on the Alert Suppressions page in Settings. From this page, users can view, create, edit, and delete Alert Suppression Patterns.

• State Alerts: State alerts were previously limited to out-of-the-box supported entities - Devices, Interfaces, and BGP neighbors only. You can now configure state alerts for any metric, including custom metrics. Another way to think about this is that threshold alerts alert when a metric is less than or greater than a value (or baseline) whereas state alerts alert when a value is equal to a certain value, for example the number 3 which corresponds to an interface being down.

Quality Enhancements

• Status Bugs: In very specific scenarios, devices were incorrectly marked as down. While most customers were not affected by this bug, those that were had instances where many devices were reported down but were not really down.
• SNMP Polling Efficiency: Several bug fixes involving SNMP timeouts, conflicting statuses and agent stability.
• Query Performance: In an effort to reduce the amount of time it takes to load some of the more complex NMS pages, we've made query optimizations to backend improve performance. While there's still room for improvement, we think you'll already notice the difference.
• Other Bugs: We addressed numerous issues relating to usability, reliability and predictability - especially where alerting is concerned.

In addition to the software changes above, you will find a great deal more information about NMS available in the knowledge base. These articles will help you get the most out of Kentik NMS.

We are committed to continuously improving to meet your needs and exceed your expectations. We encourage you to explore these enhancements and send us your feedback!

Thank you for being a part of the Kentik community. Stay tuned for more exciting updates soon.

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: