So now we start to see nsx in action, we are going to build a distributed Switch with a Transport-Network and 3 Logical layer 2 domains, one of the web vms, and two others for the apps vms and the db vm. Keep in mind this is for layer 2 network domains, machines within the same network/subnet no ip routing is available here.
First up is the transit network, now one way to understand this is to compare it with a real transit network like a bus route for example.
I want to transport the vm packet to the destination, so I go the the nearest vtep, and jump on the transit network, which uses the infrastructure of the transport zone, finally I get to the vtep where the destination is located, that is where I get off the transit network, before completing the final part of the journey with the packet. I carry the packet and for part of the journey I am a passenger on the transit network.
NSX Networking & Security > Logical Switches >
Create a new logical switch called Transit-Network which will use the Global Transport Zone
Once created check the dvSwitches for new virtual wires
Notice how a virtual wire is created on each dvS in the Transport Zone
Go ahead and create Logical switches for the Web Tier, App Tier and DB Tier – all Unicast, all using the Global Transport Zone
Once finished it should look like this
Now we should see virtual wires for all of these networks on our dVSwitches
Cool, but what if I don’t want to include site-b in the logical switch
NSX Networking & Security >Installation >Transport Zones > Actions > Disconnect Clusters
As site-b is a separate cluster
The Distributed Port Groups are deleted from the dVS
To test this I’ve created two vms, web-1 and web-2 in the 172.16.10.0 network, and placed one on esx01 and the other on esx02
First check spoof guard, and approve the ips on the network – I haven’t seen much reference to this in other blogs, but get used to checking it.
To route traffic through the logical router click on the Add Virtual Machine Icon
Select the network cards and finish
VMs are now connected to the virtual wire, and traffic flows through the logical switch
Open up the controllers and run the following commands
Find which controller has the master role for the web-tier 5001
nsx-controller # show control-cluster logical-switches vni 5001
VNI Controller BUM-Replication ARP-Proxy Connections
5001 192.168.110.71 Enabled Enabled 0
The rest of the commands are run from the master controller for the Web Tier 192.168.110.71
See which vteps are being used
nsx-controller # show control-cluster logical-switches vtep-table 5001
VNI IP Segment MAC Connection-ID
5001 192.168.130.51 192.168.130.0 00:50:56:69:ff:1e 5
5001 192.168.130.52 192.168.130.0 00:50:56:6b:c7:ca 4
see the mac addresses of the vms
nsx-controller # show control-cluster logical-switches mac-table 5001
VNI MAC VTEP-IP Connection-ID
5001 00:50:56:8f:96:3a 192.168.130.52 4
5001 00:50:56:8f:46:b5 192.168.130.51 5
Spend some time thinking about the first and second commands, only one controller has routes for the Web-Tier logical switch. NSX uses a slicing method to distribute responsibility for the logical switches between the 3 controllers. If you want to know about a logical switch, you have to ask the responsible controller, the others know who this is but nothing more.
To help understand the idea of multiple routes in a Transport Zone, let reuse the idea of a bus route.
In this example there are two logical routes that both run over the same Transport Zone. Notice the bus driver is only going to care about passengers on his route, and he will only stop to pick up or drop of a passenger. In the same way only the vteps that have vms in the same logical switch are shown in the vtep-table and mac-table commands.
The are a couple more diagrams and some troubleshooting steps in the following post
http://54.194.254.47/nsx/nsx-troubleshooting-nsx-controllers/
That’s the logical switches set up, so we can route layer 2 traffic on the same subnet between esxi hosts without a 3rd party switch.
Next is the distributed router