We will perform the following tasks in this lab:

• Configure NSX global manager
• Create stretched NSX objects (logical routers, logical segments, security groups, distributed firewall rule)
• Move the virtual machine to another location using stretched NSX objects

NSX FEDERATION OVERVIEW

With NSX Federation, you can manage multiple NSX-T Data Center environments with a single pane of glass view, create gateways and segments that span one or more locations, and configure and enforce firewall rules consistently across locations.

To start using NSX Federation, you must first install Global Manager and then add different NSX-T instances as locations. The NSX-T manager appliances that are managed by Global Manager are called Local Managers. Once the locations are configured, you can configure networking and security from Global Manager.

It is recommended to have active and standby Global Manager clusters in different locations for resiliency and availability. 

NSX FEDERATION ENDPOINTS

In an NSX Federation environment, there are two types of tunnel endpoints.

• Tunnel End Point (TEP): the IP address of a transport node (Edge node or Host) used for Geneve encapsulation within a location.
• Remote Tunnel End Points (RTEP): the IP address of a transport node (Edge node only) used for Geneve encapsulation across locations.

You will be creating RTEPs on Edge Nodes during the lab. 

LAB ARCHITECTURE

Click to enlarge

The lab environment consists of a multi-site deployment. Each site is managed by an independent vCenter and NSX Manager. At Site A, a single NSX Global Manager has been pre-deployed to allow for the creation of the federation setup as part of the lab exercise. The workload clusters at each site have been prepared for NSX-T already, and two Edge nodes per site have been grouped in an NSX Edge Cluster. At Site A, the HOL Multi-Tier WebApp is functional, and its VMs are connected to VLAN-Backed vDS port-groups. The physical network is simulated using a single Linux Router VM named vPod Router running Quagga. The vPod router will act as the ToR switches at both sites.

The vPod router acts as the default gateway for any management or infrastructure network at both sites. The vPod router also acts as the default gateway for the three WebApp networks (Web, App, and Db). The vPod router is running BGP with AS 65100, and it is already configured to peer with the NSX infrastructure on 4 different VLANs: 100 and 200 at SiteA, 300 and 400 at SiteB.

In this lab, you are going to start by onboarding the NSX Managers at each site to the Global manager. After this step, any configuration, global or local to a specific Local Manager can be accomplished through the Global Manager UI. Next, you will configure the edge clusters at each site to forward RTEP traffic between the two locations. RTEP interfaces must be configured on each edge node on a different subnet and VLAN than the one in use for the TEP traffic. IP Pools for the RTEP interfaces have been pre-created in the lab and routing between the RTEP subnets at each site set up in advance.

Once the NSX Federation is set up, the first logical component you are going to create is a stretched Tier-0 Gateway. The stretched Tier-0 Gateway will have SR components deployed on four edge nodes, two at SiteA and two at SiteB. Extending the design recommendations for a single site, you will configure the SR component on each edge node to peer to the physical network over two distinct VLANs. You will use VLAN 100 and 200 at Site A, and VLAN 300 and 400 at Site B. In the lab, however, you will only configure a single BGP peering per site: Edge-01a to the vPod Router over VLAN 100, and Edge-01b to the vPod Router over VLAN 300 to save time and focus on federation-specific configurations.

After creating a Tier-0 Gateway, you are going to configure a Stretched Tier-1 Gateway and Stretched segments for the WebApp. You will advertise connected segments at both sites.

After configuring Stretched segments and Global security policies, you will migrate web-01a VM to Site B to verify that the Global security policies are still effective after the migration.

You will also explore the local egress functionality of NSX Federation.

Activate Global Manager

A Global Manager must be deployed for NSX Federation. Deploying a Global Manager appliance is similar to deploying an NSX Manager appliance. The main difference is that during the deployment, you must select “NSX Global Manager” as the role for the appliance. The appliance size must be at least Medium or Large; it cannot be small for Global Manager.

The appliance has been deployed already for you in this environment so let’s activate the Global Manager.

1. Expand the RegionA bookmark folder
2. Select NSX Global Manager
3. Click LOGIN
4. Go to System
5. Click LOCATION MANAGER
6. Click MAKE ACTIVE
7. Click the Global Manager Name field
8. Type GM
9. Click SAVE

Verify that the Global Manager shows as Active.

Add Site A Location

Now that the Global Manager is active, you must add locations to start managing local NSX-T instances. Let’s first add a NSX Manager in Region A as a location. NSX Manager instance added as a location is also referred to as a Local Manager.  

