Eric Sloof

This article describes how to simulate VLAN ID's in your home lab without the need for a physical switch and how to create a bridge between a VLAN in GNS3 and a segment in NSX-T. GNS3 is a great free product that's able to simulate routers and switches.

This simulation is done by hosting the original binaries on a network virtualization platform. The GNS3-VM  can run as a virtual machine hosted on ESXi. The user-interface of GNS3 is a separate client that runs on your workstation but the network virtualization is done in the GNS3-VM virtual machine. 

The client interface is configured with the fully qualified domain name of the GNS3-VM and port 80 instead of the default 3080.

I also changed some settings of the GNS3-VM and configured an additional vCPU and a bit more memory. There's one other thing you need to do and that's removing one network adaptor.

So I have One network adaptor that's attached to a port group configured in trunk mode (Edge-Uplinks). This adaptor must be able to forward tagged traffic from the cloud component so we have to install the Ubuntu VLAN kernel module.

Taken from: Enabling 802.1q on the GNS3 VM

First, install VLANs on the GNS3 VM:
sudo apt-get install vlan

Load 802.1q into the kernel:
sudo modprobe 8021q

To load it permanently so it survives reloads of the VM:
sudo su -c 'echo "8021q" >> /etc/modules'

Make sure that the security settings on this port group are all enabled. So Promiscuous mode, MAC address changes, and Forged transmits must be enabled. 

I've also deployed a yVM (An ultra-small VM with VM tools) and attached it to a port group configured with VLAN 10. The IP address of this yVM is 172.16.10.20.

On the other side, The cloud component is connected to the virtual network adaptor of my GNS3-VM and attached it to a GNS3 ethernet switch "Switch1". The switch is connected to a virtual PC with IP address 172.16.10.21.

The switch is configured with a trunk (dot1q) downlink to the cloud component, the uplink is configured as a VLAN access port with ID 10.

The VLAN that's configured on the dot1q (IEEE 802.1Q) port is the VLAN that's NOT forwarded to the cloud component. So if you put 10 in here it doesn't work. That's why you see 1 which is the default (unused) VLAN on this trunk. Now I must be able to ping from the vPC to the yVM.

So it works :-) but let's take it one step further and add-in some NSX-T 3.0 magic. In NSX-T I've attached a Web segment to a T0 gateway. The edge service router VM is attached to the Edge-Uplink port group configured in trunk mode.

The segment is configured with a gateway address 172.16.10.1 and it's attached to a TO gateway.

The web segment is also attached to an Edge Bridge Profile configured with VLAN ID 10.

So now we have a bridged network between VLAN ID 10 from GNS3, VLAN ID 10 from the yVM port group, and the Web Segment. I should be able to ping from the Web-VM that's attached to the Web-Segment to the vPC and the yVM. 

The virtual machine that's attached to the Web-Segment is configured with IP address 172.16.10.12.

As you can see I'm able to ping from the Web VM to the yVM and the vPC.

In this article, I'll explain how to configure route aggregation on a T0-GW router. Let's look at the set-up first. I have two segments connected to my T0-GW router. One segment has IP address 172.16.10.0/24 and the other segment is configured with IP address 172.16.20.0/24. Both networks are advertised with BGP to a Cisco c3745 router. 

When I look at the routing table on my Cisco router, I can see that both networks were learned though BGP, and they point to the same next hop. The next hop is the uplink interface on the T0-GW-01. This is a bit unnecessary and we could optimize the routing table with route aggregation.

I'm going to configure route aggregation and tell the BGP peer that all routes that start with network address 172.16 have 10.0.0.216 as their next hop.

When I look at the updated routing table the two seperate entries are replaced with one aggrated route pointing to the 10.0.0.216.

I experienced some trouble trying to delete a segment with the NSX-T Policy UI. There was an error message complaining about a virtual machine that was still attached to the segment. I verified this message by going into vCenter and checking all the virtual machines and I was sure there were no virtual machines connected to this segment.

I fired up postman and tried to delete the segment through the REST API and again I got the same error message.

I looked-up the API call in the online documentation and discovered that there's also a force delete option. Force delete bypasses validations during segment deletion. This may result in inconsistent connectivity.

Request:

The segment was deleted successfully. 

When you have created a cluster and enable HA the default percentage for the Performance degradation VMs tolerate is 100%. I think this is a bit weird because why do you want to disable a warning when there is insufficient failover capacity to guarantee the same performance after VMs restart on the remaining hosts in the cluster.

When you are using too many resources and the utilization of your VM's doesn't fit on the remaining hosts in the cluster after a host failure wouldn't you like to know it?

When you put this value on 0% this message appears: Running VMs utilization cannot satisfy the configured failover resources on the cluster Production in Datacenter.

