vCloud Director: NSX-V to NSX-T Migration Part-2

In this blog series we will continue to understand the methods which can be adopted to migrate NSX-V to T, under vCloud Director. In our previous blog we went through the basic constructs of vCD with NSX-V, and hypotectically went through the design option for NSX-T and strategy for vCloud Director: NSX-V to NSX-T Migration . In this blog we will go through some of the industry best NFV solution integration with NSX-T and VCD.

We will go through the design option in NSX-T and types of design scenario which can be adopted, that could be ideal for Service Provider and on that basis the automation can be developed.

vCloud Director and NSX-T

In the transition phase where NSX-V will be moved out to NSX-T, it is very important to understand the constructs of vCD and NSX-T. There will be some major difference in the way the vCD pushes the instruction to create network layer, earlier in NSX-V this task was done via vSphere(because NSX-V used to come as Network & Security plugin).

NSX-T design options

Every service provider have their own way to giving services to their respective tenants, which could be generally defined on the basis of the services which will be offered. The services from network point of view could be defined on following factors:
1. No. of VM’s/Containers in a network ( That could define the no. of Network )
2. VM Microsegmentation ( East-West Traffic protection)
3. NAT Service
4. IPsec Service
5. Internet Gateway
6. Private WAN Circuit( MPLS )
7. North-South Security
9. Remote Connection
10. Load Balancer (LTM, WAF, Global Load Balancer)
11. DRaaS ( Active-Active or Active-Standby Service hosting )
12. Monitoring and Logging Service and etc

NSX-V vs NSX-T in vCD

As per the service offering the network can be constructed on NSX-T and parallelly need to see the design option from vCloud Director. If we compare the current NSX-V offerings with vCD we come across some terms which will be similar in NSX-T, but one need to understand the components in NSX-T.
In NSX-V usually every Tenant will have it’s own Edge by which the Network Policy can be implemented, very similar in NSX-T we have same called T1 Gateway which will be under Tenant control.

Here T0 will be under control of Provider by which the tenants will be categorized and will be placed under Service Provider defined T0. This we will under in further section of this blog, what is the meaning of Type of T0 in provider premises.

Categorizing Tenant

As we are aware VMware is sooner going to stop support for NSX-V, so it is very important to understand how to architect the current and future customer on the basis of NSX-T features. So the services which we discussed in above section gives us opportunity to define the T0-T1 design under VCD layer.

Network Service on NSX-T ( Shared T0 )

Currently many of the service provider have offerings, which give service for some basic features which do involve some of the advanced features of network. This service can be simple NAT, IPSec, Internet Connection, etc which at current time with NSX-V involves provisioning separate NSX-V Edges for each customer. But now with the help of NSX-T we can define Edge which is equivalent to T1 Gateway.

Here this topology there won’t be requirement to have multiple T0 ( Edge Cluster ), it can run under single T0 Gateway where the major subnet of Public IP of tenant will be defined. The Edge Cluster for T0 can be scaled up on the basis of traffic pumped from tenant, and extra Edges can be added to T0-Edge-Cluster. But in future if still requires to have more T0 then a new T0-Gateway can be created under new Edge Cluster ( Other subnet of Public IP ).

In this below design every tenant will get T1 which can scale up till 4000 under single T0, which almost a huge no. and if the NAT or IPsec Service is enabled under T1 then the Public IP will be advertised to T0. This further being advertised via T0 to Uplink routers. This design will be also capable to give service of Distributed Firewall, in that case Data Center Group concept need to be explored. As we know T1 gateway runs under Active-Standby ( due to Service Offering of IPsec, NAT and Gateway Firewall ) which can be provisioned under T1 Edge Cluster and can be scaled up by created new Edge Cluster if Edges reaches it’s maximum consumption. This scale up all depends on the no. of session and traffic but will vary provider by provider.