1. Scroll down
2. Click ADD ON-PREM LOCATION
3. Click Location Name field
4. Type Site-A
5. Click FQDN/IP field to provide the FQDN/IP address of the NSX Manager in Region A
6. Type 192.168.110.15

Leave the auto-filled username and password for the NSX Manager.

To retrieve the SHA-256 Thumbprint, you can SSH into the NSX Manager appliance or simply use the NSX-T UI. Let’s use the NSX-T UI for this one.

1. Open a new tab in the browser
2. Expand the RegionA bookmark folder
3. Select NSX Manager GUI
4. LOG IN
5. Go to System
6. Click Appliances
7. Scroll down to view more details about the appliance
8. Click VIEW DETAILS under 192.168.110.42
9. Click Copy to clipboard icon next to CERT THUMBPRINT to get the SHA-256 Thumbprint

Now that you have the thumbprint, let’s go back to the Global Manager to finish adding the NSX Manager as a location.

1. Use the first NSX tab in the browser to go back to the Global Manager
2. Right-click the SHA-256 Thumbprint field
3. Click Paste to paste the thumbprint
4. Click CHECK COMPATIBILITY to make sure the current NSX Version is compatible
5. Click SAVE to finish

Now, you can see that the Site A has been added as a location.

It may take a while for the Sync Status to show as success.

1. Scroll down to view the location that has been added
2. Refresh the Sync Status and verify that the Sync Status is now shown as Success

There is a blue notification banner that asks if you want to import objects and policies found in the Local Manager. If you import your configurations from the Local Manager to the Global Manager, the Global Manager will start managing those objects and you cannot edit those objects from the Local Manager any longer.

For more information about requirements and configurations that can be imported to the Global Manager, refer to the official VMware documentation here.

For this lab, you are not going to import any objects.

1. Click No, thanks on the blue notification banner.

Add Site B Location

Let’s add a NSX Manager in Region B as another location in the Global Manager.

1. Click ADD ON-PREM LOCATION
2. Click Location Name field
3. Type Site-B
4. Click FQDN/IP field to provide the FQDN/IP address of the NSX Manager in Region B
5. Type 192.168.210.15

Leave the auto-filled username and password for the NSX Manager.

This time, let’s use the NSX Manager CLI command to retrieve the SHA-256 instead of using the NSX-T UI.

1. Open a PuTTY session by clicking on PuTTY icon in the task bar
2.  Scroll down through the Saved Sessions to find a session called nsxmgr-01b.corp.local
3. Select nsxmgr-01b.corp.local
4. Click Open
5. Type the CLI command get certificate api thumbprint and enter
6. Right-click the thumbprint to copy it to the clipboard
7. Close the PuTTY session by clicking the X in the top right corner
8. Click OK to close the session

Now that you have the thumbprint, let’s finish adding the NSX Manager as a location.

1. Right-click the SHA-256 Thumbprint field
2. Click Paste to paste the thumbprint
3. Click CHECK COMPATIBILITY to make sure the current NSX Version supports NSX Federation
4. Click SAVE to finish
5. Scroll down to view the Local Manager for Site B that has been added

Now, you can see that the Site B has been added as a location.

It may take a while for the Sync Status to show as success.

1. Refresh the Sync Status and verify that the Sync Status is now shown as Success
2. Click No, thanks on the blue notification banner asking if you want to import your configurations from the Local Manager in Site B

Add RTEPs to Edge Cluster in Site A

You must configure a remote tunnel endpoint (RTEP) on Edge nodes in each location if you want to create stretched gateways and segments that handle the cross-location traffic. You must configure an RTEP in all the Edge nodes within an Edge cluster. Remember that TEP and RTEP must use different VLANs and layer 3 subnets.

The RTEP IP pool for Site A has already been created. Let’s configure RTEPs for the Edge cluster at Site A. 

1. Scroll up to view both locations in one view
2. For Site-A, click NETWORKING

1. Click CONFIGURE to start configuring sitea-edge-cluster

1. Click SELECT ALL to check both edges (edge-01a and edge-02a)
2. Expand the Select Edge Switch dropdown list
3. Select nvds
4. Click the RTEP VLAN field
5. Type 135
6. Expand the Select IP Pool dropdown list
7. Select SITEA-RTEPS-POOL
8. Click SAVE

The green notification banner shows that all the Edge nodes in the sitea-edge-cluster have been configured successfully.

Add RTEPs to Edge Cluster in Site B

Again, RTEPs must be configured in Edge clusters in both locations. The RTEP IP pool for Site B has already been created for you. Let’s configure RTEPS for the Edge cluster at Site B.

1. Expand the menu at the top to go back to the Global Manager
2. Select GM

