new.kentik.com Open in urlscan Pro
50.17.31.183  Public Scan

Form analysis
11 forms found in the DOM

<form class="search"><input type="text" aria-label="Search Input" placeholder="Search..." value=""><button type="submit" title="Submit Button" aria-label="Submit Button"><svg aria-hidden="true" xmlns="http://www.w3.org/2000/svg" width="14"
      height="14" fill="none" viewBox="0 0 14 14">
      <path
        d="M11.02 9.796l2.718 2.716a.81.81 0 01.262.613.874.874 0 01-.875.875.794.794 0 01-.613-.262L9.795 11.02a6.09 6.09 0 01-3.67 1.229 6.125 6.125 0 116.125-6.125 6.095 6.095 0 01-1.23 3.67zM6.126 1.75a4.374 4.374 0 100 8.75 4.374 4.374 0 100-8.75z">
      </path>
    </svg></button></form>

---

<form class="line-form"><textarea rows="1" label="feedback" aria-label="Feedback Input" placeholder="Send us your feedback" style="min-height: 30px; height: 33px; overflow-x: hidden; overflow-wrap: break-word;"></textarea><button type="submit"
    aria-label="Submit Button" title="Submit Button"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="19" fill="none" viewBox="0 0 20 19" class="submit-icon">
      <path fill="currentColor" d="M10.5 0A9.51 9.51 0 001 9.5a9.39 9.39 0 002.44 6.35l-2.29 2.3a.47.47 0 00-.11.54.5.5 0 00.46.31h9a9.5 9.5 0 000-19zm-4 11.5a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2z"></path>
    </svg></button></form>

---

<form class="line-form"><textarea rows="1" label="feedback" aria-label="Feedback Input" placeholder="Send us your feedback" style="min-height: 30px; height: 33px; overflow-x: hidden; overflow-wrap: break-word;"></textarea><button type="submit"
    aria-label="Submit Button" title="Submit Button"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="19" fill="none" viewBox="0 0 20 19" class="submit-icon">
      <path fill="currentColor" d="M10.5 0A9.51 9.51 0 001 9.5a9.39 9.39 0 002.44 6.35l-2.29 2.3a.47.47 0 00-.11.54.5.5 0 00.46.31h9a9.5 9.5 0 000-19zm-4 11.5a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2z"></path>
    </svg></button></form>

---

<form class="line-form"><textarea rows="1" label="feedback" aria-label="Feedback Input" placeholder="Send us your feedback" style="min-height: 30px; height: 33px; overflow-x: hidden; overflow-wrap: break-word;"></textarea><button type="submit"
    aria-label="Submit Button" title="Submit Button"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="19" fill="none" viewBox="0 0 20 19" class="submit-icon">
      <path fill="currentColor" d="M10.5 0A9.51 9.51 0 001 9.5a9.39 9.39 0 002.44 6.35l-2.29 2.3a.47.47 0 00-.11.54.5.5 0 00.46.31h9a9.5 9.5 0 000-19zm-4 11.5a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2z"></path>
    </svg></button></form>

---

<form class="line-form"><textarea rows="1" label="feedback" aria-label="Feedback Input" placeholder="Send us your feedback" style="min-height: 30px; height: 33px; overflow-x: hidden; overflow-wrap: break-word;"></textarea><button type="submit"
    aria-label="Submit Button" title="Submit Button"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="19" fill="none" viewBox="0 0 20 19" class="submit-icon">
      <path fill="currentColor" d="M10.5 0A9.51 9.51 0 001 9.5a9.39 9.39 0 002.44 6.35l-2.29 2.3a.47.47 0 00-.11.54.5.5 0 00.46.31h9a9.5 9.5 0 000-19zm-4 11.5a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2z"></path>
    </svg></button></form>

---

<form class="line-form"><textarea rows="1" label="feedback" aria-label="Feedback Input" placeholder="Send us your feedback" style="min-height: 30px; height: 33px; overflow-x: hidden; overflow-wrap: break-word;"></textarea><button type="submit"
    aria-label="Submit Button" title="Submit Button"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="19" fill="none" viewBox="0 0 20 19" class="submit-icon">
      <path fill="currentColor" d="M10.5 0A9.51 9.51 0 001 9.5a9.39 9.39 0 002.44 6.35l-2.29 2.3a.47.47 0 00-.11.54.5.5 0 00.46.31h9a9.5 9.5 0 000-19zm-4 11.5a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2z"></path>
    </svg></button></form>

