Cloud Foundation helps to break down the traditional administrative silos in data centers, merging compute, storage, network provisioning, and cloud management to facilitate end-to-end support for application deployment.

1. Welcome To Lab2prod.com.au
NSX-T Transport VLANs and Inter TEP Communication | LAB2PROD
NSX-T Inter TEP
Tunnel Endpoints (TEPs)
NSX-T Transport VLANs
Tunnel Endpoints (TEPs) - Understand the requirement for NSX-T transport VLANs and Inter
TEP communication. Everything you need to know about NSX-T Transport VLANs and Inter
TEP Communication.
NSX-T Transport VLANs and Inter TEP Communication |
LAB2PROD
Inter TEP Communication, Sharing Transport VLANs:
Unpacking One of The Latest Features In NSX-T 3.1
This post will include a brief recap of how Tunnel Endpoints (TEP) and
Transport VLANs have had to be configured for communication in prior
releases of NSX-T. It will then focus on how the release of NSX-T 3.1 has
changed the way Tunnel Endpoints for Edge Appliances that reside on
NSX-T hosts can be configured, and how inter TEP communication can be
achieved.
Table of Contents
 What are TEPs and TransportVLANs?
 How they communicate:Both hostto hostand hostto Edge Appliances
 How TEPs need to be configured when the Edge Appliances reside on a hosttransportnode in releases prior
to NSX-T 3.1
 A streamlined method to TEP configuration NSX-T 3.1
Note: All screenshots in this article have been taken in an NSX-T 3.1 environment.
What are Tunnel Endpoints (TEPs) and Transport
VLANs?

2. TEP’s are a critical component of NSX-T, each hypervisor participating in NSX-T (known as a host
transport node) and Edge Appliance will have at minimum one TEP IP address assigned to it. The host
transport nodes and Edge Appliances may have two for load balancing traffic, this is generally referred to
as multi-TEP.
TransportVLANs is just what NSX-T calls the VLAN used forthe TEPs,these are mappedusingprofiles andthen
attachedto the hosttransport nodesand edge nodes.
TEP IP Assignment:
 Hosttransportnode TEP IP addresses can be assigned to hosts statically,using DHCP or using predefined IP
Pools in NSX-T.
 Edge Appliances can have their TEP IP addresses assigned staticallyor using a pool.
TEP’s are the source and destination IP addresses used in the IP packet for communication between host
transport nodes and Edge Appliances. Without correct design, you will more than likely have
communication issues between your host transport nodes participating in NSX-T and your Edge
Appliances, this will lead to the GENEVE tunnel between endpoints being down. If your GENEVE tunnels
are down you will NOT have any communication between the endpoints on either side of the downed
tunnel.
The below images show the mac address table for a logical switch on a hosttransportnode.
Notice how here we have a column for Inner MAC, Outer MAC and Outer IP under the LCP section, also
how the MAC addresses have been spread across the two TEP IPs. If we dig a little deeper, we can start
by identifying what exactly those inner MACs are, where they came from and then repeat the same for the
outer MAC.
Let’s startby identifying the logical switch in question.

3. Now that we have the logical switch’s name and UUID we can dig a little deeper.
There are a couple of ways to do this, but since we have the name of the logical switch,I will continue to use
nsxcli. The next command we can run is ‘get logical-switch 6b151015-ab77-46bc-b4bd-62281ee7d6ec arp-
table’.Change the UUID to suityour environment.
Wait a second.. why are there no entries, especially since we know there is workload on this segment.
Chances are, either the Virtual Machine (VM) has not sent an Address Resolution Protocol (ARP) request
or it had and the table has since been flushed. We can repopulate this table by simply initiating a ping from
a VM on this segment.
The below image shows the same table after I initiated a ping from a VM on the segment.

4. Excellent, now we have an entry in the table, if we scroll up to the first image you can now see that the
inner MAC is the same as the MAC address from this entry. So that means the inner MAC is the source
VM’s vmnic’s MAC address.
That leaves us having to identify the remaining two outer MAC’s, this is pretty easy to do. There are a
couple of ways to do this, but let’s continue with nsxcli and the logical switch we have been working with.
This time we can run ‘get logical-switch 6b151015-ab77-46bc-b4bd-62281ee7d6ec vtep-table’, you should
see output similar to the below image.
The above output may not be enough to determine which outer MAC belongs to each host transport node.
To verify this, you can exit out of nsxcli, type in ‘esxcfg-vmknic -l’, and see the below output.
Here we can see the outer MAC’s are the MAC addresses of the vmkernel nics used for NSX-T, vmk10
and vmk11. Therefore, we can deduce that payload from within the NSX-T domain is encapsulated in a
packet header that uses the source and destination TEP IP and MAC addresses.
Visit for More Information:- https://www.lab2prod.com.au/2020/11/nsx-t-inter-tep.html