Any customer can benefit from the automation enabled by this wizard-assisted operation, as the following example highlights. 

Imagine a customer has already deployed their NSX-T infrastructure through the wizard-driven process just described. As a next step, they will create some basic firewall rules, and to do that, they need to define some infrastructure services.

Now say they want to deploy a typical set of network services, including the following:

• DHCP
• DNS
• Active directory
• Custom services

These services may run on VMs or physical servers.

The following figure shows the diagram of the NSX configuration described in this section:

Figure 8.        Example of a typical customer  use case to create a basic firewall rules definition and configuration

Under host preparation, the customer would select Create Firewall Rules, as shown in the following figure. From there, they can create infrastructure groups dedicated to these types of network services.

They would then start adding a DHCP service, which is done through a VM in this case.

Figure 9.        Deploying basic network services in just a few steps

Deploying network services is as simple as selecting the VM and providing the basic info needed in the fields provided, such as Group Name and NSX Tag.

Figure 10.    Creating a DHCP service through a VM

Once the DHCP service is created, the customer can add a second one, which is DNS in this example. The Group Dashboard shows an existing DHCP one, conformed by 1 VM. The customer would add a second Group—a DNS server.

Figure 11.    Adding a DNS infrastructure group to a NSX catalog

For the DNS service, the customer would use a physical box. In that case, they need to provide the IP address of that server, as seen in the following figure.

Figure 12.    Creating a DNS service through a physical box

This server is external to the virtualized environment in which their NSX-T lives.

In just a few clicks, the customer has added DHCP and DNS services to their environment, compliant with the firewall rules defined in our NSX policies.

To close out this example, let’s say the client wants to incorporate a custom group that may respond to specific needs of that organization. This option provides the flexibility needed to go beyond the typical infrastructure services such as DNS, DHCP, or Active Directory.

Imagine they name this new Group myService and use a dvportgroup in this occasion.

Figure 13.    Creating custom network services

The customer would select a specific distributed virtual port Group and assign it to the new infrastructure service.

Figure 14.    Assigning a dvportgroup to the new infrastructure service 

As a last step, once the customer has their NSX infrastructure and basic services deployed, they would create the environment that is going to consume those services.

The customer may have designed a scenario with the following groups: Production, Development, and Payment Card Industry (PCI).

They would start by defining a Production Group, formed by two VMs: prod.web and prod.backend.

Figure 15.    Creating the Production Group, with two VMs in it

They would then do the same with Development and PCI, choosing the VMs that are part of each group.

It is important to highlight the relevance of the NSX tag. For any VM the customer creates in the future, if they tag it with Production, Development, or PCI NSX, it will be included in that workload group. This makes it subject to all the security and communications implications that it may have.

For this example, the customer ends up with three groups, with the corresponding VMs inside of them, as seen in the following figure.

Figure 16.    Environment created with the Groups Production (two VMs), Development (two VMs) and PCI (one VM)

The client can go one step further by defining which applications run inside a particular Group. They can create a myApp application group with the two production VMs in it: prod.web, and prod.backend.

Figure 17.    Selecting applications to run inside specific Groups (in this case, Production)

The next natural step would be to define the communications that can happen between the elements in our environment. The customer can create a communication schema that allows for the following:

• Prod, Dev, and PCI can access DHCP
• Prod, and PCI can access DNS
• Prod, and PCI access myService 

The customer would implement that design assigning which environment groups (Prod, Dev, PCI) can talk to the three defined infrastructure groups (DHCP, DNS, myService). This is shown in the following figure.

Figure 18.    Defining communications between infrastructure and environment groups

The result is shown in the following figure, where there are several workload groups that can talk to certain infrastructure groups.

Figure 19.    Implementation of inter-group communications

The last step in this deployment and configuration process is to define the communication strategies for applications.

The customer has their myApp running inside the Production Group and wants to limit the traffic the application admits. They would define it to admit just HTTPS traffic.

To do so, they would create a strategy for myApp to reject all traffic and add one exception: port 443, HTTPS traffic, as shown in the following figure.

Figure 20.    Traffic strategy for the myApp application

Once all the rules are created for infrastructure, workload, and application Groups as well as the communication policies, the customer has another opportunity to review these strategies before they are published in the NSX DFW. This checkpoint is shown in the following figure.

Figure 21.    Final dashboard to review all defined policies before go-live

This is how those policies will look after they have been published. As always, even after going live, customers can come back and review, edit, any policy or rule that needs modification, as shown in the following figure.

Figure 22.    Editing rules or policies that need modification after go-live

A major advantage of this NSX distributed firewall over a physically segmented network is that the firewall is instantiated in every vNIC of every VM, allowing to define a granular network configuration and segmentation no matter where the VM or their connectivity may be. Also of relevance is to remember that all rules and existing tags move with VMs when vMotioned. If we create more instances of a specific VM (prodbackend or prod.web) to increase the solution scalability, just assigning the proper tags to them will make NSX apply all the associated rules.

Customers can apply firewall rules specific to each business-defined network zone, as seen in the following figure.

Figure 23.    VLAN-back network segmentation with NSX-T