This design gives opportunity to leverage load balancer (LTM, WAF, GTM ) services either by other party or NSX-T advanced load balancer(AVI), where the Service Engine can be shared to tenants or dedicated Service Engines can be provisioned as per the tenant request. But if some provider wish to use other 3rd party solution then in that case one should refer the validated design as an example with F5. But third party integration option via VCD won’t be available.

Some of the features which is not yet available under NSX-T is SSL-VPN, which probably needs either adopt the VCD Remote access VPN or leverage 3rd party solution of SSL VPN.

Though in this design we can also connect Tenant WAN Network but in that case we need to enable T0-VRF for every Tenant and Uplink the WAN VLAN network, and for WAN network No SNAT policy should be applied and Inter-VRF route Leaking will be required( Note : Shared T0 : Dedicate External Network Option is chosen while creating Edge(T1) which will not allow Private Network to be advertised from VCD). So in that case the Network need to be advertised from T1 to T0, but this will create issue with Tenant collapsed subnet issue and workflow of VCD could be deviated. So it is ideal to adopt and categorize the WAN required customer to be designed with T0-VRF where one can enable “Dedicate External Network” option.

Network Service on NSX-T with BYOD (VRF-Lite)

In service offering there will be some requirement for some tenants where they need to connect to their Sites via MPLS(WAN) connection, in that scenario most of the service providers have separate circuit for each tenant most probably per VLAN. This gives us to explore option from NSX-T how to provision separation from routing as well as from VLAN, without provisioning more Edge Cluster T0. Because we are aware about the limitations of T0 Edges under single domain of NSX-T which is 320 Edges, refer the updated maximum of VMware.

In that case the VRF-Lite option can be explored where each tenant will have it’s separate T0-VRF under a Parent T0 Edge Cluster. So the edges(T1) which will be created for each tenant and will be controlled by tenant to advertise the subnet from T1 ( though at backend the BGP and Network advertisement happens on T0-VRF). Here T0 is offering only routing capability so it cane be on Active-Active Edge Cluster.

If the tenant have requirement to handle some of the network services like NAT, IPSec, Security on 3rd Party solutions of their BYOD that could be possible. So in that case it is ideal to go through some of the solution like Palo Alto Integration with NSX-T , Fortinet with NSX-T and F5 with NSX-T this gives opportunity to compliment each solutions. ( Note : If there is no requirement for T1 SR service it is ideal to remove the T1 gateway from Edge Cluster) This will make sure the T1-DR service will be running on the Virtualization layer.

As per vCD 10.2.2 only BGP is the routing solution available from T0-VRF ( will be expecting OSPF support in near future as from 3.1.X release of NSX-T OSPF is being supported). Tenant at this moment have most of the BGP option by which they can change network policies.

Network Service on Dedicated Mode

In service offerings there could be requirements to have Dedicated Hardware which gives benefits from Dedicated Performance and Security point of view. In that case Providers can provision separate cluster from T0 and T1 which gives the guaranteed performance matrix and even separate network pool can be provisioned ( Transport Zone ).

Though this offering will create extra cost but for high performance offerings this can be adopted and VCD can play the front end portal for Tenants. The fundamentals of NFV solutions will remain same but for customer they can control their own Policy via Network Provisioning tools like Panorama and Forti Manager. For provider it is necessary to understand if the count of Edge Cluster is increasing under NSX-T it is ideal to provision separate vSphere and NSX-T for that tenant and this gives further more control on the Compute, Virtualization and Network layer.

Summary

In this blog we discussed the integration option of NSX-T with vCloud Director, which gives the single pane of glass for controlling VMware Suites. We went through the design option of T0, T1 gateway with various features of Dedicated Mode, Shared Mode and VRF Lite Mode, and how and when to use this design option.
We further went through some of the other industry solution like Palo Alto, F5 and Fortinet how to integrate to NSX-T, but further detailed blogs will updated soon.

In my next part we will discuss the strategy for V to T migration and go through some of the Service Provider scenarios.

Thanks for visiting the blogs and would like to thank Feature Friday team series for sharing awesome contents Happy Learning !