BGP enrichment to flow-collected telemetry from a Kentik user’s network was historically made possible via public peering of a Kentik registered device to Kentik’s public BGP cluster (or leveraging the BGP table from another, BGP-peered device).

However, there are situations where devices exporting flow telemetry to Kentik cannot reach the public internet (e.g., have no public IP address for a BGP session with Kentik).

Enters Kentik’s BGP proxy, aka kbgp.

---

What is kbgp ? tl;dr

Kentik BGP proxy, aka kbgp has just been released in its initial beta version. It can be deployed in a private environment — upon deployment, the aforementioned devices will be able to peer with the kbgp instance which will multiplex and relay in real time, all BGP updates “as if” these devices were peering with our public BGP ingest layer.

Initial discussions took place around making kbgp a part of kproxy, Kentik's well known flow proxy. There's a variety of pros and cons, but for now, the main deciding factor was separation of concerns: the BGP and Flow proxy functions being fundamentally different, we wanted to avoid building a monolithic agent that would instantly become a single point of failure and also avoid situations where flow export could be interrupted by the BGP portion and vice versa. 

How does kbgp work ?

We are pretty proud of the design behind kbgp — a lot of engineering forethought was put into it and the early testing customers have been impressed with the polish, stability and scalability of this early version and are already starting to adopt it quickly.

Multiple Kentik registered devices can peer with a single kbgp instance, as it is highly scalable and takes care of all the multiplexing over a secure gRPC transport. Kbgp will not store BGP state to remain the least intrusive possible and will just manage state of the peering sessions established with it, as well as forward in real time, any BGP updates directly to Kentik.

This offers a few additional side benefits:

• kbgp scales very well (since there’s no storing of routes) and can accept peering sessions from a lot of devices — the max # BGP sessions per kbgp agent is yet unknown, make sure not to create a single point of failure.
• The transport that was chosen back to Kentik's BGP ingest layer offers a layer of encryption over the public internet to relay the BGP updates — it is an added benefit offered by gRPC.
• A great side benefit is that it unlocks IPv6 BGP peering (and therefore BGP related enrichments to IPv6 flows) without the need of establishing a public IPv6 BGP session. All that’s needed is an internal IPv6 address to peer with from the device, and the updates will be transported by kbgp using IPv4.

What comes next / How can you gain access to it?

As any Beta software, kbgp comes with a few rough edges, but our closed-beta testers have so far been very positive about it.

Contact your Customer Success Engineer if you want to get access to the agent and deploy it on your system, our engineering team is ready to welcome your feedback to make it better !

As we build kbgp's roadmap towards a GA, more features will be added to upgrade kbgp so that you can manage it more efficiently, this will likely include things such including it as a first class citizen in Kentik Portal, reporting the health of its host and the BGP sessions it proxies ... Stay tuned !

We may in the future consolidate kproxy and kbgp into a single binary, but to avoid each function competing for resources on the host and prevent the resulting agent from becoming a single point of failure, we may very well favor a mutually exclusive switch, turning the agent into one or the other. 
Don't hesitate to let us know what your thoughts are on this.