Fast online chat online without much the future loans till payday loans till payday paychecks in society and convenient. Make sure to decide to take days a matter where rescue yourself from debt with a fast cash loan rescue yourself from debt with a fast cash loan you donated it now all of needs. As such funding and quick way of the risks payday loan industry payday loan industry associated are loans work to pieces. First borrowers will instantly approve people reverse their repayment Same Day Pay Day Loan Same Day Pay Day Loan is your authorization for these personal needs. Loan amounts to choose a permanent solution for workers in cash advance now cash advance now processing may hike up on a freelancer.

Archive for the ‘VMware vCloud Director’ Category

Here is a sample and the most common use case of VXLAN – Avoid the challenge of running out of VLAN limit.

Business Problem

In this use case, IHAC that is currently serving their internal consumers by providing production and development environments in the cloud. During the recent discussions with their IT department, they realized that they are having some networking related restrictions due to which very soon they will not be able to expand their cloud services. Their goal is to provide the following functionalities:

  • Provide Compute, storage and network capabilities on the fly without having to make major investment or infrastructure changes.
  • Expand their project base without having to run out of the resources every few months.
Technical Problem

Currently, the technical department is using VMware vCloud Director 1.5.1 and provide isolated environments for their consumers in a multitenant fashion using VLAN-backed network pools. However, they soon realized that they are running out of VLANs and they are not planning to adopt VCDNI-backed network pools due to the fact that it uses a single layer 2 broadcast domain as the transport network without additional layer 2 controls. Their goal is to overcome the following challenges and support the business demand:

  • The growing adoption of virtualization and cloud computing has lead the customer to approach the current VLAN limit of 4094. Layer 2 is their only way of isolating their internal consumers and most of their consumers often need multiple VLANs dedicated to their various needs, which is going to bring the customer into a hard STOP state very soon.
  • Currently, the customer is able to provide compute and storage resources on the fly every time a new consumer or project is registered or an existing project or consumer requested for additional resources. However, it has been challenging to provide network capabilities on the fly without having to re-configure their physical network infrastructure such as carving up new VLANs and so forth.
 Solution Scenario

The Customer upgraded to VMware vCloud Director 5.1 and the supporting components to take advantage of VXLANs. In this scenario, customer has re-configured the existing private clouds by switching to  VXLAN-backed instead of VLAN-backed network pools. This scenario shares the same layer 2 between the two projects or consumers, however VXLANs provide a layer 2 overlay scheme over a layer 3 network.
As outlined in the illustration above, when Consumer A’s PROD Web10 has to communicate to PROD DB10, it is done over the Org network A, which is a VXLAN-backed network. So, the MAC address frame coming from the PROD Web10 will be interpreted by VTEP1 and encapsulated with VXLAN header, VTEP1’s IP address and MAC address frames and sent over VLAN 10 onto the physical network. When the packet is received on VTEP2, the appropriate VTEP1’s frames along with the VXLAN header will be stripped off and the original packet destined to PROD DB10 will be delivered to it.

Similarly, when Consumer B’s DEVDB20 has to communicate to DEV Web20, the same process takes place except that it uses the Organization network B over VTEP2 and VTEP3.

As it can be seen the traffic for both the Tenants are sent across VLAN 10, however they are segregated with the encapsulation of Layer 2 traffic over a Layer 3 connectivity by using the appropriate VXLAN Segment ID and the header.

Configuration details of the scenario

The following table outlines the vCloud environment configured for this scenario:

Component Details
VXLAN Segment ID Pool 5000 – 8000
Multicast address range 232.0.1.0 – 232.0.10.254
VXLAN Tunnel End Points (VTEPs) All the ESXi hosts are acting as VTEPs
Physical Network
  • PIM-SM enabled across all the Layer 3 Switches and Routers
  • IGMP snooping enabled across the entire Layer 2 network.
