Skip to content

NCD – Navisite Cloud Director Network Topology Considerations

← NCD – Networking

This article provides an overview of common network configurations in Navisite Cloud Director® (NCD), including explanations of virtual datacenter (vDC) and virtual application (vApp) network implementations, and the implications of each on capabilities and services in customer environments.

Note: The IP addresses included in this article are included for example purposes only. Your IP addressing schemes and implementations will vary.

Navisite Cloud Director Network Types

NCD features two types of networks:
  • vDC networks – A vDC Network (or Organization vDC network) is a virtual network that exists at the vDataCenter level, and is accessible from vApps and virtual machines (VMs) within that vDC. Refer to About vDC Networks for more information.

  • vApp networks – A vApp Network is a virtual network that exists at the vApp level, and is available to all VMs within that vApp. Refer to About vApp Networks for more information.

vDC Networks

vDC networks are typically configured to be connected to a higher-level external network to connect to the internet, or they may be "isolated," only connecting vApps and VMs together without providing outside access.

Note: An isolated vDC network provides no connectivity outside of the network. It only connects its own vApps (and their VMs) together. Refer to Identifying Isolated Networks for more information.

Each vDC network is connected to an Edge Gateway (EGW), a virtual networking device, which can provide Load Balancing, Network Address Translation (NAT), Firewall, Virtual Private Network (VPN), and Static Routing capabilities.

 

The EGW devices that host vDC networks are configured with 10 virtual Network Interface Cards (vNICs), which limits them to 10 hosted networks. Typically one of the available networks is used to provide access to the public internet, leaving 9 remaining for use within NCD.

vDC Networks are created as stand-alone entities in NCD and exist outside the framework of vApp containers – although vApp containers can be configured to link to a vDC network. Because vDC networks exist independently, they can be configured prior to the introduction of vApps into the environment.

View companion articles on how to create and edit a vDC network.

vDC Networks and Zerto

vDC networks are ideal configurations for the use of Zerto's disaster recovery or migration services. Because vDC networks exist outside of a vApp container, you can pre-configure network rules before migration, easing the migration process. Zerto does not move networking rules, so it does not gracefully transport vApp network configurations.

vApp Networks

vApp Networks are created in conjunction with a vApp, and exist only within the framework of the vApp container.

A vApp is a logical container for virtual resources. A vApp can contain VMs (virtual machines), networks, and networking rules.

Each vApp network is connected to a virtual gateway networking device. These gateway devices provide NAT, firewall, and static routing capabilities, and are generally considered to be NAT Firewalls.

 

vApp networks are not ideal for hosting servers that do not perform well behind a NAT firewall, like a Microsoft® Active Directory®.

vApp networks do not have access to the public internet. They require a vDC network connection and NAT rules in order to access the web.

View companion articles on how to create and edit vApp networks.

vApp Networks and Zerto

vApp networks are not ideal for use with Zerto's disaster recovery or migration services. While Zerto may migrate the VMs in a vApp network, it cannot migrate network rules associated with a given vApp network. Extra steps are necessary (whether manual or automated) in order to migrate vApp network rules.

Network IP Address Ranges

New NCD users may fail to understand that each vApp network contains its own virtual gateway device, which makes NAT rules, firewall rules, and static routing possible. It’s therefore important to remember that vDC networks and vApp networks are separate entities, and should be configured with entirely different IP address ranges.

Configuring connected vApp and vDC networks with identical IP address ranges will prevent their network routing devices from determining a destination network for traffic.


Segregating Networks

The following illustration represents a network architecture that is ideal for segregating networks within NCD:



This configuration focuses on permitting network traffic from the internet to vDC Network A, while preventing traffic originating on vDC Network A from traveling to vDC Network B.

Other details include:
  • vDC Network A is configured to allow traffic to travel to and from the public internet.

  • vDC Network B is configured to only allow traffic to travel to the public internet.

  • Because vDC Network A accepts network traffic sourced from the public internet, it is considered a security risk. Networks that are security risks are often called "DMZ" networks.

  • Because vDC Network B does not allow network traffic sourced from the public internet, it is not considered a security risk.

  • In order to maintain the safety of vDC Network B, access rules are used to deny traffic from vDC Network A to vDC Network B. However, traffic from vDC Network B to vDC Network A is allowed.
The use of two (or more) vDC networks in this type of network architecture is an ideal solution in NCD when network segregation is required. In the example configuration above, any "high risk" VM providing public internet access should be placed on vDC Network A. Examples of VMs considered "high risk" include servers hosting public web pages, servers providing file transfer and storage services, or servers supporting remote access.

VMs providing public internet services are considered "high risk" because they present a more obvious target for hackers, viruses, and malware.

Lower-risk VMs may need to interact with the high-risk VMs (for example, to harvest data from a VM that is hosting a web site). To keep the VMs on vDC Network B as secure as possible, networking rules can be configured to allow traffic originating from the safer network (vDC Network B) to travel to the less secure network (vDC Network A), but to disallow traffic initiated at Network A from traveling to Network B.

By allowing only traffic initiated from the more secure network between the two networks, the ability of any malware/viruses/hackers present on the non-secure network to access valuable resources on the more secure network is limited. This network architecture also limits the number of resources exposed to the public internet.

The steps required to configure such a network architecture for the purpose of segregating a "DMZ" network are detailed below:
  1. Create vDC networks A and B within the NCD environment.

  2. Create two vApps, with connections to vDC networks A and B, respectively.

    As part of the vApp creation process, you must create at least one VM. In order to configure the correct network architecture, link the vApp directly to its parent vDC network, and delete the default vApp network (named "VM Network") created by NCD.

  3. Add additional VMs to the newly created vApps, as necessary.

  4. Configure a firewall rule preventing traffic sourced from vDC Network A from accessing vDC Network B, as illustrated in the example diagram above. Using the example IP addressing scheme, the following firewall rule can be created to accomplish this:



  5. Configure public network behaviors for the VMs on network A that require them (e.g., configuring public internet (https) access on a web server).

Configuring a Network for Zerto Virtual Replication

Zerto Virtual Replication (ZVR) allows you to automatically and continuously replicate application data and virtual machine (VM) images, as well as system configurations and dependencies, in order to facilitate disaster recovery.

ZVR accomplishes this by replicating VMs contained within defined Virtual Protection Groups (VPGs) to dedicated disaster recovery virtual applications (vApps) within Navisite Cloud Director.

A vDC network is ideal for use with Zerto's disaster recovery and migration services because the recovery site vDC network can be preconfigured in NCD before migrating the protected site’s vApps into the recovery environment.



Configuring Zerto replication involves creating a recovery site vDataCenter and accompanying vDC network to serve as the destination for protected resources in the event of a failover.

With the recovery site vDC network in place, pre-configuring network firewall and NAT rules at the recovery site prepares the recovery site for the incoming Zerto resources. Configuring Zerto replication (either between NCD datacenters or between an on-premise datacenter and NCD) completes the process.

Note: Customers replicating from an on-site environment to NCD must first request Zerto replications via NCD. A configured VPN or ELAN connection between sites to accommodate Zerto replication data is also required.

For more information on configuring Zerto replication, see NCD-to-NCD Zerto Replication Tutorial and Customer-to-NCD Zerto Replication Tutorial.


Feedback and Knowledge Base

(thinking…)