---

<form class="line-form"><textarea rows="1" label="feedback" aria-label="Feedback Input" placeholder="Send us your feedback" style="min-height: 30px; height: 33px; overflow-x: hidden; overflow-wrap: break-word;"></textarea><button type="submit"
    aria-label="Submit Button" title="Submit Button"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="19" fill="none" viewBox="0 0 20 19" class="submit-icon">
      <path fill="currentColor" d="M10.5 0A9.51 9.51 0 001 9.5a9.39 9.39 0 002.44 6.35l-2.29 2.3a.47.47 0 00-.11.54.5.5 0 00.46.31h9a9.5 9.5 0 000-19zm-4 11.5a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2z"></path>
    </svg></button></form>

---

<form class="line-form"><textarea rows="1" label="feedback" aria-label="Feedback Input" placeholder="Send us your feedback" style="min-height: 30px; height: 33px; overflow-x: hidden; overflow-wrap: break-word;"></textarea><button type="submit"
    aria-label="Submit Button" title="Submit Button"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="19" fill="none" viewBox="0 0 20 19" class="submit-icon">
      <path fill="currentColor" d="M10.5 0A9.51 9.51 0 001 9.5a9.39 9.39 0 002.44 6.35l-2.29 2.3a.47.47 0 00-.11.54.5.5 0 00.46.31h9a9.5 9.5 0 000-19zm-4 11.5a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2z"></path>
    </svg></button></form>

---

<form class="line-form"><textarea rows="1" label="feedback" aria-label="Feedback Input" placeholder="Send us your feedback" style="min-height: 30px; height: 33px; overflow-x: hidden; overflow-wrap: break-word;"></textarea><button type="submit"
    aria-label="Submit Button" title="Submit Button"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="19" fill="none" viewBox="0 0 20 19" class="submit-icon">
      <path fill="currentColor" d="M10.5 0A9.51 9.51 0 001 9.5a9.39 9.39 0 002.44 6.35l-2.29 2.3a.47.47 0 00-.11.54.5.5 0 00.46.31h9a9.5 9.5 0 000-19zm-4 11.5a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2z"></path>
    </svg></button></form>

---

<form class="line-form"><textarea rows="1" label="feedback" aria-label="Feedback Input" placeholder="Send us your feedback" style="min-height: 30px; height: 33px; overflow-x: hidden; overflow-wrap: break-word;"></textarea><button type="submit"
    aria-label="Submit Button" title="Submit Button"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="19" fill="none" viewBox="0 0 20 19" class="submit-icon">
      <path fill="currentColor" d="M10.5 0A9.51 9.51 0 001 9.5a9.39 9.39 0 002.44 6.35l-2.29 2.3a.47.47 0 00-.11.54.5.5 0 00.46.31h9a9.5 9.5 0 000-19zm-4 11.5a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2z"></path>
    </svg></button></form>

---

<form class="line-form"><textarea rows="1" label="feedback" aria-label="Feedback Input" placeholder="Send us your feedback" style="min-height: 30px; height: 33px; overflow-x: hidden; overflow-wrap: break-word;"></textarea><button type="submit"
    aria-label="Submit Button" title="Submit Button"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="19" fill="none" viewBox="0 0 20 19" class="submit-icon">
      <path fill="currentColor" d="M10.5 0A9.51 9.51 0 001 9.5a9.39 9.39 0 002.44 6.35l-2.29 2.3a.47.47 0 00-.11.54.5.5 0 00.46.31h9a9.5 9.5 0 000-19zm-4 11.5a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2zm4 0a1 1 0 110-2 1 1 0 010 2z"></path>
    </svg></button></form>

---

Text Content

← Updates homepage Subscribe to Updates


PRODUCT UPDATES

Latest features, improvements, and product updates on Kentik's Network
Observability platform.


LABELS

 * All Posts
 * Improvement
 * Hybrid Cloud
 * Core
 * Service Provider
 * UI/UX
 * Synthetics
 * Insights & Alerting
 * DDoS
 * New feature
 * BGP Monitoring
 * MyKentik Portal
 * Agents & Binaries
 * Kentik Map
 * API
 * BETA
 * Flow
 * SNMP