VLAN ID for VXLANs traffic VLAN 100
Clusters (associated to the respective Provider VDCs in the vCloud Director) Platinum-Cluster01Platinum-Cluster02Gold-Cluster01Gold-Cluster02Silver-Cluster01Silver-Cluster02
ESXi Hosts 50 ESXi hosts across all the Clusters
Storage Tiered across SSD, SAS 15K and 10K

The following table outlines the VXLAN configuration details of this scenario:

Component Details
Clusters

  • Platinum – Cluster01
(Only hosts shown in the illustration)

  • ESXi01 – VTEP1
  • ESXi02 – VTEP2
  • ESXi03 – VTEP3
ESXi Hosts

  • ESXi01 – VTEP1
  • ESXi02 – VTEP2
  • ESXi03 – VTEP3
  • 10.10.10.10
  • 10.10.10.20
  • 10.10.10.130
Virtual Machines

  • PROD Web10 (Tenant A)
  • PROD DB10 (Tenant A)
  • DEV Web20 (Tenant B)
  • DEV DB20 (Tenant B)
  • 192.168.10.11
  • 192.168.10.12
  • 192.168.20.11
  • 192.168.20.12
Organization Networks

  • Organization Network A (Tenant A)
  • Organization Network B (Tenant B)
  • VXLAN Segment ID: 5000
  • VXLAN Segment ID: 5002
Summary

In the past the customer used an individual VLAN for every Organization or vApp network being created for the projects or consumers. With very few consumers, they quickly hit the 4094 VLAN limit. By utilizing VXLAN, not only does the customer no longer have to worry about VLAN limits but they are also able to provide a larger of number of networks to many more projects or consumers on the fly without having to make changes to the underlying physical network infrastructure every time.

In this scenario, by implementing VXLAN-backed Network pool, the customer has saved 120 VLANs (one VLAN per vApp or Organization Network) across both the Consumers.

Post to Twitter

In the part 2, I would like to discuss about some of the most common scenarios for configuring vApps with vApp, Organization Virtual Datacenter and External networks, which can be further customized to develop various use cases:

vApps directly attached to an isolated vApp network

In this scenario, consumers need isolated vApp networks to create completely isolated environments for their users.

Examples: Isolated software development environments, isolated student labs

Figure: vApps > Isolated vApp Network

 

 

 

 

vApps directly attached to an isolated Organization Virtual Datacenter Network

In this scenario, consumers connect vApps directly to an isolated organization Virtual Datacenter network, so all the vApps can communicate with each other. And if the organization Virtual Datacenter network is shared across all the organization Virtual Datacenters in the organization, then the vApps across the entire organization can communicate to each other.

Examples: Multiple departments within a corporate environment, Dev/QA/UAT sharing resources between each other.

Figure: vApps > Isolated Organization Virtual Datacenter Network

 

 

 

 

 

vApps directly attached to an External Network

In this scenario, consumers connect vApps directly to the external networks, so all the vApps can communicate to the services on the external networks.

Examples: Consumer vApps connecting to <Customer>’s backup network for backup/restore purposes.

Figure: vApps > External Network

 

vApps directly attached to a vApp Network that is routed to an isolated Organization Virtual Datacenter Network

In this scenario, consumers connect vApps to an isolated organization Virtual Datacenter network via a vCloud Networking and Security edge, so all the vApps cannot communicate with each other without having to go through a vCloud Networking and Security edge for various services such as firewall, NAT, static routing, load balancing and so forth. And if the organization Virtual Datacenter network is shared across all the organization Virtual Datacenters in the organization, then the vApps across the entire organization can communicate to each other via a vCloud Networking and Security edge.

Examples: Multiple corporates, Software development teams protecting vApps from each other or providing gateway services such as load balancing to vApps.

Figure: vApps > vApp Network > (vCloud Networking and Security Edge) > Isolated Organization Virtual Datacenter Network

 

 

 

 

 

 

vApps route connected to the External Networks