Percentage of performance degradation the VMs in the cluster are allowed to tolerate during a failure. 0% - Raises a warning if there is insufficient failover capacity to guarantee the same performance after VMs restart. 100% - Warning is disabled.

If you leave this value on the default 100% and your virtual machines are not configured with reservations, admission control based on percentage doesn't work. Only the virtual machine overhead is counted. 

You can clearly see in the above screenshot that we have 97% of our cluster resources available for both memory and CPU while at the same time we received a warning that we're running out over failover resources. So admission control based on percentage only works when VM's are configured with reservations. 

You can add locations to the Global Manager after you have installed the Global Manager. You can add up to three locations to a Global Manager. After you add a location to the Global Manager, the NSX Manager is called a Local Manager.

On the NSX Manager appliance, run the get certificate api thumbprint command to get the Thumbprint. 

Copy and paste the Thumbprint into the required field and check compatibility.

When you're using a DVS for your NSX-T overlay transport zone, you have to think about where your edges will be connected to the overlay network. If the edge is attached to a distributed port group created on the same DVS in the same VLAN, it doesn't work.

In the picture, we can see that both tunnel endpoints are down. I'm hosting two virtual machines attached to an NSX segment based on an overlay transport zone. The segment is attached to a T0-Gateway for north-south connectivity. 
 

The Alarms section also warns us that the edge overlay network is down.

The first interface of the edge is connected to the "Edge-Uplink-Management" distributed port group. The second interface is connected to the "Edge-Uplink-VLAN" distributed port group. Interface 3 and 4 are connected to the "Edge-Uplink-Overlay" port group. 

The VMK10 Geneve tunnel endpoint on the ESXi host is using the same DVS and is configured with the same VLAN-ID 0. 

After creating a second DSwitch Edge alongside the one that's used by NSX-T, I'm reconfiguring the second adaptor of the Edge virtual machine.

After a while, the tunnels on the Edge are reestablished. 

So when you're using and N-VDS or VDS for NSX-T and you're placing an Edge on the same switch you have to put the Edge overlay in a different subnet. The Geneve traffic that originates from the Edge is not allowed to pass a switch that's hosting a tunnel endpoint for ESXi (VMK10).

One of the coolest features of NSX-T 3.0 is the possibility to host NSX-T of a distributed switch instead of an N-VDS. Especially when the amount of network adapters is limited, it allows you to create segments managed by NSX-T alongside distributed port groups and other kernel ports groups.  

Your ESXi cluster can be prepared for NSX-T by assigning a transport node profile to the hosts. This transport node profile contains an Uplink profile. The uplink profile specifies which physical NICs are used on the ESXi host. 
 

This is a default failover uplink profile with one uplink on standby and one active uplink.

In the switch visualization tab, you can clearly see that the VDS DSwitch is mapped to vmnic1 and vmnic2. This configuration is owned by vCenter. The kernel port group that's used as a Geneve tunnel endpoint will be created on this VDS. However, the failover policy for this VMK10 is managed by NSX-T.

We can see that the kernel port group is listed on the ESXi host and configured with an IP address that comes from an IP pool managed my NSX-T. The switch that's used by VMK10 is a VDS managed by vCenter.

This is the Networking view in the vSphere Client. You notice there's no port group listed for managing the policies of VMK10. The policies are managed by NSX-T.

In esxtop we're able to validate the NIC mapping of the Geneve tunnel endpoint (VMK10). It's connected to VMNIC1. When vmnic1 fails it will jump to vmnic2.

I was trying to apply a profile to my nested production cluster when I noticed the installation of the NSX kernel modules stalled at 18%. The ESXi hosts were configured with 8 GB of RAM but I also enabled vSAN of the cluster. After reconfiguring the hosts with 16 GB of memory and hitting the resolve button the process completed successfully. 

Failed to install software on host. Failed to install software on host. esx01.ntpro.local : java.rmi.RemoteException: [LiveInstallationError] Error in running ['/etc/init.d/nsx-mpa', 'start', 'install']: Return code: 1 Output: Unable to setmemconfig for mpa host/vim/vmvisor/mpa Resource pool 'host/vim/vmvisor/mpa' released. Waiting for /usr/lib64/vmware/nsx-mpa/mpa to start... Waiting for /usr/lib64/vmware/nsx-mpa/mpa to start... Waiting for /usr/lib64/vmware/nsx-mpa/mpa to start... Waiting for /usr/lib64/vmware/nsx-mpa/mpa to start... Waiting for /usr/lib64/vmware/nsx-mpa/mpa to start... Unable to start /usr/lib64/vmware/nsx-mpa/mpa It is not safe to continue. Please reboot the host immediately to discard the unfinished update. Please refer to the log file for more details.