It’s been over 6 months since I last had NSX working in my home lab, and with a rebuild I decided it was time to wrap up Part 2 of my NSX in a home lab blog post.

In Part 1 of my Deploying NSX series, we covered the prep of NSX in the environment, including deploying the NSX Manager appliance, deploying NSX Controllers and vSphere host preparation. In this part of the series, we’ll cover the creation of Logical Switches and our NSX Edge, which consist of our Edge Services Gateway (Providing DHCP, Firewall, VPN, NAT, Routing and Load Balancing capabilities). Part 3 will cover the deployment of the Logical Router, which provides our routing and bridging for the existing networks, as well as configuring routing to get traffic into and out of our new NSX environment.

So let’s dive right in…

Creating a Logical Switch

The logical switch in NSX is no more than a Distributed Port Group created on a Dv Switch. The Logical Switch in NSX is no different than our Physical Layer 2 VLANs, as they determine the border of our broadcast domain.

If you were to create 2 Logical Switches called Switch-1 and Switch-2, VM’s that are associated to Switch-1 could communicate with each other, even if on different hosts and different clusters. This is where VXLAN comes in. When you create a Logical Switch, a VNI tag is associated to that switch, and traffic will be carried via the hosts VTEP to other hosts, with zero changes needed on the physical network. Now will VM’s on Switch-1 be able to communicate with VM’s on Switch-2 at this point, not yet. Just like our Layer 2 physical network, we need something to route between the layer 3 boundaries. The same goes for traffic trying to get into VM’s on Switch-1, no way to route that traffic!

Creating a logical switch is easy. Give it a name and the Transport Zone we defined earlier. The Replication Mode will default to whatever the transport zone is, so no need to modify this.

Once the new Logical Switch is created, we’ll see that a Segment ID is provided to the Logical Switch. If you remember in Part 1, we created a range of Segment ID’s that be utilized. The Segment ID is the VLAN ID for VXLAN.

I mentioned earlier that the Logical Switch is just an extension of the Dv Switch, creating a Port Group for each Logical Switch we create. We can see that by looking at the DvS in vCenter. Notice the naming of the Port Group has the Segment ID, as well as the Logical Switch name.

At this point in time, we could go and add VM’s we want to use this new Logical Switch as shown below, but that limits us to traffic between VMs.

So we can add as many Logical Switches as we need, but remember that doesn’t allow North/South traffic, or even East/West traffic between Logical Switches. We need to get Layer 3 functionality enabled, and this comes into play with the Logical Router and Edge Gateway.

NSX Traffic Engineering

East/West traffic is handled by the Logical Router, and technically you can use the Logical Router to do North/South routing as well, using static or dynamic routing to connect to the Physical Network. But in doing so, you lose some of the best features of NSX provided by the Edge Gateway, mainly the firewall, VPN and load balancing.

For purposes of this series, we will be deploying an Edge Gateway in front of our Logical Router. The Edge Gateway will have an uplink connected to a DvS Port Group mapped to a VLAN, which is a on a /30 Subnet (255.255.255.252). The Logical Router will have an uplink to the Edge Gateway.

While there are other ways to deploy this, using the Edge Gateway in front of our Logical Router will allow us to create firewall rules for traffic inbound to the Logical Router, as well as use the Edge Gateway to Load Balance traffic.

Deploying the Edge Gateway

Deploying the Edge Gateway is a simple guided walk thru. You can deploy the Edge appliances in HA mode or not, depending on the requirements. We’ll be deploying the Edge Gateway in HA mode for this series.

We’ll set the Name and Description, Appliance Settings, such as password, SSH and Rule Generation, and then the appliance size and location of appliance (cluster, datastore, folder, etc)

Interface Configuration requires some planning/thought. As I mentioned before, we’re connecting the Edge Gateway to the physical network via a DvS Port Group, on a /30 network. To do this, I added the VLAN (103) that I want to use for the uplink to the ESXi host trunk ports, and created a new Port Group tagged to VLAN 103.

An Edge interface is created for the Edge appliance with Type as Uplink, and connected to the NSX-Uplink Port Group that I created.

The next option is to set the default gateway, which will be 10.105.255.1 as our next hop.

The final option in deploying the Edge Appliance is our default firewall and ha options. By default, the Edge Gateway has a default firewall policy to deny all traffic. You can use the logging feature to see what traffic is coming/going to the firewall to define more granular rules. For this purpose, we’ll be changing the default policy to Accept and keep Logging disabled. Remember this is a VM, and keeping Logging enabled for too long might affect performance of the Edge Gateway.

Ensure that the management IP addresses do not overlap with the IPs used for any other interface and do not interfere with traffic routing. You should not use an IP that exists somewhere else on your network, even if that network is not directly attached to the NSX Edge.

We’ve now deployed our NSX Edge Gateway, and we can see it’s properties within the vSphere Web Client.

Notice all of the configuration features that the Edge Gateway provides us. We can validate connectivity to the Edge Gateway via SSH (you remembered to enable SSH, right?).

What’s next? Well we’re still not ready to move VM’s to the NSX Logical Switches just yet. While we’ve got our Edge Gateway setup and communicating on the physical network, we didn’t create any additional interfaces facing into the NSX environment, and we don’t have the Logical Router deployed yet. We could use the Edge Gateway to provide direct communication to our Logical Switches (a use case here would be for DMZ facing VM’s), but would you have your ASA routing all your internal subnets via multiple interfaces? Not typically, so in Part 3 we’ll deploy the Logical Router and tie that to our Edge Gateway, and get traffic flowing!

Thanks for reading, stay tuned for Part 3 of my NSX in a Home Lab series!