We have improved our options for synthetic network testing by supporting different protocols for basic network tests (Ping tests). In addition to ICMP, we have expanded the options to test TCP and UDP connectivity between Synthetics private agents or between agents and any target.

As a part of this feature, we have added the ability to start the TCP or UDP listener on our Synthetics private agents which acts as an “echo service”:

• Specify one or more TCP ports to listen and respond to TCP connections
• Specify one UDP port to listen and respond to UDP packets as an echo service

Please note that UDP protocol is susceptible to spoofing attacks, therefore running this service is recommended only within private networks and with the appropriate access control to the open UDP ports by using network access lists or firewall rules.

Additionally, the network connectivity test configuration is extended with the following testing methods/protocols:

• TCP: Based on the TCP Syn packet sent to a configurable port and expecting the TCP Syn+Ack packet response from the target IP.
• UDP-ICMP: Based on the UDP packet sent to a configurable port and expecting ICMP Port unreachable received from the target IP.
• UDP-ECHO: Based on the UDP packet sent to a configurable port and expecting the UDP packet response from the target IP.

Today we are proud to announce that the highly anticipated RBAC (Role-Based Access Control) is going live. In a few words, RBAC will eventually replace our implicit User Level (Member, Admin, SuperAdmin) permission system and offer a much more granular approach to user permissions. Read on to get the details and the shape of things to come in that department.

If you are a Kentik Administrator in your company who will be tasked with managing user permissions, please take the time to read this KB article which outlines the changes from the Legacy User Level-based system, the new RBAC capabilities, and the gotchas from the migration.

What is RBAC?

Role-Based Access Control is a set of User Permission capabilities that allow Kentik Portal Admins to adopt a granular approach to what actions each user can perform in the Portal.
While RBAC will eventually fully replace our User Level model, both will coexist for a while as we port Portal capabilities from one model to the other (which will take a few quarters).
An additional framework, named Permission Overrides is also in place for a limited number of Portal modules: Connectivity Costs and Synthetic Monitoring. It allowed users to set fine-grain permissions for these aforementioned modules only: this capability has been phased out with this RBAC release and replaced by native RBAC permissions.

How does RBAC work?

Users can access RBAC settings in the company settings menu, as depicted below:

Within this settings screen, RBAC administrators will be allowed to create Roles.
Each Role contains a configurable list of permissions, such as "View Connectivity Costs", and "Edit Synthetic Tests"... and a user can be assigned as many roles as desired. When a user has multiple roles assigned to them, the resulting permissions will be the union of all permissions described in all the assigned roles.

The following screenshot illustrates a role named "Administrators", which contains permissions.

The following screenshot is that of a User Settings (from the User Management screen) displaying which roles and resulting permissions are assigned to a given user. Notice that this user has two roles: "Members" and "Connectivity Costs Viewer"

RBAC uses an "implicit deny" model
It's important to notice that this RBAC permission model is based on "Implicit Deny", which means that there are no "Prevent user from doing this..." type of configuration: a user can only perform an RBAC-regulated action if they have the related permission in any of the roles they have been assigned.

What does the initial release of RBAC encompass? 

The initial goal for this first release is to get rid of the legacy Permission Overrides model, which we are therefore sunsetting. The initial set of Portal areas covered by RBAC are listed below:

• RBAC Management:
  View permission by user, Create Roles, View Roles for the Company, Create Roles, Update Roles, Delete Roles, Assign User to Roles, Remove Users from Roles
• Connectivity Costs:
  View the Connectivity Costs workflow, Configure Providers and Costs
• Synthetic Monitoring Agents:
  Create Agents (Register), View Agents, Update Agents, Delete Agents
• Synthetic Monitoring Tests:
  Create Tests, View Test results, Update Tests configuration, Delete Tests

Introducing Kentik-Managed Roles

For convenience, we have also added the notion of Kentik-Managed Roles: these are roles that are exclusively editable by Kentik. The idea behind these is to provide a simple alternative to cover all existing permissions in one role leveraging Reasonable Defaults.
Whenever a new area of the Kentik Portal is folded into the RBAC engine, reasonable defaults for this area of functionality will be updated to these Kentik-Managed Roles - making it somewhat seamless to our users who are currently satisfied with the User Level model.

There are currently 3 such roles, and they mimic the current Member, Admin, SuperAdmin User Levels. For new users, one of these 3 roles will be by default assigned upon user creation based on the Legacy User Level.

Important Note
By default, the Connectivity Costs workflow is entirely disabled for users with the Member Kentik-Managed Role - as a lot of you have mentioned our permissions around it were too loose. New users created with a 'Member' User Level will require an additional custom Role to access the workflow. Since existing users without permission overrides already had access to the Connectivity Costs workflow, we've added a "Connectivity Costs Viewer" role to their profile so they can keep access to the workflow.

What's next in RBAC world ? 

Our initial RBAC release establishes the foundation of the RBAC permission engine. In the coming quarters we'll build on this foundation by expanding the RBAC model into new areas:

• We are working to extend Labels to multiple areas of the portal beyond Devices, Synthetics Agents, and Synthetics tests (see Test Control Center), and we want to extend RBAC permissioning to apply to content grouped together by users using labels.
• In Q4, we will extend label-based RBAC permissions to Synthetics agents and tests, and will shortly follow with Dashboards and Saved Views, allowing the permissions for content created by users to be managed both centrally and granularly.
• Our soon-to-be-released Credentials Vault will be upgraded shortly with the ability to manage secrets based on labels.

More than anything, we would love to hear your thoughts on which area of Kentik Portal you would like us to work on implementing next, so please do let us know!

The Connectivity Cost Edge workflow has gotten its initial Read API released: a proportion of our existing users were waiting on this API to better integrate Kentik with their own internal systems and I'm happy to report it is now live.
They can now, via the API, pull the summary monthly data for any month, from all and any of the providers they have configured.

