 Hi, guys. How's everybody doing? Are you guys having fun? It's Wednesday. I think we're like almost halfway, depending if you're going to the Design Summit. So my name's Cynthia Thomas. I'm a systems engineer at Medokura. Thanks so much for coming here. I think we have about 20 minutes. So we're going to talk about scaling the internet of things and how to leverage OpenStack and Medonet. And Medonet is an open source project, a neutron plugin tied into OpenStack since about the B release. So just show of hands how many people are implementing some kind of IoT rather at home or at work? Very few. Well, upon us all the age of the internet of things is coming, right? So the expectation is having 50 billion devices by 2020. And in reality, 2020, it kind of looks far away, but it's only four years away. So we've got to figure out how we're going to scale and get there. So internet of things, it's not a new concept because it sort of had been a buzzword for a while, maybe even 20 years, starting with RFIDs on tags and keeping traffic inventory. But now it's moved across different verticals like healthcare. We've heard a lot about energy grids and smart cities that we heard in Austin, some of the key notes and spreading across things like that. So, well, I wish you could see my slide, but it's taken a while to come up. Did I block myself out? Which one was that? Sorry. Well, given I'm from a network virtualization company, what I care about is what does internet of things and the devices do to the network? So in terms of how do you scale when you have so many devices you're dealing with and you have to have some kind of unique identifier on them? How do they scale with current infrastructure we have today? And of course, what we all think about and probably the adoption affecting concern the most is security risks. So meet or not as you know it or may not. I'll remind you if you don't. Network virtualization overlay. So what that means is we're providing layer two through four networking services and leveraging VXLand tunneling to go across east-west traffic amongst a distributed BGP gateway to get in and out of the cloud. So we're a neutron plug-in. We've been involved since the B release with OpenStack, so long-time contributor in projects. Our founders and chief architects actually come from the likes of Amazon, their expertise being a distributed system. So the way they architected MidoNet for those who aren't familiar is there's no single points of failure bottlenecks. So the goal is high availability and providing a distributed system. So we started about six years ago. Mido Kura was the organization producing MidoNet originally. And then the name actually means green cloud. So Midori is green and cloud is like this. It's a mashup word of meaning green cloud. So how can we make money or now we care maybe even about environmental aspects too. But as of the Paris summit in 2014, we actually went open source. So the code is completely available online on GitHub. And then we of course have our enterprise offering, which I'll give you a glimpse of today too. So given we are a neutron plug-in, we are providing the layer two through four networking services, a host of which are listed here. It goes above and beyond even OpenStack as well. But doing everything in a completely distributed manner and that's what makes our solution unique. But for those who are familiar with the concepts from Neutron, it's providing all these network functionality. Taking a look at what the architecture looks like, we eliminate the requirement for the Neutron network node for those who might be full married with previous reference implementations. So we have a single network. We have an agent that sits in user space. You deploy that across the compute hosts. We actually have this distributed gateway as well. We're completely hardware agnostic. So it just requires IP connectivity between the compute hosts and gateway nodes. And we leverage just VXLAN or GRE to deliver packets on east-west as well as north-south towards the gateways. As you might notice, there's no controller here. We consider ourselves controllerless. So all the intelligence is at the edge. So the agents at the end of the day, all the intelligence they need to provide these networking services for the VMs or various workloads which we'll see evolving now to containers and such. So keep going. So would you like some Marai with that IoT? I don't know if you guys were called just last Friday. Marai, which is, if you haven't heard, other than the Toyota car is actually also malware that's that inhabited IoT bots. And actually we have a lot of people who are doing this. We have a big company called DIN DNS in the U.S. So it took down Twitter, GitHub, Spotify. These things are very important to us. We work on GitHub. And I work with Spotify. I need that to get in the mode when I'm at my desk. So this is overall obviously performance affecting. So of course we don't want that. We need security. And that's what's holding back adoption. Given as I mentioned, the intelligence from security that we provide. We're removing the need for a service appliance and hairpinning, for example. So we're doing things more efficiently by handling things right at the edge. So what that means is things like security, security group policies, firewalls, and service, these are all implemented right at the edge before you even leave the compute host. And that will apply as you'll see as we expand portfolio towards IoT related functionality as well. What's also special about the way MidoNet has implemented security groups is you get even more options than you get with the basic neutron security groups. So neutron security groups are basically enabling white list type rules. So I'm allowing this traffic to pass. But MidoNet lets you have other actions and capabilities. So you can link various chains together. These are more of the lower level constructs. So I'm probably going a little bit fast about these kind of things. So we'll be available to talk more deeply about these constructs that we implement. But you can do things like linking chains and security policies. You can do drop, rejects, and various different options. So it goes above and beyond the basic security options that you have today with neutron. So how this applies to IoT. Let's take industrial IoT as one example. So this might involve having bots and sensors on a factory floor. And this is basically increasing the amount of traffic that's happening obviously. So the number of end points from a network perspective, even the traffic that's traversing the network and therefore there's more flows to deal with. And obviously application monitoring, caring more about higher level services from a network perspective. And of course leveraging things like OpenStack in the back end for analytics with MidoNet. So this example kind of gives you kind of a maybe a higher level view of things that can be applied from a networking perspective to implement security more at the edge. And prevents, you know, minimize like the fault domain. So here we're depicting sort of the IT and OT operations technology that would be typically implemented in an IIOT environment. So these sensor bots, you know, it starts right from the factory floor. So these sensor bots might have a certain protocol that has to be understood. This layer in between is where we want to fill the gap between IT and OT. We can call that like the fog layer. We're not getting cloud now. We're just getting fog. So maybe like on premise on the floor. So how about aggregating those protocols and traffic flows that are happening, as well as providing security policy as well. And dealing with application monitoring to understand what's happening with the network. From a network perspective beyond that, there's other things that are important as well. So it's a more challenging solution from a network perspective because you have to have a much more feature-rich set of functionality. So, for example, WAN to go to some back end, you know, encryption, of course, is important. Maybe for inbound traffic flow it might be load balancing. So these types of things are combining and stretching a network solution to expand right from the factory floor to a back end open stack cloud. Of course, monitoring is important from end to end. So providing the visibility of what those traffic flows are as we grow to 50 billion devices. And then, of course, the utmost importance which we feel that has been inhibiting the adoption of being security. Everybody cares about security. So I'll just give you a glimpse of what MitoNet Manager looks like. MitoNet Manager is the GUI interface that gives you an overall view of what's happening in the cloud where MitoNet is providing the networking services. So I'll go through a demo and you get a better look. But it's basically providing flow history, giving you the availability to search on an isolated network or a tenant project as we know from open stack. Whatever services might be applied. So that could be load balancer service, security groups, things like that. You're getting visibility into every single flow and search ability to minimize what you're looking at. So you guys want to see a little bit more of what that looks like? All right. Let's just switch it up here. Hopefully that's visibility. So I'll just give you an idea. Those who are MitoNet users might already be familiar with this. Our RESTful API is available and to be configured directly with our RESTful API, we have a MitoNet CLI so you can take a look at the constructs from a networking perspective that are part of the cloud. So here you can list the routers that could have been created, rather through OpenStack or via our API. As you can see, there's these chains and rules that are applied per router that are listed here. So that's sort of how we implement various things like security groups, firewalling, netting, staple firewalls as well. Each router can have routes depending, I mentioned that we do BGP so the external router would have BGP routes that are learned on the router. And these are all logical constructs, keep in mind as well. So it's not a physical appliance sitting somewhere. So each of the routers has ports as well as bridges, which you could basically, as you would know, as a subnet. So these would be created through OpenStack, the Neutron API or otherwise. And each of them have ports as well, obviously. And they would align even to VMs potentially or containers or pods and some of the Kubernetes integrations that we have. So even on each bridge, we can check these ports. And a typical workflow from OpenStack is when you're launching a VM, the Nova scheduler is going to request a Neutron port and that's what's landing on one of these bridges here. And then we also have visibility into some of the chains, which can be more difficult to read from CLI, but it is available that way. And this is all part of the open source code that's available on GitHub. So we'll flip over to the Neutron app manager. This is part of the enterprise offering. Let's see. So we'll just log in here, but basically it's providing a dashboard for all that visibility that you require. So we'll just get logged in and check out the network constructs that were created via the Neutron API. A little bit, there was a slow connection when this was happening. It's not indicative of performance. So initial dashboard gives you a big view of the things that are important to meet on that. So host would be your compute host or your gateway nodes within the system. Up is good, green is good. If they were down, not reachable, that they'd be all red. So you get a basic view right away. You can scroll down the left-hand side. We have all the constructs that were made. Tunnel zones are our way of registering agents into the Meadonet network. So this is one level of security. You're not going to have some rogue Meadonet agent somewhere. You have to have implemented that and attached it to a tunnel zone and defined it as VXLAN. Next, we have the routers that would have been created via the Neutron API. So they're all listed here. You can go click deeper into any of them. We have little graphs to show the type of traffic that's happening over a period of time. You scroll down further. You can see those things that we saw through the Meadonet CLI, but a little more visually consumable. So you get the ports, you get the routes, things that are related to whatever network function it is are provided to you through the single pane of glass. So obviously this has a unique user's network. Then as I mentioned, the flow history is what's really important for analytics, especially as we get many more devices, having the ability to filter, troubleshoot, and look at the various flows in the network is increasingly important with many more things on the Internet of Things devices. So you can filter based on any of the expected things you would expect from an IP, Ethernet packet, the ports, the tenant, and then you can further customize what you're looking at. So it's a more consumable way through what period of time. So you can customize what you look at and you can enter that. So this is all part of the analytics portion that's part of the enterprise offering. So it's leveraging elastic log stash on the back end and retrieving these flows. So we see there's some spikes here, so that means there's a little bit more traffic there. We got a list of the flows that happened during that period of time. We do this interesting thing at the edge. It's a simulation to determine whether it should be sent or not. So that simulation is listed there, but it's just a summary. So you can kind of drag and drop with your mouse on the graphs if you want to like zoom in on a particular time. And then the corresponding flows will show, so you can drill down a little bit more depending on what you're looking at. So if we go down to a particular flow, right now we're looking at the more summarized entries here, so the basic information. But we can scroll down, we can drill into a particular flow and see how a packet has traversed the logical topology. So that logical topology can have very complex network functions in it. So load balancing, firewalls, security groups, and then here we're showing basically the five tuple of the packet that's showing the VMs, just basically the payload of the VX line tunnel, so whatever the true packet was coming off the VM. Then we also show this flow visualization, which is what's happening on ingress when a workload is entering the cloud. So it's showing you all the logical constructs that may have been constructed and what the path would be for this packet on that. And you can drill down further and further into what exact rules were applied, whether it was allowed to drop or pass, and the highlighted entry actually just shows the match. But you can click on the ones that it didn't match and passed over. So that basically shows the port it exited, defining it by its UUID, and so you can get a lot of ton of information on a per entry basis when you're leveraging Meadonet Manager for visibility. So this makes things exceptionally easy for troubleshooting and operation tools, and that's really what the focus was with Meadonet Manager. So that was, sorry if I went really fast, I think I started a little bit late and I want to make sure I finish on time. But that was my general summary of what I wanted to present to how to apply a neutron plug-in, that being Meadonet, to the time when we got to be ready for all these IoT devices and starting with a scalable solution we're already familiar with. We know that scales and as a security groups and policy is embedded and being ready for IoT. So that's the goal for Meadonet. So thanks for your time today. Our booth is just A34, I believe. So come visit us. We can drill down further into what we talked about today, and I appreciate your time. So thanks for coming.