JUMP TO MONTH

 * November 2022
 * October 2022
 * September 2022
 * August 2022
 * July 2022
 * June 2022
 * May 2022
 * April 2022
 * March 2022
 * February 2022
 * December 2021
 * November 2021
 * October 2021
 * September 2021
 * July 2021
 * June 2021
 * May 2021
 * March 2021
 * February 2021
 * January 2021
 * December 2020
 * October 2020
 * September 2020
 * June 2020
 * February 2020
 * August 2019
 * June 2019
 * April 2019
 * March 2019
 * February 2019
 * January 2019
 * December 2018
 * November 2018
 * September 2018
 * August 2018
 * June 2018
 * May 2018
 * April 2018
 * March 2018
 * February 2018
 * January 2018
 * December 2017
 * November 2017
 * October 2017
 * July 2017
 * June 2017
 * May 2017
 * April 2017
 * March 2017
 * February 2017
 * January 2017
 * December 2016
 * November 2016
 * October 2016
 * April 2016

ImprovementSyntheticsBGP Monitoring
yesterday11/10/2022


BGP MONITOR: UPSTREAM LEAK TESTING IS OUT

BGP Monitor tests in Kentik Synthetic Monitoring came out including tests for
the following elements:

 * Reachability: % of BGP Vantage Point threshold to determine whether prefixes
   are visible “enough” through the public internet
 * Allowed Origin: whether detected originators are part of an allowed-list
   (manually specified, or via RPKI) - this is commonly referred to as “Origin
   Hijack Monitoring”

The health of a BGP Monitor test was then the worse of these two tests, across
all prefixes registered in the test, with the specificity that “Allowed Origin”
could only be healthy or critical.

--------------------------------------------------------------------------------

The “Allowed ASNs” test has now been renamed “Origin Hijack detection” to match
what the industry is calling it.

Additionally, we have added “Upstream Leak Detection” - here’s the practical use
for it:

> In a normal situation, you only want your Upstream IP Transit Providers to
> announce your prefixes to the rest of the world: under no circumstance do you
> usually want your peers to announce your prefixes to the rest of the world as
> if they were your transit provider. They should keep these routes to
> themselves, and only use them to go from their network to yours (announcing
> them to their peers will break that partition).

Enters #4 step of the updated BGP Monitor test where you can now enter the ASNs
of your “official” Upstream Transit Providers and we will inspect the 1st hop in
the AS Path of all announcements of these prefixes (and of their more specific
children).







Remember that with all BGP Announcements collected from the BGP Vantage Points,
come an AS_PATH that gives the following information:

<vantage_point_ASN> …. various ASNs … <UPSTREAM_ASN> <Origin_ASN(yours)>

If the <UPSTREAM_ASN> is not part of your allowed list of Transit Providers for
any of the prefixes (and their more specifics), the entire BGP Monitor test will
be flagged as critical for “Upstream Leak”.

For further reference, the diagram below details Origin Hijack vs Upstream Leak








Read More
Greg Villain

Hybrid CloudKentik MapBETA
a week ago11/3/2022


KENTIK KUBE (BETA) HAS ARRIVED

We’re excited to announce our beta launch of Kentik Kube, an industry-first
solution that reveals how K8s traffic routes through an organization’s data
center, cloud(s), and the internet.

With this launch, Kentik can observe the entire network — on prem, in the cloud,
on physical hardware or virtual machines, and anywhere in between. Kentik Kube
enables network, infrastructure, platform, and DevOps engineers to gain full
visibility of network traffic within the context of their Kubernetes deployments
— so they can quickly detect & solve network problems, and surface traffic
volumes from pods to external services.



Kubernetes cluster running on AKS, displaying traffic and latency to the front
end of an online shopping site.




WHY WE BUILT KENTIK KUBE

Kubernetes has become the de facto standard for cloud-based applications. As
companies migrate their workloads, ensuring the reliability, connectivity and
performance from user applications and their clusters, to the entire
infrastructure and internet is critical.

Very often, pods and services experience network delays that degrade a user’s
experience. It is difficult to identify which Kubernetes services and pods are
experiencing network delays. The complexity of microservices leaves engineers
wondering if the network reality matches their design, who are the top
requesters consuming Kubernetes services or which microservices are
oversubscribed, and how the infrastructure is communicating both within itself
or across the internet.


KENTIK KUBE USE CASES

We built Kentik Kube to provide visibility for cloud-managed Kubernetes clusters
(AKS, EKS, and GKE) as well as on-prem, self-managed clusters using the most
widely implemented network models. Teams responsible for complex networks can:

Improve network performance

 * Discover which services and pods are experiencing network latency
 * Identify service misconfigurations without capturing packets
 * Configure alert policies to proactively find high latency impacting nodes,
   pods, workloads or services.

