 Sounds on. Hey, guys, thanks for coming out. This is a session that we're going to talk about how to troubleshoot SDN. I call it Dude Where's My Packet. Myself, my name is Michael Ford. I am director of technical services for MediCorps. I run our field team, field engineering, training, professional services, all of these kind of things. So I have a pretty wide background in terms of startups, customer facing roles. I'm the internal champion for the customer. And so I have a pretty unique perspective in terms of operators of clouds. I'm also our head brew master, our barbecue pit master, and a car mechanic. I actually put these in here for a reason, because just like troubleshooting anything in technology, technology troubleshooting is a very personal thing. A lot of people do it a different way. It's part art and part science. So basically, in a traditional sense, I say it's broke. Now what? When you think about traditional networks and what you're going to do with troubleshooting, there's a lot of different tools that you have to use, a lot of different areas to troubleshoot when we're talking about networking. You're going to use your Linux foo, your Google foo. You're going to do a lot of different stuff. You've got to go to all these different places, use Wireshark, of course, TCP dump. And that's actually really time consuming for a lot of operators. You need a lot of patience. And for me, when I do troubleshooting, you need a lot of beer. You've got to have this patience and beer. If you think about cloud operators and the way things are working with traditional neutron, traditional OVS troubleshooting, your dumping packets here and there, your checking over here for this port and trying to TCP dump it and check the routing tables, and it gets actually really complex. And it's very, very difficult. So let me go back one here. When you think about the rise of the SDNs, all of our competitors at Midecora, you have basically a packet. When it left the VM, it enters a black box. And I put this in here. It enters a subspace wormhole and magically appears on the other side. And I say that because you don't know what the packet's doing. And that's a very fundamental thing that you have to know when you're doing any kind of network troubleshooting. As I say, when it presents the problem to the traditional operators, you're trying to understand why a failure happens, why a VM can't talk to another VM east-west inside your cloud, or even north-south when you're sending it out, doing NAT or anything, layer three. So the traditional operator, they need to have an understanding of exactly what's going on with these packets. And so here at Midecora, we designed a technology to allow you to look into that black box, which I'll show in just a minute. But the main point is that when you have the knowledge of what's going on with the packet in your environment, this allows you to have a more confident approach to running and operating your cloud. You can sleep better at night. And we all like to sleep a lot. So it's a very good thing. So back to, dude, where's my packet? As I was saying, so this packet troubleshooting, the connectivity issues in the cloud, this is the number one thing that you're going to do when you're operating a cloud, especially with an SDN. You're going to have a developer come to you at some point, and maybe they're running continuous integration. And they're like, hey, two days ago, my VMs could not talk for an hour what happened. And so this is where having a history of what happened, not only on top of actually knowing what's going on inside the black box is very helpful. So the MidoNet flow tracing and flow history. If anybody's not familiar with MidoNet, basically it's a fully decentralized SDN platform. We run agents like locally. We replace the OVS user space agent when we're talking neutron OVS. But it's basically a packet simulator. A packet comes out of a VM. Our agent would catch it. And it runs a packet simulation on it. It'll do all of the things like TTL documentation. It'll simulate it going through a router, bridge, layer 3 VPN distributed load balancing, all of these things. And then it encapsulates it, sends it via VX LAN tunnel to another hypervisor. And as I was saying, that's always been the black box before. That's our black box, at least. So with this MidoNet flow tracing and flow history, now you have a record of what our agents are doing locally and as an aggregated system. I will show you it here. And let's see. Let me get out of this guy here. And I apologize. The internet was pretty bad here, so I had to pull up a bunch of tabs and preload this. This is our MidoNet manager. And the MidoNet manager is kind of like the operations control center with MidoNet. It gives you the ability to quickly see all the network aspects inside your SDN for your cloud, and so for a cloud operator. This is another tool that you'd use alongside Horizon when you're looking through your networks and a few different things. We have this concept of hosts. And when you're doing some troubleshooting, the first place is always to check the health of the SDN itself. And this is going to be your hosts. In this environment, I only have one compute node, so it's going to show one host, but it's up. In the case of having 60 or 80 compute nodes, it would tell you how many up and how many are down. So these are the MidoNet agents. So that's the first place you can look for a problem. If we take a look at our routers, so as an operator, when you're wondering what's going on with the network, not only on top of the flow history and flow tracing that you might be doing, you want to see some port analytics. So if you think about how much traffic is running through a given tenant router, we have the ability to show you that inside MidoNet manager in a realistic way. You can see if a tenant is hammering the specifics of the network. If there's specific ports, if we take a look down here, you can see specific ports here. You can see their traffic over history. So if you're experiencing a lot of load and latency, or one of your users calls up and says, why is the network so slow, you quickly go into MidoNet manager, pull up, and you can say, hey, your port is running six gigabits per second out of one of your VMs. What are you doing? You can very easily identify specific problems inside your network. And so you can kind of hover over. You can check details on ports. So like this port, it gives you the UUID, the address that's attached to it, all the MAC addresses. And everything else that you would need to actually start troubleshooting specific problems. And that's why I'm showing you what we do with the routers and stuff first. Also, within MidoNet, you can see here we have the concept of filters. The MidoNet filters allow you to do many different things inside of your network. You can do, of course, security groups, firewall, distributed firewall, and a few other things. But it also allows you to do some service and search and chaining. You can say, send traffic from this node if it matches x address wherever you want to send the traffic, and it'll return the traffic as well. But you can quickly identify what we're using there. The security chains actually also appear on the bridges. So if we take a look at a bridge, the bridge is going to be like if you open Stack Horizon, you create a network, and you create the subnet. This is going to be the bridge in MidoNet. And so from here, if you take a look at the bridge, you can see what traffic's going over that specific bridge. So now when you're going from router down to the bridge level, so you have a tenant view, an aggregated tenant view, and then when you click on the bridge, now we have a specific to, sorry, subnet specific information, because inside of a tenant, you might have 1,000 subnets. And you can take a look at one of them to see which VM is attached to it, which VM is sending traffic, how many flows per second it's generating. Check out layer two ports. Mac addresses, all of these things. Sorry, I apologize. Thirsty here. So the next thing, though, this is the important bits. So when we talk about flow history, this is where you're going to start aggregating a lot of information here. Flow tracing in our open source product is done on a per node basis. You'd go into a single compute node, say I want to see what simulations are happening for this VM, this port, this protocol, and it'll pull all of them out. With our enterprise product, though, we take all of this data and we aggregate it into an analytics cluster. It's pretty slick the way we do it, as it doesn't impact CPU performance or RAM on a specific hypervisor. So you take all of this information, and what are you going to do with it? Well, in the case earlier when I said, you get the developer that calls up and said, what happened two days ago during this time frame? So you can go into the product and you can pull up the flow history. So if we scroll down here, I have one open. You say, OK, well, during that time frame, here's the simulation, here's the protocol. In this case, this is an R request that we're dropping. This is based on anti-spoof rules. But so you pull up here and you hit Show Details. And what you can see is the flow visualization. So if you take a look, this is a very simple environment just for this demo. But you see where it says Private Bridge? You have the filters that are applied to it, so all of the security groups. And you can see this is the steps that the packet's going to go through before it's sent out of a VXLan tunnel. And so in this case, you can see drop if it doesn't match this IP address. That's an anti-spoof rule. If it doesn't match this Mac, basically if it's unfragmented, we can return it and accept it. You can do jump changes, as I was saying earlier, about service insertion chaining. But these types of views and all of the SDN players are kind of going this direction. We all have a different take on what this is. But in reality, these are the tools that operators are going to need because you have to be able to know what's going on inside your network at all times. And so we call it opening pandora's box now. And so the more we can push for operations tools like this, the faster OpenStack adoption is going to happen as well. Because now you have a production-ready, professional grade-type solution that we're all used to in a traditional bare metal world. One thing I did want to mention, I don't have it set up here. I apologize. When you're talking about operators again, let's check in time. So if you think about how many here are OpenStack operators? I should ask. We got one. So not many operators. OK, that's fine. I'm trying to give you a little bit of insight into what operators do on a daily basis. But things like the flow tracing, flow history, data aggregation, those are really needed right now. So I definitely want everybody to see what we're doing at Metakora, what we're going to be doing in the future, and kind of the power of what SDN in general will do for an OpenStack cloud. But running out of time here, it's one of those things. It's tough now that there's not that many operators here to kind of get out there. But is there any questions so far? Do you have a question? No, no question. Thought you had one. So I think that's going to be the end of my presentation. I just wanted to show you guys the Mutonet Manager, what we're doing with the open source product, what we're doing with the enterprise product, kind of where we're going to go, where we're trying to help push the industry. And as we're all here at the OpenStack summit is to kind of drive this whole OpenStack platform forward. So questions? Any? No? OK, great guys. Thanks for coming out. I appreciate it.