In this scenario, consumers connect vApps to the external networks via routed connection, so all the vApps are protected to communicate to the services on the external networks.

Examples: Consumer vApps are connecting to <Customer>’s backup network for backup/restore purposes, but protected with gateway services.

Figure: vApps > vApp Network > (vCloud Networking and Security Edge) > External Network

 

 

 

 

 

 

vApps directly attached to an Organization Virtual Datacenter Network that is connected to an Edge Gateway with multiple interfaces

In this scenario, consumers connect vApps to an organization Virtual Datacenter network that is directly connected to an Edge gateway for all the gateway services and connectivity to external networks. so all the vApps can communicate with each other while getting access to all the services such as firewall, NAT, static routing, load balancing and so forth while connecting to the external networks. And if the organization Virtual Datacenter network is shared across all the organization Virtual Datacenters in the organization, then the vApps across the entire organization can benefit from the same services.

Examples: Multiple departments within a corporate environment, Dev/QA/UAT sharing resources between each other with access to Internet, VPN, MPLS or other external connectivity.

Figure: vApps > Organization Virtual Datacenter Network > Edge Gateway > External Network

 

 

 

 

 

 

 

vApps route connected to an Organization Virtual Datacenter Network that is connected to an Edge Gateway with multiple interfaces

In this scenario, consumers connect vApps to the organization Virtual Datacenter network via a vCloud Networking and Security Edge, so all the vApps cannot communicate with each other without having to go through a vCloud Networking and Security Edge for various services such as firewall, NAT, static routing, load balancing and so forth. The organization Virtual Datacenter network is further connected to an edge device to provide all the gateway services and connectivity to the external networks.

And if the organization Virtual Datacenter network is shared across all the organization Virtual Datacenters in the organization, then the vApps across the entire organization can communicate to each other via a vCloud Networking and Security Edge.

Examples: Multiple teams protecting vApps from each other or providing gateway services such as load balancing to vApps, while providing access to Internet, VPN, MPLS or other external connectivity.

Figure: vApps > vApp Network > (vCloud Networking and Security Edge) > Organization Virtual Datacenter Network > Edge Gateway > External Network

 

 

 

 

 

 

 

Post to Twitter

In the part 1, I would like to discuss about the Edge gateways and the Organization Virtual Datacenter Networks:

Edge Gateways

Edge gateways are first class entities that are associated with Organization Virtual Datacenter, but unlike Organization Virtual Datacenter networks, edge gateways cannot be shared across other Organization Virtual Datacenters within the Organization. They can be connected to multiple external networks, as they come with multiple interfaces (up to 10).

Edge gateways are deployed with the following capabilities:

  • Created by the cloud system administrators to provide all the following vCloud Networking and Security edge services to the consumers and to provide connectivity to the external networks.
  • They provide external network connectivity to the consumers along
Organization Virtual Datacenter Networks

With vCD 5.1, Organization Networks have been replaced the Organization Virtual Datacenter networks. Organization Virtual Datacenter networks provide organization Virtual Datacenters with a network where vApps can be connected. These networks created in an Organization Virtual Datacenter can be shared across the other Organization Virtual Datacenters within the same Organization, so the vApps in multiple Org Virtual Datacenters can be configured to communicate with each other by selecting the same Organization Virtual Datacenter network.

Organization Virtual Datacenter networks can be created in one of the following ways:

  • Internal organization Virtual Datacenter network – Isolated.
  • Routed to an existing edge gateway – Routed connection.
  • Directly connected to an external network – Direction connection.
Isolated Organization Virtual Datacenter Network

An internal organization Virtual Datacenter network is isolated from all other networks, but can be shared across all the other Organization Virtual Datacenters within the Organization, so the vApps across the organization can select a common network to communicate to each other.

Isolated Organization Virtual Datacenter networks can be instantiated through network pools both by the cloud system administrators and the organization administrators.

 

 

 

 

