Video Tutorial - Introducing Common Network Architectures in Navisite Cloud Director (NCD)
Audio Transcript: Introducing Common Network Architectures in Navisite Cloud Director (NCD)
Hello everyone and welcome! My name is Hannah Warren. I’m here today for Navisite, giving a brief demonstration of our Navisite Cloud Director (or NCD) platform, which you can access through the Proximity login portal.
Quick note about today’s tutorial: this is a general-level tutorial with our product in its current iteration. If you have specific questions or issues with your environment, please make sure you contact our Customer Service department.
For a more detailed tutorial, please visit our Knowledge Base, which is linked on the screen (http://navisite.uservoice.com) and also in the video description below.
And with that, we’ll get started!
For the purposes of this demonstration, we will examine vDC and vApp Networks, discuss what they are, and compare and contrast them.
You may also have heard of “North/South versus East/West” network architectures during your career. In this video we will bring those concepts into some context in NCD.
First, we’ll review a few pre-configured networks using NCD’s network view, which you can find by clicking the left navigation menu item “Views” and selecting “NCD Network.”
In the Network view, you can see that we have a total of three networks configured in our Woking vDataCenter. The first network we’ll discuss is a stand-alone vDC Network – “VDC-1.”
Looking at the diagram, you can see the network is connected to an edge gateway device that provides access to the public internet. The network is also configured to host an internal network, 10.10.11.0 /24.
One thing you’ll want to remember: Virtual edge gateway devices in NCD have a maximum 10 virtual NICs associated with them. Therefore, you’re limited to hosting 9 networks on an edge gateway, because one of the NICS is used right away for accessing the public internet. In the example shown here, we have 3 virtual NICs in use – one for the public internet connection, one for VDC-1, and one for the Woking Default vDC Network.
So, in this scenario there are 7 remaining NICs available for hosting additional networks.
The EGW device provides us with a variety of network services, which we can view by clicking on the edge gateway for our network, which takes us to the vDataCenter detail page.
And once we minimize the Edge Gateway section, we can scroll and see we have the ability to configure firewall rules and NAT rules for our network. In addition, load balancing can be configured, along with defining static routes. Edge gateways can also be set up for VPN.
vDC Networks are defined at the vDC organization level and exist independently of other NCD resources. As such, they can be pre-configured for vApps to be connected to them later on.
Here we are back at the network diagram view, and we’re going to zoom in on the second vDC network we’ve preconfigured for this example – “Woking Default vDC Network.”
This particular vDC network has a vApp network attached. Before we dive into the vApp network details, let’s revisit the directional concept we mentioned earlier.
These two vDC networks – VDC-1 and the Woking Default vDC Network – are both using NICs on our edge gateway. This is similar to hosting two networks on separate ports on a physical networking device. So, this would be an example of an East/West networking architecture.
Because they’re East/West, we can use Firewall rules to control traffic flows between the two networks.
In contrast, the vApp network pictured here is not directly connected to the public internet, but it is connected to a vDC network - Woking Default vDC, or 10.10.4.0/24. Because of this connection, VMs within the vApp can gain access to the public internet through the use of NAT rules. This will give VMs on the lower vApp network translated addresses on the top-level vDC network.
All this is an example of a “North/South” network architecture.
Note that a vApp network does not necessarily have to be connected to a vDC network at all. But, if it has no connection to any vDCs, the vApp network is considered isolated.
A vApp network (which NCD names “VM Network” by default) is created in conjunction with vApp containers and only exists in the context of a vApp container. The vApp network is hosted behind its own separate gateway device, and provides a handful of network services.
Unlike vDC networks, vApp networks can only exist inside vApp containers. Because of this, vApp networks cannot be configured before the vApp itself exists. This is in contrast to vDC networks, which are standalone entities and can be preconfigured.
Looking at the vApp Network detail page, we have the ability to configure NAT, Firewall, and static routing. Unlike vDC networks though, load balancing and VPNs are not supported.
The VMs on a vApp network have pre-configured NAT rules – a default feature provided in NCD - to automatically configure a VM to have access to the public internet.
That wraps up this video installment. Thanks for tuning in to this demonstration in NCD. As always, we’d appreciate your feedback! If you found this video helpful or have ideas for videos in the future, we do source those from comments on our content, so don’t hesitate to share your thoughts with us. You can follow our YouTube channel for future videos, and there are 24/7 detailed demonstrations with screenshots and step-by-step “How To”s at our knowledge base: https://navisite.uservoice.com/knowledgebase
Thanks for tuning in. I’m Hannah Warren, and I’ll see you next time!
Thanks for tuning in. I’m Hannah Warren, and I’ll see you next time!