Gain end-to-end K8s visibility

 * Identify all clients and requesters consuming your Kubernetes services
 * Know exactly who was talking to which pod, and when.

Validate policies and security measures

 * See which pods, namespaces, and services are speaking with each other to
   ensure configured policy is working as expected.
 * Identify pods and services that are communicating with non-Kubernetes
   infrastructure or the internet — when they should not be.


HOW KENTIK KUBE WORKS

Kentik Kube relies on data generated from a lightweight eBPF agent that is
installed onto your Kubernetes cluster. It sends data back to the Kentik SaaS
platform, allowing you to query, graph and alert on conditions in your data.
This data coupled with our analytics engine, enables users to gain complete
visibility and context for traffic performance inside and among Kubernetes
clusters.


MAPPING YOUR NETWORK WITH KENTIK KUBE

Kentik Kube provides east-west and north-south traffic analytics inside and
among Kubernetes clusters. 










Network map showing EKS clusters communicating between AWS regions.

Kentik Kube can display details so you can see if your route tables, NACLs, etc.
are all configured correctly. You can drill down into a cluster to see if there
are latency or other issues. Our eBPF telemetry agent deployed into these
clusters lets you see the traffic between nodes and pods as well as any latency.










HOW TO GET STARTED WITH KENTIK KUBE

Kentik Kube is now in beta. You can apply to trial the beta by clicking on the
Kentik Kube section of the menu. Please share your feedback with us. We’d love
to hear what you think.

Read More
Christoph Pfister

ImprovementService ProviderBGP Monitoring
2 weeks ago10/28/2022


KENTIK MARKET INTELLIGENCE INSIGHTS ARE HERE!

Early this year we launched Kentik Market Intelligence to spell out the internet
interconnection ecosystem for you. It crunches large amounts of public BGP
routing data, and scores and ranks all networks in any market based on the size
of their customer base.

With this new release, we've added a significant feature set: Kentik Market
Intelligence Insights. 

--------------------------------------------------------------------------------


KMI INSIGHTS? TELL ME MORE...

Insights are the relevant news items around the networks and markets you care
about. When crunching the billions of BGP dump entries multiple times a day, our
platform now identifies interesting insights that get contextualized in the KMI
UI, coloring them with the networks involved and the market they are observed
in.

Sample insights can be: <This provider> added <this transit customer> within
<this geography> for instance, or any network adding new providers, as well as
rank changes and changes in routing announcements between two networks.







Each insight comes with a certain amount of mandatory attributes: 

 * A Customer Network: as identified in the Provider/Customer ASN relation we
   crunch with every run
 * A Provider Network: as identified in the Provider/Customer ASN relation we
   crunch with every run
 * A Market: the market this insight applies to
 * Insights type:  as explained before, our engine classifies insights based on
   their nature (see list in the screenshot above)
 * Magnitude: an arbitrary 1-5 value that helps order these insights from most
   important to least important, which is most often correlated with the change
   in prefix score, either plus or minus, between two networks

All these attributes have two purposes: helping the Kentik Market Intelligence
UI display them in context (see further down this announcement), and allowing
users to slide and dice these insights and tailor them to any subset they'd like
to keep track of.


CONTEXTUALIZED INSIGHTS

A new "Top insights" panel now appears on the right side of the landing page, it
can be collapsed/expanded using the top right [insights] toggle.







The landing page will display unfiltered insights, ordered by magnitude, and
this list of insights will by default follow the market filter used on the
landing ranking screen.

This side panel can be configured to include or exclude specific types of
insights, or to extend the period covered by the insights.







When navigating to any Network Details screen, the insights right-side panel
will be displayed on the "Overview" tab for this network, and filtered to focus
on the investigated network.








TRACK NETWORKS AND MARKETS THAT MATTER TO YOU !

A while back, we introduced Observation Deck, which is a place for every user to
compose their landing page with the areas of network visibility that
specifically matter to them, based on widgets from specific workflows and areas
of the product.

Kentik Market Intelligence now has its first widget and it's powerful!




 You can now create as many KMI widgets as you'd like so you can focus on the
markets and/or networks that are important to you.









In the future, we will add more KMI-related widgets to the Observation Deck so
that you can embed widgets showing rankings and visualizations from KMI.

We hope you'll enjoy this update as much as we do. Please send us your feedback
on it, we'd love to hear what you think!

Read More
Greg Villain

ImprovementService ProviderFlow
a month ago10/11/2022