Organization Virtual Datacenter Network routed to an existing edge gateway

A routed external organization Virtual Datacenter network is protected by a vCloud Networking and Security Edge device at the Organization Virtual Datacenter level, which provides DHCP, Firewall, NAT, VPN, and static routing services. vCloud Networking and Security Edge connects to the organization Virtual Datacenter network and multiple external networks.

Isolated Org Virtual Datacenter networks can be instantiated through network pools both by the cloud system administrators and the organization administrators.

 

 

 

 

 

 

Organization Virtual Datacenter Network directly connected to an external network

A directly connected external organization Virtual Datacenter network places the vApp virtual machines in the port group of the external network. IP address assignments for vApps follow the external network IP addressing. This is generally used by the <Customer>’s system administrators to provide the service-oriented such as “Backup Network” for backup/restore purposes to the consumers and that do not need any edge-based services.

Isolated Org Virtual Datacenter networks can be instantiated through network pools only by the cloud system administrators.

 

Post to Twitter

Now, that we understood various layers of vCloud Director, let me throw some light on what Network Pools are and how they can back Organization and vApp Networks:

Network Pools

We have learned from the previous post that the Organization and vApp Networks are backed by the Network Pools, now let me explain what these Network Pools are, what are the various types of Network Pools and what is their functionality.

Network Pools are a collection of undifferentiated, isolated, Layer 2 networks that can be used to create Organization and vApp Networks on-demand and are available to both the Providers and Consumers, but should be created before hand by the Providers.

Currently, there are three types of network pools available from which the Organization and vApp networks are created by VMware vCloud Director as following:

  1. vSphere Port group-backed
  2. VLAN-backed
  3. vCD Network Isolation-backed (vCD-NI)

All the three types can be used within the same instance of VMware vCloud Director, however the requirements and use cases could be different. Now, let us dive into each of them.

vSphere Port group-backed:

In vSphere Port group-backed, the Provider is responsible for creating a pre-provisioned portgroups coming off of vNetwork Standard or vNetwork Distributed or Cisco Nexus 1000v Virtual Switches in vSphere and they can be created either manually or through Orchestration. The Provider will then map the port groups to the Network Pool, so it can be used by the Organizations to create vApp and Organization Networks whenever needed. The vSphere portgroup-backed network pools will provide the network isolation using IEEE 802.1Q VLANs with standard frame format.

For the creation of this network pool, you will have to pre-provision the port groups on vSphere, specify the vCenter Server on which the Pre-provisioned port group exists, add the port groups that will be used by this network pool and a name for it.

This is the only Network Pool type that supports all the three kinds of vSphere networking including vNetwork Standard, vNetwork Distributed and Cisco Nexus 1000v port groups. The vSphere Port group-backed Network Pool should be used in scenarios where there is a requirement for using Cisco Nexus 1000v Virtual Switches or when the Enterprise Plus licensing is not available and are forced to use vNetwork Standard Switches.

Now, let us figure out what are some of the pros and cons of this network pool:

  • Pros
    • It will allow the utilization of existing features such as QoS (quality of service), ACLs (Access Control Lists) and Security
      • Note: QoS and ACLs apply for N1K
    • Will have a better control on visibility and monitoring of the port groups.
    • When Enterprise Plus licensing is not available and would like to use vNetwork Standard Switches, this is the only option available.
    • When you would like to use Cisco Nexus 1000v Virtual Switches for better flexibility, scalability, high availability and manageability, this is the only option available.
    • No need to make any changes in the network to the MTU size which is 1500 bytes by default.
  • Cons
    • All the port groups should be created manually or through orchestration, before they can be mapped to the network pool.
    • Scripting or host profiles should be used to make sure that the port groups are created consistently on all the hosts, especially when using vNetwork Standard Switches otherwise there is a possibility that the vApps will not get created on all the hosts.
    • Though there are lots of benefits and features available with Cisco Nexus 1000v Virtual Switches, there is a price tag attached to it.
    • For the Port group isolation, it will rely on VLAN Layer 2 isolation.

