VMware VCA 1V0-701 – VCA-DBT – NSX

1. Intro to NSX

And NSX exists in order to virtualize key network functions. So what does that mean? NSX can be used to create logical switches, to create logical routers, to create firewalls, to set up edge routers that can do things like load balancing and network address translation and VPN. NSX also features integration with a great deal of third party solutions, making it an extremely powerful and extremely customizable solution for networking. It also features a Rest API for cloud management platforms so that we can automate and manage NSX using a Rest API. So let’s start our introduction to NSX by breaking down a simple network diagram. I like to use lots of pictures when it comes to NSX because it’s a networking tool. And when it comes to networks, diagrams are our best friend.

So here we see two virtual machines VM One and VM Two. These Virtual Machines are running on different physical ESXi hosts, but they’re on the same network. They’re on the ten one 10 network. So these Virtual Machines are going to be on the same layer two network. They’re going to be connected by a switch. Virtual Machine Three is on a different layer three network. It’s on the 170 216, ten dot zero network. So the only way that Virtual Machine Three can communicate with Virtual Machine One and Two is through a router five Virtual Machines on different networks, they need to use a router in order to communicate. And then down here at the bottom, we see the physical network. So each host is connected to a physical switch and then in between them, we have a physical router.

Well, this router would actually present some problems with a traditional Vsphere distributed switch or a VSAR standard switch. Actually, this network topology wouldn’t even be possible. I wouldn’t be able to allow VM One to connect to VM two over layer two because there is a layer three device in the middle. But NSX makes this possible through logical switches. These are NSX logical switches. So these are simply layer two switches that my Virtual Machines can connect to. And they make it possible to pass layer two traffic over a layer three physical network. That’s one of the major features of an NSX logical switch, that it can span a layer two or layer three physical architecture.

Here we see a distributed logical router. So both of these logical switches, they’re connected up to a router that runs right inside the ESXi host. And now if VM Three and VM One need to communicate, their traffic doesn’t have to leave the ESXi host to hit a physical router. Their traffic can be routed right inside the ESXi host. And that traffic between those two Virtual Machines never needs to hit a physical network. So our distributed logical router, a little router that runs inside every ESXi host, I’ve got a little firewall called the Distributed Firewall that is attached to the virtual nick of every Virtual Machine that makes features like micro segmentation possible. And then at the edge of my network, I’ve got the NSX edge providing me a northsouth router, providing me a firewall load balancer, VPN network address, translation, all sorts of good stuff like that. And the beauty of it is, this is no disruptive. I can put NSX as an overlay on top of my existing physical network using any supported ESXi host.

2. NSX Components

Starting with the NSX logical switch. So in our diagram here, and we’re going to use a lot of diagrams in this lesson, in our diagram here we see a physical network. We’ve got two ESXi hosts on the left, two Asxi hosts on the right. And in the middle we’ve got physical switches and a router interconnecting these ESXi hosts. And what I would like to do is, is create virtual machines on these ESXi hosts that reside on the same layer two network. However, given my physical topology, this is not possible. I’ve got a router in the middle. A layer two network cannot span a layer three physical router. So with a traditional Vs for distributed switch or Vs for standard switch, I cannot accomplish this network topology as shown. But if I deploy an NSX logical switch here we see an NSX logical switch. It’s identified by something called a VNI. That’s just a VXLAN network. Identifier simply identifies this particular logical switch and I create this logical switch. It actually has the ability to span a physical layer three network. It creates something on these physical ESXi hosts called a V Tap or VXLAN tunnel endpoint.