6PE SUPPORT FOR BGP-BASED FLOW ENRICHMENT

Kentik added support for 6PE technology and BGP IPv6 Labeled-Unicast address
family to be used for Flow enrichment.

The IPv6 Provider Edge (6PE) is the technology that enables isolated IPv6
networks to communicate using MPLS LSPs over an IPv4 MPLS backbone network.

The diagram below demonstrates the typical scenario for the use of the 6PE
technology. CE routers which are at the border of the IPv6 islands, advertise
their IPv6 routes to the 6PE routers of the MPLS network. These PE routers are
the only dual-stack routers, which support both IPv4 and IPv6. The 6PE router
advertise the received IPv6 routes to other 6PE routers using MP-BGP session
over IPv6 Labeled-unicast address family. These route have:

 * Original IPv6 route received from CE
 * Inner MPLS label value, which would be used in the 6PE router’s data-plane to
   encapsulate packets toward IPv6 island’s networks.
 * Next-hop with the IPv6-mapped IPv4 address which is in the form of
   “::FFFF:<IPv4-address>”.
   * The mapped IPv4 address is the address of the advertising 6PE router.
   * It determines the Outer MPLS label which will encapsulate IPv6 packets
     inside the MPLS network







To perform enrichment based on the 6PE information, Kentik’s user should
establish the BGP session with the IPv6 Labeled-unicast AF between their 6PE
router and Kentik. Based on the received IPv6 LU routes the Kentik’s ingest
layer would be able to enrich the Flow’s received from those 6PE routers. All
“standard BGP” dimensions would be populated, but more specifically:

 * The “Next-hop IP” dimension will be populated with the next-hop IPv4-mapped
   IPv6 address from the received route
 * Based on the IPv4-mapped address, the Kentik ingest would identify the
   next-hop 6PE router and populate “Ultimate-Exit Device” dimension and based
   on that, the other “Ultimate-Exit” dimensions.

Additionally, to instruct the use of Labeled-unicast routes, a user needs to
select additional configuration for 6PE routers in the Kentik.  At the Settings
→ Devices page, select the 6PE router device and “Edit device”, then at the BGP
Tab, at the “BGP route selection” drop-down menu select the option  “VPN table,
fallback to Labeled-Unicast table, fallback to Unicast table”.

The example of the Data Explorer output with the 6PE BGP next-hop dimensions is
shown below:










Read More
Dušan Pajin

ImprovementService ProviderFlow
a month ago10/7/2022


BGP ROUTE SELECTION MODES

Kentik has added a new configuration option, which determines how the BGP routes
are selected for flow enrichment process. To make the whole process clear enough
we should start with the basics.


BGP SESSIONS

BGP session between customer’s router and Kentik can be established over:

 * IPv4
 * IPv6

Since these are “Multiprotocol BGP” sessions, for each of the sessions, it is
possible to enable multiple Address Families, for example: Unicast, Multicast,
Labeled-unicast, L3VPN, Flowspec, etc.

These Address Families are defined with AFI (Address Family Identifiers) and
SAFI (Subsequent Address Family Identifiers) attributes. They are regulated by
IANA and the exact values can be found on the following links:

 * IANA AFI numbers:
   https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml
 * IANA SAFI numbers:
   https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml

The Kentik side of the BGP peering with customer’s devices will be enabled with
the Unicast, Labeled-Unicast and L3VPN families by default. For the BGP “IPvX”
session from the Kentik side will have the following AFs enabled:

 * “IPvX” unicast
 * IPv4 and IPv6 labeled-unicast
 * “IPvX” L3VPN - (IPv6 L3VPN address family is not used)

Received routes from each of these address families are stored in the separate
route table, which is check during the Flow enrichment process.

NOTE: IPv6 VPN routes are received, but not used for the enrichment

The Flowspec address family will be enabled only if the customer explicitly
enable it in the device configuration on the Kentik portal.


BGP ATTRIBUTES ENRICHMENT PROCESS


ASSIGNMENT OF THE “ROUTE PREFIX/LEN” DIMENSION

The assignment of the Src and Dst Route Prefix is the following:

 * Src and Dst Route Prefix dimensions are first populated from the Flow
   information using Src and Dst Mask field from Flows - if applicable.
 * Src and Dst Route Prefix will be overwritten further in the ingest processing
   if there is a matched BGP route.
 * The way to know if the Src or Dst Route Prefix is coming from flow or BGP is
   by observing other BGP route attributes:
   * if the Route prefix originates from the flow information the dimension
     “Next-hop AS Number” will be “0 - -Reserved AS-,ZZ” and the dimension “AS
     Path” will be empty.
   * if the Route prefix is overwritten by the BGP information, the BGP related
     dimensions such as “Next-hop AS Number” and “AS path” will be populated


