 Bonjour, welcome. Bienvenue à la vie de Paquette. I'm very happy that you're all here today. So thanks very much for coming. Je ne parle pas beaucoup de français, so most of the talk will be in English. I hope you weren't tricked by the title for those English speakers. I'm sure that that's reassuring. So welcome. So I kind of have an ambitious amount of material, so I think I'll just try to run through it and then we can do questions and answers at the end. So we'll start just with an introduction more to set the groundwork on network virtualization overlays. Then I'll talk about MidoNet as an example of a distributed architecture and some of the benefits that we have with using a distributed architecture. Then we'll go into la vie de Paquette. So the life of Paquette as it goes through an open stack and MidoNet environment. Next we'll do sous de la couple. Just a little under the hood, a little more nitty gritty, a little more deep dive into what's happening on the underlay and on the host level. Then I'll do a few use cases just to talk about some of the advantages that we do get when we have a distributed architecture and some of the differentiators we have compared to some other solutions and alternative architectures. And finally I'll talk about distributed software and we'll get to that when we get there. So network virtualization overlays. I thought I would start a little bit further back. Personally my background is more on the hardware networking side. So those infrastructure kind of familiar with this type of architecture, a three tier architecture sort of designed to aggregate, push packets along. It was architected at a time where we didn't have as many virtualization or virtualized workloads that is. So as network design kind of modified and adapted to the network, the virtualized workloads, we kind of did ad hoc things to start of adapt to the needs of virtualization. So we started making large layer two broadcast domains and sacrificed some of the stability there, dealt with reconvergence and spanning tree, started developing hardware protocols like OpenFlow that have a longer life cycle to get implemented and implemented in hardware and agreed upon from a standards perspective. Then of course we kind of forced particular network architectures depending on the type of functions we needed like load balancers, firewalls of course and wanting them to be deployed in an HA manner, deploying them in pairs. Of course this forces traffic trombones in the network and so with all these functions we still need to implement let's say layer two switching and routing, load balancing, firewalls, NATs, these are still functions we require in the network but how can we do that with a new design let's say? We can still leverage the old infrastructure but we can implement these things in a much simpler manner. So this is where we can try to consolidate these functions and try to do it in software. So what we can do is we build a network virtualization overlay and we get much more agile networking so we can build larger clouds, we can build logical topologies and be prepared for a virtualized environment and we can do this in what we call a single virtual network hop so what's cool is we can apply all those network functions that we saw previously implemented through hardware appliances or even virtualized appliances but now we can do it in single virtual hop and implement this through a logical topology. So some examples of overlays one type of architecture is the centralized controller model so what we have here is centralized intelligence so we might have a controller that's making all the routing decisions or other network function decisions and it's all housed at the controller. So as we start getting going we start adding compute power we start spinning up more VMs and we start taxing the controller a little bit more. When we built out the network initially we probably allotted or tried to estimate the type of scale we wanted to build within the processing power at the centralized controller but what happens is you could end up overloading and facing different types of failures in that manner just based on what you may have tried to estimate the network growing to. So some of the advantages with distributed architectures are we can achieve all the network functionality including those routing decisions and other network type functions in a single virtual hop. Other things that are beneficial are no single point of failure whether it be a cluster of control nodes or basically particular appliances within the network. So distributed architectures are specifically made to be built out scaled out for the cloud so the more processing power the more compute nodes you add the more processing power you get. What we also see with network virtualization overlays is we totally simplify the underlay. So this means you can leverage your existing infrastructure and existing routing protocols for example as long as these agents or the intelligence at the edge is reachable over IP connectivity. What we also get with that network virtualization overlay is not just virtualizing network appliances but we actually virtualize a logical network topology. So what that means is we can actually easily manipulate, create, delete and build these networks as clouds demand as our tenants demand as our users demand and everything's ready to go. So we get that rapid creation and modification of a virtual network. So part of the beauty of that edge intelligence is we can add functionality and push it to the edge and easily implement without the reliance on hardware or networking or specific hardware protocols that would be required for our change with SDN. Alright, so let's be agile at the edge let's take the plunge, let's decouple ourselves from the physical network. So MidoNet is a product that's created by Mido Kura of which I'm a systems engineer and is an example of a distributed architecture. So the MidoNet is a network virtualization overlay and it's a product that implements layer two logical switching, layer three routing, NAT, stateful and stateless NAT that is, distributed firewalls, logical layer for load balancing. We implement that with VXLAN or GRE tunneling as our overlay technology and we work with OpenStack Neutrons API so we're basically a neutron plugin and we've been involved with OpenStack since the B release and from day one we've implemented a distributed architecture. So high availability, built ready to scale out for clouds and OpenStack. So looking more at our distributed architecture this diagram depicts the components of our architecture. So as you can see here the region resides on each of the hosts and it's interfacing with the kernel and VMs that are spun up. As you can see in the center all that's required on the underlay is layer three connectivity so you can use your existing layer three infrastructure for example and build a stable underlay without large broadcast domains and do all the networking at the edge. Here we also see network state database so it's just a passive database of where we store the logical topologies for each of the tenants with an OpenStack so the cloud orchestrator could represent something like OpenStack to interact and create and modify networks. Below we have our BGB gateway so this is just our gateway in and out of the network so this can be anything from layer three gateway using BGP to scale out which we'll get into more in our use case scenarios or layer three static routing or layer two gateway. So these are just ways to terminate the VXLAN tunneling or GRE tunneling and get in and out of the network. So let's talk about the la vida and packet in an OpenStack and MidoNet environment. So first we'll just do a light stroll just to get the landscape and understand the MidoNet environment so you can see how packet traverses using this network virtualization overlay technology. So as we know cloud computing can be complicated as we mentioned we were trying to do a lot of things on the underlay network to account for virtualized workloads and building clouds on top of. So building this OpenStack and MidoNet environments as you can see here we can on the left-hand side we just store basically our logical topologies in our network state database on the upper right-hand side we're representing our gateway nodes so these could be the BGP gateway nodes on which the MidoNet agent resides and since we tried to minimize the requirements of the underlay so just being as agnostic as possible for the hardware basically the gateway nodes are our agent residing on x86 boxes and then we can install our MidoNet agent on all of the servers below and all that's required between everything is IP connectivity so it makes it pretty simple for your requirements on your underlay so now as a tenant let's build a virtual network so MidoNet provides this functionality called a provider router so basically from an operator's perspective or a tenant's perspective it's access to the external network for let's say any of the tenant's networks on which you can basically configure up links so this is automatically created once you create an external network within OpenStack and then each tenant can build its own tenant router as you guys are probably familiar with we're doing the tenant isolation so each tenant can build its own router define its own network and assign particular subnets each tenant obviously has its choice to implement security groups so we do that all in a distributed fashion so they can define those security group rules and also NAT as well so once those are created we can spin up two VMs on the network so here they get their .2 and .3 address so as I mentioned earlier the network state database is basically just a passive database storing all of the logical topologies so everything that we may have built through OpenStack would be stored in some entity form in this passive database so let's make these VMs talk to each other let's pass some packets so what happens on the first inbound or outbound packet this VM basically sends its packet to the kernel and that MitoNet agent basically intercepts the packet since it's not known if it's the very first packet and it's not cached locally the MitoNet agent will query that network state database to find out the logical topology so it does a query according to that VM so it might be a particular tenant so we'll find out all the information relevant for that tenant's topology network and where it's going to let's say it's the egress destination VM so once it pulls that information down the local agent does all of the routing decisions or any type of packet manipulation that needs to happen so we call this basically the packet simulation of that VM as if it's traversing the tenant network until it reaches that destination VM so that packet hasn't even left the host and it's pretended to be simulating through this kind of logical network and the packet's manipulated and basically the kernel will be programmed to have that flow entry and then we can build a GRE or a VX LAN tunnel to the destination compute host and then send that packet along the way so the destination host will deliver it to the destination VM so that pull down of the logical topology only happens on the first packets after that that logical topology is completely stored locally and cached and once the flow entry is programmed in the kernel the remaining packets can fly at nearer line rate to the destination VM so a similar process would happen if these packets were bound for the external network except we would be creating GRE or VX LAN tunnels to the external or excuse me the MidoNet gateway nodes and since the agent resides on those nodes as well any incoming traffic would be treated the same way so part of the beauty of that is implementing like security group firewalls for example, we can drop traffic as soon as it comes in and protect the underlying network so let's go Sulu Keppo under the hood a little bit and then we'll have some of the nitty-gritty so in general what's happening in this network is on demand state propagation so whenever a change is made a tenant makes a change to their network let's say through horizon these changes are passed on to the network state database which actually is just zookeeper under the hood and the agents and zookeeper are in a relationship with a public subscribe model so whenever a change is implemented that change gets pushed down to the agents that care about the change so we're leveraging zookeeper and just using remote procedure call over TCP and relaying that information to the local agents sorry so what happens when the VM sends this first packet as I mentioned if the information is not locally stored or cached we're going to do that query to the database so what happens is if it's not already configured we're going to get a kernel flow miss so when that happens the kernel is going to send the packet for queuing and processing to user space via netlink so MidoNet is going to receive that netlink message and then further process the packet so then as I mentioned if MidoNet doesn't have it locally stored it will do that query to the network state database to retrieve the logical topology from there once the logical topology is pulled down all the processing was done locally by the MidoNet agent on the host with the virtual layer simulation and then we install the flow into the kernel so whether it be a drop or modify or forward of the packet that will be installed in the kernel at that stage by the MidoNet agent so an example once a packet is sent to the kernel from a VM once we match the tuple to that of the packet header we can basically use the actions within the kernel to decide on what the rules are that would have happened based on that network simulation so with some examples of that flow table entry match that would have corresponding actions would be changing and modifying let's say if two tenants are going between two different subnets through a tenant router for example we would be modifying the MAC address to be that of the routers we would be changing the TTL on the IP header and then we would actually encapsulate the packet with GRE or VXLAN so that would be another action to perform and then of course send it over delivery over an IP Ethernet header to the destination VM indicated in that header so what's key here too is the GRE key or the VXLAN VNI ID is actually the indicator for the destination host on which V port to deliver that packet so once that packet is delivered using this network overlay the destination VM the destination host is aware of the virtual port associated to the destination VM and it's indicated by that GRE key or the VXLAN VNI so talking about some of the benefits of a distributed architecture and some of the differentiators we have that are implemented one is our distributed BGP gateway so some really cool things that we're doing is implementing BGP to ingress and egress the virtualized environment so using basically this well-known protocol obviously allows us to easily insert into existing environments and get off and going with an HA available protocol this is easily implemented with physical boxes today that are all doing standard BGP what's cool is you can basically put out x86 boxes as you need to increase the bandwidth you need out of your network and each one will act as a BGP gateway so basically you can provide your bandwidth on demand and scale out that way and all the links will be active so it's not acting in an active standby pair it's not just active-active limited to two links you can keep scaling out as long as those BGP gateways are available on the underlay through your IP network and just using ECMP we'll pick a gateway to traverse and exit the network that way so all of the uplinks are active and then of course using the standard-based protocols allows us to implement easily into existing environments so what's cool about this also is a lot of hardware vendors struggle to just create a logical chassis for routing and here we are creating a logical provider router to implement these uplinks and an HA solution and a quite easily implemented configuration which I'll show next so here on the left-hand side I'm depicting more of the physical implementation so what you can do is basically you would be installing our agent on each of the nodes have them interconnected with an IP fabric meaning just a layer 3 class underneath keep it simple and then our BGP gateways which you can continue to build out based on the demands of the network so what this translates to in our metonet logical topology is from an operator perspective we're implementing as I mentioned earlier that provider router so with multiple links coming off of these BGP gateways that equates to multiple egress points on this provider router so you can just create these ports and associate them with BGP peers on the upstream and you have that on-demand and egress points so from the tenant's perspective that's just added bonus an HA solution that can scale out and allow the tenants and the operator to provide a service with dynamic routing and an HA scalable solution so as I mentioned it's pretty simple to set up with the provider router so this is an example of our metonet CLI so you can just list the provider list the routers on the network just to obtain the router ID then you simply just add a port this is really similar to hardware networking just add a port with an interface on it a slash 30 here would represent a point to point link that you might want to do and then because we are dealing with the virtualized we have to map from virtualized to the physical network we just create a binding of that specific port that we just made with that IP interface and we bind it to a physical NIC so in this case it would be ETH1 finally just like in hardware networking if you got to turn on the protocol you got to do something to do it so here we add BGP to that specific IP interface we give it a local AS number we indicate the remote AS and the BGP peer that you can get your BGP peering session up and running with an upstream box and then the last line the last configuration is simply just telling BGP which subnet to advertise so in this case it would likely be in an open stack meto net environment it would likely be your floating IP pool so another example of a distributed architecture that's beneficial for a network function is a distributed flow state so our meto nets distributed architecture enables flow states to be processed locally so there's no query to a network state database or a centralized controller for example to keep track of connection tracking for example so the one tricky thing here is the ingress and egress points of a flow may vary so what we do is basically give hints to these interested sets of nodes the ones that are highly likely to be the ingress points or egress points of these types of flows so there's several advantages obviously it's a lower latency since we don't have to do a query or we don't have to force the traffic to a particular controller or anything that's processing connection tracking for example so we get that lower latency as well as pure independence from a centralized transaction like that so no query to the network state database or a service node that might be taken care of that because it's all done locally so how do we do that let's say a new flow is coming in and requires the flow state to be tracked so first we check the local states if it exists on the local box if it doesn't we create it and from there we forward on the the state towards other interested nodes that means other potential ingress nodes or egress nodes for this flow and then we tunnel the traffic and pass on the packet to deliver it to its destination so this flow state would be represented by the flow computation as I mentioned earlier like a packet simulation and tracking and then the tunnel and cobsulation so what's key here is we're using specially defined tunnel keys within the GRE header to propagate that flow state to those other nodes so that's how they find out about the flow state we're basically using a fire and forget state propagation which means we're not waiting for a confirmation for those other interested nodes we just send it the flow state and then we send the packet with no delay so what happens when so the knowledge being spread like that to other interested nodes means that we can account for asymmetrical traffic flows and relay the traffic on without delaying the packet so within MitoNet this is simply done by creating these port groups so we define a port group we simply give it a name and say set the state full parameter to true and then we just add the ports that would be consistent with the potential same interests to this port group so in this example we might add all uplinks from the provider router to one port group because they would likely have these incoming packets from any direction depending on how they got routed from the external network another example might be load balancing for the egress points you might put all the hosts from a pool in the same port group so those are some of the advantages that we can get with this distributed architecture distributed software so what I mean by that is we actually went open source yesterday so we're really excited about it I don't know if you've heard but this means you can go and grab our software and try it out today so we got a new logo if you're familiar this is our MitoNet this is our MitoKura Enterprise MitoNet logo so that was our original logo but now this is the one representing our open source community so we're Apache 2 licensed we consider ourselves the most highly available, reliable and stable since we've been in pretty mature network virtualization overlay being in the works of three years and now this functionality is available for you to try out yourself and see for yourself so there's a lower barrier for you to try out our products and we just launched yesterday so these are our original members of our community so we're grateful for their support and we continue to work with them we're very vendor neutral so we consider ourselves very open compared to some of the alternative solutions so now we're truly defining that by outright stating that we're now open source so we'd love for you to try our product we would love for you to contribute and join the community so you can check out our MitoNet.org website and sign up for yourself download the code yourself get involved in our community on the IRC chats my colleagues and I are going to be there to support you guys so that your learning curve can be much shorter and get you up and running as quickly as possible so we encourage you to get on there and so there's a little legal document to sign and we'll have the support of our team when you're trying it out so that being said just a reminder of our enterprise products as well as now our newly launched open source code available to you we're on Twitter we're actually having a launch party tonight so you're all welcome to come, please come I think we're starting at five, is that right? five o'clock? so five o'clock just across the street here very close so please feel free to come by it's Atlas Zoo we're starting and I thank you for your time today I hope you guys try us out are there any questions? did you want a mic? oh sorry go ahead, yep when you're scaling out your gateway router at the end, how does it do the load balancing? is it like a hash based or is it round robin? yeah, we're doing ECMP basically so it's just round robin from the choice of the ingress point so every scaled up provider is a new BGP peer to the external to the external? to the external so we make that decision on which gateway to use right at the ingress point so it would be right at the virtual machine at the host level so when a VM is initiating a traffic flow before it even leaves its own host it will decide on which gateway to use in a round robin fashion which provider which of those gateway routers just round robin, it will go through all of them okay thanks thank you for your presentation you say that thing getting open source what governance model is for the project who decide on upstream and what is the relationship between enterprise and open source models to start the Mido Kura team will be governing we expect it to flourish and then let the community decide on how it's further governed in the future so just as an initial start we the Mido Kura team will be governing it and the second question so right now we have we're using our stable code base as the released product so it's basically version 1.8 it's the latest version of our code so from there we expect there to be contributions and the Mido Kura Enterprise MidoNet will take its own stream where it's hardened with QA it's going to be fully supported so those are some of the differences between the enterprise version and the MidoNet version the open source MidoNet version thank you yeah yeah when we're doing these overlays are you expecting the OSs to be downgraded on their MTU to handle the increased size of the overlay or are you expecting to do jumbo frames and if you're expecting to use jumbo frames what do you expect all those settings to accumulate to because jumbo frame is not actually a finite number it's actually a variable right so as long as as long as the plumbing in between for the underlay as long as the MTUs match the whole way through and account for that header so the MTU on the actual VMs VNIC should be smaller but as long as the MTU from end to end accounts for the header then you should be fine whether it be a standard Ethernet packet or a jumbo frame okay so do I have to go through my entire corporation change all desktops all database servers down in MTU so they can interoperate with you so for desktops are you talking more about the VDI solution well no but if anybody is going to talk to this environment and if you're having a MTU issue I'm going to have to downgrade my entire corporation so the packets can go in and out without fragmentation or I'm going to have to for this one overlay network all those switches are going to have to be set to an MTU value in a jumbo frame range to be able to handle the overhead so just where the just where the overhead is implemented that's where you would need to increase your MTU so you wouldn't need to do it on your physical network or your physical endpoints you would just be needing it to do it where it ingresses into the virtualized environment to account for the header one more question sorry your example had a you're doing EBGP between the is it just EBG supported or can you do EBGP and what are all the is it like a full feature support for or is it just a subset can you talk about that some more today we're just doing EBGP so you can easily just use a private AS like a reserved AS or something so we're not implementing to the full extent of MPBGP and those types of things but it's more for the sake of advertising routes in a dynamic fashion yeah okay well thanks for your time again hope to see you tonight at our launch party and feel free to stop by our booth as well in the startup area so thanks everyone merci