And you don’t really need to understand exactly what the VTAP is or exactly what a VNI is. The exam isn’t going to cover those sorts of topics. But what you do need to know is that what happens here is that there are these tunnels that get created over the physical network directly interconnecting all of these hosts. So if you’re a visual person like I am, think of it this way. All of these Vteps have a connection to all of these other Vteps. They’re aware of the other Vteps in the network and they can communicate with the other Vteps in the network. So if the VTAP on host one has some layer two traffic that needs to get to host four here on the far right, it can make that happen. It can take that traffic that’s coming over layer two. It can pump it over the appropriate little tunnel here that it is established and send it over to the appropriate V tap. Even though it’s a layer three physical network, it doesn’t matter. All these Vteps establish these tunnels between each other and therefore are able to pass layer two traffic regardless of the physical network topology. So now what does this give us from a functional perspective?

What are the capabilities that this creates for us? And the big thing is now I can create layer two networks completely in software without changing anything on my physical network. So if I decide I want to create a new network, I can simply create a new logical switch and I don’t have to configure anything at all in my physical network. So I am decoupling these network components from the physical network and decoupling is always the goal of virtualization. So this is virtualization for my networks. Now I can create network components independent of the underlying physical hardware. And that gives me a whole ton of flexibility. It also gives me the ability to automate the creation of network components. Next, we’re going to take a look at the distributed logical router. But before we do that, let’s take a moment to think about how we have traditionally routed traffic in a VSphere environment.

So here we have two virtual machines. These VMs are running on the exact same ESXi host. They have different IP addresses on different networks. And so VM One is on the 192 168 one network. VM Two is on the ten one dot one network. They’re on different networks and that’ll work just fine. But in order for those virtual machines to communicate with each other, their traffic needs to be routed. A router is what interconnects these different networks. So for VM One to communicate with VM Two, it is going to generate a packet. It is going to send that packet to its default gateway, which is this physical router. And so the packet needs to flow through the physical adapter of the host through a physical switch, hit a physical router, get routed back to the same physical switch back to the same ESXi host, and eventually reach its destination.

And these two VMs are running on the exact same host. So you can see how that traffic pattern isn’t really optimal. Ideally that traffic would never have to leave the ESXi host. That’s where the Distributed Logical router comes in. The DLR does is it’s a little router kernel module that’s installed right into ESXi. It sits right on your ESXi host as a hypervisor kernel module. And if you ever hear that term, it just simply means this is baked right into ESXi. And so now when VM One needs to communicate with VM two and that traffic needs to hit a router, there’s a router local to that ESXi host. And so the traffic never needs to traverse the physical network in order to be routed. And that’s the beauty of a DLR. So number one, it’s going to give you a more optimal traffic flow because traffic isn’t going to unnecessarily hit the physical network. That’s what we call hairpinning. And I’m not sure this will come up on the exam, but when we talk about packets being unnecessarily sent to the physical network and hitting devices that they don’t really need to hit, that’s hair pinning, the DLR eliminates that hairpinning by performing the routing right within the hypervisor.

So that’s one of the big features of the distributed logical router. But the other big benefit is, again, it is a software defined component that can be created or destroyed on demand without any changes to the physical network. Next we have the distributed firewall. And this is one of the most popular reasons for implementing NSX. This gives us the ability to do micro segmentation. So in this diagram, I’ve got VM One and VM two and they are on the exact same ESX I host and take a look at their IP addresses. They’re on the same network, they’re connected to the same virtual switch.

So in the past, how would I possibly implement a firewall policy to control traffic between these two VMs? I would have to have something inside of the operating system, maybe I’d use the Windows Firewall or something like that or some third party solution. The only other way that I could implement a firewall policy on two virtual machines like this is I could take them, put them on different networks and force their traffic to flow out to the physical network, hit a physical firewall, implement my security policies there. But these VMs would have to be on different networks, I would put them on different VLANs, I would put them on different IP networks to make that happen.

