saudmalik
Contributor
Contributor

NSX design with cisco UCS/Fabric Interconnects and Nexus switches

Jump to solution

Hi Experts,

I am new to NSX designing and deployment and working on a project. we are deploying NSX for 4 tier applications (web, app, db, domain-controller). I will be using logical switches, DLR, ESG and DFW. I have following confusions. we are planning to use static routes.

1. do we span all the vlans from virtual to physical environment? e.g. mgmt vlans, tier vlans(web,app,db), vxlan transport vlan, or it should be specific vlans only?  which means would i be configuring all the vlans in NSX environment in my physical switching environment?

2. vds? do we create only 1 vds initially during vcenter deployment or more? Do we have to take any special considerations while deploying for NSX deployment?

3. Static routes- we are configuring static routes on the DLR and ESG? Should I use default routes upstream? on the physical router should we be routing all the virtual environment subnets to ESG.

4. Where and who should create VMs? Via NSX OR vCenter before nsx deployment?

5. We have a Domain controller tier. Should it be part of 3 tier apps or separate with allow any any rule on DFW?

Thanks,

Sam

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
cnrz
Expert
Expert

1) The Vlans that exist for Physical Machines  extend to the NSX VXLAN Logical Switch in the following cases:

  • If in the Current deployment there are Physical Machines in the same Vlan and IP Subnet with Virtual Machines. If this common Vlan Port Group is Migrated to a VXLAN Backed Logical Switch Port Group and not possible to change the IP addresses of the VMs, then a Bridged DLR (Distributed Logical Router) functions as the conversion point between Physical Vlan and Virtual VXLAN
  • If P-to-V Conversion of the Physical Machines Continue for this Vlan

Vlans that cover only VMs, or the Vlans that cover only the Physical Machines don't need to be extended.

2) For the NSX Deployment, there may be more than 1 dVS or only 1 vDS depending on the design. There may be other type of traffic other than VXLAN based VMs  such as Backup, Storage, Management, VMotion and the general design best practices apply here as well.  One requirement of NSX is a common VDS that spans the entire Cluster. For every Cluster this "common VDS" may be different. Again this VDS may be a seperate VDS dedicated for VTEP Functionality, or VTEP Functionality may be added to the existing VDS. It may be better to seperate the VTEP vDS.

3) For the DLR, generally a default gateway is sufficient. If static routes are used, then the ESG needs default route upstream, and static routes with next-hop of DLR downstream for the Subnets of the Logical Switch VM IP Subnets. On the Physical Router static route to the VM Subnets, as well as DLR-ESG Link Logical Switch Subnet is needed. Management of Static routes is easier if route summarization is possible, or if non contigous IP Subnets need to be used, then it may be a good idea to use dynamic routing protocol such as Ospf or BGP. There are also IP Address Management functionality in Vrealize and other IPAM solutions if automation is needed for big and dynamic environments.

4) NSX has no functionality in VM Creation, it only creates Network Services as Switches, Routers, Firewalls, Load Balancers. The VM Creation part continiues the same way as before. One point to note may be the Logical Swithes created appear as VXLAN Named port Groups on the VDS. NSX Manager creates port groups on the VDS, only difference is the Name includes VXLAN. The VM is as before added to this VXLAN Backed Port group from the Settings, or added to the  Logical Switch from the NSX Manager  GUI that again  appears as a Plugin for VCenter. So VCENTER is the point to Create the VMs and add these VMs to the Logical Swithes.

5) Domain Controller tier may be a seperate tier, or one other tiers, may be better to put seperate tier other than 3 Tier Apps. Generally it is the same design without NSX. dFW Rules may help to protect the Domain controller with only allowing ports  from the VM or Physical Machines being allowed. dFW Rules may be applied to VXLAN based NSX logical switches as well as VLAN based DVS Port groups since it is kernel module.

View solution in original post

0 Kudos
1 Reply
cnrz
Expert
Expert

1) The Vlans that exist for Physical Machines  extend to the NSX VXLAN Logical Switch in the following cases:

  • If in the Current deployment there are Physical Machines in the same Vlan and IP Subnet with Virtual Machines. If this common Vlan Port Group is Migrated to a VXLAN Backed Logical Switch Port Group and not possible to change the IP addresses of the VMs, then a Bridged DLR (Distributed Logical Router) functions as the conversion point between Physical Vlan and Virtual VXLAN
  • If P-to-V Conversion of the Physical Machines Continue for this Vlan

Vlans that cover only VMs, or the Vlans that cover only the Physical Machines don't need to be extended.

2) For the NSX Deployment, there may be more than 1 dVS or only 1 vDS depending on the design. There may be other type of traffic other than VXLAN based VMs  such as Backup, Storage, Management, VMotion and the general design best practices apply here as well.  One requirement of NSX is a common VDS that spans the entire Cluster. For every Cluster this "common VDS" may be different. Again this VDS may be a seperate VDS dedicated for VTEP Functionality, or VTEP Functionality may be added to the existing VDS. It may be better to seperate the VTEP vDS.

3) For the DLR, generally a default gateway is sufficient. If static routes are used, then the ESG needs default route upstream, and static routes with next-hop of DLR downstream for the Subnets of the Logical Switch VM IP Subnets. On the Physical Router static route to the VM Subnets, as well as DLR-ESG Link Logical Switch Subnet is needed. Management of Static routes is easier if route summarization is possible, or if non contigous IP Subnets need to be used, then it may be a good idea to use dynamic routing protocol such as Ospf or BGP. There are also IP Address Management functionality in Vrealize and other IPAM solutions if automation is needed for big and dynamic environments.

4) NSX has no functionality in VM Creation, it only creates Network Services as Switches, Routers, Firewalls, Load Balancers. The VM Creation part continiues the same way as before. One point to note may be the Logical Swithes created appear as VXLAN Named port Groups on the VDS. NSX Manager creates port groups on the VDS, only difference is the Name includes VXLAN. The VM is as before added to this VXLAN Backed Port group from the Settings, or added to the  Logical Switch from the NSX Manager  GUI that again  appears as a Plugin for VCenter. So VCENTER is the point to Create the VMs and add these VMs to the Logical Swithes.

5) Domain Controller tier may be a seperate tier, or one other tiers, may be better to put seperate tier other than 3 Tier Apps. Generally it is the same design without NSX. dFW Rules may help to protect the Domain controller with only allowing ports  from the VM or Physical Machines being allowed. dFW Rules may be applied to VXLAN based NSX logical switches as well as VLAN based DVS Port groups since it is kernel module.

View solution in original post

0 Kudos