VRF METADATA COLLECTION

As the part of the SNMP interface discovery process, Kentik SaaS or Kentik
kproxy will perform the VRF discovery and interface association. This
information about the VRFs is collected over SNMP using MPLS-L3VPN-STD-MIB, if
the device supports it. The devices from Cisco and Juniper Networks support this
MIB. We have also developed support for for Nokia’s proprietary MIBs.

For each VRF, Kentik collects:

 * Name
 * Description
 * Route Distinguisher (RD)
 * Route Target (RT)
 * Interface association


BGP ROUTE MATCHING PROCESS

The enrichment of the BGP/Route related Flow dimensions is performed as a result
of matching the Flow’s IP address against the BGP route received from customer’s
device over BGP sessions. The default behavior of the matching process is the
following:

 * Flow’s Src interface is checked if it is assigned to the VRF.
   * If the source interface is in the VRF, flow’s Dst IP address is looked-up
     against the BGP VPNv4 routes with the RD associated with the source
     interface’s VRF:
     * If there is a route match, the route will be assigned to the flow
     * If there is no match, or there is no BGP VPNv4 table at all, or even no
       L3VPN AF established as part of the BGP peering, the match will not be
       found and BGP route dimensions are not populated.
   * If the source interface is not in the VRF, flow’s Dst IP address is
     looked-up against the “global” BGP table containing Unicast IPv4/IPv6 AF
     routes.
 * The same process is performed for flow’s source IP address route lookup,
   based on the destination interface association with the VRF.


BGP ROUTE SELECTION CONFIGURATION

To address some additional scenario’s that we have seen in the customer’s
network, Kentik added the configurable option to influence the BGP route
selection process related to which BGP routes will be used for matching process.

This configuration is available at the Settings → Devices → Edit Device dialog →
BGP Tab.







At the dialog, there is a new drop down menu called “BGP Route Selection” with
the following three options:

 * VPN table for VRF interface, Unicast table for non-VRF interface (default
   option)
 * VPN table, fallback to Unicast table
 * VPN table, fallback to Labeled-Unicast table, fallback to Unicast table

The following table describes the behavior of each configuration option:

Dropdown menu optionVRF interfacenon-VRF interfaceVPN table for VRF interface,
Unicast table for non-VRF interface- use only L3VPN routes- use only Unicast
routesVPN table, fallback to Unicast table- use L3VPN
- no match: use Unicast
- use L3VPN
- use Unicast
VPN table, fallback to Labeled-Unicast table, fallback to Unicast table
- use L3VPN
- no match: use Labeled-Unicast
- no match: use Unicast
- use L3VPN
- use Labeled-Unicast
- no match: use Unicast





Read More
Dušan Pajin


a month ago10/4/2022


SNMP: CPU AND MEMORY UTILIZATION FOR HUAWEI DEVICES

Kentik now supports SNMP collection of the CPU and Memory utilization for Huawei
devices.

--------------------------------------------------------------------------------

The Kentik’s ingest/kproxy will determine that the discovered device is Huawei
device by searching for the “huawei” string in the well-known SNMP sysDescr OID.

The Kproxy would monitor the following number of device’s “Components”, with the
use of the SNMP OIDs described below:

 * Iterate over ENTITY-MIB to get the descriptions of all the Components and
   their indexes using OID .1.3.6.1.2.1.47.1.1.1.1.2
 * Iterate over HUAWEI-ENTITY-EXTENT-MIBto get CPU and memory utilization for
   each component:
   * CPU utilization in percent, using OID: .1.3.6.1.4.1.2011.5.25.31.1.1.1.1.5
   * Memory utilization in percent, using OID:
     .1.3.6.1.4.1.2011.5.25.31.1.1.1.1.7
   * Uptime of the component, using OID: .1.3.6.1.4.1.2011.5.25.31.1.1.1.1.10

Kentik will ignore any components which have both CPU and Memory utilization
equal to 0.

The support is available in kproxy starting from version v7.36.0. The example of
the Data Explorer query is shown below:










Read More
Dušan Pajin

ImprovementCoreSNMP
a month ago9/14/2022


