fbpx

Meet up with the Cisco Telemetry Broker Group: Ajit Thyagarajan

Intro

 

In my earlier blog in this collection, I spoke with Sunil Amin about his focus on the Cisco Telemetry Broker , the hot new item which allows customers to lastly have the telemetry across their business be programmable and open to any analytics platform.

Nowadays I’m here with Ajit Thyagarajan who’s in charge of the architecture of the Cisco Telemetry Agent. Ajit will discuss early prototypes, lessons learned in developing and building the merchandise, and present us a sneak peek into what’s arriving at Cisco Telemetry Broker later on.

Job interview

TK: Ajit, 1st tell us just a little about your background, as you and I proceed in the past to the first days of the web and possess adapted to numerous changes through the years. Ajit : TK, many thanks for achieving this – extremely excited to be taking part in this job interview. Yes, I’m quite fortunate to possess been mixed up in evolution of the web also to have spent period learning from a few of the visionaries who formed most of the core suggestions in place today. I spent plenty of my graduate college days focusing on Internet Protocols. I developed the theory for the existing version of the web Group Administration Protocol (IGMP version 3), worked extensively on different multicast protocols, and some of modifications to the present version of the System Period Protocol (NTP) around autonomous construction. It had been in this phase that I must say i created a liking for packet processing.

My initial real job after college was with an Web router startup creating next-generation hardware-based routers to maintain with the need for faster Web speeds. It was an exciting encounter, and I haven’t appeared back again since, having been associated with various companies constructing networking products.

I started concentrating on network security nearly about ten years ago. It’s been a remarkable area, where I’ve had the opportunity to leverage my history to comprehend how threats are shipped over the network. At Cisco even, I have spearheaded your time and effort around Encrypted Visitors Analytics, an extremely exciting solution to analyze network visitors intelligently and perceive threats.

      TK          : You started at Cisco towards the finish of 2018 and had been first assigned to boost on some of the Secure System Analytics (referred to as Stealthwatch in those days) products that procedure packets. How do you move from those achievements to the prototype of CTB? What issues were you influenced to fix?

 Telemetry     

      Ajit          : When I very first joined Cisco, I has been assigned to the group that has been looking into how exactly to mix the cloud and on-prem products right into a solitary offering. It was within my first off-site conference that it was taken to my interest that the FlowSensor had been experiencing performance problems and that provided my history with packet processing, I might want to help. I really was intrigued and jumped directly into the code. Within a little while, I experienced analyzed the architecture and discovered a few optimizations which instantly fixed the core overall performance issues, in order that was an enormous win! Since that time, we’ve added numerous enhancements like shifting to the info Plane Development Package (DPDK) to obtain much higher performance looked after resulted in us obtaining a brand new FlowSensor 4240 to the marketplace a year roughly ago.

The UDP Director (UDPD) was among the other products exactly the same team owned, and I began to dive heavy into its architecture and realized that it had been ripe for a significant refresh. I also began to understand the sort of issues that were becoming solved by the UDPD and understood that there is a much bigger possibility available on the market. It has been around that point that I was released to Vector Packet Digesting (VPP) technology and recognized the game-changing opportunity before us.

      TK          : Our viewers might not be acquainted with VPP so that it would be excellent if you would reveal what it will be and just why it became a simple area of the Cisco Telemetry Agent Nodes.

      Ajit          : I had been intrigued by VPP when I was initially introduced to it, as a whole information plane for high-rate packet processing especially. At its core, Day time CPU architectures to procedure packets not separately vpp leverages modern, but because vectors or groups. This takes benefit of both instruction and information caches to optimize the digesting of packets in a pipelined way. The resulting performance enhance can be one or two orders of magnitude. In addition, the VPP architecture emerged pre-packaged with a genuine amount of plug-ins for typical packet processing such as for example support for IPv6, various tunneling formats, numerous NICs, etc. and considering that it had been being supported by way of a great group within Cisco actively, it made a whole lot of sense for all of us to leverage this as a data plane, not only for CTB but additional products that necessary higher speed packet processing.