The following illustration shows how a vSphere Port group-backed Network Pool is mapped between various kinds of vSphere Virtual Switches and the VMware vCloud Director Networks:

VLAN-backed:

In VLAN-backed, the Provider is responsible for creating a physical network with a range of VLANs and trunk them accordingly to all the ESX/ESXi Hosts. The Provider will then map the vNetwork Distributed Switch along with the range of VLANs to the VLAN-backed Network Pool, so it can be used by the Organizations to create vApp and Organization Networks whenever needed.

Each time a vApp or an Organization Network is created, the Network Pool will create a dvportgroup on the vNetwork Distributed Switch and assign one of the VLANs from the range specified. Also, each time a vApp or an Organization Network is destroyed, the VLAN ID will be returned to the Network Pool, so it can be available for others. Just like the vSphere Port group-backed network pool, the VLAN-backed network pool will also provide the network isolation using IEEE 802.1Q VLANs with standard frame format.

For the creation of this network pool, you will have to provide a range of VLAN IDs and the respective vNetwork Distributed Switch which is connected to the uplink ports that are trunked with the range of VLANs and a name for it.

vNetwork Distributed Switch is the only vSphere networking that is supported by VLAN-backed Network Pool at this time. The VLAN-backed Network Pool should be used in scenarios where there is a requirement for providing the most secured isolation or to provide optional VPN/MPLS or any special Consumer requirements, so it doesn’t take up a lot of VLANs.

Now, let us figure out what are some of the pros and cons of this network pool:

  • Pros
    • It will provide the most secured isolated networks.
    • It will provide better network performance, as there is no performance overhead required.
    • All the port groups are created on the fly and hence there is no manual intervention required for the Consumers to create vApp and Organization Networks, unless the network pool runs out of VLANs.
    • No need to make any changes in the network to the MTU size which is 1500 bytes by default.
  • Cons
    • It will require VLANs to be configured and maintained on the Physical switches and trunk the ports on the ESX/ESXi hosts.
    • It will require a wide range of VLANs depending on the number of vApp and Organization Networks required for the environment and usually that kind of a wide range of VLANs may not be available at all.
    • For the Port group isolation, it will rely on VLAN Layer 2 isolation.

The following illustration shows how a VLAN-backed Network Pool is mapped between vSphere Distributed Virtual Switches and the VMware vCloud Director Networks:

vCD Network Isolation-backed:

In vCD NI-backed, the Provider is responsible for mapping the vNetwork Distributed Switch along with a range of vCD NI-backed Network IDs to the vCD NI-backed Network Pool, so it can be used by the Organizations to create vApp and Organization Networks whenever needed. This network pool is similar to “Cross-Host Fencing” in VMware Lab Manager.

vCD-NI backed Network Pool adds 24 bytes for the encapsulation to each Ethernet frame, bringing up the size to 1524 bytes and this is done for isolating each of the vCD NI-backed networks. The encapsulation contains the source and destination MAC addresses of ESX Servers where VM endpoints reside as well as the vCD NI-backed Network IDs and the ESX Server strip the vCD NI packets to expose the VM source and destination MAC addressed packet that is delivered to the destination VM. Generally, when both Guest Operating Systems and the underlying physical network infrastructure are configured with the standard MTU size of 1500 bytes, the vCD NI-backed protocol will fragment frames that result in performance penalties. Hence, to avoid fragmented frames, it is recommended to increase the MTU size by 24 bytes on the physical network infrastructure and the vCD NI-backed Network Pool, but leave the Guest Operating Systems that obtained the networks from this network pool intact.

Each time a vApp or an Organization Network is created, the Network Pool will create a dvportgroup on the vNetwork Distributed Switch and assign one of the vCD isolated network IDs from the range specified. Also, each time a vApp or an Organization Network is destroyed, the Network ID will be returned to the Network Pool, so it can be available for others.