1. Go to System
2. Go to Location Manager
3. Scroll down to view the Locations
4. Click NETWORKING for Site-B

1. Click CONFIGURE to start configuring siteb-edge-cluster
2. Click SELECT ALL to check both edges (edge-01b and edge-02b)
3. Expand the Select Edge Switch dropdown list
4. Select nvds
5. Click the RTEP VLAN field
6. Type 235
7. Expand the Select IP Pool dropdown list
8. Select SITEB-RTEPS-POOL
9. Click SAVE

The green notification banner shows that all the Edge nodes in the siteb-edge-cluster have been configured successfully.

Verify RTEPs Configuration

Let’s verify that RTEPs have been configured correctly by looking at edge-01a.

1. Open a PuTTY session by clicking on PuTTY icon in the task bar
2. Select edge-01a
3. Click Open
4. Maximize the window for a better view
5. Run the command get rteps and hit enter to see that one RTEP interface has been created for the Edge node and the IP has been allocated from the 192.168.135.0/24 range
6. Run the command get vteps and hit enter to see the two TEP interfaces with IP addresses from a different subnet than the one for RTEPs, 192.168.130.0/24
7. Run the command get logical-switches and hit enter to view the automatically generated VLAN logical switch on VLAN 135 for the RTEP traffic (the other two segments on VLAN 130 are for TEP traffic)
8. Run the command get logical-routers and hit enter to view the automatically created logical router for RTEP traffic, which you can identify by looking for the value RTEP_TUNNEL in the Type column
9. Close the PuTTY session by clicking the X on the top right-hand corner
10. Click OK to close the session

Create a Stretched Tier-0 Gateway

With RTEPs now configured on the Edge nodes, you can create stretched logical components across the two locations to handle cross-location traffic.

You will start by creating a stretched Tier-0 Gateway. At each location, this Tier-0 Gateway will have SR components on each edge node to peer with the physical network over two different VLANs. In Site A, the Tier-0 Gateway will use VLAN 100 and 200 while in Site B, it will use VLAN 300 and 400.

In this lab, however, you will only configure a single BGP peering per site in the interest of time. In Site A, you will create a BGP peering using Edge-01a over VLAN 100. In Site B, you will create a BGP peering using Edge-01b over VLAN 300.

Let’s create a VLAN segment to use for BGP peering in Site A.

1. Expand the menu at the top
2. Select GM Global Manager to go back
3. Close the Local Manager UI tab from earlier by clicking X on the second browser tab
4. Go to Networking
5. Click Segments under the Connectivity section
6. Click ADD SEGMENT
7. Click the Segment Name field to start giving a name
8. Type sitea-edge-uplink-1
9. Expand the Select Location dropdown list
10. Select Site-A
11. Expand the Select Transport Zone dropdown list
12. Select VLAN-EDGE-SITEA-TZ
13. Scroll down to configure more details

1. Click the VLAN field
2. Type 100 and enter
3. Expand the Select Uplink Teaming Policy dropdown list
4. Select uplink-1-only

1. Scroll down further
2. Click SAVE
3. There is no need for additional configuration of the segment so click NO

Let’s now create another VLAN segment to use for BGP peering in Site B.

1. Click ADD SEGMENT
2. Click the Segment Name field to start giving a name
3. Type siteb-edge-uplink-1
4. Expand the Select Location dropdown list
5. Select Site-B
6. Expand the Select Transport Zone dropdown list
7. Select VLAN-EDGE-SITEB-TZ

1. Scroll down to configure more details
2. Click the VLAN field
3. Type 300 and enter
4. Expand the Select Uplink Teaming Policy dropdown list
5. Select uplink-1-only

1. Scroll down further
2. Click SAVE
3. There is no need for additional configuration of the segment so click NO

Now, you are ready to create a stretched Tier-0 Gateway.

1. Go to Tier-0 Gateways under the Connectivity section
2. Click ADD TIER-0 GATEWAY
3. Click the Enter Name field
4.  Type Global-T0
5. Expand the Select Location dropdown list
6. Select Site-A
7. Expand the Select Edge Cluster dropdown list
8. Select sitea-edge-cluster
9. Click ADD LOCATION to add Site B
10. Expand the Select Location dropdown list
11. Select Site-B
12. Expand the Select Edge Cluster dropdown list
13. Select siteb-edge-cluster

1. Scroll down until you see the SAVE button
2. Click SAVE

The stretched Tier-0 Gateway has been created successfully. Let’s now configure the external interfaces to leverage for the BGP peering on this Tier-0 Gateway. You will start by adding an interface for Site A.