[Ajit photo will go here]

      TK          : All of those other development group and I connect to highly technical people in Sales and Consumer Success for suggestions. What are a few of the functions in Cisco Telemetry Agent which were not known whenever we began but had been found along the way?

      Ajit          : It's been amazing collaborating with the Product sales and Customer Success people to hone the top features of the Cisco Telemetry Agent. There are many features that weren’t planned originally. For example, High Accessibility (HA) as applied in the UDP Director permitted limited to two nodes with one node because the active and another because the standby. With CTB, we realized we're able to do better and applied it in energetic/active mode with an increase of than two nodes getting section of a cluster. Another had been in a position to classify all telemetry visitors as syslog, NetFlow, sflow, etc. in a port-agnostic manner. That is beneficial to know which sources are sending what telemetry incredibly.

      TK:           I've a few favorites if you don’t brain, I'd like you to talk with the feature code called Dead Destination Recognition (DDD) and why it is very important customers.

      Ajit          : Therefore DDD basically monitors every location for potential problems with configuration or visitors delivery. When a location is got by you that gets traffic just over UDP, it’s very tough to figure out if the location will be alive or not. Therefore, we applied a heartbeat system that permitted us to detect possible problems with the receiving program and thus possibly prevent gigabytes of information from flooding the system and overpowering switches and routers. Oftentimes, switches and routers deliver ICMP unreachable packets if the location is down back, compounding the traffic concern further, therefore eliminating this visitors storm in the entire situation of a down destination is super useful.

      TK:           One amazing function of Cisco Telemetry Agent is the capability to transform legacy protocols to contemporary customers on the fly also to transform contemporary protocols to legacy customers. Let’s discuss the VPC Movement Logs to IPFIX transformation open to customers. Why achieved it is performed by you and what were the challenges?

      Ajit          : Customers nowadays are significantly adopting hybrid cloud infrastructures. Among the common problems is that the various tools useful for analytics or presence haven't held up with the opportunity to keep track of both cloud and on-prem assets which brought about the necessity to transform cloud movement information to IPFIX for intake by a few of these equipment. Cloud providers furthermore aggressively roll out brand-new features rather than all tools be capable of benefit from them. Having a brokerage have the ability to transform a few of this information for tools to take in the structure they understand permits uninterrupted operation.

      TK:           I've noticed that architects really like Cisco Telemetry Agent and the idea infrastructure that solves all their telemetry routing. I noticed one consumer say, “I could finally treat just about all my telemetry for the business as program code!” Without spilling an excessive amount of, what is following for Cisco Telemetry Agent?

      Ajit          : We want customers to take into account CTB not as an individual box solution that will take telemetry in and pushes telemetry out. Instead, we wish them to take into account CTB because the next era Intelligent Telemetry Plane (ITP), where all the CTB nodes operate in tandem to control all the telemetry in the system, giving the client unprecedented visibility into who's producing what telemetry and how that telemetry has been consumed by which customers. Simplifying this by intelligently handling the telemetry in the client environment and providing an individual pane of cup will undoubtedly be how CTB evolves in the years ahead. Expect to see additional information around this once we roll out this ground-breaking functionality.

      TK:           It's been a genuine pleasure interviewing you and much more of a pleasure dealing with you on Cisco Telemetry Broker! Any parting thoughts you’d prefer to share before we wrap things up? How should our audience find you on the Interwebz?

      Ajit          : Many thanks TK! Been a genuine pleasure taking part in this interview it’s. I am super worked up about the opportunity before us. We have been really seeking to expanding the scope of the to other areas aswell for full stack visibility, so keep tuned in. If you're interested for more information about CTB or some of my interests, do connect to me on           LinkedIn          .

      Find out more           concerning the Cisco Telemetry Broker. If you’d prefer to see a few of Ajit’s newer presentations from Cisco Live, make sure to           check them out.          .
        <br>

 

%d bloggers like this: