VMware NSX Tutorial - Technical Introduction #VMware #NSX

[Music] hi I'm Shawn Howard with VMware's Network and security business unit I'm going to talk today about sort of an intro to the technical parts of NSX we're going to go through and you know in depth may be may be stretching it's only give you about 25 30 minutes but will give you an idea for technical audiences kind of what the main components are what the objective of different things are so as a level set for those that may not be familiar the basic premise of NSX is to abstract network constructs it's not really to do anything mystical that you aren't familiar with already you've got so let's say here on the slide you can see that I've got a physical network of some type there's some switches there's some routers doesn't really matter for our purposes here I've got a bunch of hypervisors connected to that I've got these distributed virtual switches here and presumably you've already got something like this right it's already doing network virtualization to a certain degree you've got these virtual switches what nsx proposes to do is create this layer so sort of you know inserts some additional code into the switches it creates this it sort of federates them together into this you know this virtual fabric or you can think of it like a network hypervisor or something like that but it's a layer of abstraction on top of the physical environment that allows you to build logical network stuff so let's say in my virtual environment I've got these little these little applications right the VMS you can see here represent different applications and what i'm doing is creating logical environments on top of that so i'm saying alright this workload down here has a couple of layer two segments you know analogous to VLANs it's got a load balancer it's got some security policies on those VMs it's got a router you know different subnets same deal over here it's a this application works slightly differently so maybe it has different rules different firewall policies different subnets and or maybe it has the same subnets as the other one and then this application at the top here you can see we're doing some bridging out to a physical thing so we're saying we have this physical workload that for whatever reason has to be layer to adjacent to these VMs so for each application we're creating the logical topology on top of the physical topology without really caring how the physical topology works under underneath so if you're familiar with like Amazon AWS or a juror or you know our MV cloud air when you go out to create those things when you go and say you get a little control panel that says hey I want to create a subnet you know I want to create a the equivalent of a VLAN I want to create a broadcast domain and assign the subnet to it and I want another one I'm going to hang these VMs off this one and those VMs off that one and route and have these firewall rules between them and you're just defining this logical topology you don't really care in the end how the cloud provider goes about making that happen if you go to ec2 for instance or if you clot air or any of these that you say create you know create a V PC or create a V X LAN or whatever they're not really making a VLAN they're not really reaching into the physical network and programming switches and telling them to create VLANs and stuff like that it's just doing it logically on top of this so all the big cloud players do something like this they abstract the physical away and then it makes it a lot more flexible it opens up all kinds of possibilities to do this thing in an automated fashion to do self-service delegation all that stuff so that's the objective here so how does this all kind of work how do we make this happen or there's a few fundamental things we have to do first so NSX is the thing that you install into your environment it's a it's pretty simple to deploy in and of itself it's like most of you more things you download a an OVA and you deploy this management console and there's several layers to it so the management plane this nsx manager here that's the OVA that you deploy that's the thing that hooks into V Center it's the thing that you know gives you an extra tab in the V Center web client that allows you to you know create logical switch create logical router that kind of thing then you have the control plane these controllers now the controllers don't fixate too much on them in terms of day-to-day management of the nsx environment most of what you'll be doing through the web client the controllers provide a bunch of behind-the-scenes coordination of things that we'll get into you can almost think of them well you can almost think of them as the same thing as Active Directory domain controllers or something they're replicating with each other and you can connect to any of them and from a you don't really have to think too hard about which I mean there are roles and things that different ones do but you don't have to think too hard about it you just connect Active Directory and do queries right so and then at the data plane layer the data plane means this is the thing that's actually passing packets that resides in the hosts it doesn't reside in any particular place it resides on every host that's prepared for NSX so the benefit of that is all this other stuff can go down and as long as there's as long as the one host and the environment is running some amount of network stuff is passing through right so these things are independent of each other to a large degree now this top thing here where they're saying self-service portal you don't have to have this but to realize the maximum value of NSX you want some kind of some kind of system in front of it NSX is meant to be consumed via API even though there's a GUI with the web client all that in larger environments what you're really after is the ability to just issue API commands from some sort of portal or our own view out where we realize automation does this even the cloud director there's a number of you know OpenStack can do it you can write your own thing a number of customers out there I see that all the time people write their own Ruby portal or PHP portal or whatever but the idea is you can consume it all in an automated fashion via a common REST API into the nsx manager again cloud consumption layer not necessarily required but highly recommended to realize the most value so deploying it there's some stuff you do one time and like I said you download this OVA you deploy the nsx manager once that's hooked in you go to the you get this networking security tab you go in there and say ok deploy the controller clusters you basically just give them IPS and then it automatically pushes the controller's out and I'm up and everything according to the parameters you fed it you only deploy three controllers that's it and then you do this host preparation thing and that's done on a per cluster basis so this so like if I have five clusters in my environment and I want to run NSX functions on four of them I would only prepare those four clusters I wouldn't necessarily prepare the other one because you have to license an entire cluster at a time so that's the licensing boundary - I say prepare this cluster it has five hosts or whatever in it then it's Falls the fibs and all that doesn't require reboots or anything but it pushes all this stuff down and prepares them and either 4vx land for distributed firewall for whatever functions you select and then you have to have licenses for all the sockets and the hosts that got prepared there's thing there's another step called logical network preparation where this gets into we have some options with regard to how we're going to do so if you're familiar with ARP broadcasts and layer two there's a function that sort of needs to be done that's like that of discovering where IP addresses and things live so sort of proxying arp over layer three is effectively what's going on there and we have options we can do this over multicast we can do it with unicast with the controllers we can do a hybrid mode so there's some thinking that has to be done at this level to decide you know how you're going to lay it out and then now we're talking about the consumption part now the consumption part once you've set all you know you set up your physical fabric you've prepared the hosts you've deployed the controllers and so forth you stop messing with that stuff and that's from then on all you're doing is just saying hey deploy these live will Network constructs and on top of the physical environment that that you've set up you can deploy these spin them up span them down you know automate grow them change them you know whatever it doesn't really matter that's you know one of the main benefits to that to abstraction these things up into the virtual layer is that you can mess with them and you can only you're only really hurting the thing that you're touching so in other words much like a VM you could delegate control of a given logical switch or a given you know you can delegate given logical edge services gateway Forks Apple and say hey this subtenant can mess with this and they can break their own stuff but they can't break the overall environment the way that it would be if you say delegated control the course which to somebody and said hey just be careful don't break the other VLANs can't really do that right so talk a little bit about the switching so how does that logical switching stuff work so taking a step back remember in that first slide how we had a physical environment I said it didn't matter what the layer two layer three situation is well that's what logical switching vx lands overlays all this stuff is about it's about not carrying how your physical topology is with respect to layer two layer three you know whether you chose to be on a different subnet for all it cares but we need it to be logically that two VMs attached to the same logical switch our layer to address it from their perspective so how does that work and this you know when you have to care about the physical stuff you have all kinds of things like spanning tree and broadcast domain sizes and things like that that you get into that you don't really have to worry about with this so with VI again you architected physical infirmities overlays on top of it you know just a quick easy fashion so here's a slide I threw together that hopefully illustrates this a little bit better so let's say this is my typical hierarchical architecture right I've got the edge where all my services lid I've got a core got a distribution layer I've got an access later now let's focus on the lower three hosts they're vSphere host one two and three let's say that's the cluster that I build you know I build a three host cluster it's in row 1 so it falls into distribution switch one and let's say that I'm terminating my VLANs at the distribution switch totally normal so these VLANs the red and green VLANs are only available in row 1 and I say ok I create red VMs on the red VLAN green VMs on the green VLAN I trunk those VLANs down from the distro down to each virtual switch in each host and that's great a year later or whatever I want to grow this cluster I want to add two more hosts to this cluster and utilize that capacity and say well what does that mean that means now I have to have that green VLAN extended over to this new row where it doesn't live so we have to go as virtual admins we have to go to network engineering and say hey do this so focusing on the red one we have to say hey take the red one and extend it across the core extend it you know and I've just caused all kinds of problems for network engineering has they've carefully compartmentalized their spanning tree there's lots of reasons they don't want every VLAN on every port everywhere totally flat in a network of any appreciable size that becomes problems because of spanning tree blast radius because of all there's lots of reasons really good ones that we're stepping all over the network engineers architecture and it takes time it takes rfcs it takes care on our part we have to go make sure that all those you know 2v2 VLANs is not a big deal but what if we had like 50 and then we have to make sure that those VLAN tags are trunked right on every single port touching every host this is the sort of stuff you get into when your VM is tied to a physical thing in the network at VLAN and that in turn it has to live on that VLAN because it has to be on a certain subject it has to be layer to edge sent to other VMs it has to be behind a certain firewall to get a security policy all that you wind up with this sort of half virtual set up so what an overlay does now we're talking about VX land in nsx there's other ones you may read about like stt which is comes into played some cases and nsx there's a env GRE users even IPSec there's number of overlays in the world and it's kind of academic which one's slightly better than the other they all do this thing I'm about to describe so we make it so that the physical hosts the actual physical networks that those hosts have trunked to them we don't care as long as the hosts can route to each other somehow so let's say that you know the three hosts in row one or on the purple VLAN and 300 the two hosts in row two are on the blue VLAN doesn't matter we don't you know that's it that we just have to give them one IP all right and then they all route to each other and then artificially we create this VX land overlay so the red VMS on the red VX land as far as they're concerned they're just free VI admins out there they're just attached to a porta group it's like anything else it's like you have a part group that's backed by a VLAN in this case you have a port group backed by the X land so you just attach the VMS that need to be on that VX land that need to be layer to add you sent on a certain set to that that vertical port group and then they can talk to each other there none the wiser as to what's going on here so how does this work under the peppers oops alright so my VM let's say it's doing a art broadcast or something it's doing or it wants to talk to another VM it's going to that is on its same subnet it's it's let's say it's already done its art broadcast it's already figured out that it's good you know it needs to talk to this MAC address so it's sending a layer 2 Ethernet frame to what it thinks is something that's right there on its same subnet or right there on its broadcast domain and it does that stands the standard thing the host has a thing called a V tab which is that IP address on the blue or purple VLAN and it then says oh ok so you're actually you know it might involve the controllers and stuff here to look up where the target VM lives and or do some multicast or something depending on how you have it set up and it says okay I need to encapsulate that with a layer 3 packet send it over to the target host and then the target host V Tech D capsulate sit and hands the layer T frame to the VM as far as VMs are concerned everything's normal and you don't really have to think too hard about this either it just happens so when we say physical workload integration I do want to real quickly point out that it's 21st century you can route it's not a big deal you know when I got started in the entry in like 1993 or for whenever it was routing was a big deal latency wise now it's really not so I would say to most customers that say hey I have a VM I need to talk to physical things if you're ok with having a routing hop which in the vast majority of cases is perfectly fine just do that just route and you won't have to do this bridging about to describe however if you do have a situation where I have these VMs that want to be X land and they must be layer two edges in meaning same broadcast domain as some physical stuff then we can do a bridge so there's we can do this in software like if you're doing a migration or something we can do this in software if if you really are doing a ton of this and it needs to be you know up all the time and super fast and everything else you might want to look at hardware V temps that's where that stuff comes into play when you start talking about hardware V tabs layer two bridging it's actually a pretty small pretty narrow use case and you know for most people a better example when they say physical workloads here maybe imagine instead of servers what we have is physical load balancers that have to be layer two adjacent because of the way the load balancers are configured that's a more common use case the default gateway needs to be a physical thing for stuff on a bx land in any event like i said it's it's it's a relatively uncommon situation if you're okay with routing you know it's mess with it a lot of people at this point ask like well how do I know how do I see and troubleshoot this stuff I have this overlay and it's you know that network people are confused and can't troubleshoot things so there's a few things first of all your network team is probably using some kind of net flow some kind of something like that and we could push net flow we could push every flow that every VM on you know everywhere in the entire environment we can push that data to whatever system they're using in PRTG or Cisco's thing or whatever we can also do a our span you know our span your span meaning we can mirror a report because they take this virtual port mirror all its every single packet that goes to it over to something that is running Wireshark that can look at it you know we have SNMP moobs you know all the normal stuff we can also syslog so we can push to Splunk our own login site well anything that does syslog an siem system we can push every single flow that ever happens and I don't mean every single packet what I mean is a summary of each flow you know this thing talk to that thing on this port this amount of data that kind of deal we can send that and you can keep a record of every flow that ever happens to be on all your VMs in your environment it's a you actually end up with with a lot more visibility in most cases and then we have some built-in thing where we have a thing called a it is here's nsx manager connectivity check but it's a it's cults become a trace flow where you can nominate two VMs and say trace the flow and it'll show you the entire path of V tabs and everything all the encapsulation D capsulation that's happening so there's a lot of tools in the tool chest there to troubleshoot things now VMs have a single logical switch you can see here I got the web one tap one they're distinct subnets well oops the physical view as you can see here if you notice the two hosts on the left or on the 150 0/24 and then there's host on the right that's on a different slash 24 250 but the VMS don't care again VMs they're all they're all logically layer to a Justin now routing we get into distributed routing what we're talking about here is it's not just about multi-tenancy but this is a use case where it's very valuable multi-tenancy in our case meaning you are a service provider and you have like lots of different customers each with their own little bucket of resources but sharing the same physical physical resources physical network physical hosts but they logically each have their own bucket which is how it is and be caught error for example or maybe you're a company that has developer environments you have a dev test prod UA and they're kind of separate you know maybe they're overlapping IP schemes but they're but they are need to be kept logically separate there's lots of use cases for multi-tenancy apart from the service provider thing in other words v there we go so you you end up in those environments with a lot with some scale issues you end up especially via mobility becomes a big problem now the benefits distributed routing and hypervisor what we're talking about there is again I create a logical router it doesn't live and it's not like a VM distributed logical router is not a VM that lives on some host somewhere that everything here pins to its it lives everywhere and nowhere so in other words I'm creating this logical router I'm giving it interfaces like it was a physical router Orting think of it like Linksys router at your house or something you just go into the web clients they create this distributed logical router and it gives you some tabs like you know to design the interfaces and stuff and it's got an uplink it's got the two down links logically it all works the way you would expect I've got those two segments it's on that are connected to the logical router now this controller thing that it's showing here this is just control plane traffic for the router to figure out what VMs live where and what routes it needs to host and it's a it's but but it's not like everything's data traffic's going to the controller or anything like that so let's say two VMs want to talk oops they you know the routing is done in the hypervisor again it's not like if a VM VM one what's talked to VM five it doesn't need to actually like go somewhere to be routed and come back the way it is with VLANs it could just be routed by whatever local host so we're talking about route peering here so if we're creating distributed logical router x' for each tenant through a cloud portal through some automated process we you know and we assign routable let's say we're not doing that were assigning routable IP s we need those things to be announced on our physical network so we can do this via OS p OSPF or bgp so those dl RS at the bottom level there can peer up to what's called an edge services gateway and that's where it actually the edge services gateway is the thing that talks to the quote unquote you know real world real VLANs and you can see that on the left there dl are traffic that's just going you know east-west traffic we call it between the hosts or you have something going north-south needs to leave the data center it goes out through that ESG now the ESG is the edge security gateways again these are the things that that are on an off ramp to the physical world so in this case here in this case here let's just say we have one ESG and a bunch of deal ours below it the aggregate throughput that we could do north south not east west east west is as much as the host can but north-south would be ten gates ting gigatons and that sometimes isn't enough right so we may want to have it a bunch of DL RS or a bunch of tenants going up through an EC and P topology where we can have up to eight of these EES G's in a kind of you can think of them in an e CPE MCC and P clusters however you want to think of it but the idea is equal cost multi pathing load balancing with OSPF for bgp could do this and balance the traffic you can get up to 80 gigs north-south so that's kind of your you know again north-south is traffic like leaving the data center it's not which tends to most it's rare I've seen maybe two customers that actually need all eight they don't really one or two is absolutely plenty because it's again most your traffic sees West distributed firewall so everything I've talked about forget all that this has nothing to do with any of that it it ties in in a sense but it is a completely distinct function of NSX and many customers deploy it in the absence of all that of their overlay stuff and routing and everything else so what I'm about to discuss with attributed firewall you don't need you you can do the V temps and distributed Relic routers and he has to use and all that but you don't need any of that do it you can deploy DFW right on the exact ecology you have today so the idea is most most companies you can think of it like the the you know what they call it the you know the the bond bond theory or whatever where it's like the card outside and the creamy inside the most data central like that they have really hard perimeter security with layer seven inspection and anti-ddos and all this stuff but inside they have either no or very little maybe a better analogy is your front doors big steel wooden something hard to kick down but the interior doors are real weak so it's not that there's no security internally but it's it's low much lower how would you fix that well you could put a bunch of east-west firewalls in the reason nobody does this is it's not it not only is it tend to be cost prohibitive meaning like put a stateful firewall at the top of every rack it's also really hard to manage so it tends to be that we focus and fixate on ease on north-south traffic but once something gets in somehow or another the weakest thing let's something in now it can go crazy inside your data center so distributed firewalling it's basically putting a you know every VM as a virtual NIC on a virtual port facing you on a virtual switch and what the DFW does is it's a kernel module that goes into the district that into that virtual switch and firewalls the traffic before it can enter that that virtual port and it does this in a you know totally distributed manner at line rate if your hosts like the bus and Knicks and everything on it can push 20 gigs this can push nineteen point nine or I mean it's very very small penalty to pay in terms of bandwidth just effectively line rate and the latency it adds is like 12 micro microseconds not even milliseconds it's really really small imperceptible so now it's now it's totally feasible to do this firewalling everywhere on every vm everywhere all these traffic and manage it centrally so again firewall rules enforced the v-neck level how you construct these firewall rules is it's not the classic 5-tuple IP thing that a physical firewall has to do it's it is 5-tuple in the sense that you have to say source destination what's talking whether it's allowed a block that kind of thing but we could define the source and destiny Center knows about so it could just be dam names whatever IPs those VMs happen to have we're not enforcing it based you know we're deciding based on their Lodge whole identity so an example here would be I have two VMs on the web tier VLAN let's say and I I want them to be able to talk to the load balancer and I want them to be able to talk port 80 or 443 or whatever out to the internet but I don't want them talking to each other because I don't want it to be that if somebody does a buffer overflow on one of my web servers that they can then move laterally with a poison heart attack or something which is really easy to do I can say okay they can talk out HTTP and then they can't talk anything else and then I'm saying now they can talk eight four four three maybe this is a reverse proxy down to a tomcat server on the app tier or something like that and then block everything else and it doesn't matter again what their IPS are and whether it on the same subnet or different subnets or any of that it's enforced logically based on their membership in these security groups so we can identify membership and security groups by lots of different things it can be things like the you know like objects that are invaded like the data center object and vCenter or the virtual network or the virtual machine name or you know we we could do it by IPS to we can also do it with this thing called security tags or other attributes in virtual Center like I can just arbitrarily assign a bunch of tags to things that say this thing belongs to production this VM belongs to finance this one belongs to HR or whatever and base security groups and they can overlap it's kind of like Venn diagrams we can have things with multiple memberships and different things and they inherit this cumulative security policy it winds up being way way far way way fewer rules to manage than classic five tuple ip-based and it's it's much easier to troubleshoot and understand when you're looking at it and the policy just you know if you change the IP in a VM if I'm basing it off the name that's fine if I'm basing it off the security tag fine change the IP that's not how we're just you know you don't then have to go in some firewall somewhere and update the rule or delete it there's no now there's no security rule to clean up so we can automate things like in we can integrate with a number of different third-party systems to do things we you know if you're familiar with the with the old V shield endpoint stuff where we're scanning hybrido scanning for antivirus at hypervisor layer we can tie that in such that if a vulnerability is found on say a web server by this vulnerability scanner that we have tied in it can then tell NSX hey add a tag that quarantines this thing until we're done remediating it and during the time that it's quarantined until you're remediated it can only talk to the AV server for example we can automate that kind of thing it's very dynamic possibilities and finally we're going to talk about the load balancing NSX load balancer it's it handles I would say 95% of use cases that that most customers use an f5 or a net scaler or something like that for now I'm not saying you wouldn't you need to like throw out your net scalars and F files and stuff this is more for East it's more commonly used in my experience for east-west load balancing within data centers big high-capacity internet-facing load balancers that you've already invested millions perhaps in those stay in place and we when you start doing like load balancing between say the web app and see full tears of an application and you know in that case you can use a fairly simple load the logical load balancer that does all again 95% of things that you would ever want and that you can deploy as many of these as you want right so I deploy these things I give them my Peas I create VIPs and server pools and all the stuff again through the web client or through API commands and it can do all this you know normal sorts of things there's site-to-site VPN services there's SSL VPN services this is typically done for migrations or to in some cases stretch layer to for an active-active day Center type situation and now we're going talk about the NSX so there's lots of different reference designs technical papers things you can look up that will talk about this but the general idea here is the architecture you can do it everyone right is we're not saying you have to do this architecture but what we're saying is let's say you were doing a layer three leaf spine or something where we don't have any VLANs extended past top Iraq the ones on the left that compute clusters can be on that you know connected to that it's only the edge clusters you can see at the right that we really have to care about real VLANs that get trunk to those hosts so that that's why we kind of concentrate north-south traffic to these specific edge clusters that way we don't have to extend actual VLANs all over the place and north-south traffic tends to be again much less than east-west and then we would say hey you know you have your management clusters you should already have an infrastructure or management clusters is a separate thing and separate racks then you know you don't want a circular dependency but you don't have to do any of this in a small deployment of I've seen NSX deployments that are three hosts they just have everything consolidated into those three hosts so again you know we in the virtual world logically faithfully reproduced layer two through layer seven services we can scale stuff out central API to control this thing central standardized thing and there's resiliency we didn't have time to get into as much summative light too with regard to resiliency but let's say you have virtual edge services gateway if you just check a box and say make it resilient and it creates the VRP barrier and all that stuff the the resiliency story is the same as with physical routers and so forth and we and this is also a platform for third party services we didn't get much into that but think about the power of distributed firewall and how it has a tap basically on every single virtual NIC everywhere and think about that we can allow access to that tab to any you know third party provider that wants to do it so there's a lot of IDS possibilities and things like that so I where I see a lot of customers going with this is the first project is don't change anything don't install any overlays or anything like that first project is enter data center micro segmentation meaning you're using the distributed firewall to implement a segmentation mandate without having to like create a much new VLANs and re IP your stuff it's a hugely valuable thing that people tend to do right off the bat then as they work towards actually automating their IT and moving towards sort of the next-gen sddc data center architecture they start introducing the other elements again you can you can ask questions of our panel here you can you know register there's lots on there's lots of online free courses there's hands-on labs I'd encourage you to do and we also check with your VMware SC or account rep we have you know public free you know one in two day class event type things that that you can just go to you just have to know that there and there probably in your city if you're in the US so thanks and that is it

Channel: Technocraft

Views: 62,798

Rating: 4.5818181 out of 5

Keywords: VMware NSX, NSX, VMware, virtualization, NSX Manager, vRealize, vCloud Air, vRealize Orchestrator, vCloud Connector, vmware nsx tutorial for beginners, vmware nsx training, vmware nsx overview, vmware nsx installation, vmware nsx deep dive, VMware NSX Overview, network virtualization, Vmware Nsx tutorial for beginners, nsx vmware, nsx virtualization, nsx virtual networking, nsx virtual firewall, VMware NSX overview, vmware nsx architecture, vsphere 7, introduction to Vmware NSX

Id: qi7pMeBSa5U

Length: 33min 32sec (2012 seconds)

Published: Tue May 17 2016