Hedgehog VPC Peering Demonstration

My name's Manishh, I'm CTO for Hedgehog. Um, and so in this first segment, uh, I want to talk about the open network fabric and how we simplify networking. So, um, if you have to design a modern network, um, you have a few considerations to think about.

Uh, I've depicted here a, um, modern GPU training network, right? There's actually two networks, a front end and a backend. You have these servers with, uh, usually 10 plus ports that are connected up to your network.

And, uh, you have to make some choices in terms of, uh, how you're gonna configure things and what you're gonna do there. Um, if it's a little bit too small to read, that's kind of the point. Uh, there's a lot of, uh, moving parts and a lot of things to get right.

We make that a lot simpler at hedgehog through abstraction. And we have two main abstractions. We have the low level, uh, wiring diagram abstraction, which, uh, gives you the ability to describe what topology you've designed to the hedgehog system.

And then we have our operational abstraction, um, that we call VPCs or Virtual Private Clouds. As Amazon talks about them, I, I think it's not the best name, but that is what they're known by. And this gives you the ability to partition up your cluster into multiple tenants, connect those tenants together.

So, uh, when you're using Hedgehog, you have a few steps to go through, um, for your on-prem. So the first piece, the technology is not magic, and so you do have to still design and size your network appropriately. Um, so the question is, uh, you had asked, first of all, how many networks do you have?

Um, after, you know, all the converged ethernet stuff came out, it was, oh, it's easy. You have one spine leaf topology and you're done. With modern AI networks though, you usually have two networks, one for the backend, for the RDMA traffic and one for the front end for everything else.

Um, you then also have to, um, then decide, okay, well what am I connecting to that network? So how many hosts do I have? How many ports?

For example, in an AI network, um, usually you have a nick per GPU that's gonna be running today at about 400 gigabits per second. There's about, there's eight of them in a host. If it's the maximum density.

So you have eight ports to your backend network, and then the front end, you usually run two, 200 gigabit ports off of a smart nick of some sort. And so that's another two ports. Once you have that information, then you get to the fun part and you get to actually, um, buy some stuff.

Uh, so you get to go look and say, okay, well what kind of switches do I want and how am I gonna get all those port capacity in there? And the good news is that this can be daunting. There's a lot of options, but switch hardware vendors would love to help you with this problem because they get to sell you some hardware.

So once you have that system, um, built and wired up, uh, you have to specify to hedgehog how it works. And so you do this through what we call the wiring diagram and has a few different moving parts. So these YAML configurations that you see here are, um, these YAML configurations that you see here are the specification of switch configuration and the connections.

And so on the left you see, um, a switch configuration for a DS 5,000 switch. You specify what model is a switch, what role does it have spine leaf. You notice that you can very easily set up some AI options.

So instead of setting up tons and tons of options around queuing and loss and all that stuff, you can just say, Hey, uh, roki, true Roki, QPN, and you get those features for AI network if you want. Um, and then on the right you specify the connections between things. So here we have, um, a spine leaf connection.

So that's a fabric connection and then connections your server facing connections to your hosts. Um, everything's in YAML because everything we do is based on the Kubernetes API, and I'll talk a little bit about that. Um, next, so the next piece is that you actually have to bring everything up.

So Hedgehog itself, um, starts by running on a control node and that control node is connected to your management network and can speak to all of the switches on the network. And everything, like I said, is done through the Kubernetes API. So why the, hmm, oh, there we go.

Just stall a little bit. Um, why the Kubernetes API? So the great thing about Kubernetes API is that you now have a well-known API with a huge ecosystem of tools that you can use to actually configure the system.

So for example, if you want role-based access control, you don't have to go and figure out some hedgehog specific role-based access control. Kubernetes itself actually has a role-based access control mechanism that you can apply to objects in different ways, and that works just seamlessly with Hedgehog. The other interesting thing about Kubernetes, and we don't think about it too much, it's probably one of the most successful network orchestration platforms out there.

Now, you might think, well, wait a minute. Isn't Kubernetes there to deploy applications and manage them? Yes, but when you do that, um, the, um, overlay networks that are run in, uh, the CNIs are actually, um, managing your overlay network in that situation.

