new.kentik.com
Open in
urlscan Pro
50.17.31.183
Public Scan
Submitted URL: https://t.www.kentik.com/t/101106/c/0c782702-38cf-47fc-8e76-9c890f4a9309/NB2HI4B2F4XW4ZLXFZVWK3TUNFVS4Y3PNU7WIX3VORVT2ZBX...
Effective URL: https://new.kentik.com/?d_utk=d7dd035d-e0e5-4d61-9311-056d16221e2b
Submission: On November 11 via api from CH — Scanned from DE
Effective URL: https://new.kentik.com/?d_utk=d7dd035d-e0e5-4d61-9311-056d16221e2b
Submission: On November 11 via api from CH — Scanned from DE
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