November 4

Part 18: My vCloud Journey Journal – External Networks (including Dry Bones!)

3-layers-vCD-vSphere-Physical-CLEAN-COPY copy.png

If you have been following my series on “My vCloud Journey Journal” I’ve been gradually using various learning materials to familiarize myself with vCD 5.1. I’ve got to the part of the configuration where I need to configure my “external networks”. Compared to the other aspects of networking in vCD I think the external network is perhaps the easiest to get your head around. The trick I think is understand what’s meant by “external” – external to what? As I understand it an “external network” lies outside of the Organization vDC and that doesn’t necessarily have to mean the Internet. In multi-tenancy scenario it can just mean a network outside of the organizations that can be used to link organizations together. So you could see it as the “corporate backbone” or network. So despite the name you can setup access to an “external” network without necessarily giving VMs/vApps in the Organization access to the Internet. On their own external networks don’t really do anything until an Organizational vDC is created, and Organization network is created. Even then nothing much happens until vApps are created to gain access to the Organizational Network.

I’ve jokingly said the networking reminds me of the song “Dry Bones”. You know the one that goes:

The toe bone connected to the heel bone,
The heel bone connected to the foot bone,
The foot bone connected to the leg bone,
The leg bone connected to the knee bone,
The knee bone connected to the thigh bone,
The thigh bone connected to the back bone,
The back bone connected to the neck bone,
The neck bone connected to the head bone,
Oh, hear the word of the Lord!
I first heard the song watching Denis Potter’s “The Singing Detective” on BBC TV in the 80s. Back then I had a thing Joanna Whaley (who plays one of the nurses). I wonder why?

Ahem, anyway – I digress…
So in the case of vCD – the vApp Network connects to the Organization Network, and the Organization Network connects to the External Network. Each of these connection points are optional. So a vApp Network doesn’t have to be connected to the Organization Network (in fact they can be connected to the external network). In this respects it acts very much like an internal Standard vSwitch (where no VMnics have been attached). But if you wanted communication to the outside world (outside the domain of the Organization) it would be not uncommon to have them linked together.