So what we ended up with is a whole bunch of subnets, a whole bunch of VLANs, a whole bunch of complexity in our network just in order to force certain traffic through firewalls and I still couldn’t do it with every single virtual machine it’s infeasible. I can’t apply security policies to every VM unless I’m using some guest operating system based tool like Windows Firewall. The distributed firewall overcomes this challenge. I want you to think of the distributed firewall as essentially I’ve got a little firewall here, I’ve got another little firewall instance here. This is run as a service in our ESXi host called the Vsfwd and what that means is I can have a specific policy for this virtual machine. Maybe this virtual machine is a database virtual machine so I can have a set of rules for incoming and outgoing traffic for this VM.

I can have a set of rules for maybe this is my application server for incoming and outgoing traffic for this virtual machine and even though they’re on the same logical switch, that firewall policy is applied before their traffic even hits the logical switch before the traffic. So the next step would be to hit their logical switch so those firewall rule sets are applied before the traffic is even switched. It’s like every single virtual machine has a firewall bolted onto its network interface and this is what allows me to perform what we call micro segmentation where I can apply traffic rules anywhere in my network. And this is a huge win for things like compliance.

This gives me a whole host of capabilities for internal security and it also significantly cuts down on complexity because I don’t have to have a whole bunch of lean’s and subnets in order to execute my security posture. NSX Manager is our management plane component and we’re going to talk about it in just a moment. But I just like to point out here NSX Manager is the tool that is used to configure all of these firewall rules. NSX Manager talks to these hosts directly to get those rules configured. Next on our list we have our NSX Edge. And I know this is a relatively complicated looking network diagram here, but I do want to walk you through it because we’re going to do a review of everything that we’ve covered so far in this lesson. Kind of put the whole picture together. So here on the left I’ve got a virtual machine. It’s called VM one. And this is my virtual machine that wants to get some sort of traffic out to the network. So virtual machine One is connected to a logical switch and here you can see logical switch VNI 5002. It’s present on both of these hosts.

We’ve got a little VTPs creating these tunnels through the network. So it doesn’t matter that I have a physical layer three network under the surface. Logical switches can overlay and can extend a layer two network across a layer three physical network. So anyways, VM One wants to get some traffic out to the Internet. So it sends that traffic to its default gateway. And its default gateway is its router. And that’s right inside the Csxi host. It’s our distributed logical router. And the distributed logical router looks at the destination of that traffic and determines, hey, this traffic is actually bound for the Internet. So what the distributed logical router does is it does what any router does. It looks at its routing table and it says how do I get this traffic towards the Internet? And it determines that the next hop for that traffic is something called an NSX Edge. It’s another router. This is what we call our north south router. The edge is connecting my NSX domain to an external physical network.

That’s how Internet traffic gets in and out of my NSX domain, is the NSX edge. And the NSX edge is also kind of like the Swiss Army knife of the NSX environment. It does VPN, it does load balancing, it does network address translation, it provides a firewall, it’s a router, does a little bit of everything. So that’s the NSX edge. The NSX edge is a virtual appliance. It’s a virtual machine. It’s not a kernel module. It’s own independent virtual machine that runs on one of these ESXi hosts. So let’s follow this traffic one more time. As it goes through the network, VM One generates some kind of ping destined for an external physical network. It hits the logical switch. The logical switch sends it to the distributed logical router. That’s my default gateway, that’s my router. And so the packet then is transmitted over my physical underlay network to the NSX Edge. The NSX Edge looks at its routing table, determines that this traffic is bound for the Internet and away it goes.

So how do I manage all of this stuff? There’s a lot of components involved here. The list that we’ve looked at is actually a partial list. There’s other things that can be set up. So how do I manage all of this. Well, I’m going to use NSX manager. This is our management plane component and it integrates with Vcenter. Every NSX manager instance has a one to one relationship with a Vcenter server and so I can use the Vsphere web client or the HTML five Vsphere client to manage all of this. The NSX manager is my rest API server. So any API calls that are made to NSX are made against the NSX manager. And it’s used to create many of the components that we use with NSX, like our NSX edges. It’s used to deploy all of our NSX kernel modules like the distributed logical router and it’s also used to create the NSX controller cluster. And this is our control plane component.