1. Click YES to continue configuring the Tier-0 Gateway
2. Scroll down to view additional configuration options
3. Expand the INTERFACES section
4. Click SET next to Interfaces

1. Click ADD INTERFACE
2. Click the Enter Name field
3. Type vl100-edge01a
4. Expand the Location dropdown list
5. Select Site-A
6. Click the IP Address field
7. Type 192.168.254.13/29 and enter
8. Expand the Segment dropdown list
9. Select sitea-edge-uplink-1
10. Expand the Select Edge Node dropdown list
11. Select edge-01a
12. Expand the URPF Mode field
13. Set it to None (this is done because we have Edges in ECMP mode)

1. Scroll down
2. Click SAVE

Let’s now create an interface for Site B.

1. Click ADD INTERFACE
2. Click the Enter Name field
3. Type vl300-edge01b
4. Expand the Location dropdown list
5. Select Site-B
6. Click the IP Address field
7. Type 192.168.254.29/29 and enter
8. Expand the Segment dropdown list
9. Select siteb-edge-uplink-1
10. Expand the Select Edge Node dropdown list
11. Select edge-01b
12. Expand the URPF Mode field
13. Set it to None (this is done because we have Edges in ECMP mode)

1. Scroll down
2. Click SAVE
3. Click CLOSE

With the interfaces configured, you can configure BGP peering. First, let’s configure a BGP neighbor for Site A.

1. Scroll down to view additional configuration options
2. Expand the BGP section
3. Scroll down further to view the BGP configuration options
4. Click on the Local AS field
5. Type 65001

1. Click SAVE
2. Start configuring BGP Neighbors by clicking Set in the BGP Neighbors section

1. Click ADD BGP NEIGHBOR
2. Click the Enter IP field
3. Type 192.168.254.9
4. Expand the Location dropdown list
5. Select Site A
6. Click the Remote AS number field
7. Type 65002
8. Click the Source Addresses field
9. Select 192.168.254.13

1. Scroll down
2. Click SAVE

Let’s now add a BGP neighbor for Site B.

1. Click ADD BGP NEIGHBOR
2. Click the Enter IP field
3. Type 192.168.254.25
4. Expand the Location dropdown list
5. Select Site B
6. Click the Remote AS number field
7. Type 65002
8. Click the Source Addresses field
9. Select 192.168.254.29
10. Scroll down

1. Click SAVE
2. Click CLOSE

The last thing you will configure in this lab on the Tier-0 Gateway is route redistribution. This is in preparation for when you create and connect a stretched Tier-1 Gateway to this Tier-0 Gateway. Tier-0 Gateway will advertise Tier-1 Gateway connected interfaces and segments as well as NAT IPs.

1. Expand the ROUTE RE-DISTRIBUTION section
2. Scroll down to view more options
3. Click Set next to Site-A to configure route redistribution for Site A

1. Click ADD ROUTE RE-DISTRIBUTION
2. Click the Name field
3. Type redistribution1
4. Click Set under the Route Re-distribution column

1. Check the box for NAT IP under the Advertised Tier-1 Subnets section
2. Check the box for Connected Interfaces & Segments under the Advertised Tier-1 Subnets section
3. Click APPLY

1. Click ADD
2. Click APPLY to finish
3. Click Set next to Site-B to configure route redistribution for Site B

1. Click ADD ROUTE RE-DISTRIBUTION
2. Click the Name field
3. Type redistribution1
4. Click Set under the Route Re-distribution column

1. Check the box for NAT IP under the Advertised Tier-1 Subnets section
2. Check the box for Connected Interfaces & Segments under the Advertised Tier-1 Subnets section
3. Click APPLY

1. Click ADD
2. Click APPLY to finish
3. Click SAVE to finish configuring the Tier-0 Gateway
4. Scroll down
5. Click CLOSE EDITING

The stretched Tier-0 Gateway has been created and configured. Let’s verify the BGP peering on this Tier-0 Gateway.

1. Expand the Global-T0
2. Scroll down to view more options
3. Expand the BGP section
4. Scroll down further
5. Click on Site-A(1) in the BGP Neighbors section

1. Click Check Status of the BGP neighbor to make sure it says Success

1. Click the Information icon for more details about the BGP neighbor

1. Verify that connection status with edge-01a is Established then click CLOSE
2. Click CLOSE
3. Click on Site-B(1) in the BGP Neighbors section
4. Click Check Status of the BGP neighbor to make sure it says Success

1. Click the Information icon for more details about the BGP neighbor

You only configured BGP Neighbor with edge-01b so no information is shown for edge-02b.

