Juniper OpenContrail

for sticking around I know it's well into your lunch hour by now and I really appreciate that you took the time to listen to one more presentation today yeah I looked at the calendar I know there's no one's slotted behind me my name is Bruno Reisman I'm originally from Holland I'm based out of the US now I am the architect for Software Defined Networking at juniper networks and topic of my presentation today once I get it up on the screen is going to be open contrail open contrail is a network virtualization platform it's open source and it is built and supported by juniper and one thing that you will notice is that in very many ways open control is quite similar to the previous presentation the nice era nsx product the main difference being that we decided to open source everything just to give you a little bit of history behind open contrail juniper networks of course is best known for its physical hardware physical routers physical switches physical security gateways and about nine months ago we acquired a company called Khan trail systems that has a network virtualization solution that is aimed at the open source stack including cloud stack and also OpenStack then in on September 16 we announced the first product that came out of that acquisition which is what I'll talk about today which is called contrail and at the same time we made a decision that raised a few eyebrows in the industry which is we decided to open source everything the AVI router which is our equivalent of the V switch the forwarding plane as well as as the end controller that sits on top of it there is of course also a commercial product that you can get from juniper or some of our partners it's the identical same product literally the same checksum on the binary image the only difference between the commercial and the open-source products is that you get support from juniper or one of our partners before I go into the details of what open control is how it works from a technology I'm going to spend a few slides explaining what we mean when we say network virtualization the very first thing is that within a cloud or within a virtualized data center network virtualization means being able to give each tenant the illusion of having a logically separate separated network that is isolated from all of the other tenants in the cloud in a public cloud a tenant is literally a customer of the cloud in a private cloud a tenant is typically a department within the organization or may be a separate virtual network that you put all your vending machines on so that to keep it separate from everything else these virtual networks sit on top of a physical network in very much the same way that a virtual machine sits on top of a physical server and these virtual networks in the case of open control can be layer two segments or they can be layered three networks or as we'll see in a couple of slides that can be more complicated arrangements where you have multiple layer two segments connected by security policies if you're familiar with virtual private clouds in Amazon it's very see the concept is very similar to that we actually don't create these virtual networks using VLANs in in a way very similar to the previous speaker we actually also create these virtual networks using overlays there's a lot of scaling and stability and complexity issues that are related to implementing virtual networks with VLANs it's fine to use VLANs at small scale deployments but when you got once you get to very large-scale deployments VLANs simply don't cut it some of some examples of why VLANs don't work as well as overlays is the amount of state that you need in your physical network if you implement a virtual network in a data center using a VLAN it implies that every time you add a tenant to a network you have to touch all of your physical networks all you all of your physical switches and all of those physical switches will end up with every MAC address of every virtual machine in your network another example is has to do with things like spanning tree in order to to avoid loops in your network after tenants turn on spanning tree if you turn on spanning tree you don't efficiently use all of the paths in your network you can do multipath very effectively you cannot get around that with various technologies but then your network becomes very very complicated very quickly so by using overlays implementing these virtual networks becomes much more simple the second piece of functionality that open control provides in terms of network virtualization is the ability to apply policies at the boundaries of these virtual networks at a very high level of abstraction what you can do is you can say I want to apply a security policy between this green virtual network for the green tenants and that red virtual network for the red tenants okay if I had not done that then because they're separate virtual networks they're separate closed groups and they would not be able to come Qatar so what I can do is I can apply a security policy that essentially says I want to make an exception I want to allow this green VM to communicate with that red V M but subjects to a particular security policy and that's the policy might be something like I only want to allow HTTP traffic and when the traffic goes from the red to the green VM then I want to apply network address translation okay with these two particular examples stateless firewall filters or ackles and Nats those types of simple functionality can be provided into V switches themselves once you get to more complicated four pieces of policy but between virtual networks you need a more sophisticated concept which is called service chaining okay it's simply a more sophisticated or more complex version of a policy between virtual networks where you apply more sophisticated services to the traffic that flows between one virtual network and another virtual network in this particular example I might say the green virtual network is allowed to talk to the red virtual network and I want to only allow HTTP and and I want to apply that same as before but now I also want to apply maybe stateful firewall or deep packet inspection or content caching and in order to implement those higher level therefore to layer seven types of services you need to insert service appliances and apply that traffic force the traffic to go through those service appliances those service appliances could be virtual service appliances they could be virtual machines that hosts a virtual firewall there's a number of companies including juniper that provide virtual firewall virtual firewalls that are running in virtual machines in the case of Juniper it's a virtual version of rx firewall that product is called Firefly but there's similar products from other companies as well or you might want to deploy services in this service chain by putting physical appliances in that service chain you might want to put a physical firewall in the chain maybe because you need it for performance reasons or for some other reasons so the way that we do service chaining will allow you to have a mixture of and physical services in a service chain like that one final observation on this slide once you start deploying virtual services you will also need scale outs okay physical appliances tend to be implemented with Asics and tend to have extremely high performance virtual appliances tend to have lower performance and when you need more capacity than a single virtual machine image can provide you need scale out you need to instantiate multiple parallel instances of such a virtual machine and load balancer traffic across it so that's another feature that's built into this service chaining concepts the third thing that you need for virtual networking is the ability to connect different virtual networks in different locations across a wide area network at the bottom here I have two instances of a private cloud in two different data centers for some company and they might want to do DCI or data center interconnects they might want to connect the red virtual network in the bottom left to the red virtual network in the bottom right and the green virtual network on the bottom left to the green virtual network on the bottom right etc or you might want to connect a virtual network in a private cloud with a virtual network that's provided as a virtual private cloud service by some public cloud provider such as for example Amazon typically what many customers and customers of ours to enter large enterprises they they build a private cloud for the norm for the typical capacity and then they burst out into a public cloud for the peak capacity around Christmas for example and so once again I need to be able to connect a virtual network within my private data center to the corresponding virtual network for me in the public cloud the way that we open control have implemented our virtual network technology is actually based on a technology that's very widely deployed in networks in the Internet today which is called MPLS layer 3 VPN ok even before juniper bought open contrail or contrail this this this has always been one of this has been the bread and butter of Juniper Networks this is one of the things that that many of our customers use we have deployed literally tens of thousands of MPLS layer 3 VPN s where some of the largest VPNs contained thousands or tens of thousands of PE routers and have millions of routes in there forwarding tables this this is exactly what we're good at the people who found it contrail came from juniper and similar companies understand that technology then they spent some time at Google learned how to build really scale outs as the end controllers and combined those two pieces of technology to implement the contrail of technology that I'll get into in more detail in a second as a result of that as a result of the fact that our internal virtual network technology is based on the same technology as those MPLS layer 3 VPN s is actually very easy for us to do that wide area interconnect it's very easy for us to connect virtual networks within a data center to layer 3 VPN within a wide area network to connect data centers together or to connect a private cloud to a public cloud and then we're able to provide things like traffic engineering and quality of service across the wide area network in attendence aware way so those are the different use cases the different applications of open contrail I'm going to rewind and revisit every single one of them and explain how they're actually implemented under the hood and a lot of this will will should be quite familiar after what you've seen before this let me start with explaining how virtual networks are implemented on the left hand side you see you see the logical diagram this is what we're trying to build on the right hand side you see the physical implementation of it at the top you have your cloud management system this would be either cloud stack or OpenStack then below that you have the contrail controller which is an SDN controller that is responsible for the networking aspects of the virtualization and then below that on the left and the right you have two virtualized servers each with a couple of VMS then that horizontal line shows the boundary with the hypervisor and that white thing and that white thing in the bottom is what we call a V router but what most other people in the industry call it V switch we like to call it a V router because the the control V router doesn't just do layer 2 overlays but layer 3 overlays as well when you want to create one of these virtual networks you go to the northbound API or through the graphical user interface of cloud stack and you ask it to create a virtual network then you ask it to instantiate a number of virtual machine and attach those virtual machines to the virtual network cloud stack is responsible for creating the virtual machine for managing the lifecycle of the virtual machine itself then it delegates the responsibility of creating the virtual network and attaching the virtual machines to the virtual network to contrail open contrail what control does is a couple of things let's say that we first create that red virtual machine on the bottom left control is told by cloud stack I just created a virtual machine on this particular server and it needs to be attached to the red virtual network the control controller realizes this is the first red virtual machine on this particular server so I'm going to need a separate routing table which we call a routing instance on that particular V router to separate to create a separate routing table for that virtual network that's that little red circle in the whites via router similar thing happens on the other side it the VM the first VM is put there for the red virtual network we create another routing instance there and then finally trill the control controller realizes oh wait a minute I have a red virtual machine over here and I have another red virtual machine over there and they're both - the red virtual network so they need to be able to talk to each other in order to achieve that it creates that overlay tunnel that gray tunnel from V router to V router which once again we also are not religious about what the encapsulation is we support MPLS over GRE we support MPLS over UDP we support VX LAN the forwarding plane takes the packets that comes from the virtual machine gives it to the V router which doesn't look up in the routing instance realizes that the destination is over there on the other side of the network and capsule eights the packets sends it across a tunnel to the other VM on the other side what that means is that the physical switches the underlay as we call it that sit between the physical servers are just forwarding packets based on the source and destination IP address of the physical servers okay there's no states at all for tenants into physical underlay there's no MAC addresses no I P addresses of VMs anywhere in fact the only thing that's required of the physical network is that it can forward IP packets from server to server which means it can be any switch from any vendor even it's not from juniper that's how we implement the basic virtual network virtualization Palo excuse me to implement policies and service chaining the workflow works as follows you go to the northbound interface and you express your policy you say I want this green virtual network to be able to talk to that red virtual network but subject to the following policy constraints only HTTP I want to do NAT and I want the traffic to be forced through a virtual load balancer and a virtual firewall that are running in virtual machines at the bottom of this diagram what contrail will realize is that the red virtual machine and the green virtual machine need to be able to talk to each other there needs to be a route in the routing instance from the green virtual machine that gets the traffic to the red virtual machine however that route should not take the shortest path the direct path from red to green that route should force the traffic to take a detour to visit those two particular virtual machines that virtual load balancer and that virtual firewall so that the traffic can be processed as it goes from green to red in order to achieve that the very first thing that you need to do is to obviously instantiate the virtual machines that hosts the virtual firewall and the virtual load balancer and just like a real firewall or just like a real load balancer these virtual load balancers and virtual firewalls will have multiple interfaces inside interfaces and outside interfaces and then I glue everything together by putting one interface in what virtual network and the other interface in another virtual network and if you pay very close attention to the slide you will notice that between the load balancer and between the firewall on the left-hand side I put a little yellow helper network to glue steps together okay and then what control does it creates all the right routing tables and all the right tunnels in all the right places as shown on the right-hand side of this diagram so that the traffic is forced through the right sequence of virtual machines this diagram on the right hand side is get might give you the impression that it's rather simple but I've oversimplified things quite a bit in real life they're going to be many green VMs and many red VMs and so that forcing of traffic from all the right places to all the other right places will involve many routing instances and many tunnels and manipulating many different things the other oversimplification that I've made is that I've only shown one virtual firewall in real life there could be multiple instances of this virtual firewall for scale-out and if that happens you need to have load balancing from step X to step X plus one in your service chain and that's why that little glue that little yellow helper virtual network really needs to be a multi-point to multi-point virtual network so that we can spray the traffic across the multiple steps in the service chain then the last use case is connecting virtual networks to physical networks at the top of this on the left hand diagram I showed a logical picture I want to have a virtual network within a data center that is connected to a physical network on the outside world that might be an MPLS layer 3 VPN for example on the right hand side I show you the the physical implementation of it at the top we have what we've seen before a virtual network within a data center a couple of V routers with routing instances connected by a tunnel and at the bottom I have a very traditional layer 3 VPN PE routers see II robbers with customer sites and an MPLS LSP to glue everything together in order to connect that layer 3 VPN to my virtual network I need to have a gateway router at the edge of the network that gateway router in the case of Juniper would be an MX router what it needs to do is it needs to speak all of the MPLS layer 3 VPN protocols towards the bottom which is BGP and LSPs for MPLS LSPs and at the top it needs to speak whatever protocols it needs to speak to be able to connect into this virtual network what we have done to make that very easy and straightforward is given the contrail controller the ability to speak BGP to these gateway routers because the contract controller can speak BGP to the gateway routers you can take any router from that you bought in the past 10 years to be that gateway function every single router in the world that supports MPLS layer 3 VPN can speak BGP to the contrail controller in the data plane what you need to be able to participate in the virtual network is support MPLS over GRE historical accidents every single router that was built in the past 10 years also supports that and the reason is that if you rewind 20 years when MPLS was deployed and when it was still a very young technology there were some operators that liked layer 3 VPN but didn't like traffic engineering and so in order to support those operators juniper and every single other a major router vendor supports MPLS VPNs with GRE as the encapsulation ok so the way we do this integration is done in such a way that we only use standard protocols and we interoperate with existing networking equipment that's already out there once you have that gateway functionality you can build something like this you can create a virtual network in one cloud another virtual network in another cloud and glue them together with MPLS layer 3 VPN and do things like traffic engineering in your wide area network that's a variation of that same technology also allows us to connect at all servers or non virtualized servers to a virtual network in a data center ok there's many ways that you can do that one of those ways is shown here what you can do is you take your better metal server you take an Ethernet or a VLAN up and then you use a gateway to connect that non-virtualized server to the virtual network in your data center that Gateway could be software gateway this is something that was discussed in the previous discussion or it can be a hardware gateway it could be the top of rack switch that is sitting right there next to your server so here once again we use existing technology that is already implemented on most high-end top-of-rack switches the ability to create a routing instance to terminate that VLAN or Ethernet into and then we use BGP to populate the routes into that routing instance one of the important concepts of contrail is that you configure the network at a very high level of abstraction you say I want these virtual networks I want to apply these policies at the boundaries of my virtual networks I want to connect this virtual network to that physical Network and then contrail trance compiles that down to what actually needs to happen on a network and internally that's done by using this concept that we like to call as the end as a compiler internally within the contrail controller everything is built around formal data modeling we have variables that describe the high-level service and in that formal data model we currently have things like a virtual network a policy a gateway function and then you instantiate objects into that data model by using the northbound REST API is that are automatically generated from the data model then we also have a low-level data model that describes the particular technology in the network so for overlays that it's robbing those tunnels routes gateways that are all targets every time somebody changes something in the high-level data model this thing in the middle the transformation engine wakes up and translates that high-level requests into a detailed description of what needs to happen in the network in the virtual network or in the physical network and then we have multiple southbound protocols desired state to the network using BGP or XMPP or other protocols it's not just a matter of configuration taking high-level concepts and breaking them down into smaller things for operational State and analytics it's also the other way around all of our V routers in the hypervisor are constantly collecting events for every single flow in a network and sticking those events in a massively scalable database and then we aggregate that and correlate that so that you can manage your network and troubleshoot it at the same level of abstraction as what you use on the management and on the configuration side of things now you might be concerned that this as the end controller that the contra controller is a single point of failure or a bottleneck in your network and the short answer is it isn't because it's very carefully designed to be highly availability and highly available and horizontally scalable even though it's a single logical system with a single management interface and a single pane of glass it's actually internally implemented using different nodes there are different nodes that provide different functions we have the configuration nodes that contain the data models and the compiler we have the control nodes that contain the southbound protocols such as XMPP and BGP we have the analytics nodes that contained another V explained that I was talking about each one of these nodes can have multiple instances if any one of those instances fails the system as a whole continues to function it's an active active model rather than an active standby model and if any one of those nodes runs out of capacity you can add an additional one instance of that particular type of node and the system will automatically scale out and redistribute the load while it's running then to close off we decided to open source everything the reason why we decided to do that is because we want to fit into the open source ecosystem that cloud stack is as well as OpenStack that wouldn't work as well if we were a closed source component in that environment as I mentioned everything is open sourced the controller the V router same feature same scaling the open source version provides everything that I talked about which is network virtualization the ability to apply policies the ability to implement service chaining the ability to connect to a layer 3 VPN in a wide area network because we are a you know we are a vendor of networking hardware we are very careful to build this in such a way that it works on the hardware of any vendor but if we also do some integration with our own physical network so that you get some additional capabilities if it's juniper equipment one example of that is integrated analytics where we also generate analytics events from the physical network so that you can troubleshoot your your virtual network over a physical underlay so thank you very much if there's any questions I'd be happy to take them what is the plugin well we've integrated it into the 4.2 cloud stack and we've also integrated it into the 4.3 cloud stack all the older code is there I'm not sure if we've been in a name to Dagon and then it integrates with the contract controller through the North North mount REST API is that the controller exposes that are consumed by that code yeah so the question to peripheral could repeat the question I'm not sure if I caught it entirely but I think the question was around how do you route traffic from one isolated Network the green one to the other isolated network the red one and force it through a particular sequence of virtual services it's similar in concept yeah it's very similar to that concept of inter VLAN routing although it's implemented using overlays rather than freelance do we have a V PC router that uses overlay and networks does the open contrail plugin create a V PC router I believe so yes well if you actually want to see it we have a booth downstairs that shows the integration with OpenStack so sorry with CloudStack as well currently we support KVM and XenServer and ESXi support will come in q1 of 14 and hyper-v is on the roadmap but not a specific date yet it is not used in production yet we have about 20 customers that 20 or 30 by now that are evaluating it and there's a couple that are close to production the ones that are publicly announced when we announced contrail as well as the open sourcing of it there's a video of that and there's a couple of customers there that talked publicly about being close to deployment [Applause]

Channel: Sniper Network

Views: 13,886

Rating: 4.9080458 out of 5

Keywords: sdn, software defined networking, nexus, cisco, APIC, aci, iso, switch, managemnet, cloud, Management, Software, Technology, System, Data, Training, Security, Information, Systems, Design, Computer, Solutions, Business, Computer Security (Software Genre), OpenDaylight Project, openstack, openstackneutron, neutron, vmware, nsx, Juniper OpenContrail, Juniper Networks (Venture Funded Company)

Id: BLnbKs3hXZE

Length: 32min 59sec (1979 seconds)

Published: Wed Jan 14 2015