So this is used to do things like manage our logical switches, manage the configuration of our routers and anytime we’re talking about the control plane it doesn’t pass any actual virtual machine traffic. So with NSX we’ve got three planes. We’ve got the management plane, the control plane and the data plane. The management plane is NSX manager and it is used exclusively to configure and manage the environment. The control plane is kind of like halfway between the management plane and the data plane. The control plane is not going to impact traffic if it fails, neither does the management plane. If either of those planes fail, if NSX manager fails, nothing goes down. I just lose my ability to manage. If the NSX controller cluster goes down, nothing breaks. All my traffic keeps on flowing. But with a control plane failure it will eventually impact traffic. It may slow things down. I don’t have any actual virtual machine traffic flowing through the control plane but it does perform some functions that are critical to the ongoing health of my network.

Whereas the data plane, this is where the VM traffic actually flows. If there’s a failure on the data plane that’s going to impact my virtual machine traffic. So the NSX controller is going to handle some functions internal to my logical switches, internal to my distributed logical routers. It is very important that we keep these up and running at all times. Therefore, they are deployed in clusters of three virtual appliances running on three different ESXi hosts. Now finally, I just want to take a look at a little bit of documentation here and mention a few things that you should bear in mind if you are preparing to take the VMware certified Associate Exam.

So what we’re looking at here is the VMware documentation for NSX and if you just go to Google and type in NSX Docs you’ll find this. This is the NSX for Vsphere documentation and I have specifically gone to the NSX Administration guide and under the NSX Administration guide there’s something that I want to encourage you to read prior to taking the exam. The NSX data center for Vsphere components. I want you to go and read on what is the data plane? What is the control plane?

What is the management plane? Those are three things I think are worth your time to read because what you’ll find is a lot of the exam questions are based very closely on this documentation. And these are three areas of the documentation that are definitely going to be covered on the exam. It would also be worthwhile to give a quick read to the NSX Edge and NSX Services areas as well, but I would say those are less critical.

3. NSX Use Cases

Now, before we get started, I just want to show you the VMware product page for NSX. And this is going to be the source of a lot of the content that you’re about to see here. You can find out about the different use cases for NSX data center. And if we scroll down, you can take a look at the different licensing editions that are available and some of the resources that are available including training and certification, white page papers, data sheets, and all sorts of other good information including hands on labs. And one of the primary driving factors that is encouraging adoption of NSX is security. So we have these traditional perimeter firewalls that normally sit at the boundary between our data center and the Internet. And for a long time these have been used as our primary security measure.

The problem is what happens when somebody inside the organization is creating the security issue? What happens with things like social engineering or when somebody plugs in a USB device that they should not be plugging in? How do we protect against those scenarios? We need to provide some sort of protection inside the network to prevent internal attacks from circumventing our security controls that exist at the border. And the answer to this problem is micro segmentation. Micro segmentation gives us the ability to apply security policies wherever we want and it’s built right into our ESXi hosts. So now I can do things like create firewall rules for individual virtual machines, even if they’re on the same switch, even if they’re on the same host.

I can implement security policies for every single individual virtual machine in my environment. And the management of this entire solution is integrated with Vsphere. And I can configure everything right in the Vsphere web client. I can even automate my security posture using service composer. So I can define things like security policies that say if I have a virtual machine with the name DB, I’m going to apply a certain set of rules to it. If I have a virtual machine with a certain operating system, with a certain name, with a certain tag, with all sorts of different criteria, I can dynamically enforce firewall rules, antivirus network introspection services, data loss prevention services. I can automate all of those security solutions on the fly based on the policies that I define.

So it greatly enhances security. Because the moment I create a new virtual machine, all of the appropriate security policies can be dynamically enforced on that virtual machine. And another major benefit is the portability. So virtual machines may move from host to host. They may be migrated from one V center instance to another. I can create rules with NSX that will follow those virtual machines wherever they go. That way my security posture does not change as those virtual machines are migrated. Another use case that’s possible with NSX is multicloud networking. So let’s say I have a physical data center and I want to run some virtual machines in the cloud.

