Deploying NSX Edge - Architecture & UI Together

 


In this blog post I'm going to discuss the NSX edge. I'll keep the explanation restricted to edges of virtual machine form factor. However, bare metal edges are also possible. The use-case for bare metal edges are high packet throughput scenarios, such as at a telco / ISP. 

Architecturally, edges are the bridge between the physical network and NSX overlay network. Edges are a resource on which virtual routers and network services can be deployed. By services, I'm referring to things such as DHCP, NAT, stateful firewall, or most commonly, logical routing and switching and more. 

To prepare your infrastructure for edge deployment, consider the following:

  • Is our NSX edge cluster of a collapsed design (i.e. shared with compute cluster) or broken out into its own cluster as recommended by the NSX design guide?
  • What is the management network? (needed: subnet, gateway, vlan, and vCenter portgroup, mgmt ip and FQDN)
  • What network is connecting the TOR to the edge? (needed: subnet, vlan, portgroup, using routing protocol? BGP, OSPF or static route?)
  • What network has been designated to carry overlay traffic?  (needed: subnet, gateway, vlan, and vCenter portgroup)
  • How will we assign ip addresses to the TEP interfaces? (ip pool or DHCP?) 
  • What are the management login credentials?
  • What DNS server do you use? (create a-record for the edge mgmt interface)
  • What NTP server do you use?


Ideally, you'll want to break out NSX edges into a separate set of ESXi hosts in their own cluster. For my lab, I only have one cluster, so I have a collapsed cluster design. You'll need to know what design you've chosen so that when you create edges, you can fill out the following screen on the NSX edge wizard:


With that said, here is what an NSX design would look like if using separate compute and edge clusters:



In my lab, the physical networking is provided by a Cisco 3750 swtich. Here is my VLAN config and subnet config:



Next, lets create the a-record for my edge's management interface. Below I show an a-record for a previously created edge with management ip address 172.17.0.50. As I make a new edge, I will use ip address 172.17.0.51:




Lets create a new edge at ip address 172.17.0.51. Notice I have chosen a small VM for my lab. I suggest you deploy an Extra Large VM in a production use case. Why deploy a medium or large and then require a change window once your organization outgrows that VM? Set it one time during initial provision and save yourself a maintenance window.:


Next we select what vSphere cluster to deploy the edges on. I've shown this image above and am showing it again.

Now we apply the ip address, default gateway, FQDN, and mgmt porgroup.

On the next page you'll have to pull together many previously configured components of this deployment. It should be noted that I haven't discussed all of these settings in detail. If you need more info on these use your Google-fu!
  • Edge Switch Name: You can type in a switch name here. It must be the same name if it is to be used across multiple edges. 
  • Transport Zone: NSX comes with default transport zones. You should probably configure your own.
  • Uplink Profile: This describes how the edge vm will connect to the dvSwitch for uplink and overlay traffic.
  • IP Assignment: It describes how the edge teps get their ip addresses.
  • Teaming Policy Uplink Mapping: Maps edge vnics to vSphere portgroups.

An expanded view of the teaming policy uplink mapping:


Afterwards, you click finish and the edge starts to deploy. We've seen the edge from the menu perspective, but what did we actually configure from a visual standpoint? Check the image below to find out.

Edge Management interface configuration:

Alright, what about the other 3 edge interfaces? How did those get configured? Check the image below to find out.

And how do these edge uplink configs map to the edge uplink profile? Check the image below to find out.



Assuming you've planned appropriately and entered all of the configuration into the GUI correctly, you should have an edge VM deployed. You can validate the vm and its interfaces in the vCenter UI:


Lastly, what did we actually just build? Lets take a look inside of the edge.



That's it!











Comments

Post a Comment

Popular posts from this blog

VXLAN versus GENEVE (NSX-V vs. NSX-T)

Image
  August 14th, 2021 With the ramp-up of NSX-T overlay networks and transition away from NSX-V overlay networks, it's a good time to look at one of the fundamental differences between them. NSX-V uses VXLAN as its encapsulation protocol while NSX-T uses the more recent GENEVE encapsulation protocol. Each require the physical networking devices have their MTU adjusted to 1600 bytes or greater. We'll take a detailed look at why that is. First, the basics: VXLAN is: short for Virtual eXtensible Local Area Network Is defined in rfc 7348 - https://datatracker.ietf.org/doc/html/rfc7348 Uses UDP port 4789 8 byte header GENEVE is: short for Generic Network Virtualization Encapsulation Is defined in rfc 8926 -  https://datatracker.ietf.org/doc/html/rfc8926 Uses UDP port 6081 16 byte header From the prospective of the physical network, an overlay network is essentially an application. NSX-T is an application using well known UDP port 6081. Switching perspectives to the overlay's
Read more

"Twice NAT" with NSX-T T0 Gateway

Image
  Network address translation, or more commonly NAT, is most often used to do source NAT or destination NAT. In rare instances, SNAT or DNAT isn't enough to get ip packets to their destination. Enter twice nat. While twice NAT isn't a function I've needed often, it was a function drilled into me while studying for various Cisco exams. I used to watch Christian Matei explain it over at INE and it really helped me to understand what twice NAT is and how to configure it on Cisco devices. Previous to my time working with NSX-T, I'd only utilized twice NAT once. A few years back, a customer wanted to build and IPsec tunnel from the organization HQ to a branch office. The private ip space used by HQ and the branch used overlapping ip space. We used twice NAT to NAT the source and destination ip address in a single NAT rule ( similar to this guy ) before shoving it all into an IPsec tunnel. Previous to working with NSX, circumstances requiring twice NAT were uncommon.  While w
Read more

Packet Capture Network Traffic Inside ESXi Hypervisor

Image
The three components of computer infrastructure are considered compute, storage, and networking. When applications don't work properly, its often the case that networking is the first component to receive blame for failed application performance. In the case of virtualized workloads (i.e. applications running on virtual machines), we are fortunate to have a powerful troubleshooting tool which allows us to packet capture network traffic in an ESXi hypervisor. For this blog, I'm going to use an Hands On Lab (HOL) from the VMware website to demonstrate the process of doing a quick live packet capture. The output of the packet capture will be sent to the shell of the hypervisor. There are ways to sent the network traffic to a file so it can be extracted and analyzed by a packet analyzer tool, but that will be for another post. First, lets start with heading over to the HOL website:  https://labs.hol.vmware.com/ For this lab, I'm going to type NSX in the search bar to find
Read more