1. Expand the Edge Node dropdown list
2. Select edge-01b

1. Verify that connection status with edge-01b is Established then click CLOSE
2. Click CLOSE

Create a Stretched Tier-1 Gateway

Let’s now create a stretched Tier-1 Gateway to attach to the stretched Tier-0 Gateway that you just created. This stretched Tier-1 Gateway will not have any services enabled. Without any Service Routing (SR) components, you don’t have to select an edge cluster or set a specific location as primary or secondary. This will simply be for Distributed Routing (DR).

1. Go to Tier-1 Gateways under the Connectivity section
2. Click ADD TIER-1 GATEWAY
3. Click the Enter Name field
4. Type Global-T1-DRonly
5. Expand the Select Tier-0 Gateway dropdown list
6. Select Global-T0

1. Scroll down to view more configuration options
2. Expand the Route Advertisement section
3. Toggle the button next to All Connected Segments & Service Ports to have the Tier-1 Gateway advertise all its connected segments and service ports to the Tier-0 Gateway

1. Scroll down further
2. Click SAVE
3. Click NO as no further configurations are needed for this Tier-1 Gateway

Create a Stretched Segments

In this section, you will create stretched segments for the WebApp, which is currently on VLAN-backed networks. The stretched segment subnets will overlap with the current VLAN-backed networks used for the WebApp, but the physical network prefers the path to the VLAN-backed networks. Therefore, there will not be any disruption to the availability of the WebApp during this process.

1. Go to Segments under the Connectivity section
2. Click ADD SEGMENT to create a Global segment for Web VMs of the WebApp
3. Click the Segment Name field
4. Type G-WEB
5. Expand the Connected Gateway dropdown list
6. Select Global-T1-DRonly
7. Click the Gateway CIDR IP field
8. Type 172.16.10.1/24

1. Scroll down
2. Click SAVE
3. Click NO
4. Click ADD SEGMENT to create a Global segment for App VMs of the WebApp
5. Click the Segment Name field
6. Type G-APP
7. Expand the Connected Gateway dropdown list
8. Select Global-T1-DRonly
9. Click the Gateway CIDR IP field
10. Type 172.16.20.1/24

1. Scroll down
2. Click SAVE
3. Click NO
4. Click ADD SEGMENT to create a Global segment for Database VMs of the WebApp
5. Click the Segment Name field
6. Type G-DB
7. Expand the Connected Gateway dropdown list
8. Select Global-T1-DRonly
9. Click the Gateway CIDR IP field
10. Type 172.16.30.1/24

1. Scroll down
2. Click SAVE
3. Click NO

Let’s verify the stretched segments by going to the vSphere Client of Site A.

1. Open a new tab in the browser
2. Expandthe RegionA bookmark folder
3. Select RegionA vCenter HTML5 Client
4. Click LOGIN
5. Go to the Networking tab in the vSphere Client
6. Expand SiteA-vDS-01
7. Verify that the three overlay segments you have created are in Site A (G-APP, G-DB, G-WEB)
8. Expand SiteB-vDS-01
9. Verify that the same three overlay segments are in Site B as well (G-APP, G-DB, G-WEB)

Let’s verify the routing advertisement.

1. Open a PuTTY session by clicking on PuTTY icon in the task bar
2. Scroll down through the Saved Sessions
3. Select vPodRouter
4. Click Open
5. Maximize the session window
6. Enter the quagga CLI using the command vtysh and hit enter
7. Run the command sh ip bgp to view the routes and hit enter

You will see the three overlay segments being advertised. Each subnet is received from edge-01a at Site A (192.168.254.13) and edge-01b at Site B (192.168.254.29). The best path currently as marked with > is 0.0.0.0 because the VLAN-backed segments are directly connected to the eth2 interface of the vPod router.

1. Close the PuTTY session by clicking the X in the top right-hand corner
2. Click OK to close

Migrate WebApp to the Stretched Segments

Currently, Webapp uses the eth2 interface on the vPod router as the default gateway. You will now migrate the WebApp to the global segments you have created, and the traffic will start being forwarded to the global Tier-0 Gateway instead of the vPod router.

First, verify that the WebApp is working.

1. Open a new tab in the browser
2. Click the 3-Tiers-WebApp bookmark

You can view that the Customer Database Access page has loaded properly. Let’s now migrate the WebApp to the global segments, starting with the segment for web VMs.

1. Go back to the vSphere Client by clicking on the vSphere browser tab
2. Right-click the SiteA-vDS-01-Web port group

1. Select Migrate VMs to Another Network

1. Click BROWSE for Destination network
2. Select G-WEB overlay segment
3. Click OK

