VMware NSX Edge Gateway & Distributed Firewall with Tim Davis @aldtd #vBrownBag

whoo good evening everyone thanks for joining us as the brown bag tonight we're concluding our NSX ninja Club excuse re in a sex ninja presentations with Tim Davis we're going to talk about the edge gateways distribute firewalls and design and we'd like for you to join into the conversation you can tweet to us at V brown bag and I'll be watching the Twitter feeds with the at V brown bag and the hashtag V brown bag we'd invite you to watch our other shows as for the different time zones you can see there without any further ado I would like to introduce for the third time our guest Tim Davis I'm so glad to be here again as tellin Tom a little bit ago before we started broadcasting and all that as much as I'm glad that the series is wrapping up because it's been three weeks at the same time I wish there was more because I really like talking about that effect and not the presentations into going really well so if you could pass me the ball sure if it isn't call the ball on this one knowing you pass you the baton close enough all right great cool so we're going to go ahead and start off here today we are going to go over the edge services gateway the distributed firewall and a little bit of intro to design really not a whole lot I could do an entire week straight on design I could do an entire week straight on distributed firewall edge services gateway so we'll just kind of blow through these will kind of try to hit all the things that we can here I'm in the limited time that we've got left here so look like lips lips yeah so the nsx edge is really the ingress ingress point the the barrier into your nsx environment so when you do deploy nsx out there you start doing virtual networking most of your features and everything are going to come through the edge services gateway now this is an appliance that gets deployed out into your environment this isn't part of our distributed topology like the DLR or the distributed firewall so this is a point where your data is going to traverse through a virtual machine so if we look here this is kind of an overview of the services offered by the edge services gateway this is going to be firewall and this is a stateful layer for firewall just like distributed firewall and as I alluded to in the past couple of weeks the firewalling that happened on your edge services gateway is completely separate from your distributed firewall one of the reasons that's super important is because depending on how you deploy your edge services gateway in what form if you're doing like an equal cost multi pathing you lose your stateful services on that edge now why that's ok is that you're still doing state for stateful firewall in kernel with your distributive firewall and we'll talk about that a little more in a bit so looking over at the the services here layer 3 through layer 7 services so you're looking at DHCP DNS routing that edge service gateways are where we do our VPNs we have a couple of different types of that the load balancer so when you deploy an edge you can deploy an edge to be a full edge router with fire own services and all that or you can just deploy an edge out just to be a load balancer and do nothing but load balancing if you're doing a one-armed or inline that you deploy in edge services gateway that does nothing but load balancing so the benefits for this real-time service instantiation so we can go ahead and deploy all of these services right when you need them you're not having to go out and deploy a physical appliance rack and stack it cable it give it IPs and all this kind of stuff all of this is done with the same kind of quickness that we can give you with other networking services it is an x86 compute form factor and I think I just skip past that so again this is a virtual machine that runs in your network you don't have to go out and physically deploy this when you go into NSX and you throw API calls for an edge or you go through and you click the settings for it it will automatically deploy this from your nsx manager so this is a quick look at our reference architecture for edge services if you notice we're kind of adding on a new rack to the standard vmware recommended topology where you have management cluster as well as compute clusters in the nsx reference architecture which we'll go over at the end we add an extra cluster called the edge cluster and what this is is this is where all of your es GS are deployed so that you're only connecting your northbound and southbound traffic through one specific cluster everything else from your computer your management is all east-west and we'll kind of go over that here in just a little bit so let's take a look at some of the service if ik features yes sorry I keep interrupting you where's a question that came in from Twitter and I think it's a it's a fun question I don't know if I would ask more more clarification but it says if we're running native the X LAN can we also run NSX on the same network I'm not sure exactly what gravamen so this is a kind of like somebody asked us when we went over switching and routing last week for instance V X LAN is run on Cisco's API fabric you absolutely can run NSX doing the X lamp on top of an existing DX plan whether it be Cisco's or somebody else's the only thing that's required there is the extra header room for encapsulation because VX plan adds that 50 byte header so if you're double encapsulating you need 100 bytes extra as opposed to just a standard 50 bytes that we normally ask for so as long as you have the MTU size for it you can absolutely run double encapsulation like that running nfx on top of a different installation of the excellent I got it now thank you so much yes sir so going back here we've got the edge services gateway so it does run firewalls nat DHCP last week we talked about having overlapping IP spaces on ESXi hosts mainly used for things like Application Lifecycle or you know development and things like that NAT the ESG is how we do that so you have your two VMs that are 192 168 1 1 but they're behind different ESG s using matting in order to get in there so that's kind of the mechanism to make that work routing we do with the ESG now this isn't like your distributed routing this is going to be you know standard routing from that one stand-alone machine it's not distributed all across all of the hosts like the DLR is load balancing this is the big big feature that we have any ESG we absolutely can do some crazy high-performance load balancing including SSL offloading really for the most part if you're using f5s in your environment most likely you're not using like Web Application Firewall and eye rolls and everything like this for all of your workloads most environments have some really basic load balancing that even if it's high performance and SSL offloaded you're still doing like one fit to a pool of EMS and we can absolutely take over load balancing for that site to site VPN so before multi-site nsx was really a big thing we were able to use edge services gateways to do site site VPN and kind of stretch that if you're doing things like mergers and acquisition or you know bringing in other environments or consolidating data centers using site-to-site VPN can be very help pull through the edge services gateway ssl VPN so if you've got remote contractors and things like that that need access to your environment there are some other solutions you know cisco has one how also has one then they kind of allow you to you know just bpn into your environment you can use the edge services gateway for that we have a client for just about every major OS there at this point and then the the big one here layer 2 VPN so the thing used mostly what this is used for is when you're migrating VMS from VLAN back port groups into VX lan back port groups or if i'm sorry or if you're you know setting up a site to site where you need a technology without the use of hardware like OTV you can use that l2 VPN and of course high availability so we have a few different ways that you can deploy ESG that allows you to have high availability on that whether it be just active standby or the up to eight of them in a nice EMP fabric and of course dns relay with syslog all of our stuff whether it be the distributed firewall the SGS nsx manager everything conduces log we can dump all that out to the syslog you already have or we can of course use any other syslog aggregator or log in site which with nsx when you buy nsx you automatically get login site it comes free with it whether you have one tiny site or a bunch of sites you get as many OS sizes you need to cover your entire nsx environment so that's cool so looking at the nsx edge in DFW with a security comparison here distributed firewall is going to be mostly for your east-west stuff obviously because we're distributing that load across all those ESXi hosts and all of your VMs able to move around they keep all that you know firewall information the edge services Gateway firewall is still set from the same place but those are just mainly for north-south traffic coming in and out of an NSX environment whether it be a tenant or your overall environment there's multiple sizes of edge services gateways compact large quad large and XL really for the most part I mean I've never seen a compact used unless it's like a home lab large really is semi common in really really small environments quad large is mostly I've seen that when it comes to just needing like a lot of firewall rules and stuff like that the edge if you're going to be doing any form of load balancing you should be using extra-large and if those things are sized to handle the connections per second and everything that you're going to get really needing for high-performance load balancing so this is just kind of a look at the UI for configuring edge services bear in mind that some of these screenshots that I may have maybe a little out-of-date do the fact this con the content was built a little while back so if I see something specifically I'll point it out but this is pretty good so you can kind of see a little bit of the settings here for the configuration of an ESG for impactor conversion so when you deploy in ESG and you deploy it you know say you want to start out a compact you can actually go through and convert it to large extra-large quad large and all that just with a click of a button it'll go out and it will redeploy a new edge it will backup the config dump the config over and then a little fail over to the new edge so in interface based routing and firewalling your OSPF your ibgp and ebgp all of that is peered upstream your physical devices through your edge services gateway we talked about that a little bit in the routing last week where when you're doing a distributed logical router got that little control the end that piers upstream to your ESG your ESG is then what piers upstream to your physical devices this is going to be your north-south routing point so for scale and performance this is up to line rate performance with a scale of architecture II so with the es G's at this point in time you're getting roughly 10 gigs of throughput per device in the future you can see that you know being kicked up a little bit we don't have anything specifically coming out but they're looking into technologies like Intel DVD K which essentially allows you to write the package directly to the NIC instead of having to pass those packets through the tcp/ip stack there's companies like viata that are getting 40-plus gigs of throughput through a virtual machine so definitely look for more you know performance than 10 gigs but at this point in time we see a lot of customers that don't really have more than 10 gigs north-south traffic coming through one ESG if they do then that's why that's when we recommend things like equal cost multi path routing through es GS where we can aggregate those together for up to 80 days so the NSX load balancer on the edge lots of different things that we can do here we can do a little bit of application rules nothing really crazy we do have a scripting language that's available just like f5 does if you've got some like really really crazy context rules and web application rules and stuff like f5 Scott we're not going to be able to compete which is why we have to partner integration the virtual f5 but I believe the rule of thumb that we've seen is generally about 80% of the little balancing most customers have in their environment is pretty basic in grand scheme of things even if it is like really huge pools and high throughput and all that huge connections per second we can handle that we can absolutely handle performance just some of the really really crazy context stuff that we're gonna let em 5 - what f5 does best but if you need ipv6 support we've got that if you need SSL termination certificate management we can handle that no problem we've got lots of different health checks in the environment so you're not just looking at saying yeah is the host up great you can kind of see the connections for the host is the host stable is everything going well with your load balancing environment you can have multiple virtual go ahead we have a question in from Ken can ask he says it's nice than nsx edge can be scaled up can it be downsized at a later time if desired it cannot so we can scale up we can't scale down so what you would need to do then is to deploy out a smaller one and move your connections and your configuration and stuff over so if you do want to scale up make sure you know that you're you know not able to go back all right I think I got another couple questions but a letter finished a little monster uh there is one thing that I had heard and maybe you can confirm it hmm I heard that basically the load balancer can do everything H a pouch you can do that is absolutely correct and there's three guesses on why that's true you're only going to need one exactly guess where our load balancer is based off of so if you are familiar with H a proxy H a proxy is a fantastic load balancer that's what ours is based off of now we didn't just take a cheap proxy and slap it in there and you know we're good to go because you're going to get some of that VM or secret sauce thrown in there but absolutely so if you're looking for comparisons of performance and stuff like that you can definitely you know compare apples apples a little bit so logical VPN user and site to site so user VPNs are extremely important for companies that have like offshore contractors or Road Warrior workers and stuff like that we've got the ability to deploy a client out on you know Windows Apple Linux and all that and give you access into your environment just like any other VPN client would also site-to-site VPN so if you've got multiple data centers or multiple remote sites you can deploy edges out there and create IPSec tunnels now one cool thing that you might also be able to do with this is if you could deploy edge services Gateway out into maybe a public cloud somewhere what would stop you from setting up a site site VPN allowing you to have that connectivity between on-prem and cloud so it's this high performance 2 plus gigs per tenant when you're doing VPN you're not going to get that full you know up to 10 gig line rate to kind of thing out of the ESG due to the fact that it's still doing its other functions but you can get 2 plus gigs so throughput per tenant now that doesn't mean you get two gigs period that means per tenant and when we think 10 and we say ESG so if you need more than that you can split out and deploy multiple 10 at yes geez giving you that extra space use cases for this you know cloud the corporate of course cloud onboarding you need so if you're kind of spinning out new workloads spinning in Newark loads having that connectivity is definitely helpful also a remote branch office is a big one this is a little bit out date in terms of information because we now have the nsx Robo skew which is a little bit different in how we how we manage things and it's priced completely different so for Robo is a big use case for you and definitely reach out to your nfx se because we're doing some really cool stuff and of course the layer 2 VPN if you need that stretched layer to connectivity between say on you know on pram in a public cloud we can give you that l2 connectivity this is SSL based web proxy support and broadcast support so with this you're also getting that two plus gigs per tenant if you need more you can do multiple tenants those are different routing points though so you won't be able to have everybody aggregate through VPN for mes people before go on a a couple questions from from slides back is the SSL offload able to use the newest Intel instructions for performance you know of if using any particular I mean obviously it tends to be that newer servers are better do you know if NSX is yeah that's a great question that I don't know off the top of my head ping me on the side whomever asked the question or area let me know and I can get you all the info we have up to date on our load balancer for offloads I do know that last time I saw a load balancing presentation they did definitely talk about using hardware offload for that and since what Intel's doing but for the exact answer I need to look at it for you know ways and the other question is maybe more conceptual is the ESG up to being a border firewall okay your nsx se will never ever ever tell you to get rid of your perimeter firewall period if they do you need a new one that's not to say that the edge services firewall is not fantastic but at this current point in time with the wait data centers architected we will never tell you to get rid of your perimeter firewall now that's not to say that you won't have your perimeter firewall out there peered directly down to an ESG and maybe someday in the future that may change but as of right now really when it comes to your actual data center leave the iron in place let it do what it does best and just you know throw the ESP downstream from that I wish I could tell you otherwise but right now we just we can't do it not to say that it couldn't handle the job it's just the recommendation right now cool thank you so yes she high availability heart beating synchronization these things have helps you connectivity using the same port group they do heartbeat to each other anti affinity rules they're automatically done for edge services gateways when it's a set dial or set to high availability is unless the controller cluster where you do have to manually same type entity that's automatically done to the issues I believe there that's going to change at some point so if we look we have the active standby model there is a failover timer 15 seconds you can tune these timers down and as soon as there's a dead timer that flips over so with modes of configuration you have advanced and manual and you can kind of let it do its own thing or you can actually go in and set PHA stuff up yourself and here's some of the failover behaviors if you want to take a screenshot by all means or I can you know send the deck out again if need be it just kind of talks about what happens in failure scenarios with a stateful firewall it's going to synchronize the connections over and then fail and it says failover to standby in 15 seconds but of course that can be configured down to 6 so do we have any more connection or questions on this one at this point you I'm not seeing anything on Twitter all right so let's go ahead and move on to the distributed firewall I'm a little behind but I'll make it work so a firewall placement and evolution this is what we literally just talked about you've got the standard architecture where you've got the firewall at the edge of the at the edge of the network that comes down and that kind of handles firewalling for everything north south or east to west although in this traditional model we found that most customers just our firewall east-west or they're setting up VLAN sprawl everywhere and they're basically traversing everything from B and Avilan through a firewall and this is hair pending a lot of traffic and it's really pushing those physical firewalls up where you're needing 20 40 60 and 100 gig interfaces and if you've ever priced out 100 gig firewall or a 40 gig firewall even it's it's expensive so then we kind of evolved into yesterday's cool include virtual infrastructure and we kind of put a firewall inside of each VM that's like the windows firewall and IP tables and Linux and all that and I mean if if a box is compromised in any way what's the first thing the person is going to do they're going to go in and either service iptables stop they're going to kill it or even worse they're going to go in and they're going to inject rules so that they can traverse around the network without you knowing that the firewalls can shut off this is all well and good it's hard to manage at scale so we've kind of evolved now with nsx and to having our distributed firewall where that firewall is implemented the hypervisor level and it's distributed across all the hosts so if we kind of look here at the overview for DFW they say no choke point really due to the fact that we're kind of spreading all the services out we're firewalling just about everything in your environment you're not really having to hairpin all that traffic over through and you're not taking 39 gigs worth of traffic and shoving it through a 40-day interface or voting one gig traffic through a 40 gig interface you're really kind of spreading that load out we're also moving enforcement as close to the workload as possible without bringing it in band of the VM that's a really important distinction with that so bringing it to the v-neck level it is as close to the workload as it can possibly be without being inside of the hosts where it can be shut off if it's compromised so that's that's one thing that we really pride ourselves on is keeping the firewall still out-of-band of the VM but still is close to the workloads we can possibly get it it is scale out now technically if you want to split hairs you have 110 gig card in there and you put another 10 gig card in there you just scaled up but really for the most part were scale out so if you've got all this traffic in your environment and you need more firewalling most likely you're going to need more compute as well so you throw another host in there and you've got another you know up to 20 gigs towards firewalling now it says line rate performance 15 plus gigs that's actually changed since then you will get 15 plus gigs but on our last performance testing if you've got 20 gigs in your host you're going to get like 19 and a half or more gigs of throughput on that especially if you've got things like receive side scaling and larger sees a larger C to offload and stuff like that configured as well as the excellent offload on the next you'll get a lot more performance out of them so the distributed firewall provides security filtering functions on every host that we're turning every single of your hosts into the firewall doing layer 2 through layer 4 and again this is stateful firewall so we're also offering centralized configurations and we're doing that through our distributed firewall configuration and that not only industrious ribbet if I want but it also does edge far along from there as well if you're using a partner like Palo Alto at this point in time I believe it's just Palo Alto that's allowing you to do it but you can actually use Palo Alto spanner AMA to configure distributed firewall before when you need it to redirect traffic into Palo Alto you are having to manually create the rule in DFW for that redirection now when you create a rule in Palo Alto it will push down the redirection into DFW so if you've already using interim in your environment now you can do all of this cool new distributed firewalling and kernel still through panoramas that's not important well I guess it is vm name and attribute and stuff like that really we're able to pull all this crazy context from the distributed firewall since we are connected to V Center so we can pull all kinds of things the VM name what OS is running and all this so your building policy not just on 50,000 lines five two black piece game you're building it on what your business looks like this group to this group or this VM to this VM or even this person can access these specific resources now distributed firewall can enforce security no matter what whether it's on VLAN VX LAN or even on the same layer two segments now if you're familiar with networking firewalling on layer two is impossible unless you're using something like pv LANs or something like that if it's on the same broadcast domain it's really you can't really jump in there with the distributed firewall since we're doing it at the v-neck even if it's on the same the VLAN we can absolutely do a policy enforcement now if we look here we are enforcing at the v-neck and that's whether it's encapsulating with the X LAN or not make its check before and after and I'll go here I thought my little thing was next my visualization hello so let's look at the components here real quick vCenter server talks to nsx manager as we talked about before this is one-to-one pairing you're never going to have one too many arm anyone at this point it's just you got one to one your nsx manager then talks directly down to your ESXi hosts for DFW that's even if you have virtual networking or using the controllers in that scenario your nsx manager is talking to controllers for virtual networking in distributed firewall no matter what is talking directly through to the ESXi host front portion there it is so here's my little visualization of a packet it says vs fw and it's above the V switch I actually like the way that this is built so we're using a technology that's built into your ESXi hosts called the DV filter groups or DV filter slots now what this is if you can think of your virtual machine as a physical server and your distributed switch is a physical switch you've got that little Ethernet cable that's connecting the two on that cable there's 16 little slots the first four they're reserved for ESXi the last four those are also reserved for ESXi those eight in middle those are the sweet spot that we can start to connect into when you connect the ESXi host and you prep it for nsx and you give it the distributed firewall module distributed firewall locks into slot number five every single time data traverses out of that VM it clicks through every single one of those little slots when it goes through the first four it's all fine and good it gets checked then it gets to number five and it checks do I have a distributed firewall rule that says that this traffic canna cannot go yes or no if it gets yes it gets passed on now if you're using a partner like Palo Alto or checkpoint it's going to register into that next slot so it goes hey I pass the distributed firewall but I know that I have to get checked by Palo Alto that's when it clicks into the next slot and it gets checked over into the Palo Alto service p.m. once it gets done with that if it passes it gets put right back on the chain and set through so if we look at the visualization here that packets actually be checked four times going from source to destination to wipe em away they're twice on the way back so depending on how your pipe topology set up it could get dropped on one way but not the other or on the way back but not the way out that all depends on how you design your policy the same thing happens whether it's going over to a different host it's going to get checked that same four times two on the way there and then two on the way back but if there should go faster ere we go okay does that add much latency or any sort of notif engine is not so this is one really cool thing when we talked about performance last week in the week before your distributes which is already busting that back over I mean it's already happening so it's making that layer two decision with NSX we're saying while you have it already busted open check for layer three and now check against this firewall table so in the grand scheme of things we're not adding a lot of overhead for what it's already doing our scale numbers last time they came out was roughly one to four or one to five percent of one core of the CPU and maybe four to six gigs of RAM if you have received size scaling turned on which opens up more cores for network processing you're talking one to five percent of force CPU of course in green scheme of things with really loaded ESXi hosts you're talking maybe one percent of the compute infrastructure is overhead for nsx well yeah we actually do have some questions that came in to from that thank you goal franceour and do it that was my question we have question can we manage nsx using the html5 clients absolutely not and I wish I could tell you otherwise I really do they are working on the html5 module but at this time SRM and NSX specifically are still using the web client you can definitely see that changing in the future but as a 6-3 that just came out it is still in the web client and I'm sorry for that and another question is can it be ad on integrated kind of through our back that sort of thing yes so we absolutely do our back so we can say not only only security people can come in and make firewall policy or only Network people can do Network things we can also do identity based firewalling the big use case for that is VDI where we can say when a finance person logs into their finance VDI they get a specific finance policy if that user logs out in a domain admin logs in they immediately get everywhere and we can do that with Active Directory Integration in the Active Directory Integration stretch into creating rules for the firewall yes yes we can build policy based on Active Directory groups and users and again the big use case for that we've seen is VDI that's amazing so policy rule objects we can create objects based on layer 3 and layer 4 stuff we can do even layer 2 rules doing things like our Penelope blocks our rules are processed top-down through the Ethernet tab and then the general tab so it's going to do all of your layer 2 rules first from the top down and all your layer 3 rules and four rules from the top down I was asked before this even started about how to design policy since it is top-down and creating groups and everything your blanket policy will be at the bottom so if you are a zero trust model it'll be denial at the bottom and then up above that in order of how they would be hit you would have your rules white listing that traffic otherwise you would have a bunch of denies where they allow all at the bottom but really we'd like to try to help you get to zero trust as easily as possible this is kind of a look at our centralized management screen you can kind of see that it is you know source destination service and action just like any other firewall but you're not seeing a bunch of IPs everywhere this first source does have some IP sets which we can use but then if you look and you see like engineering traffic DC containers so we're looking at clusters and all that if you look at the engineering group it'll actually show you which specific things are in there if it would ever get to one of those okay either way what will that click yes sir I do have a question from Josh Andrews of course you do how is a be pool one more time how is it polled how is it pooled so when you go in and you go through the configuration and you connect it to Active Directory it goes through and start scraping those groups when you start to create firewall policy based on Active Directory groups it'll actually go through and connect out to ad and pull in groups that are available to you and you can search through them and ad groups so you don't have to do any separate configuration from what be Center does yes yeah you have to add it as a data source basically inside the VNS ex-manager config got it okay do you have to set it up separately and it is a separate configuration for IPFW than it is for the are back stuff the are back configuration is one thing and then identity-based firewalling is another and with this count as a solution in the PSC one more time because I remember that the PSC s had a had a definite number of solutions that they supported especially if you did an embedded PSC uh so I'm since you said that it s I believe I believe in FX does show up as a solution therefore that awesome thank you so sections um these are one way that we can use to kind of group rules together it is still top-down but you can set up groups so we've seen this a lot where companies will do like rules for application a rules for application B and they'll be kind of into a set of rules this sections do not impact overall security policy it is still from the top down on the rule set if you do have mass rules where basically one rule will not be able to be hit because there's a rule above it that keeps getting hit a tool like V realized network insight will show you this and that's kind of how you can fix your policy or build your policy a little bit better definitely go back and look at the V brown bag that was recorded the week before I started it with Sean O'Dell doing do you realize network insight if you have questions on designing security policy for NSX or anything like that that's the tool that we use to design security policy that tool does everything you could want to do in terms of planning for micro segmentation so policy rule object filled this is just kind of looks like a what we can build policy off of ipv4 v6 addresses that standard the data center so you can have it say rules for any VM that's in this specific virtual data center or rules for any VM that's in the specific cluster and you can go all the way down to setting a rule for a specific DMV NIC so if you have a VM that has multiple Phoenix you can set security policy for the different remix in that VM the biggest thing we've seen is security groups based on virtual machine name or even the OS that it runs services so we've got a ton of different preset services that are in there but you can also set your own NSX distribute if R also does a LG or application-layer gateway the big thing for this would be Active Directory so active directory uses about 20,000 ephemeral ports and really high range if you're trying to firewall this then you're either having to go through and open up all of these different little pinholes and leave them all open or you can go through and say well I only have a hundred users so I'm going to change the registry in Active Directory to have it only use a hundred of those ports that's all well and good but we can actually go through and say great we know that's an Active Directory server we know it uses 20,000 ephemeral ports so we'll go ahead and allow those ports on a socket by socket basis and then let those through and then close the port when it's done so that's a really really cool thing that we can do here with our firewall now action we have block allow log do not log this is a little out of date because we also have redirect and copy now and you can either log or do not log with that or allow and block with that and what that is if you're using something like a Palo Alto then you'll redirect in to Palo Alto if you're using another third-party solution like gigamon then you can copy and you can either block or allow and copy and log so there's lots of different actions that we can do here now the apply to feel is extremely important in terms of designing security policy so the apply to field says where the rule is set a lot of times we see it done to like a logical switch but you can also apply a rule to a virtual machine so if you have a rule set up that says this VM can't talk to this VM but you have the apply to field set to say a third VM that's not involved that rule will not be enforced because it's not applied to the VM in question in anyway so that's just another field that comes in when you're actually designing the distributed firewall policy here's just an example of a logical switch rule now I'm running a little behind so I'm going to kind of skip through the example here security groups these can be static or dynamic this is by far one of the most important things when designing security policy for NSX you can have a static policy saying well these five VMs are part of this thing so I want them in there or you can do a dynamic policy and say well any any VM with an OS of Server 2003 it's in my quarantine policy or any VM has web - in the name it's the web policy you can also use things like security tags so if you're deploying using a cloud management platform like VRA you can deploy it out and say any VM in this stack it's the security tag as soon as that VM object is instantiated before the VM even turns on it automatically has its security policy based on security tag or the security group it since now you can also set up security groups with regular expressions and we can also do static inclusions and exclusions so you can say I want all of my Windows servers to get the Windows policy except my templates I need those to have no policy none that's one use case that we've seen use for that little example we applied to it bolon if you guys want to take a look at these examples just let me know and I can send that out we have any other questions pending if now I'm going to move into the design piece for the last few minutes here yes sir a'right design basics so we're going to kind of putting it all together we're going to go over a few of the things that we did before and just kind of round out the last bit here so we talked about a lot of things over the past few weeks lots of different components like the virtual switch the nsx manager the VIPs distributive bar wall and load balancer and all that knowing how they kind of come together is super important the biggest use case that we have maybe 60 percent or so or more of our customers that buy into NSX is security micro segmentation and that's due to the fact that it's the easiest to implement so a lot of customers see the benefit in having the full you know shebang with network virtualization the X LAN and all that cool stuff but staging your design and implementation saying well we'll just go ahead and deploy it out we'll use micro segmentation we can use VR ni to set everything up and it'll be great then eventually for phase 2 we'll set up the network virtualization and will migrate things into VX plans that's the biggest use case and phased approach that we've seen at this point the second East case is automation customers that are looking to kind of speed up you'll hear the term DevOps a lot I'm doing air quotes and you can't really see that right now um but if you're looking at spinning up virtual machines faster using a little web portal so your developers can click a button at the ends and stuff why would you not use the networking and security piece of that as well because we've got customers that are on this full push to deploy VRA but they're like no we don't want to do NSX right now so they want to go out and deploy a bunch of VMs real quick but they still have to cut be lanced and signing the IPS out they still have to wait a week for security policy really what's the point in doing all this VM automation if you're not going to round out the entire stack and deploy the whole thing at once you still have to wait three weeks for security does it's not really that much faster so we see a lot of customers that are are implementing NSX as well whether it be VRA or OpenStack or even just scripting that way you're deploying everything at once so this is a typical architecture and this is one thing if you've ever looked at the hands-on labs maybe you've taken the VCI xnv exam before this is a really really common architecture where you got logical switches you've got a distributed logical router you've got a transit logical switch you've got an nsx edge and you've got it routing peered from the DLR the ESG and upstream this is really kind of showing you everything we've got in terms of network virtualization all in one really basic looking architecture so designing aspects if any of you are VC DX's are looking to do VC DX or you don't know what VC DX is but you know you like to hurt yourself definitely start the process I recommend it but you'll realize that you've been working in tech for a long time so you know all these tiny little nerd knobs all of those nerd knobs become design decisions and you have to be able to tell somebody why you made that decision and when it comes to developing business cases and making a true design that supports a business it's all well and good if you want to tell them well we went with an all flash of ECM because we thought it was cool well they're going to ask you why you had to spend the money on that how did that help the business just saying well it's cool and it's fast doesn't really do that so when it comes to designing NSX you really need to think of what are my business drivers how do I take all of these features and all these cool new stuff and map it back to my business requirement now if they have a business requirement of be badass than done every single design decision you make will fit business requirements you're one of being badass so looking at physical fabric options with nsx I said it before and I'll say it again we're always going to say we don't care we kind of care really the most part we don't care what brand it is we don't care what apology it is if you have a stable fabric that meets a few basic requirements of can you ping from here to here yes do you have an MTU that works yes all right let's do this so we see we spine a lot these days a lot of customers want to go that route they're looking to go that route that is a favorite but you don't need it you can be two-tier three-tier really whatever keeping your physical fabric in mind when deploying nsx is extremely important because you need to know do I have the MTU to go where I need to go do I have the round-trip time from my two sites within 150 milliseconds which is what we need for the excellent all those things get compiled into your design decision list so looking at the cluster design I talked about this just a little bit ago today we're kind of adding in that third cluster for your standard vSphere design so vSphere it best practices is a compute cluster and a management cluster separating those workloads out so that your management doesn't run over your compute a big driver for this is generally you're not going to need to size your management cluster hosts as large as you would for your compute clusters now with nsx we're adding in that last cluster of the edge cluster so that you can have that north-south traffic traversing just through one cluster and everything else internally is going to be east-west now what this looks like in terms of this design is now instead of doing what most Network admins do and trunking everything down to every single ESX host and letting the VDS do the VLAN tagging now your only trunking your management and you're the excellent transport to your compute and your management all of your north-south VLANs are being trunk down just to your edge cluster so design decisions for multi BTech IO Josh some info on performance with multi beat F and all that kind of crazy stuff I haven't forgot about you I'll get it but there are just some decisions for going multi V tab generally if you're doing some like crazy crazy high throughput stuff or you need true there is no single point of failure anywhere you would go multi beat f most of our customers are single DTaP but there are some kind of TV and failover modes where you cannot build multi Veta and that's LACP route based on IP hash explicit failover and physical NIC load you cannot use any of those team policies for multi beat em due to the fact of how we're handling connections for V tab if you do want to use any of those then you can do single nsx v10 now if you do want to do multi btf you can use originating port and source source mac cache those are extremely popular so there's a giant transportation company here in my area that's doing multi beat em for their deployment and they're going to be using source mac cash for their teaming available load transport zones we talked about this a little bit I believe it was the first week transport zones are one of those things where even for our largest customers with crazy designs just do one transport zone the only use case I've ever seen where they've used two of them is going to be if they have VDI and server mixed into the same workload which isn't against best practices or is against best practices it is so it's one of those things where generally just stretch transport zone as far as you want your logical switching and routing to traverse just have one just have one Global transport zone so this is just kind of a visualization here we've got our our cluster here we've got the Vitesse we've got our compute VDS and on H VDS and we've got that VX land transport zone that spans all of those clusters replication modes we talked about this when we are talking switching multicast mode if you don't have multicast configured that's igmp snooping and stuff like that on your switches and pin multicast routing on your routers don't use multicast just use unicast that's what it's there for 99% of our customers are using unicast mode if you do have multicast available to you then you can definitely look at the multicast modes whether it be hybrid one multicast if you want to know more about those then definitely go back to last week's switching and routing talk and we did talk about that for a while I should have hidden this slide we already went over this in the routing sorry high availability so when you're designing high availability for your edge services gateways the biggest question that you're going to have is how much throughput do I need if you've got more than 10 Giga non-stop traffic you should make a design decision to go ecmp if you've got less than that then you can definitely go active standby now there is a little bit of downtime for that failover depending on how you have your timers tuned if you don't want to have that you can definitely go ecmp so that you can have an entire edge go down and there's no failover time it's just automatically rerouting through the other edge services gateway so with an active standby model I've talked about this several times again design decisions if you need stateful services at the edge then you have to go with active stand by and not ecmp I know that they are working on changing that so that you can do some of that but the fact that you're doing asynchronous wrapping through an ecmp model kind of ruins the statefulness of your edge so if you need stateful services at the edge then definitely go with an active standby model and that 10 gigs if you have say a design decision where you've gone active standby because of the stateful services but you need more than 10 as a requirement then you can definitely deploy multiple pairs and set them up as kind of tenants to the inside and you can route through the two but you can have two separate edges that are doing that then that gives you the aggregate 20x throughput with the stateful services sizing we talked about kind of why you would want to size up to the different sizes again make sure that you choose wisely because you cannot scale down you can scale up if you're going to be doing any form of load balancing go extra-large you won't regret it that's really where all the performance and stuff starts to take a hit is if you're doing large and quad large with some really really high performance load balancing so distributed firewall design considerations using the apply to field limits the scope of the policy now we say that your distributed firewall only publishes the rules to the VMs that are on that host at that time now that is true but if you scope the policy down it kind of cuts down on some of those rules that may be around that don't need to be so in terms of performance if you're trying to get the most performance out tune that applied to field as low as you can go so say if you're doing a policy that involves any VMS on a logical switch apply that policy just to that logical switch or even just that couple of hosts that that vm might be on at any time definitely designing distributed firewall policy is important be realized network insight can help you do that or of course our PS resources or even a partner PS resource can help you do that you can absolutely take the awesome features and performance of our distributed firewall and screw it up by taking the policy that you have in your existing fire all today and simply dumping it over into DFW you're not taking advantage of the security groups and naming conventions you're not at that point in time taking advantage of a lot of the grouping and scoping that we can do with distributed firewall in terms of designing for performance Tim does yes sir that's something from that previous slide it said that now behavior would change in 6.2 but I think we're already in what six about 2.4 we are in 6.3 right now so again I apologize I didn't go and update some of the information here it hasn't been updated just yet since 6 3 just released here recently but yeah that's what that little check mark I need all right thank you hmm and we're here at 8:30 I have just a few more slides you want me to keep going do you want to give people the chance to drop off keep going man all right shouldn't be too much longer here my apologies for running over so the DFW apply to field we talked about how important this is this is just kind of a mock-up that we showed earlier our back this is another one of the very biggest things that you can do if you've got vendors that are walking in saying the antler is going to take away your networking and security and give it to the vmware guys again ask your vmware guy if he knows how to troubleshoot bgp ask them if they know a zero trust security is and tell them they can't google it we can absolutely design an nsx where your networking guys can touch networking things and that's it your security guys can touch security and that's it you can have it law where your VMware admin logs in and they don't even see that in effect oh it all depends on how you want to design your security you absolutely have to have SSO on your vCenter server if you're using vSphere 5 5 u-3 and all that which is our requirement for NSX you've already got either a multi-site or PSCs and stuff like that especially at six oh you've got PSCs and you've got an SSO domain that's one of the ways that we use for our Beck NTP your NTP design is crucial and I say that for any vmware product nsx is highly distributed so this time has to be in sync so if you don't know what ntp is or you're not super familiar with it i urge you to go and look at it and be familiar with it if you're using any form of highly distributed systems ntp is important if you start going out and deploying all of this stuff with ntp out of sync you're going to run into errors although most likely in your vSphere & v center environment you're already running into problems you just might not know it and also DNS DNS crucial forward and backward DNS for everything that way make sure you have all the stuff set up like for nsx manager before you deploy so here's some of the rules and scopes that we have for our back Enterprise administrator nsx administrator security administrator and of course auditor if you have a qsa for PCI giving the auditor role they can go and look at whatever they want without touching the scope is the really cool part so if you have a multi-tiered service provider type deployment you can give somebody enterprise administrator access only to their specific edge services gateway they can't get to anybody else's ESG so if you're doing a service provider type thing you can give that customer full access to their edge they can't go to your provider edge or to another customer's edge or if it's you you can give yourself enterprise administrator with no scope or no restriction so that you can get everywhere we kind of give you that power to design your security the way that usually fit if you need to push your security to 11 we have partner integration with high trust which will take and turn every single little nerd knob at your environment into a checkbox where you can say well this person can log into absolutely everything but they can't touch that one little obscure button they do that by basically putting a proxy in front of your vCenter server so that all of your traffic and login ins and everything gets sent through that and it's also really good for audit logging so you can go through and say so-and-so logged in this exact second and touch that exact button and then logged out if you're in government environments or something where regulation is heavy that might be something that you look into and that's it we are done with the NSX series thanks for pointing along then we actually want you to keep going but your head like a lab that's okay I do have a couple of laps I do have a couple questions Mitchell asked us how well does NSX work or integrate with vSphere integrated containers okay so containers are a big thing I'm not so keen on the containers at this point in time we absolutely have stuff the tin works for NSX with containers in the coming months and years you can see that to get a lot better at this current point in time you're pretty much just like building distributed firewall policy based on the VM itself not the actual containers but that's going to start changing and be on the lookout for that I can't I can't really dive super super super far into the container thing right now okay and the other question NDA kind can role based access control use two-factor authentication or is that client OS dependent what would happen if someone asks you at a point in time are our back it just is real basic when the user logs in they get what you see we don't control how the login works other than basically like connecting to LDAP or Active Directory just like you do in vCenter server if you need something like that I believe high trust has an integration with 2fa where you can complete that kind of two-factor authentication we don't do the authentication part we just say that once they get logged in this user account can do XYZ ok it may be that since these fear 6.5 supports our essay as well it may be an eye that will be anyway s so we hand we use the same SSO domain login stuff that VCR uses so if vSphere 65 supports RSA for two-factor then you can use that same two-factor login and then once you get logged into the web client would use any other role based access control to select what they can and cannot see and do in NSX because all we are with NSX we're not a separate product that you log into we're just a new tab in your vCenter server the click on and go into to configure so as far as logging into V Center that's whatever the standard login process is policy and they do have one question you mentioned vc bx r uo v c bx I am NOT a VC DX I whole are you work you going to see a three BCPs to Lully caps and a VC IX and I am writing vc DX as we speak very good it is such a brutal process and it's taken me so much longer than I wanted it to be anybody that tells you that there is a way to balance work home and VC DX is a liar they're an absolute liar because there is no balance one of them suffers period so I highly recommend if you are not one that you should look into what the process is there's a new group that just got done this past week we currently have I think it's 257 of them which in the grand scheme of things is not a lot of people but hopefully that number explodes over the next few years we look forward for you showing those your VC DX design decisions in the future in the future we Brown Bag I hope so man hope so uh we got one final question from Nick stone chip keep asking if the permissions are set as a V Center level for NSX is it in the same familiar interface or to actually do it in a different way so there's actually two different places for that when it comes down to actually seeing an FX in vCenter server you use the standard vCenter rolls location when it comes down to actual are back within nsx that's going to be within the nsx client or within the the nsx tab and configuration so there is two different places the standard v center is just where you can see that tab so if you log in and you can't see the nsx tab you have to go to the normal SSO administrators to give that role once you get in there you can actually say all up a little are back stuff for firewall and networking and all that nemeceks awesome Tim I I just can't thank you enough for committing yourself to doing three weeks of MS x4v brown-bag it has been a pleasure it was awesome man and I remember when fraps asked me about doing that or you did or somebody did like six to eight months ago they're like God it's not going to be until May and I'm like oh cool that's future means problem and then here it is and here we've been it's been awesome I think it went really well and I appreciate everybody for checking it out it's been great Tim we really appreciate it the great service you're doing to the community one last question is if people want to learn more how can they learn even more about NSX that's fantastic Google search it there is so much out there for NSX right now Jason Nash has a dated but still fantastic rural site series we've got some free NSX modules on the the VMware Education site my learned up VMware com if you want to actually get in there and get your hands dirty with it you can go through two laps hol vmware.com log in and start using NSX immediately if you've got a home lab and you want to deploy NSX you can now subscribe to V mug advantage for $200 and getting access to NSX enterprise licensing this is a new thing it's really big it's really awesome we also have NSX ICM courses if you want to go through and deploy NSX and learn how to do that to get start to get certified we have Optima I can scale classes like that like the GCP one for datacenter virtualization we have stuff like that for NSX we have a troubleshooting workshop - that's new that's a to be pretty awesome reach out to your core count teams if you want to talk about your company in NSX your company most likely has a vmware rep assigned to it and most likely in your area you have an nsx SE just like me that's assigned to your account if you need help finding out who your nsx account team is you can always see me on twitter and i can help you find that out you could also go and get the vc PNV book for learning NSX there's so many different things Oh YouTube the VMware YouTube we do these things called whiteboard videos which if you're not familiar with it are really really cool where you see people in black shirts like drawing on the screen there is a whole series on NSX and security for those whiteboard videos that are really cool in a really great place to start and so many different ways if you need more ways feel free to reach out we also the janitors tell us don't forget the official training there's actually a class coming up in Chicago in four weeks that is 50% off yes he actually has done posted that on the VMware reddit page we are doing a I think it's a beta of the new NSX 6.3 class in Chicago 50% off if you've got a training budget and you don't want to blow all of it in one time that class is going to be awesome it's going to be really really cool so definitely check that out as well you can find that from my learn VMware comm awesome great sounds like that tons of places to learn about it then absolutely I guess there's no other questions all we can say is thank you what was that area No thank you so much absolutely thanks for letting me run over a little bit guys appreciate it any time you

Channel: vBrownBag

Views: 12,632

Keywords: vbrownbag.com, vbrownbag, nsx ninja, virtual network, enterprise network education, edge services gateway, sdn, vbrownbag Enterprise IT Education, virtual machine, training, distributed firewall, edge, dfw, technology education, #vBrownBag, vmware nsx, vsphere, vexpert, nsx esg, nsx, virtual networking, nsx 101, software defined networking, cloud storage, nsx design, vmware

Id: IR5s61uC-vY

Length: 70min 15sec (4215 seconds)

Published: Mon Jun 12 2017