SNMP: CPU AND MEMORY UTILIZATION FOR F5 BIG-IP DEVICES

Kentik now supports SNMP collection of the CPU and Memory utilization for F5
BIG-IP devices. Some of the F5 BIG-IP devices do not support flow export
features, which means that the collection of the SNMP metrics would require use
of Kentik's kproxy with the “bootstrap_devices” option.

--------------------------------------------------------------------------------

The general behavior of the Kentik’s SaaS ingest or Kentik’s Kproxy is that the
SNMP metrics collection would only start once the flows are received from the
certain device. This behavior can be limiting in some cases and can be changed
by the use of the Kproxy’s Bootstrap devices feature. This feature is enable
with the use of the-bootstrap_devices command line argument. This argument
should provide the comma-separated list of devices’ IDs. For those devices, the
Kproxy will start the SNMP metrics collection immediately, without waiting to
receive devices’ flows. More information about the Kproxy CLI arguments can be
found in our Knowledge Base article:
https://kb.kentik.com/v0/Bd04.htm#Bd04-kproxy_CLI_Reference

The Kentik’s Kproxy will determine that the discovered device is F5 BIG-IP by
looking for the “big-ip” string in the well-known SNMP sysDescr OID.

The Kproxy would monitor the following 4 Device “Components”, with the use of
the SNMP OIDs described below:

 * Name “Global”:
   * MemoryTotal [bytes] - OID Name: sysGlobalHostMemTotal, OID:
     .1.3.6.1.4.1.3375.2.1.1.2.20.2.0
   * MemoryUsed [bytes] - OID Name: sysGlobalHostMemUsed, OID:
     .1.3.6.1.4.1.3375.2.1.1.2.20.3.0
   * CPU [percentage] - OID Name: sysGlobalHostCpuUsageRatio5m, OID:
     .1.3.6.1.4.1.3375.2.1.1.2.20.37.0
 * Name “TMM”:
   * MemoryTotal [bytes]- OID Name: sysStatMemoryTotal, OID:
     .1.3.6.1.4.1.3375.2.1.1.2.1.44.0
   * MemoryUsed [bytes] - OID Name: sysStatMemoryUsed, OID:
     .1.3.6.1.4.1.3375.2.1.1.2.1.45.0
   * CPU - value will be 0
 * Name “Other”:
   * MemoryTotal [bytes] - OID Name: sysGlobalHostOtherMemoryTotal, OID:
     .1.3.6.1.4.1.3375.2.1.1.2.20.44.0
   * MemoryUsed [bytes] - OID Name: sysGlobalHostOtherMemoryUsed, OID:
     .1.3.6.1.4.1.3375.2.1.1.2.20.45.0
   * CPU - value will be 0
 * Name “Swap”:
   * MemoryTotal [bytes]- OID Name: sysGlobalHostSwapTotal, OID:
     .1.3.6.1.4.1.3375.2.1.1.2.20.46.0
   * MemoryUsed [bytes] - OID Name: sysGlobalHostSwapUsed, OID:
     .1.3.6.1.4.1.3375.2.1.1.2.20.47.0
   * CPU - value will be 0

For each component  MemoryFree and MemoryUtilization are calculated from
collected MemoryTotal and MemoryUsed metrics. Each component use standard Uptime
which is collected at the device level from sysUpTime OID.

The support is available in kproxy starting from version v7.36.0. The example of
the Data Explorer query is shown below:










Read More
Dušan Pajin

ImprovementAPI
2 months ago9/12/2022


KENTIK’S PYTHON SDK VERSION 1.0.0 RELEASED

The important characteristics of the Kentik Platform are rich API capabilities
and the supporting SDKs. For the last two years Kentik has supported the
development of the community Python SDK which is based on the Kentik’s APIs.
This SDK enables our customers to use Kentik’s Platform APIs natively in the
Python programming language, with Python Objects and Methods instead of dealing
with the details of the API syntax.

--------------------------------------------------------------------------------

The Community Python SDK is available on GitHub:
https://github.com/kentik/community_sdk_python.

Just over a month ago, we released a new version 1.0.0. Until this version, the
community Python SDK supported objects and methods that are exposed within
Kentik’s REST API v5. With this new release, the support has been extended to
some of the endpoints of our new gRPC-based Kentik API v6, specifically
supporting Synthetics monitoring and Cloud Export configuration.


IMPORTANT NOTE ON BREAKING CHANGES

