Looking for operational consistency between on-premises and Azure VMware Solution environments? Read this use case to see how the NSX-T Manager User Interface makes it easy to connect third-party networking and security appliances.
Challenge
When moving to Azure VMware Solution (AVS), customers may want to maintain operational consistency with their current 3rd-party networking and security platforms. The types of 3rd-party platforms could include solutions from Cisco, Juniper or Palo Alto Networks and the means for connectivity is independent of the NSX-T Service Insertion/Network Introspection certification process for vSphere or AVS. The following is a use case based on an actual customer deployment.
Solution
The AVS environment allows access to the following VMware management components:
- vCenter User Interface (UI)
- NSX-T Manager User Interface (UI)
Within this architecture design, the uplink of the 3rd-party appliance can be connected to a segment that is attached to the NSX-T “Tier 1” router while the individual or trunked downlinks of the appliance will support the connectivity of the Virtual Machine (VM) workloads, which is similar to the on-premises deployment model as depicted in the following diagram:
Diagram 1: Deployment Model for Connectivity of a 3rd Party Appliance with NSX-T
Once the appliance is attached to the NSX-T “Tier 1” router, static routes need to be configured to direct traffic through the 3rd-party appliance. Within the NSX-T Manager UI, the customer has the ability to create these static routes on the NSX-T “Tier 1” router which will assist in the network traffic direction through the 3rd-party appliance and to the customer’s VM workloads within AVS. Once the static routes are created, they can be redistributed within the dynamic routing protocol, Border Gateway Protocol (BGP).
This would allow for the static route information to be dynamically sent from the NSX-T “Tier 0” router through the uplink to the Top of Rack (ToR) platform and eventually, to the Azure Express Route backbone – which will allow for the end-to-end connectivity from the customer’s locally attached on-premises Express Route service to the AVS environment. This approach would provide a means to maintain operational consistency between what is currently on-premises and the AVS environment.
Diagram 2: Operational Consistency Deployment Model of 3rd Party Appliance in Azure VMware Solution
An additional consideration for this design is related to the location of the VMs within the cluster and the potential vSphere Distributed Resource Scheduler (DRS) event which attempts to load balance the VMs across the ESXi hosts within a cluster via vMotion based on available resources. During such an event, the 3rd-party appliance may reside on one ESXi host while the VM workload resides on another ESXi host. Within a customer’s on-premises data center, this situation can be resolved by stretching the VLANs on the ToR switch that are associated to the uplinks and downlinks attached to the 3rd-party platform which would provide connectivity independent of which ESXi host the platforms and VMs reside in. Within AVS, this needs to occur as well using NSX Segments or vSphere Distributed Switch (VDS).
Once the solution is verified based on these mentioned topics, the customer is able to consume the 3rd-party platform within AVS in the same way as the on-premises data center environment which will align with the requirement for operational consistency between on-premises and AVS for services such as disaster recovery.
