 Okay, great. Good afternoon. My name is Matt Peterson. I work in the office of the CTO at Cumulus Networks And I'm filling in for for Nolan leak my boss the CTO who's right in the front here with the long hair So they keep me in check. We're going to talk about deploying open stack fairly quickly Driven kind of from the network perspective Now a lot of folks don't necessarily realize what Cumulus Networks does so we provide a Operating system for bare metal switches so the operating system is a fork of Debian and what's neat about Cumulus Linux is that it's hardware Accelerated so you get the same performance of our traditional switching platform But the flexibility of Linux as the management or the control plane And so we're going to kind of break down essentially going from the loading dock into production I'll show both a video and some slides that kind of give you some background of how that's accomplished The first thing to start off with is getting an operating system installed on these bare metal switches So you might have heard of bare metal switches or white label switches The analogy here is the same as compute so when you're buying a compute platform Say a super micro or a Dell or an HP Typically you're not getting the operating system bundle at the same time So you'll use a USB stick or use pixie to install that operating system on that compute device We follow that same model in the networking space. So we use an open source bootloader called ony This is something that cumulus networks contributed to the open compute foundation And it's effectively a method of installing an operating system completely unattended We like to call it pixie on steroids if you will and so what's great about ony is that it supports a lot of modern Protocols like DHP v6 You can download images via HTTP it includes request headers like the serial number of the switch and the manufacturer So it's a real nice way to get the operating system installed on the bare metal switch completely unattended When we look at cumulus Linux the product itself as I mentioned It's based the current product is based off of the Debbie and wheezy distribution And there's a lot of value add and not creating a brand new distribution that doesn't include some heritage And for us one of the great things about that is that you can take advantage of the robust packages that are available for Debian So Debian has little over 40,000 packages available and their app get repository Those are available to be installed on the cumulus platform So if you have a particular library or scripting language or maybe even a text editor that you want to be able to use on your network Device that's completely possible with the cumulus Linux our model is that the switch should look and feel like a server So when you run if config you see all 48 ports same way you would manage a server in terms of using configuration management or Monitoring or even triple a say LDAP for example again That would be applied the same way on the networking side all the tools run natively So if config IP route to quagga LDP all these standard network tools that you would use on a server That has a couple nicks those all run natively under cumulus Linux So it's obviously required at open stack an open stack event that we have an open stack diagram And so where we fit into the picture so cumulus Linux again is an operating system for bare metal switches And it provides hardware acceleration So that means that we're getting the same performance as traditional switches But again that flexibility of the management of the control plane Within the open stack world what that allows you to do is pick and choose different architectures So you may choose using overlay technology like a conda or a metonet You may want to do a more traditional layer to Deployment so you only have only have one or two racks You don't need a large overlay technology maybe in that case So there's a lot of flexibility in the architecture that you can deploy and again This is radically different than a lot of the other traditional network vendors would have a very prescriptive approach of this is the only way We support open stack. We're very flexible on different deployment models there So I want to walk through our example here We have what's called a solution guide available on our website and a solution guide is essentially a PDF document That includes all the steps to accomplish this end result both do using automation Which will walk through and all the manual steps that includes all the prerequisite documentation to like diagrams a bomb list of items to cable up or buy So it's very prescriptive on how to do this deployment So if I'm going kind of fast Just realize that you can download the documentation for what we're talking about this afternoon So we're going to start kind of a very basic architecture using M lag That's a multi link aggregation pretty much every switching vendor every NOS vendor has some sort of layer 2 Technology that can span multiple switches and have a common layer to a broadcast domain Cisco calls it VPC Juniper virtual chassis Arista calls it M lag everyone's got a slightly different name But essentially it's the same goal of expanding a layer 2 domain between multiple switches And still having some high ability or redundancy with spanning train So what does that look like starting from the kind of the basic building block of a single hypervisor? So in our example, we're connecting a physical compute device to two different switches and an active configuration So from the hypervisors perspective, it looks like a standard LACP link or a link aggregation link There's no hacking or any changes required on the hypervisor It just looks like a normal link ag now obviously in that hypervisor We're gonna have multiple tenant networks that are present there There's a link between the switches as a communication or a signaling link Essentially to do a heartbeat another health check statuses between the the m lag or the C lag environment These deployments can be fairly small typically we see m lag used for Two to four racks are very small deployments, but you can continue to expand them out So that that scales pretty efficiently Particularly for smaller deployments to get started a lot of folks again They like to start off with m lag because it's a kind of a known quantity in terms of Debugability and it's fairly simple. There's no V-lands or overlays or tunnels or anything in between their traffic to get that architecture up and going so it's a very simple Initial implementation if you will So part of our goal was to have some constraints here that represented exactly what a customer would experience And so in our model here for this solution guide We basically use a USB stick the provision not only the switches, but also the compute devices And so because of that we have some basic constraints. We need to know how the cabling is configured We attempt to auto-detect that as best as we can But we do have some requirements that there's a minimum amount of cabling between switches that are running the the m lag Signaling protocol and that there's a minimum amount of bandwidth available as you build this architecture And again, that's all spelled out in the solution guide It's not strict on on the speed, but again, it's a best practices for deploying this architecture So I'm gonna roll through a video that kind of walks through the steps the video is about three minutes And I'm gonna annotate it along the way so that we can get a little bit of a look and feel of how that would That deployment would occur Let's get this up here So we made this video in collaboration with Dell who's one of our hardware partners and you can go to their booth out in the floor And again, the idea here is that we're modeling from going from the loading dock into production all the steps that would be required there Now obviously we advertise this as a 20 minutes or less if it takes your facilities team You know three weeks to open up a box obviously that's not going to be 20 minutes or less But the time is basically when you stick the USB stick and engage the power So as you notice here, there's a requirement of cabling that we show in the video The intention here is that there's enough bandwidth going down between the leaf and spine switches We plug in the USB stick because the device doesn't have an operating system installed on it The very first thing that occurs is the only mode gets initiated And so only is again that open source bootloader very similar to pixie and functionality of it very modern So again, it has things like HTTP, SCP, FTP It's not just a single threaded TFTP IPv4 only solution Only can also source from a local USB device So again, one of the constraints that we set up in this demonstration was the idea of setting a complete deployment Without any internet access and again very prescriptive on the cabling that's done So what will happen the very first time is that the only bootloader is run And that installs the operating system completely unattended So if we look at this screen here, we see the bootloader of the switch that we're using This is an S sorry an S6000 which is a 32 by 40 gig switch from Dell And so it will have its standard bootloader to get the system up and going Only will then initiate only goes through various waterfalls So it detects if there's a ethernet plugged into the management port If there is it will bring link up it will attempt IPv6 neighbor discovery DHCP v6 Eventually it's going to fall back to a known static IP address It will continue that waterfall also for the discovery protocol So for example, it will attempt to look for a DHCP response That includes a URL of the image that it needs to download If it doesn't get that response, it will then assume that the DHCP server is also an HTTP or FTP server So again, it goes through these waterfalls on getting out of the network Using a discovery protocol or a file transfer protocol and then the file name So the file name can be very particular of a certain platform and a manufacturer and an architecture Or it can be a very generic file name And again, in this use case what we're doing is installing from the USB stick So as you can see it mounts from the USB stick Basically it extracts the image and runs make a fest does all the various partitioning and installs the operating system And again, this is typically done unattended and out of band One of the great things about only is that it allows monitoring capabilities as this installation is occurring So it does syslogging if you send that DHCP response You can SSH or telnet into ONI So again, our goal was to kind of free the environment of using console cables Making it very modern to approach provisioning Now the first time Qmuslinix comes up again looks very similar to a traditional debbing based operating system One of the things you'll note here is that because we've installed Qmuslinix the first time There's no license key to enable the platform to actually load all the front panel ports So the way that we do license enforcement on Qmuslinix is that a license file must be present To start up a process which we call switch D which enables those front panel ports that be available Without the license only the EF0 or the management port is available And so as you can imagine we have a same very similar workflow for Qmuslinix And the sense of zero touch provisioning pretty much every vendor has some methodology of zero touch provisioning Typically that is I'll fetch a configuration file That happens to be the name of my management mac address for example And the Qmuslinix world we're very flexible on what you can use for a zero touch provisioning script Essentially what we do is a DHCP request on that management ethernet zero port We look for a url response. We fetch that url And we go ahead and execute that as a shell script now. There's some Safety checks in there. We look for a regex that's present in that shell script And on the Qmuslinix platform We ship with bash ruby python and pearl pre-installed So you can write your ztp script in those four different languages Or you could in fact call an app get to install an additional language or library if you needed to And so in this particular example What we're doing is sourcing from that usb stick Again the ztp follows our owning methodology where it will discover on the network first If that's not present it can also discover locally with a usb stick Again same sort of waterfall approach to what that file name is that it executes the ztp script as And so we're doing a number of steps here in terms of installing a license Getting the platform up and going and because this is the first switch. It's the genesis switch of this deployment We're going ahead and we're enabling a DHCP server. We're enabling an ntp server dns server enough infrastructure So that all the other switches and compute devices can be booted off the network So one of the things that we mentioned in the solution guide is that all of these switches And all of the servers are plugged into an out of band network And on that network is where we're running this infrastructure that provisions the environment So the very first thing that happens is this initial genesis switch gets enabled with various demons and configurations So you can see a little bit of that coming out in the console. Again, this is intended to be a completely unintended operation So the the output is is not the prettiest because generally you're not plugged into the console cable for these various steps as you can see The system has been configured with a hostname. It also has a configuration file That it's received for its network. So we have those peer links Those are the m lag links between the the paired switches and then we have other various links As as this is nova net where we have a range of vlan tags that we're supporting So next we're going to have The next switch come up, which is mated with this. So we call the first switch spinal one The second one is spinal two and again, it's got a source from the network Ztp script. This one the outputs a little bit more verbose a little bit easier to see One of the things that we're doing in this script is detecting the cabling as I said earlier on We're prescriptive in the amount of cabling but not necessarily the speed or which ports it's plugged into So we try to auto detect that as best as we can So this is the second switch that we're building. It will find its mated pair. We're discovering that based upon A lldp chassis mac address. So that's essentially a unique identifier between the platforms It's detected that its peer is spinal one Its ip address and its mac address of its peer and then it will start configuring its local interface That it's bringing up so its local et cetera network interfaces file It installs a license all the other prerequisites to get the platform up and running Obviously restarts various demons any other dependencies Now on the server side, we didn't actually capture a video that shows traditional pixie booting I'm sure everyone's seen that and it loves pixie. It's it's awesome. It's everyone's best friend But essentially there because on this network, we've offered a dhp server and a tftp server We can install an operating system completely unattended and our solution guide We're actually using a buntu's Distribution for open stack and we essentially offer a pre seed file That the servers will fetch down and each time a server finishes completing its installation That's recorded on the the genesis switch And so we can enumerate the hostname for additional servers So the first server will be called controller 01 The second server will be computer 01 followed by computer 02 and that will continue to enumerate great So obviously at the end of this where all the switches and the compute environment has been provisioned Then you go into your your standard, uh, you know horizon interface To create a vm So because the the talk is limited to 20 minutes today We didn't want to do Exactly everything that you could see we want to refer you to our solution guide that's available And a demonstration that's available both in our booth and the del booth We go back to the slides here to just highlight very quickly Some of the approaches that were shown in the video again We use the usb stick on that first genesis switch that installs that switch environment But it also makes a infrastructure available on the management network or the out of band network So all the other switches and all the compute devices can install completely unattended The shell script that runs on here is fairly simple All these scripts are available as part of our solution guide So we try to make these as as simple and easy as possible. These are mostly bash scripts There's a little bit of python that does things like ip calculation that sort of stuff But it it's fairly easy to read The intention was that a lot of our customers are network engineers that may not have a lot of scripting or linux knowledge So we wanted to make it fairly easy to be able to uh read these scripts and see all the various tasks that are occurring Again This initial genesis environment is really setting up the infrastructure for all the other switches and compute to install The additional switches are slightly different right because they're booted from the network and they receive again The license and their configuration over the network We continue that for enumerating what their host name is and what their ip address is On the server side, um, again, we we serve a pre seed file We have a small little cgi that basically enumerates the host name Some of the raid settings that sort of thing makes it very easy to just Install all these compute devices again completely unattended Our model here is that if you cable it correctly And you put all the devices in this kind of factory default state You should be able to walk away in 20 minutes. All this infrastructure is built for you After the pre-seed is done We essentially do a phone home to say this device has completed being installed as compute device The bios has still configured to boot from the network So we actually write out a pixie config that says next time that compute device boots Boot it from the local hard drive This is a trick that a lot of infrastructure providers will do Again on the open stack side We're using a bunch use distribution and we use a number of puppet modules to get all the open stack infrastructure up and running It's very simple. It's essentially a one-time script that runs Puppet agent to get all the dependency packages installed So we have a link up at the top there and again We've got a tar ball and a zip file that includes all the examples that we showed here today Both documentation and also the scripts that are available One thing I wanted to point it out was a lot of people came in our booth and wanted to get the the rocket turtle We have some rocket turtles down here. If you'd like to get one, we just have to scan your badge And I have eight seconds for questions. So Any questions in three seconds? Okay, thank you very much. We'll be back at the back here at the cumulus booth. Cheers