VCP6-NV Study Notes – Section 1 Understand VMware NSX Technology and Architecture–Part 2
Objective 1.3: Differentiate Physical and Virtual Network Technologies
Differentiate logical and physical topologies, components and services
Servers are interconnected by a physical network that already meets the basic requirements for network virtualization –> provide IP connectivity between the physical servers.
Because the vSwitch is the first hop in the data path for every packet that enters or leaves a VM, it’s the natural place to implement the data plane for network virtualization.
In typical data centers, however, not every machine is virtualized. The solution to this issue was to develop gateway capabilities that allow physical devices to be connected to virtual networks. A gateway capabilities that allow physical devices to be connected to virtual networks is what under the control of the NSX controller, maps physical ports, and VLANs on those ports, to logical networks –> VMs are connected to physical server and vice-versa.
Source: https://octo.vmware.com/network-virtualization-gets-physical/
An NSX gateway connects physical devices to virtual networks. This approach to connecting physical and virtual resources can be viewed in two main categories:
- terminating the overlay on physical devices, such as top-of-rack switches, routers, appliances, etc
- managing interactions between the overlay and the physical devices that provide the underlay
Source and further here: https://blogs.vmware.com/networkvirtualization/2014/07/physical-virtual-networking.html/
Also here: https://octo.vmware.com/vxlan-stt-and-looking-beyond-the-wire-format/ and here: https://octo.vmware.com/geneve-vxlan-network-virtualization-encapsulations/
Differentiate logical and physical security constructs
NSX DFW provides L2-L4 stateful firewall to any workload in NSX environment. It runs in kernel space providing near line rate network traffic protection, scaling in terms of performance and throughput simply adding ESXi hosts (Infrastructure linear scale).
- DFW is activated at host preparation and VM that should no included to this filter can be added to exclusion list functionality (by default NSX Manager, NSX Controllers, and Edge services gateways)
- One DFW instance is created per VM vNIC
- When DFW rule is created user can select a Point of Enforcement (PEP) for this rule
- DFW policy rules can be written is two ways:
- L2 rules mapped to L2 in OSI model –> using only MAX addresses in source and destination fields (are always enforced before L3/L4 rules)
- L3/L4 rules using IP addresses in source and destination fields
- DFW is fully complementary with NSX Edge services gateway that provides centralized firewall capability. ESG is typically used to protect north-south traffic and as such is the first entry point to the Software-Defined Data Center
- VMs can be connected to a VDS VLAN-backed portgroup or to a Logical Switch (i.e., VXLAN-backed port-group). ESG Firewall can also be used to protect workloads sitting on physical servers and appliances
- DFW system architecture is based on 3 distinct entities
- vCenter Server
- NSX Manager
- ESXi Hosts
- When vCenter containers are used in the DFW policy rules, VMtools must be installed on the guest VMs. If the DFW policy rules use only IP information (e.g., host IP, subnet IP, or IP sets) then the presence of VMtools on guest VM is not required.
- a kernel VIB is loaded into the hypervisor during host preparation –> this VIB is known as VMware Internetworking Service Insertion Platform (VSIP)
- is responsible for all data plane traffic protection
- adds complementary services like SpoofGuard and traffic redirection from third party partners
- SpoofGuard protects against IP spoofing by maintaining a reference table of VM name and IP address, populating it with information retrieved from VMtools during VM’s initial boot up. It disable by default and must be explicitly enabled per Logical Switch or vDS portgroup.
- Traffic redirection tyo 3rd party vendors provide the capability to steer particular type of traffic to a selected partner VM
- Partner Security Services tab provides a powerful and easy to use user interface to define what type of traffic needs to be redirected to which partner services
- The DFW instance on an ESXi host contains 2 separate tables:
- Rule table
- Connection Tracker Table
- A specific flow is identified by 5-tuple information:
- source ip address
- destination ip address
- protocol (TCP, UDP, ICMP,… )
- L4 source port
- L4 destination port
- DFW rules are enforced as follows:
- Rules are processed in top-to-bottom ordering
- Each packet is checked against the top rule in the rule table before moving down the subsequent rules in the table
- The first rule in the table that matches the traffic parameters is enforced
- The DFW default policy rule, located at the bottom of the rule table, is a “catchall” rule
Perimeter Firewall: Edge firewall services are part of the NSX Edge Services Gateway (ESG). The Edge firewall provides essential perimeter firewall protection which can be used in addition to a physical perimeter firewall
Endpoint Security: Installing Guest Introspection automatically installs a new VIB and a service virtual machine on each host in the cluster. Guest Introspection is required for NSX Data Security, Activity Monitoring, and several third-party security solutions.
Extensible framework Guest Introspection enables host based security services like anti-virus, anti-malware, and file integrity monitoring. Deploy this requires the Guest Introspection service appliance –> NSX automatically deploys vShield Endpoint VIBs (deployment consideration are the same as with DFW). This enables network security services like L7 firewall and IDS/IPS along with other monitoring services
Data Security: Data security allows detection of sensitive data in the guest virtual machines
Activity Monitoring: Activity monitoring allows detection of network connections for each individual application inside a guest virtual machine, regardless of its anywhere inside the datacenter
Flow Monitoring: Is a traffic analysis tool that provides a detailed view of the traffic to and from protected virtual machines. When flow monitoring is enabled, its output defines which machines are exchanging data and over which application. This data includes the number of sessions and packets transmitted per session. Session details include sources, destinations, applications, and ports being used. Session details can be used to create firewall allow or block rules. You can view TCP and UDP connections to and from a selected vNIC. You can also exclude flows by specifying filters.
Objective 1.4: Understand VMware NSX Integration with Third-Party Products and Services
Understand integration with third-party partner tools and systems using NSX REST APIs
Refer to Objective 1.3 about DFW
In distributed service insertion, a single host has all service modules, kernel modules, and virtual machine implementations on a single physical machine. Vendor solutions that make use of this type of service insertion include Intrusion Prevention Service (IPS)/Intrusion Detection Service (IDS), Firewall, Anti Virus, File Identity Monitoring (FIM), and Vulnerability Management.
Determine integration with third-party services and Determine integration with third-party hardware
- Distributed Service Insertion: In distributed service insertion, a single host has all service modules, kernel modules, and virtual machine implementations on a single physical machine
- Edge-Based Service Insertion: NSX Edge is deployed as a virtual machine in the Edge Services Cluster along with other network services. NSX Edge has the capability to redirect specific traffic to 3rd-party network services
- Consuming Vendor Services through Service Compose: Third-party vendor services include traffic redirection, load balancer, and guest security services such as data loss prevention, anti virus, and so on. Service Composer enables you to apply these services to a set of vCenter objects. A security group is a set of vCenter objects such as clusters, virtual machines, vNICs, and logical switches. A security policy is a set of Guest Introspection services, firewall rules, and network introspection service.
- Deploy a Partner Service: If the partner solution includes a host-resident virtual appliance, you can deploy the service after the solution is registered with NSX Manager. Prerequisites:
- The partner solution is registered with NSX Manager
- NSX Manager can access the partner solution’s management console
- Redirecting Traffic to a Vendor Solution through Logical Firewall: You can add firewall rules to redirect traffic to registered vendor solutions. Redirected traffic is then processed by the vendor service. Prerequisites:
- The third party service must be registered with NSX Manager, and the service must be deployed in NSX.
- If the default firewall rule action is set to Block, you must add a rule to allow the traffic to be redirected
- Using a Partner Load Balancer: You can use a third-party load balancer to balance the traffic for a specific NSX Edge. Prerequisites:
- The third-party load balancer must be registered with NSX Manager, and it must be deployed in NSX
Source: https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.2/nsx_62_admin.pdf
Install/register a third-party service with NSX
This is a generic high-level workflow for inserting a third-party service into the NSX platform:
- Register the third-party service with NSX Manager on the vendor’s console (it depends on vendor procedure)
- Deploy the service in NSX
Source: https://docs.vmware.com/en/VMware-NSX-for-vSphere/6.2/nsx_62_admin.pdf
Objective 1.5: Understand VMware NSX Integration with vRealize Automation (vRA)
Understand integration with vRealize Automation
vRealize Automation provisions, updates and decommssions network and security services in lockstep with your virtualized applications –> Network and security services are deployed as part of the automated delivery of the application, consistent with its connectivity, security, and performance requirements.
vRealize Automation and NSX accelerate the delivery of network and security services customized to the specific needs of modern applications. vRealize Automation dynamically configures network and security services within the context of the infrastructure or applications that are being deployed.
vRealize Automation service blueprint policies specified by administrators control how these services are provisioned, so resource consumers don’t have to be networking and security experts
- To integrate network and security with vRealize Automation an IaaS administrator must install the NSX plug-ins in vRealize Orchestrator and create vRealize Orchestrator and vSphere endpoints.
- A fabric administrator can create network profiles that specify network settings in reservations and blueprints
- A tenant administrator or business group manager can configure network adapters, load balancing, and security for all components provisioned from a multi-machine blueprint that uses a routed network profile
- A tenant administrator or business group manager can use the templates to define multi-machine service networks. In a multi-machine blueprint, you can configure network adapters and load balancing for all components provisioned from that multi-machine blueprint
Configuration steps:
- Configuring vRealize Orchestrator Endpoints: If you are using vRealize Automation workflows to call vRealize Orchestrator workflows, you must configure the vRealize Orchestrator instance or server as an endpoint.
- Create a vSphere Endpoint for Networking and Security Virtualization: An IaaS administrator creates an instance of a vSphere endpoint to allow vRealize Automation to interact with a vCloud Networking and Security or NSX instance.
- Run the Enable Security Policy Support for Overlapping Subnets Workflow in vRealize Orchestrator: Before you use the NSX security policy features from vRealize Automation, an administrator must run the Enable security policy support for overlapping subnets workflow in vRealize Orchestrator.
- Creating a Network Profile: fabric administrator creates external network profiles and templates for network address translation (NAT), routed, and private network profiles.
- Configuring a Reservation for Network and Security Virtualization: IaaS administrator can use a reservation to assign external networks and routed gateways to network profiles for basic and multi-machine networks, specify the transport zone, and assign security groups to multi-machine components
Demonstrate NSX deployment capabilities built into vRealize Automation
Run the Enable Security Policy Support for Overlapping Subnets Workflow in vRealize Orchestrator Understand NSX preparation tasks for attaching a network profile to a blueprint:
- Prerequisites
- Verify that a vSphere endpoint is registered with an NSX endpoint
- Log in to the vRealize Orchestrator Client as an Administrator
Compare and contrast Network Profiles available in vRealize Automation
Creating a Network Profile:
- A fabric administrator creates external network profiles and templates for network address translation (NAT), routed, and private network profiles.
- Network Type:
- External Network Profile: create an external network profile to define external network properties and a range of static IP addresses
- Private Network Profile: administrator can create a private network profile template to define an internal network and assign ranges of static IP and DHCP addresses to it
- NAT Network Profile: A fabric administrator can create a NAT network profile template to define a NAT network and assign ranges of static IP and DHCP addresses to it
- Routed Network Profile: A fabric administrator can create a routed network profile to define a routable IP space and available subnets for routed networks
Discern vRealize Automation preparation tasks for deploying a machine with on-demand network services
Checklist:
- Install and configure the NSX plug-in –> Install the NSX plug-in in vRealize Orchestrator. See Install the NSX Plug-In on vRealize Orchestrator and the NSX Administration Guide.
- Configure NSX network settings, including gateway and transport zone settings –> Configure network settings in NSX. See the NSX Administration Guide.
- Create NSX security policies, tags, and groups. –> Configure security settings in NSX. –> See the NSX Administration Guide.
- Configure NSX load balancer settings. –> Configure an NSX load balancer to work with vRealize Automation –> See the NSX Administration Guide. If using NSX 6.2, also see Custom Properties for Networking.