 Hey, good morning, everyone. Thank you for joining us today. My name is Sintil, and he's Venkat. We are both from Dell Technologies, a CTO team, part of Sonic for a long time. So before we dive into Suzuki today, I wanted to provide a quick overview on observability. So what is observability? Imagine you have a black box. You cannot see what's going on inside it. But you can observe its external outputs. Observability is that very ability to understand the internal state of a system based on its solely about its external outputs. This means we can identify and troubleshoot the problem swiftly and more precisely using the only information we receive from the outside. So now let's deep dive into what, a bit deeper into what network observability is. What does it mean? Well, it is an extension of the concept of observability into the realm of networks. It is all about gaining insight into your internal network, internal workings of a network, understanding how the internal state impacts the business objectives and user experience. It is about being able to answer your questions about your network quickly and easily. So that brings us to an important question. Is network monitoring the same as network observability? The short answer is no. Although the terms are often used interchangeably, there are crucial differences between the two. Network monitoring focuses on measuring and tracking the performance of the system. On the other hand, network observability provides you a deep understanding of the system itself. So to sum up, while monitoring keeps a constant eye on your system performance, observability goes a step further, offers insight into the inner workings of your network itself. So that's a major difference. So it's good to understand both the concept, knowing how to implement them successfully, significantly enhances your network performance and understanding of your network. So choosing is not about whether you're choosing monitoring or observability. It's basically how you can integrate both in your system management principles. So show our fans how many people are aware of tools SuzyQ before coming here. Today, we are going to introduce to a fascinating tool that has been revolutioning network observability. It is called SuzyQ. What exactly is SuzyQ? SuzyQ is an open source multi-vendor network observability framework and tool. This tool allows us to analyze your network using vendor agnostic queries and methods. This means you can use SuzyQ to understand, diagnose, and improve your network, regardless of what hardware or software vendors are using. The story of SuzyQ began in early 2020 when it was founded by Dinesh and Justin, two experts who foresaw the need for a better way to observe and analyze the networks itself. The main goal of SuzyQ is to improve understanding of your network. It does that by gathering data using an agentless approach. That means that you don't need to have specific installations in the vendor NOS itself. So you are able to collect all the information in abstracted form. So that way, it's basically it's standardized the data format so that it's easy for you to compare and analyze. And SuzyQ stores all the data files in a pocket, a popular big data format known for its efficiency and flexibility. So you will be able to have fast queries based on the data and then you can gather much more insights into the network. So you can use, it provides multiple management interface, the command line interface, a graphical user, REST API, and even a Python programmatic interface to go and analyze the data you collected via that platform. It has a very simple architecture. So as you can see, you have a telemetry collector which collects the information from multiple things using SSH and REST API. And then it has parser, which parses the data. And then it comes back and normalizes the data and then updates into the universal repository. So from there, you will be able to query the system. So one thing which amazed me, I'll tell you a real life example, right? So let's take how SuzyQ can empower you without actionable insights and about your network, right? That's what the most compelling feature of SuzyQ, that's what I love about it when I initially saw the tool. Immediately the tool, I think they started development around April. I think I made my first contribution from Dell to support Sonic in around September timeframe itself. So because I took the tool and then I see the value it provided, right? You can ask what kind of questions I can ask the network, right? In terms of what kind of, what are the software versions I'm running in the system, right? It could be either a trivial SRNO questions or it could be a very complex question. What happened to my network at 3 a.m. in the morning? Why Node A cannot talk to Node B? That it can go that deep to give a quick example, right? So we were in the customer environment trying to deploy Sonic. We are asking them how much Mac table scale they need and they were talking about 140,000. Our devices doesn't support it. We need to implement Mac carving in order to increase the Mac L2 table size because they are an L2 network. And then we ask them, can we try this one tool which doesn't do much harm to their network? It just reads one variable. We tested it a couple of times in their production network and then it has a feature called gather once. And then we gathered the data and what we found out immediately within one hour, the customer was so surprised, right? They had only 28,000 unique Mac address. Whatever they thought about their network, they had 130,000 Mac address is not true. So it was so powerful and to understand your network, what you're running. So today it's all very complicated. So this one, what impressed me was you have thousands of devices across your data center. It gives you one CLI to you. So in the singles, you don't have to log into any of the devices. It provides you one single CLI. You can query all your devices and see what their state are. You can combine the queries in multiple ways. You can assert the system. So that's what brings the power of Suzuki in my opinion, right? So typically the other user example I could think of is after we deployed, typically in one of the customers, whenever we go deploy and troubleshoot, when the network is done, we need to find, they'll say, okay, this is the Mac address or IP address which is having a slow problem. So now the networking team has to go and find where exactly the problem is. So what happens is it took us, so we need to go into log into a system, go into a central part and see where the Mac address or the IP address subnet is. Okay, okay, this goes to this part. So okay, let me log into the border gateway of that part. And then I log into border gateway of that part and then see, okay, where this subnet is located and then I track that down to the actual rack. It takes me about 20 to 30 minutes to do that process itself. When the network is down, we don't want to go and do that kind of things. You just ask a simple query in Suzuki, find this IPR Mac. It gives you where all the Mac really, where it is originated, where all it is there across all the systems. So it's very easy for you to go and immediately tell and pinpoint what's going on in the system. So that's what I really love about Suzuki, right? So as I said, Sonic Integration at Suzuki was introduced by Dell at September. Suzuki uses, I initially, when I started using it, I didn't want to use Rester Management API. So I wanted to be really native so that we can support not only community distribution as well as distribution, but other distributions where people are supporting like us, Dell. So we wanted to work on both sides. So we used the regular SSH, Sonic CLI, Linux CLI and FRR CLI so that it works both on community Sonic as well as the enterprise distributions. And then it supports almost all the features that today, being it interface, BGP or BGP, VPN, MC lag. So all those features are already supported in Sonic. We wanted to give a quick glimpse of it. So I just, so this is how simple it is. In a sense that you go to a Suzuki CLI, you say what is ARP? And then it gives you what you want to do summarize. And then it tells you, I want to see what all the ARPs at leaf one. You can dump for the entire data center or entire part, what you have. And you can specifically query, okay, I want to do this leaf. I want to do this namespace. Or I want to do, look at this part, right? It's the entire, it's one CLI. You don't have to log into any devices. It's one CLI where you can gather that insight, right? More better is the programmable interface. You can assert your network. You can do an upgrade and after upgrade and before upgrade. You can say whether is there anything down in my network? Right, it's BGPs. It's the way it's behaving. I'm getting all the routes which I supposed to get it. So you can programmatically verify, you can put it into your CI CD systems and programmatically verify this thing. And it also has a simple GUI to understand the path and other stuff. Whatever you're doing in CLI, it can be done via GUI as well. But I prefer CLI, we are network engineers. We're still using CLIs. But the way I think about CLI and seeing that as a single management pain, that's what opened my eyes in SuzyQ. That's why I allowed about the tool because it's immediately I've been able to understand the network. We just wanted to give a quick glimpse of what SuzyQ is today to you. So we have a short demo. Hello everyone. So we took this sample topology wherein we have two parts and then connected together with the central part. So in this demo, we are going to focus more on the part one. And then I have the SuzyQ inventory files. Basically, I have all the IP addresses mentioned there with the SSH connection towards all these part one nodes. So basically what I have is all leaf nodes running Community Sonic 2022 November release. And then the spine nodes are basically the Enterprise Sonic version distribution by Dell Technologies. So this is what the versions. No, I'm just showing what are all the things present in the Sonic switches. This is the version and all the various containers running in each switch. So now, and then we are going to the inventory file. Just I mentioned like the inventory file as the all the nodes IP address and then the username password. And this is the Docker I'm running for the SuzyQ with the port exposed 85 01 for the GUI. And then I'm basically starting the polar for the inventory file. So the polar could be continuous or the snapshots or continuous basically periodically pulls all the nodes and then stores the information in the big data like central mentioned. And then there's a snapshot view as well. So you don't want to continuously monitor, pull the nodes and then do it. If you want to just get what is the snapshot of my part and a given point in time, you can do that as well. So right now I'm just going into the Sonic SuzyQ CLI and then giving various queries, right? For example, device show. Device show is gonna tell us for a given part of what are all the nodes available and the IP addresses and the image being used in those nodes, et cetera. So and then there are various options as well in the device show. For example, you can group by columns, right? There are various columns you can just put. Okay, for a given part, what are all the most names available? So you can just group by most names and then there are other options under the device. Basically you can get what are all the images running on this part. So you can just basically based on this information you can see, okay, these are all the nodes needs upgrade for security or whatever reasons, right? So you can do all that. So and then the current tables, these are all the tables being supported in various NAS today. So we have enabled that support for Sonic as well. So this is gonna provide all the, you know, R, BGP, MLAG and all those informations are available currently. So you can very well enhance the code to have additional capabilities as well. So and then this talks about what are all the, what is the interval and how many rows are there in the database and all that. So based on this information, we are gonna execute the various other queries that are available, for example, BGP show. So BGP show is gonna show what are, how many BGP sessions are available across pod, right? So what is the AS number being used and what is the session state and et cetera. So and then there is a BGP asset. So it's gonna basically solve pass right now. So if there are some problems in the nodes and basically it's gonna mention that what is the problem and what is the current state of that particular node. So this way you can quickly debug and what's going on this particular node and then we can quickly recover from that. So the various routes summarize is gonna provide how many routes are there and then the various ARP information available in there and then you can see their status. You can basically filter by the particular leaf node, filter by IP address, filter by MAC address and the various options are available. In fact, you can use the regular expression as well to pinpoint a particular IP address from a given node and then the MLAG, MCLAG information is available as well. So what are all the nodes available and what is the MLAG role on that particular node? And then the VLAN show. So this is basically gonna give you the global view of what's available in the pod. So the VLAN is one example where how many VLANs are available, how many ports are members of those VLANs, all that information you can query and as usual you can put all the filters like any other commands we have. So and then you can route show, you can very well filter the various columns, various OS names, namespace, all those filtering logic and apply on the data available in the DB. So I'm going inside the core router now to basically bring down to showcase the asset functionality available in the Susie queue. So I'm just brought down one of the link. So this should reflect on the BGP session right now. So I'll just go back to the Susie queue CLI to execute the BGP asset to see what's the status of the, so right now in the Sonic you see the session went to idle state from established. So if I go back to the Susie queue CLI it's gonna reflect on the state and you can easily see it. So the result would be failed saying BGP notifications and the whole time it expired because we brought down the link. So this is one example. So there could be many things you can observe with this Susie queue. So like Sandil mentioned, there are times start time, end time and all those things are there. You can execute complex queries in order to get what's happening in the part network. So these are all the information. So you're available with Susie queue. With that I would like to end this demo and hand over to Sandil for any closing thoughts and call for action. Thank you. So I think, thank you Vangat. I think hopefully this would have provided a glimpse of what Sonic is and a good introduction to you. So Susie queue is a license and an Apache license so which makes it freely available to use for modification and an enterprise version is also available offering additional features and support. So here are the key resources. I wouldn't walk you through all these things. So there is your first stop is a GitHub where you can go and play around it. It's just four commands for you. You do a Docker pull, put your IPs and start the polar, you're done. So since it's a column or database, you can filter and query, you can slice and dice it any way you want. So that's what's more powerful about it. So key takeaways, right? So network observatory is not just another bus word in the IT industry. It's a crucial concept that has tangible impacts on the organization of all sizes, right? Achieving network observability comes with a plethora of benefits. Firstly, it enhances your network visibility, enabling you to understand your internal network workings. The first thing and foremost, I keep repeating this myself. Most of the customers we went and maybe go into, right? So they don't clearly understand what's going on in their network. So this provides you first and foremost to better understand your network. What is there in my network? I'm a running VLANs. How many VLANs are in my network in total? How many MAC address, what is the scale? Did I, my uplink is all almost done or how much is the bandwidth? Do I need to upgrade in the next cycle? Do I need to upgrade for higher grade switches? How many ports are still open? How much bandwidth still I can support? So some basic questions to start with some basic questions, some complicated questions at times. How my network has grown over the period of time. But it can do all those things for you, right? The key thing is about, so Suzuki also allows you to access information without risk of logging in, right? So that's a key feature I already talked about. So you don't have to log in each and every device. It's just one CLI, you do it. And then it takes away all the mechanics of parsing, coding and all those things from you because it's an abstract information. You can compare all this data across Sonic, Arista, Cisco, Juniper, everyone together, right? It gives you the same format for everybody. So it's easy for you to understand because most of the network has an heterogeneous network. So it provides a holistic over time. So that's the benefits of Suzuki and Sonic. So I would like to take a shot. And finally, as we come to the end of this discussion, the profound impact SuzukiQ can have in your network observability space. We'd like to take few calls of action. Firstly, encourage you to explore and understand what SuzukiQ is. It's much more simple. So take it for a test drive. I was telling Tim, it's just one command. Just right now we can pull in and then show we actually have a live demo we wanted to show you. So we didn't want this laptop. So that's why I stopped it. If somebody is interested, Wengat has this in his laptop. So you can play around with Suzuki if you want. Take some time. So take it for a test drive. Try to deploy it in your lab networks whenever you do lab. So see how powerful it is for yourself. And then come back and contribute, right? In conclusion, SuzukiQ is more than just a tool. It's a community as well. Like how Sonic, a growing community of dedicated network enthusiasts who are trying to make network much better, to manage the network much better. So we invite you to join this community, learn and contribute. Thanks for listening to us. If you have any questions, I'd be happy to take that. Yeah. I don't want to specify any names, but I know that few companies are already using it. It's been deployed. And they are all happy and they're asking for you and other nurses support for us from DelVial. So they're asking why can't you do this for other centers, right? So it's already deployed. It's not part of foundation. No, I don't think so. I'd love the question. Thank you. So I think this is valuable. I have not seen this tool anywhere in the open source out there. There are a lot of tools for monitoring and other stuff for observability in the application world. For networking, there's nothing there. This is the first tool, which we've seen and then got impressive. Right now, there's a very small community, which works on it. It's all GitHub. So there's no, it's not under any foundation. It's all in GitHub. Dinesh, Dinesh from Cumulus. If you... No, former cumulus employee and Amazon, Justin from Amazon. Now I think even Linux foundation, Nila is the co-founder right now because they saw the traction. I think they started an enterprise version of it. And Nila and Dinesh are heading that. Nothing, nothing. Yeah, just as I said, right? So when I implemented this for Sonic, we used, we didn't want it at the time because it's just 2020, the management framework is not there yet. It is not. So I tried to use, even though we internally had management framework, I didn't want to just support management framework. I wanted to be, it supports both community and Dell versions of it. So I used to implement this with the CLI piece of it. One thing, because it's already supported cumulus and FRR, it's much more easier to adopt to Sonic that way as well. So that is another reason why we went that route. So it was very, it's not a big effort to integrate Sonic into ZUZIQ. For that matter, any NOS, it's a straightforward way to implement, to bring in other stuff. Yeah, it is SSS access. Venkatak showed you how you can pull the inventory. You can pull the inventory from Netbox. You can pull the inventory from Ansible. You can use the keys. You don't have to use an Mpassword. So all those are supported. You just download the Docker. Update your inventory. Start the polar. That's about it. Once you have it, you have access to the CLI. And you'll be really amazed. I'm telling you. When you see that, the entire network and then seeing it one shot and then going for all the CLIs, if I do a MAC address and then say unique MAC address in the system or unique, how much devices I have. So it's one CLI for all the boxes. You have 1000 boxes, you just dump. It's thousands and thousands of rows. So it's up to you. How do you want to dice it and slide it in? Because there's a column at a database and it can go across tables. So you can mix and match however you want. Yes. Yes. And it's just scraping the data. And then if you think that it'll be a bigger burden, that each polar, each table has a separate timer. So you can tune it according to your network, how big your network. You don't want to pull that much. You can slow it down, fast speed it up. So those things are possible. It's pure CLI scraping kind of thing today. And you can use REST API as well. I would eventually want to migrate to the REST API and structured format, but right now it's all purely CLI. Oh no, REST API, Suzuki is still outside, right? There is no agent. So we are just making the REST calls to the Sonic and then get the data back, right? But it comes as a structured data. Right now I am trying to scrape the data with regular expression and everything. If somebody changes Sonic CLI, changes tomorrow, somebody will introduce a new CLI. My regular expression might not work going forward, right? I have to keep updating this text there for some formats to make sure that it's always compactable, right? So that's what the consides are. I would like to migrate to, as soon as we have the full management framework support. So we have the management, we are planning to additional supports for management framework is coming in Sonic, right? With that, we should be able to support all the future via the standard REST API formats. No, there is work required in Suzuki. It's other way around. It's reverse way. So what I do is because I am supporting Sonic, so I will go when the release comes out, I'll run Suzuki once, make sure that everything is there. It's not only me, there are a lot of folks in the community who actually deployed in Sonic, they are really interested in this one. So they have actually provided a lot of fixes as well, patches as well to this one. No, nothing like that. Yeah, anything more? Thank you. Thank you so much. I appreciate all your time listening in. Thank you.