Now it’s true that an “External Networks” most common use to gain access to the outside world – the Internet. But I can be also used to gain access to a network outside the domain of the Organization. In my case the fictitious holding company “Corp, Inc” contains three other business which may or may not need access to one of another. It’s the part of the networking layer that’s probably the most static and stable – unlike the networking that takes place within an Organization that is much more dynamic and flexible. There are some other case where “external networks” are used to access resources which outside of the “Organization” but reside on your private network. For example you might need to use an external network to access an IP based storage network, and use that present storage directly into the VM – I’m thinking of cases where its preferable for VM to mount an NFS share or run its own ISCSI initiator to access storage. Another example might be if you are running some type of backup agent within the VM, and the VM needs to access a backup system which resides outside of the Organization. There two usage cases which I hadn’t thought about – and that could be VPN access via an external network to a public cloud or using an external network to bridge two sites together using a stretched-VLAN configuration or MPLS (multi-protocol label switching”. The interesting thing about this last example is how frequently the official literature recommends all the “resource groups” (or clusters used to run VMs/vApps created via vCD) to be within the same physical location. Clearly, I think some of the documentation was written before the idea of stretched clusters/sites were in vogue or common place.

These “external networks” are built of the back of vSphere portgroups on the Distributed vSwitch (but you can use Standard vSwitch and Cisco N1000V port backed portgroups” if you wish. It’s entirely feasible to have multiple external networks if you so wish. In my case I have two – one that give access to the Internet, and the other issued for the corporate network backbone. To have multiple external networks each portgroup must point to a different VLAN on the switch. In my case I have two switches – one dedicated to vSphere/vCloud Suite management, and the other used by tenants. So these “external” portgroups must be setup first with the correct VLAN configuration (in most case I assume folks will use our support 802q. VLAN Tagging). To confirm your VLAN configuration on the portgroups using the web-client you can navigate to >Networking >Your Datacenter >Right-Click your portgroup and select Edit Settings.

Screen Shot 2012-11-01 at 14.51.16.png

Creating an external network is relatively easy process but some of the options need a little bit of clarification and are really dependent on understand how they are used by Organization Network. It’s possible for an Organization Network to be directly connected to the External Network. Let say the External Network has an IP range of 192.168.3.0/24, this would be mean the Organization would have to use the same range of IPs. However, if the Organization is connected via vCNS Edge Gateway (the artist formerly known as vShield Edge!) then a NAT/Routed connection can be made. This automatically creates a vCNS Edge Gateway instance for the Organization and allows the IP’s within the Organization to be something else (say 192.168.4.0/24), and the Edge Gateway uses just one single IP to broker access to the external network. For that reasons when your creating an external network your asked to provide a pool of IP address VMs that might connection directly to the External Network via the Organizaation Network. The alternative would be that every VM within Organization would need to be manually configured for an static IP address.

Note: In fact there many different permutations to the Organization network. So many I’m going have to leave that for another blogpost.

You can kick of the creation of new “External Network” from the “3. Create an External Network” option on the vCD Welcome Page or alternatively, you can select the “Manage & Monitor” tab and in >Cloud Resources >External Networks click the + Button to add a new external network. You start of the process of creating a new external network, by selecting a vSphere portgroup that will back it.

Screen Shot 2012-11-01 at 15.17.05.png

In my case both the Gold & Silver Clusters have access to the same Distributed vSwitch – and are the clusters that back the Gold Provider Virtual Datacenter and the Silver Datacenter. That might not always be the case. It could be that the Gold Cluster and the Silver Cluster each have their own discrete connection to the external network. In that case we would need two external networks created – one for Gold and one for Silver. As you can see “External Networks” are very much a resources associated with the Provider vDC (mine are called the Gold/Silver Virtual Datacenter) – in contrast Organizations are associated with “Network Pools” from which Organization Networks and vApps networks are dynamically created.

You will see this for example if you created a brand new cluster in vSphere with new servers – perhaps you would call this the “Platinum” Cluster, and link it to the same storage and networks used by Gold/Silver. When you created the new Provider vDC you would see which “External Networks” where available to it. You might recall in the previous post this area was blank, because no “External Networks” had been defined. So were in a bit of chicken-egg situation.

Screen Shot 2012-11-01 at 17.18.37.png

Anyway, with that in mind – when you come create an “External Network” you will be asked create a pool IP addresses. These can be used in two cases:

  • To automatically IP VMs in a vApp Network that get connected directly to the External Network
  • and/or if the Organization Network was connected the External via vCNS Edge Gateway (in what’s often referred to as being NAT/Routed Connection), the Edge Gateway would take an IP address from the pool as well

Without the pool of IP any system connected to the External Network (whether it be vApps or the Edge Gateway) would need to be statically configured manually, and that hardly fits in with our “dynamic” view of networking within a Virtual Datacenter.

Screen Shot 2012-11-01 at 15.20.33.png

Once you click OK, you can see the pool IP address and like any resources you can monitor its consumption by tenants in the system.

Screen Shot 2012-11-01 at 15.27.13.png

Finally, once you have completed this page, you can set the name for the External Network. I’ve been thinking a lot about naming conventions with vCD. Part of me is tempted to use a naming convention that allows you to quickly relate the vCD object to the vSphere object. I think that will save time needlessly entering dialog boxes to find out vSphere object that provides the interface to the underlying network. Another part of me wants to use a naming convention that simplifies this so it means the admins within vCD can easily see what vCD object does in terms of functionality.

In otherwords I could use:

vDC-DvSwitch-ExternalInternetAccess

OR

The Internet

The tech part of my brain wants to opt for the 1st convention. But the keep-simple-stupid part of my brain likes the second “convention” that might be a bit more “user” friendly.

Screen Shot 2012-11-01 at 15.40.55.png

In my case I created two External Networks (The Internet and The Corporate Network). They both use the same IP network id of 192.168.3.0/24 (of course the pools ranges themselves don’t overlap). One uses the 192.168.3.199 as the Default Gateway which is my Juniper Firewall, and the other uses 192.168.3.1 which is software based router that I have on my network…

Screen Shot 2012-11-01 at 16.15.28.png

 

 



Copyright 2018. All rights reserved.

Posted November 4, 2012 by Michelle Laverick in category "Cloud Journal