And so it's a very, very, it's a very, very popular network orchestration system. What we've done is add some CRDs to, um, extend it so that it can configure the physical network as well. So you take that wiring diagram, you feed it into that Kubernetes API, and what happens then is that the system is gonna use zero touch provisioning and boot and install the network operating system on all your switches.

It'll handle upgrades and lifecycle issues around those switches, and it configures an agent on each of those switches so that it can enforce the configuration that you've specified through our APIs. So that's the low level API. Now, you still have to actually have your cluster tenants, so you're not done just once the network comes up, you actually have to do something.

Um, if you don't have something like hedgehog, then multi-tenancy becomes an issue. Um, generally in a large cluster, you, there are times where you wanna partition that thing up, um, and you gotta figure out how I'm gonna do that. So are you gonna have a VRF per tenant?

Are you gonna run BGP with EVPN, with L two vxlan, maybe L three vxlan, what VLAN setups? There's a lot of configuration that goes into those tenants. And after you've configured that, then you have to figure out, okay, how am I gonna peer those tenants together?

What routes am I gonna leak? What route maps do I need so I don't leak the wrong routes? There's a lot of stuff going on here and it's all manual configuration, um, under the hood there to do that.

Make sure you don't make any mistakes as those things change because you can otherwise then connect tenants that shouldn't be connected and have, um, problems with that. So, multi-tenancy with hedgehog. Um, essentially now we have a VPC abstraction.

So on the left you can see this yaml, which is V vp, uh, sorry, which uh, describes A VPC. And so it has all the stuff that you would think about having for a network. So you can configure DHCP, your IP ranges, your host routes, and so on.

Um, we have different modes of operation, which is actually important. You can operate A-A-V-P-C and L two mode, which creates a layer two network across the overlay network or an L three mode. L three mode's important because if you're building, um, a higher speed network with say, Broadcom's Tomahawk five chip set, um, doesn't support L two VNI.

So you can use L three VNI and then you just say which hosts are on watch VPCs through, um, those attachments. When you do that, everything else is configured under the hood. So we configure B-G-P-E-V-P-N, we configure the VLANs, we configure the route leaks, the route, everything else that you need to get those tenants up and running.

Now it's not useful to have usually a tenant that just talks to itself. You usually want to talk to something else as well. And so here, um, you have peering.

So I've shown a peering object here on the left. Um, it's, this is a simple peering object. I'm not gonna, for time reasons, I'm not gonna go into the details of, um, the additional permit and deny stuff that you can have there based on subnets.

What we do here, um, when you push that peering object, we will now configure route leaks between the VPCs and those route leaks. Now allow VPC one to communicate with VPC two and vice versa on the IP addresses that were leaked. Um, not trivial to do correctly.

Um, it's very easy to leak the wrong routes and get more connectivity. So all the route maps and acls and everything to make this work are done automatically. I'm pointing out this route leaking too 'cause it'll become important and how the gateway actually integrates, um, with the product.

But for now, I'm going to hand it off to, uh, founder and chief architect, uh, Sergey OV to run a demo and show you how all this works. Um, and then we'll move on to the new material, which is gateway. Sounds good.

So, um, we'll start with, uh, taking a quick look on the, on the apologies that we're using for it. So for the demo, just to keep it simple, we have, uh, three switches. The, those are celestica DS 5,000, uh, 800 gigabit switches.

One is a spine to the leaves. Uh, the actual topology doesn't make a lot of a difference for the, for the demo, but uh, it's kind of more or less regular setup. And we have a gateway connected to, to the spine that we'll talk in, in the second part with demo.

Uh, but for now we will take a look on the 0 1 0 4, which are connected to B PBC one and the BBC two, we have a different subnets. Um, so I'll go into, uh, here and we'll have the example of the, of the VPC. So the VPC one, uh, here does have a subnet of 10 51 0 slash 24.

And, uh, like each VPC can consist of multiple subnets. Each of them are named some way, and you, you, you can define it. So for example, subnet zero one is, is a, is a name for the one that can be using in the demo and have a V attached to it.

So that's how the servers, uh, that turn servers, uh, gets attached to, to the VPC. And then we provide a bunch of out of the box functionality for the VPCs, like, uh, out of the box DHCP. And we can do the DHP relay for if, if you already have your own DHCP server.