See the API tester here:
https://portal.kentik.com/v4/core/api-tester/cost-v202308/swagger if you are a US SaaS customer, or here https://portal.kentik.eu/v4/core/api-tester/cost-v202308/swagger if you are an EU SaaS customer.

A lot of you have been asking for a feature allowing you to embed a Dashboard URL containing the value of the Guided Mode Parameter in your external systems.
This is now possible, read on!

Dashboards always come with this URL format: https://portal.kentik.<com|eu>/v4/library/dashboards/<dashboard_id>
Let's say your Guided Mode dashboard pivots around a Destination Interface Provider dimension.

In this example, you can access this dashboard with the parameter pre-filled with the value my_provider using this URL:
https://portal.kentik.<com|eu>/v4/library/dashboards/<dashboard_id>/guided?provider=my_provider

Finding the parameter name to use in the URL after the guided?<parameter>=<value> portion may be a little tricky: parameters in Guided Mode do not 1:1 correspond to the SRC|DST|SRC_or_DST dimensions you are used to in Data Explorer, because Guided Mode considers families of Dimensions, and discard the directionality. Here are a few examples:

• Using SRC, DST (or both) ASN as a parameter will result in using as_number as a parameter name
• Using SRC, DST (or both) AS_PATH as a parameter will result in using bgp_aspath as a parameter name
• Using SRC, DST (or both) Provider as a parameter will result in using provider as a parameter name

The extensive list of URL parameters is available below for your consumption:

- application
- as_group
- as_name
- as_number
- aws_acc_id
- aws_priv_dns
- aws_pub_dns
- aws_region
- aws_subnet_id
- aws_vm_id
- aws_vm_name
- aws_vm_type
- aws_vpc_id
- aws_zone
- az_inst_id
- az_inst_name
- az_region
- az_rsrc_grp
- az_sub_id
- az_sub_name
- az_vnet
- bgp_aspath
- bgp_community  
- bot_net
- cdn
- city
- cloud_provider
- cloud_service
- connectivity_type
- country
- device
- device_label
- dns_query
- eth_mac
- gce_proj_id
- gce_region
- gce_vm_name
- gce_vpn_snn
- gce_zone
- interface_capacity
- interface_desc
- interface_group
- interface_id
- interface_name
- ip
- market
- network_boundary
- port
- provider
- region
- service_name
- service_provider
- service_type
- site
- site_market
- tag
- threat_list
- traffic_org
- vlan
- vrf

Our customers have requested a feature to mute the alarms and notifications for Synthetic tests during their maintenance windows or other activities on their network. Alert Suppression is now available under the Alerting and Notifications section inside the Test Settings.

Users can specify the start and end time of their silence/maintenance window and will not be alerted during the selected period.

Today, we're excited to announce an exciting update to Kentik's Alerting threshold condition capabilities. We've improved our threshold conditions to make them easier to configure and more powerful than ever. For those unfamiliar, kentik's threshold conditions allow users to set thresholds including baselines, to alert them when key performance metrics exceed or fall below-specified values. We have made it easier to configure these thresholds when using baselines, by providing a simple "Above or Below" drop-down, versus in the past, to configure a policy to trigger at 20% below the baseline, we had to set the rule to 125% above the baseline, as this is what the API was expecting. This was confusing and hard to understand for the user.

You know can simply select a % above or below the baseline. This should provide a much easier-to-understand experience for users creating alert policies with baselines.

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. 

Kentik's Cloud Performance Monitor is a great way to see at a glance the performance and accessibility of different services provided by AWS.

This month, we added support for Aurora and Lambda services. Customers may use the Cloud Performance Monitor to see the amount of traffic forwarded to and from these services. In addition to the traffic volume, customers can also see AWS service performance information, such as HTTP latency and status codes, if they deploy synthetic agents with tests targeting those service endpoints. Set up synthetic tests that target Aurora and Lambda service endpoints to see performance information similar to what is shown below:

Note: The Cloud Performance Monitor page is dynamic and shows only services actively communicating with your cloud deployment. If your account doesn’t show these new services or the services pictured in the screenshot above, that’s likely due to a lack of traffic towards those services in your environment.

Google Cloud allows customers to configure sampling rates at the flow records generation point on a per-subnet basis, which can significantly reduce the cost of flow log generation.

The Kentik portal now displays the average sampling rate for each exporter and the number of subnets configured with sampling. This is not a configuration knob, but a value configured on the Google Cloud dashboard. The inclusion of this data in Kentik Cloud provides a quick way for users working multi-cloud environments to consume sampling rate information.

We are happy to announce the general availability of Azure Firewall logs as a datasource following its initial introduction in May.

Customers can consolidate flow records generation by using Azure Firewall as the primary source of flow information sent to Kentik. The ingest process is identical to the one used for NSG flow logs and requires customers to store records in their storage accounts.

Customers can filter traffic flows traveling through a particular firewall in the Data Explorer by using the “Logging Resource Category” and “Logging Resource Name” dimensions and then excluding NetworkSecurityGroupFlowEvent (NSG flow logs):

Note: Azure Firewall flow logs don’t have traffic throughput information, so users must choose flows/s as the metrics instead of bit/s. This will create a visualization similar to the graph shown above, and allow Kentik to see flows going through the firewall. With these metrics, customers can determine the relative load of the Azure Firewall and attribute flows to the firewalls.

For customers seeking traffic throughput information from Azure Firewall Logs, the Azure team has advised using “Fat Flows”. However, at the time of publishing this announcement, the Fat Flows feature is in preview and unavailable for API ingestion. Once it is fully supported in the API, Kentik will add “Fat Flows” support.