1. Click NEXT
2. Check the box next to the Virtual Machine column to select all the virtual machines on this port group

1. Click NEXT
2. Review the settings and click FINISH

Migrate the segment for app VMs.

1. Right-click the SiteA-vDS-01-App port group

1. Select Migrate VMs to Another Network
2. Click BROWSE for Destination network

1. Select G-APP overlay segment

1. Click OK
2. Click NEXT
3. Check the box next to the Virtual Machine column to select all the virtual machines on this port group

1. Click NEXT
2. Review the settings and click FINISH

Migrate the segment for database VMs.

1. Right-click the SiteA-vDS-01-DB port group
2. Select Migrate VMs to Another Network
3. Click BROWSE for Destination network
4. Select G-DB overlay segment
5. Click OK
6. Click NEXT
7. Check the box next to the Virtual Machine column to select all the virtual machines on this port group
8. Click NEXT
9. Review the settings and click FINISH

Let’s verify that the virtual machines have been moved.

1. Click G-APP under SiteA-vDS-01
2. Go to the VMs tab and verify that app-01a VM is there
3. Click G-DB under SiteA-vDS-01 and verify that db-01a VM is there
4. Click G-WEB under SiteA-vDS-01 and verify that the three VMs (lb-01a, web-01a, web-02a) have been migrated

With the WebApp on the overlay segments, you will shut down the eth2 interface on the vPod Router.

1. Open a PuTTY session by clicking on PuTTY icon in the task bar
2. Scroll down through the Saved Sessions
3. Select vPodRouter
4. Click Open
5. Maximize the session window
6. Shut down the interface by running the command ifconfig eth2 down and hit enter

Let’s view the routes now.

1. Enter the quagga CLI using the command vtysh and hit enter
2. Run the command sh ip bgp and hit enter

You no longer see the Next Hop 0.0.0.0 since you shut down the eth2 interface. The best path marked with > is now the global Tier-0 Gateway (192.168.254.13).  

1. Close the PuTTY session by clicking the X in the top right-hand corner
2. Click OK to close

Verify that the WebApp is still functioning

1. Go to the Customer Database by clicking the third browser tab
2. Click Refresh and verify that the page still loads correctly

Let’s make sure the traffic is now flowing to the global Tier-0 Gateway.

1. Open the Command Prompt from the task bar
2. Run the command tracert -d 172.16.10.10 and hit enter

You can verify that the traffic is going through the global Tier-0 Gateway from the second hop, 192.168.254.13, which is the Tier-0 interface on the Edge node (edge-01a) in Site A.

1. Close the Command Prompt window
2. Close the Customer Database Access tab in the browser
3. Close the vSphere Client by closing the browser tab

Configure Global Micro-Segmentation

With NSX Federation, you can configure global micro-segmentation where distributed firewalls will apply to virtual machines regardless of which locations the machines are located.

You will create a simple firewall rule that blocks access from the Web tier to the Database tier of the WebApp. The firewall rule will be set as part of a global policy so that the configuration will be pushed to both Local Managers at both sites.

You will use a membership criterion based on tags, and the virtual machines must have tags applied at the local manager level. Let’s start by assigning tags to the virtual machines at Site A.

1. Expand the menu to go to Site A Local Manager
2. Select Site-A
3. Go to the Inventory tab
4. Go to Tags
5. Click ADD TAG to create a tag for web virtual machines
6. Click the Enter Name field
7. Type web
8. Click the Enter Scope field
9. Type webapp

1. Click Set Virtual Machines
2. Scroll down to find the web virtual machines
3. Select web-01a virtual machine
4. Select web-02a virtual machine

1. Click APPLY
2. Click SAVE
3. Click REFRESH to view the tag you have just created
4. Click ADD TAG to create a tag for database virtual machine
5. Click the Enter Name field
6. Type db
7. Click the Enter Scope field
8. Type webapp
9. Click Set Virtual Machines
10. Select db-01a virtual machine
11. Click APPLY
12. Click SAVE
13. Click REFRESH to view the tag you have just created

With the tags in place, you can now create global security groups with a membership criterion based on these tags.

1. Expand the menu to go to the Global Manager
2. Select GM
3. Go to Inventory
4. Click Groups
5. Click ADD GROUP to create a global security group for the web virtual machines
6. Click the Group Name field
7. Type WEB
8. Expand the Region dropdown list
9. Select Global to indicate that this is a global security group

1. Click Select Members
2. Click + ADD CRITERIA
3. Click the value field
4. Type web
5. Select the web value
6. Click the Scope field
7. Type webapp
8. Select the webapp value
9. Click APPLY