And we provide passing like multiple customizations to like how, how DHCP will work, like, um, time servers, NTP servers, uh, customer routes, all the stuff that you, you, you expect from, from the HCP and the benefit of that we, you get all the DCP functionality out of the box despite the, uh, very complicated multi balance model. So you don't need to solve it on your, on your own. So now, um, if we, um, uh, look at the, at the probably back and, and on a, and here, so what I want is to just ping between the servers and uh, we can go, uh, to the environment.

Um, and uh, you can see like on top on terra one I have on 51 2 and uh, here on the bottom I have 10 52 2 IP address on the zero four. So if we'll just try to, sure, it'll disconnect on the demo. Um, yeah, if we would try to bring this IP address and I just pass a couple arguments to do MOS and some payload in them, such we'll more visible on the graphs.

Um, it's not working because we don't have a period between the VPCs. Uh, so now if we take a quick look on the hearing between the VPCs, VPC one and VPC two, uh, the minimal version of it is very simple. You just need to specify the pair of VPCs, uh, that you, that you want to able to talk to each other.

And we do allow to specify a little bit more about precision. You can say like, which exact subnets can talk to other subnets from between the two EPCs and we have more granularity using the gateway, which will be second part to a demo. So let's, uh, let's apply it now.

Um, so we just apply the subject. You can use like the, the one of the benefits of using Kubernetes is that you have all of the tools, uh, in a very good shape for Kubernetes because like a lot more people around the world using it to run applications. So you have all your gith tops or your like configuration tree detection, all the tool is very good tuned towards it.

And, um, here basically by applying that it's um, it is using it very simple YAML and it who the, we have a fabric controller that, uh, takes this object and converts it to the set of configuration changes that needs to be applied in the switches and switches right in the engine. That's basically pulling the API and uh, looking into what actual change need to be applied. So it detects configuration drifts, it returns some data on the monitoring and introspection from the switches and things like that.

So, so now if we would, uh, get back to the server. You can see we actually, we have a pink Ryan, uh, right now. So like one thing I want to demonstrate, uh, which, um, ish was mentioned is like how, how it's implemented on the hood.

So if we, if you go on a switch then uh, we can just take a look on the routes in the VAF and like each VPC is basically the VAF for another instance on a, on a switch. So if we just go to look at the routes in V PC one, you can see that we have some routes from the VPC itself, like we know about the host one two slash three two IP address that we had on the server one. And then you can see that about like a minute ago, like four seconds ago, we got, uh, another couple of IP addresses IP routes from the BGP.

Uh, that's exactly when I created the um, uh, period configuration in our API. It reconfigured the switches to actually leak routes between the VA Fs. So now we have some, um, some routes from the second VPC linked into the VAF of the first VPC.

That's how, uh, the connectivity between them and is established. And, uh, just to demonstrate it like another thing, um, we can go to like RAF fund board, it's just a Grafana cloud. Um, we support, uh, collection and exporting metrics to, uh, basically all the metrics from the switches.

Our control. Now a lot of insights like counters, uh, QAPs, um, typically all you can think about like over some, uh, over, over like interesting information from a switches. We do, uh, support like ate to the TUS compatible APIs and uh, we do collect all the logs as well and push it into working compatible APIs.

So essentially we have, so that it's compatible LG TM and API level, you can use it. And here, uh, just to kinda demonstrate it little bit that we use like switches to do that. Um, we have, uh, those switches they've been showing on a diagram attached to different leaves.

So essentially this, uh, this graph is from the spine and we are looking at the, at the two, uh, down links from a spines to the leaves and we can see the some traffic, uh, going there. That's why we see that basically the same numbers for two ports on a spine, 'cause two, two different switches sleeve, uh, sleeve switches are attached there. And that's kind of indication of that we're not not using gateway, we just, just directly appeared on the switches.

And that's it for the first part of a demo. Okay, great. Thanks.

One, one thing I wanna mention, by the way, about the, uh, Grafana cloud and the dashboards. Um, one of the cool things about the API is, um, you just have a small YAML file that gives you your credentials to your stack, your Grafana stack, and it connects and then automatically starts sending all of the, uh, all the data to, to either Grafana cloud or whatever your on-prem stack is. So you don't actually need to do a lot of switch by switch configuration or anything to actually collect the data in a centralized way.

It's also turnkey. Um.