I can extend my network into the cloud. I can have virtual machines with the same IP address scheme on premise, and I can move those virtual machines to the cloud without even changing their IP addresses. I can create networks that span multiple locations for disaster recovery purposes. So traditionally, if I have a Dr site, one of the more challenging aspects is I either need to stretch layer two to that disaster recovery site or I have to readdress every virtual machine if a disaster occurs.

And that’s a massive problem. The other problem is I have to change all of my DNS entries if a disaster has occurred. And I’m going to now start to create those virtual machines at my recovery site, and they’re all going to have new IP addresses. This is a major operational difficulty. With NSX, I can eliminate all of that. I can use something called cross venter NSX. I can have virtual machines that automatically boot up at my recovery site. And we don’t need to change the IP address. We don’t even need to change our routing tables.

So NSX, and specifically cross vcenter NSX provides a very simplified disaster recovery response in terms of networking. And again, I have the ability to migrate VMs to other data centers and to the cloud without necessarily having to change the IP address. So that’s another big benefit. I can take my VM. I can move it wherever I want. This enhances the portability of my virtual machines. A third use case for NSX is compliance. So based on the micro segmentation capabilities of NSX, I can create what we call a zero trust model inside the network. That basically means none of my virtual machines are trusted to talk to any of my other virtual machines unless I explicitly allow that traffic. If I create a new VM by default, it can’t talk to anything.

I’ll have to explicitly apply policies to that virtual machine in order to identify the types of traffic that I want to allow in and out of that VM. Now, I can do this automatically using security policies, but at the end of the day, the default posture for every VM is they are not trusted. And unless we specifically open up certain holes for their traffic, they will not be able to communicate with anything else. It also gives me full visibility across my infrastructure and all of my endpoints. It’s very easy for me to map out and visualize my network. And then I can build application centric policies with Service Composer. This is my automation piece.

If a virtual machine is running certain operating systems, if it falls within a certain naming convention, if the virtual machine is tagged with a certain tag, I can dynamically apply a set of rules to it. And this greatly helps with compliance because I could tag all of my virtual machines that are subject to some compliance regulation with a certain tag and then dynamically enforce security policies based on that tag. And finally, I have the ability to integrate third party solutions. So here I am at the VMware Solution Exchange website and this shows me all the third party solutions that I can potentially integrate with my VMware products. And I am specifically just looking at the products that can integrate with NSX for Vsphere. And here you can see many of those products. So if we take a deeper look here, we can see, hey, we’ve got checkpoint for security, I’ve got Cisco Firepower, I’ve got the Cisco Adaptive Security Appliance. And as we go through and look at a couple other screens worth of results, you can see there’s all sorts of security solutions.

Trend micro deep security, f five big IP bit Defender, the Palo Alto Next Generation Firewall. And on and on the list goes So there’s just a whole variety of third party solutions that I could potentially integrate with NSX to better improve my posture for compliance. The fourth use case that we’re going to look at is automation. So as we continue to develop more and more applications and we have a need to get things to market more quickly, manual processes can really slow down and hamper application development. But with NSX, our network components are software based, security functions are software based, and anything that’s software based can be automated. So if I need to create logical switches, if I need to apply a set of firewall rules, if I need to create a new distributed logical router, I can automate all of these functions to help improve the speed with which I can roll out new applications.

Not only that, but it ensures the appropriate networking and security posture for those applications. And then to take it to the next level, I can leverage Vrealize automation. So Vrealize automation can be used to create what we call Blueprints. Think about it this way. If I have a new application that I want to roll out, it may have a whole set of VMware components that that application depends on, on including NSX networking components. I can create a Blueprint in Vrealize automation to automate the creation of all of those components around my application whenever that application is requested.