1. Click SAVE to finish
2. Click ADD GROUP to create a global security group for the database virtual machine
3. Click the Group Name field
4. Type DB
5. Expand the Region dropdown list
6. Select Global to indicate that this is a global security group
7. Click Select Members
8. Click + ADD CRITERIA
9. Click the value field
10. Type db
11. Select the db value
12. Click the Scope field
13. Type webapp
14. Select the webapp value
15. Click APPLY
16. Click SAVE to finish

Let’s verify that the virtual machines have been placed appropriately in each security group.

1. Click View Members for the WEB security group and verify that the two web virtual machines are shown as members

1. Click CLOSE
2. Click View Members for the DB security group and verify that the database virtual machine is shown as a member

1. Click CLOSE

Before configuring a firewall rule that will block the web virtual machines from communicating with the database virtual machine, let’s verify that they can communicate.

1. Open a Putty session by clicking on the Putty icon in the taskbar
2. Scroll down through the Saved Sessions
3. Select web-01a
4. Click Open
5. Run the command ping db-01a and hit enter. Verify that the web virtual machine is able to communicate with the database machine
6. Hit the tab to stop the pings (outside this simulation, this would be Ctrl + Shift + C on a Windows machine)

1. Click X on the top right-hand corner to close the session
2. Click OK to close

Let’s now configure a firewall rule that blocks the web virtual machines traffic to the database virtual machine.

1. Go to the Security tab
2. Click Distributed Firewall
3. Click + ADD POLICY
4. Click the three vertical dots for the New Policy
5. Select Add Rule
6. Click the New Rule field to give it a name
7. Type Block WEB to DB
8. Click the pencil icon in the Sources column to change the source from Any
9. Select the WEB security group
10. Click APPLY
11. Click the pencil icon in the Destinations column to change the destination from Any
12. Select the DB security group
13. Click APPLY
14. Expand the Action dropdown list
15. Select Drop to drop packets that are sent from the WEB security group to the DB security group
16. Click PUBLISH

Verify that the web virtual machines cannot send traffic to the database virtual machine anymore.

1. Open a Putty session by clicking on the Putty icon in the taskbar
2. Scroll down through the Saved Sessions
3. Select web-01a
4. Click Open
5. Run the command ping db-01a and hit enter
6. Hit the tab to stop the pings (outside of this simulation, this would be Ctrl + Shift + C on a Windows machine) and verify all the packets sent from the web virtual machine have not been received by the database virtual machine

1. Click X on the top right-hand corner to close the session
2. Click OK to close

Let’s still make sure the WebApp is functioning.

1. Open a new tab in the browser
2. Click the 3-Tiers-WebApp bookmark and verify that you can view the Customer Database Access page load properly

1. Close the tab

Migrate a Web VM to Site B and Verify Functionality

The main advantage of NSX Federation is the flexibility of workloads between the locations that are managed by the Global Manager. You will migrate the web-01a virtual machine from Site A to Site B using a cross vCenter vMotion. Even after this virtual machine has migrated to Site B, you will see that the micro-segmentation policy is still enforced at Site B, and the WebApp functions properly. You will also see local egress functionality, where traffic leaving from Site A will use the Edge node in Site A (edge-01a) while traffic leaving from Site B will use the Edge node in Site B (edge-01b).

Let’s first migrate the web-01a virtual machine to Site B.

1. Open a new tab in the browser
2. Expand the RegionA bookmark folder
3. Select RegionA vCenter HTML5 Client
4. LOG IN
5. Right-click web-01a virtual machine
6. Select Migrate
7. Leave the migration type as Change compute resource only and click NEXT
8. Select esx-01b.corp.local
9. Click NEXT
10. Leave the selected destination folder as is and click NEXT
11. Verify that the destination network is G-WEB and click NEXT
12. Leave the button as Schedule vMotion with high priority and click NEXT
13. Click FINISH to start the vMotion

After a few moments, you will see that the web-01a virtual machine has been moved to Site-B. Let’s go back to the NSX UI and verify the Local and Global Manager inventories.

1. Go back to NSX UI by clicking on the first browser tab
2. Expand the menu to go to Site B
3. Select Site-B
4. Go to Inventory
5. Click Virtual Machines and verify that web-01a is in Site B
6. Click 1 under the Tags column to verify that it still has the web security tag

1. Expand the menu to go to the Global Manager
2. Select GM
3. Go to Inventory
4. Click Groups
5. Click View Members of the WEB security group and verify that the web-02a virtual machine in Site-A is still in this group

