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.

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.

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.

To simplify troubleshooting workflows in Google Cloud, we've added several new details to the Kentik Map for Kentik Cloud. In the Cloud Network Details sidebar, we've added support for displaying the Firewall Policies that apply to each VPC. We've also added support for displaying details about the Load Balancers deployed in each VPC.

The new Firewall Policies area complements the Firewall Rules area added in July 2023, which shows the actions taken by those rules—denied and allowed traffic—in the selected VPC. 

For troubleshooting, the VPC details sidebar is now the single destination for getting all information related to firewall actions and rules:

In addition, the Cloud Network Details sidebar now also contains detailed metadata about the load-balancers deployed in the selected VPC:

A lot of our users have been asking for a way to export a spreadsheet of a certain amount of configuration items from Kentik Portal, namely:

• Devices list as in "Settings > Networking Devices" 
• Sites list as in "Settings > Manage Sites"
• Users list as in "Settings > Manage Users"

This is now available on all of these screens by clicking the "Action > Export > Data Table (.csv)" on all of these three screens

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!