As it is already mentioned, Kentik’s API v6 is natively a gRPC API, but it also
supports the REST access. The community Python SDK is using the Kentik API v6
directly over gRPC. To accommodate communication with the Kentik backend using
both REST-based Kentik API v5 and gRPC-based Kentik API v6, the necessary change
has been introduced that would require a change of your existing Python scripts
and programs.

In most of the cases, you would initialize the KentikAPI object with the
constrictor that is using the api_url argument, for example:

from kentik_api import KentikAPI

client = KentikAPI(api_url=KentikAPI.API_URL_US, auth_email=email, auth_token=token)


The api_url argument would expect the URL to the Kentik’s API endpoint, which
would be in the form: https://api.kentik.com or https://api.kentik.eu. However,
the endpoint that is used for the Kentik’s API v6 is in the form of the host,
for example: grpc.api.kentik.com.

For this reason and to be able to configure API access information with the
single parameter, it was decided that api_url argument of the KentikAPI
constructor should be replaced with api_host argument. The argument is expected
to contain only the fully qualified hostname of the server hosting the target
Kentik API instance (the default value is KentikAPI.API_HOST_US which is equal
to api.kentik.com). Consequently, the Class variable KentikAPI.API_URL_US has
been replaced with KentikAPI.API_HOST_US and KentikAPI.API_URL_EU with
KentikAPI.API_HOST_EU

To summarize, if you upgrade the version of your Python SDK to 1.0.0 or later,
you will need for adjust the initialization of the KentikAPI to use the changed
argument, for example:

from kentik_api import KentikAPI

client = KentikAPI(api_host=KentikAPI.API_HOST_US, auth_email=email, auth_token=token)



INSTALLATION

You can easily install the latest version of the Python SDK using pip, for
example:

$ python3 -m pip install kentik-api


Let us know what you think about our Python SDK and feel free to submit any
contributions or issues over GitHub. Happy coding!

Read More
Dušan Pajin

ImprovementCoreSNMP
2 months ago9/9/2022


SNMP: CPU AND MEMORY UTILIZATION FOR PALO ALTO NETWORKS DEVICES

The list of supported devices from which Kentik can collect CPU and Memory
utilization is growing. Kentik now supports SNMP collection of the CPU and
Memory utilization for Palo Alto Network devices. 

--------------------------------------------------------------------------------

Palo Alto devices are using the standard HOST-RESOURCES-MIB, for CPU and Memory
usage. The Kentik’s ingest/kproxy will determine that the discovered device is
from Palo Alto by looking for the “palo alto” string in the well-known SNMP
sysDescr OID.


FOR CPU:

 * Component name is provided in the OID: hrDeviceDescr:
   .1.3.6.1.2.1.25.3.2.1.3.index
 * CPU utilization is provided in the OID: hrProcessorLoad:
   .1.3.6.1.2.1.25.3.3.1.2.index


FOR MEMORY:

 * Component name is provided in the OID: hrDeviceDescr:
   .1.3.6.1.2.1.25.3.2.1.3.index
 * Memory utilization is provided from the SNMP table: hrStorageTable:
   .1.3.6.1.2.1.25.2.3

The support is available in kproxy starting from version v7.36.0. The example of
the Data Explorer query is shown below:
















Read More
Dušan Pajin

ImprovementCoreFlow
2 months ago9/9/2022


FLOW INGEST: SUPPORT FOR VLAN FIELDS IN NETFLOW/IPFIX

Kentik now supports collection of the NetFlow and IPFIX fields for
source/destination VLAN, which we previously not collected from the received
flows. 

--------------------------------------------------------------------------------

The related VLAN fields are shown in tables below:


NETFLOW V9 VLAN FIELDS

Field TypeValueLength (bytes)DescriptionSRC_VLAN582Virtual LAN identifier
associated with ingress interfaceDST_VLAN592Virtual LAN identifier associated
with egress interface

Resource:
https://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00800a3db9.html


IPFIX VLAN FIELDS

ElementIDNameAbstract Data TypeDescriptionReference58vlanIdunsigned16Virtual LAN
identifier associated with ingress
interface. [RFC5102]59postVlanIdunsigned16Virtual LAN identifier associated with
egress interface. [RFC5102]

Resource: https://www.iana.org/assignments/ipfix/ipfix.xhtml

These two fields are collected from NetFlow/IPFIX protocols and stored in the
Kentik’s Source VLAN and Destination VLAN dimensions.

The support is available in kproxy starting from version v7.36.0. The example of
the Data Explorer query is shown below:










Read More
Dušan Pajin