1. Expand the Select Location dropdown list
2. Select Site-B to verify that the web-01a virtual machine that you have migrated to Site-B is still in this security group

1. Click CLOSE

Let’s verify the Layer 2 extension between the sites by making sure that the two web virtual machines can still communicate with one another. The security policy should still be applicable, so let’s also verify that the web-01a virtual machine cannot send traffic to the db-01a virtual machine.

1. Open a Putty session by clicking on the Putty icon in the taskbar
2. Scroll down through the Saved Sessions
3. Select web-01a
4. Click Open
5. Run the command ping web-02a and hit enter. Verify that packets are being sent and received between the two web virtual machines
6. Hit the tab to stop the pings (outside this simulation, this would be Ctrl + Shift + C on a Windows machine)
7. Run the command ping db-01a and hit enter
8. Hit the tab to stop the pings (outside this simulation, this would be Ctrl + Shift + C on a Windows machine) and verify all the packets sent from the web virtual machine have not been received by the database virtual machine

1. Click X on the top right-hand corner to close the session
2. Click OK to close

Let’s still make sure the WebApp is functioning.

1. Open a new tab in the browser
2. Click the 3-Tiers-WebApp bookmark and verify that you can view the Customer Database Access page load properly

1. Close the tab

Lastly, let’s explore the local egress functionality.

1. Open a Putty session by clicking on the Putty icon in the taskbar
2. Select edge-01a
3. Click Open
4. Maximize the session window

To perform the packet capture, you need to identify the external interface IDs and use that ID to start the packet capture.

1. Run the command get logical-routers and hit enter to identify the VRF of the SR-Global-T0 router
2. Run the command vrf 3 and hit enter
3. Run the command get interfaces and hit enter

1. Scroll up to find the vl100-edge01a uplink interface with the IP address 192.168.254.13/29
2. Right-click the interface ID to copy it to the clipboard
3. Type exit and hit enter to leave the VRF CLI context
4. Type the command start capture interface
5. Right-click to paste in the interface ID
6. Finish typing the rest of the command: direction output expression ICMP and hit enter to start the packet capture

1. Open another Putty session by clicking the edge-01a.corp.local Putty session on the taskbar
2. Select edge-01b
3. Click Open
4. Maximize the session window
5. Run the command get logical-routers and hit enter to identify the VRF of the SR-Global-T0 router
6. Run the command vrf 3 and hit enter
7. Run the command get interfaces and hit enter

1. Scroll up to find the vl300-edge01b uplink interface with the IP address 192.168.254.29/29
2. Right-click the interface ID to copy it to the clipboard

1. Type exit and hit enter to leave the VRF CLI context
2. Type the command start capture interface
3. Right-click to paste in the interface ID
4. Finish typing the rest of the command: direction output expression ICMP and hit enter to start the packet capture

Now that you have packet capture going on both edges, let’s now create some traffic from the web virtual machines.

You will generate traffic first from web-01a, which is in Site B, and verify that the traffic is captured only on edge-01b in Site B and not on edge-01a located in Site A.

1. Open a Putty session by clicking the edge-01a.corp.local Putty session on the taskbar
2. Scroll down through the Saved Sessions
3. Select web-01a
4. Click Open
5. Run the command ping 192.168.110.10 and hit enter (this is an external IP)
6. Hit the tab to stop the pings (outside this simulation, this would be Ctrl + Shift + C on a Windows machine)

1. Close the web-01a PuTTY session window
2. Click OK

As you can see in the Putty session of edge-01b, the traffic from web-01a virtual machine has been captured. If you open the Putty session of edge-01a, however, you will see that there were not any packets going through that Edge node in Site A when you generated traffic from the web-01a virtual machine.

1. Minimize the edge-01b PuTTY session to view the edge-01a session

You can verify that edge-01a did not have any packets from the web-01a virtual machine go through. Now, let’s generate some traffic from the web-02a virtual machine, which is located at Site A. This time, the edge-01a session should show packets being captured.

1. Open a Putty session by clicking the edge-01a.corp.local Putty session on the taskbar
2. Scroll down through the Saved Sessions
3. Select web-02a
4. Click Open
5. Run the command ping 192.168.110.10 and hit enter (this is an external IP)
6. Hit the tab to stop the pings (outside this simulation, this would be Ctrl + Shift + C on a Windows machine)

1. Close the web-01a PuTTY session window
2. Click OK

You see now that in the edge-01a Putty, session packets from the web-02a virtual machine have been captured here. If you go back to the edge-02a Putty session, you will see that no new packets have been captured.

1. Minimize the edge-01a.corp.local PuTTY session

Source: VMware HOL LAB