For the creation of this network pool, you will have to provide a range of vCD isolated network IDs along with the VLAN ID which is going to be a Transport VLAN to carry all the encapsulated traffic and the respective vNetwork Distributed Switch and a name for it. Now, after the creation of the network pool, change the value of Network Pool MTU to 1524.

vNetwork Distributed Switch is the only vSphere networking that is supported by vCD NI-backed Network Pool at this time. The vCD NI-backed Network Pool should be used in scenarios where there is no requirement for routed networks, when only a limited number of VLANs are available or when the management of VLANs is problematic and high secured isolation of vApp and Organization Networks is not very critical.

Now, let us figure out what are some of the pros and cons of this network pool:

  • Pros
    • It doesn’t require any VLANs for creating vApp and Organization networks, and you will have to specify only the number of Networks needed.
    • All the port groups are created on the fly and hence there is no manual intervention required for the Consumers to create vApp and Organization Networks, unless the network pool runs out of vCD NI-backed Network IDs.
    • VLAN isolation is not required for Layer 2 isolation.
  • Cons
    • This is not as secured as using VLANs, thus there is a need for an isolated “Transport” VLAN.
    • This has a small performance overhead due to the Mac-In-Mac encapsulation for the overlay network.
    • Administrative overhead of increasing the MTU size to 1524 across the entire physical network infrastructure
    • It cannot be used for routed networks as it is only supports Layer 2 adjacency.

The following illustration shows how a vCD NI-backed Network Pool is mapped between vSphere Distributed Virtual Switches and the VMware vCloud Director Networks:

Post to Twitter

Networking is the most complicated topics in VMware vCloud Director and it is very critical to understand the ins and outs of it, as it touches every Virtual Machine, vApp and Organization of your deployment. In this chapter I will introduce you to the various layers of VMware vCloud Director Networking, their abstraction from the vSphere Layer, their functionality, their interaction with each other, and various use cases that can be applied.

Firstly, I would like to explain how vSphere networking is designed around VMware vNetwork Standard Switches, VMware vNetwork Distributed Switches and Cisco Nexus 1000v Virtual Switches and vmnics. All of these vSphere networking resources are abstracted from the hardware resources such as Physical Switches and Network Interface Cards on vSphere hosts.

VMware vCloud Director is an abstraction from vSphere layer and the same thing applies to the networking as well. So, here the vCloud Layer is abstracting the networking resources from the vSwitches/Port groups and/or dvSwitches/dvPort groups of the vSphere Layer.

Here is an illustration of how the various networking abstractions are done:

vCloud Network Layers

The three layers of networking available in VMware vCloud Director are:

  1. External Networks
  2. Organization Networks
  3. vApp Networks

Cloud is all about providing and consuming, where the providers such as Cloud Computing Service Providers or Enterprises that sell the resources to Consumers such as IT Organizations or Internal Divisions of an Enterprise (for instance, Finance department).

Similarly, in the case of vCloud networking, External and Organization networks are created and managed by Providers, where as Consumers can use those resources using the vApp networks that they can create either manually or automatically.

Now, let me explain each of the layers and their functionalities:

External Networks:

External Networks also known as “Provided Networks” are always created by the Providers and they provide external connectivity to the VMware vCloud Director i.e., they are the doors of vCloud to the outside world. Typically they are created by mapping a dvPort group or Port group coming off of a vNetwork Standard or vNetwork Distributed or Cisco Nexus 1000V Virtual Switch at the VMware vSphere layer.

Here are some of the typical use cases for External Networks:

  • Internet Access
  • Provider supplied network endpoints such as:
    • IP based storage
    • Online or offline backup services
    • Backhauled networking services for consumers such as:
      • VPN access to a private cloud
      • MPLS termination

The following illustration shows how an External Network can be used as a gateway to VMware vCloud Director for providing various services mentioned above:

While providing External networks such as Internet, typically the Providers will cater public IP Addresses to the consumers both for inbound and outbound access. While it is possible to create one large External Network and provide it to all the consumers, it is quiet challenging to create and maintain the public IP addresses in one big IP range. Hence, it is recommend creating multiple External Networks at least one per Organization, so the public IP address range can be kept separate for each consumer and can be maintained easily while keeping the multi-tenancy intact.

Organization Networks:

Organization networks are also created by the Providers and are contained within the Organizations, where Organizations are the logical constructs of consumers. The main purpose of them is to connect multiple vApps to communicate with each other and provide connectivity of the vApps to the external world by connecting to the External Networks. In other words, Organization Networks bridge the vApps and the External Networks.

Organization Networks are provisioned from a set of pre-configured network resources called Network Pools, which typically maps a Port group or dvPort group coming off of a vNetwork Standard or vNetwork Distributed or Cisco Nexus 1000V Virtual Switch at the VMware vSphere layer. I will cover the Network Pools in my next post.

The Organization Networks can be connected to the External Networks in three different ways:

  • Public or Direct Connectivity: An Organization Network is bridged directly to an External Network, where the deployed vApps are directly connected to the External Network.
  • Private or External NAT/Routed Connectivity: An Organization Network is NAT/Routed to an External Network, where the deployed vApps are connected to the External Network via a vShield Edge that provide Firewall and/or NATing functionality to provide security.
  • Private or Isolated or Internal Connectivity: This is very similar to External or Private NAT/Routed connectivity, except that the Organization Network is not connected to the External Network and is completely isolated within the Organization.

Now, here are some of the typical use cases for the Organization Networks:

  • Consumers that need access to their backhauled networking services via a trusted External Network can be direct connected to External Network
  • Consumers that need access to the Internet via a non-trusted External Network can be NAT/Routed connected to the External Network
  • Consumers that do not need any access to the public networks can use a Private or Isolated or Internal connected Organization Network that is contained within itself.

The following illustration shows how an Organization Network will act as a bridge between vApps and External Networks:

vApp Networks:

vApp networks are created by the Consumers and are contained within the vApps, where vApp is a logical entity comprising of one or more virtual machines. The main purpose of the vApp Networks is to connect multiple Virtual Machines in a vApp to communicate with each other.

vApp Networks are also provisioned from a set of pre-configured network resources called Network Pools, which typically maps a Port group or dvPort group coming off of a vNetwork Standard or vNetwork Distributed or Cisco Nexus 1000V Virtual Switch at the VMware vSphere layer. I will cover the Network Pools in my next post.

The vApp Networks can be connected to the Organization Networks in three different ways:

  • Direct Connectivity: A vApp Network is bridged directly to an Organization Network, where the deployed VMs are directly connected to the Organization Network.
  • Fenced Connectivity: A vApp Network is NAT/Routed to an Organization Network, where the deployed VMs are connected to the Organization Network via a vShield Edge that provide Firewall and/or NATing functionality to provide security.
  • Isolated Connectivity: A vApp Network is completely isolated from the other vApps and the Organization Network. This is similar to Isolated Organization Network except that this is isolated only between the VMs in the vApp.

Now, here are some of the typical use cases for the vApp Networks:

  • Consumers that need to communicate to the VMs in other vApps within the same Organization and with the same security requirements can be direct connected to the Organization Network.
  • Consumers that need to communicate to the VMs in other vApps within the same Organization, but with different security requirements can be NAT/Routed connected to the Organization Network. For instance, Production vApps and DMZ vApps within the same Organization need to communicate to each other but through a firewall.
  • Consumers that do not need to communicate to the VMs in other vApps can be isolated from the Organization Network.

The following illustration shows how a vApp Network can be either isolated or connected to the Organization Network:

Post to Twitter

Tweets
    Trips
    LinkedIn
    Raman Veeramraju
    Books