or… How I learned to enable routing between two vApp Networks connected to the same Organization Network…
In my previous post I introduced vApp Networks into the soup. One of the tasks I’ve set myself is getting them to speak to each other. I’m finding increasing difficult to explain the relationships that I’m forging via the medium of blogpost/images alone. So I decided to make a little “Educreations” video on my iPAD to explain the scenario before I set to with the blogpost.
WARNING: THE most common mistake I’ve made with handling the Edge Gateways for the vApp Networks is simply remembering to click the “Apply” button.
So, now that’s a bit more clear. Lets set too. Two things I’ve done to make my own life easier when testing is turning OFF firewalls. Now this clearly isn’t a production level configuration. I’ve turned off the firewall on the Edge Gateway and also within the guest operating system. It just makes life easier with pings and tracert tests. In my case vApp1 is called “CorpHQ – Security Servers” (on the 192.168.10.x vApp Network) and vApp2 is called “CorpHQ – View Servers” (192.168.11.x vApp Network) – and I disabled the firewall on both.
NOTE: I later discovered that the Windows ultility pathping gives MUCH better info of the route packets take than tracert does.
When you do this icon that’s used to represent the vCNS Edge Gateway loose the (fire)wall icon, and just gets a blue cross instead:
For good measure I logged into each of the VMs within the vApp, and disabled the Windows 2008 Firewall (Control Panel, System & Security, Windows Firewall, Turn Firewall on or off). Once that’s done I was ready to enabled the “routing” capabilities of the two vApp Networks. I did this mainly to facilate testing & troubleshooting, as this was the first time I’d done this kind of configuration with vCloud Director.
As I said in the video its critical to know the EXTERNAL interfaces IP address of the destination network. So if 192.168.10.x wants to speak to 192.168.11.x then the router at 192.168.10.x needs to know the EXTERNAL IP address of the Edge Gateway that handles the 192.168.11.x network. On the properties of the vApp Network itself under the “Static Routing” tab:
CorpHQ – View Connection Servers vApp: (192.168.11.0)
CorpHQ – View Security Servers vApp: (192.168.10.0)
The “View” vApp on 192.168.11.x external address is 172.168.7.12
The “Security vApp on 192.168.10.x external address is 172.168.7.15
So enable networking between the two vApp – The View vApp needs a route to 192.168.10.x using 172.168.7.15 and the Security vApp needs a route to 192.168.11.x using 172.168.7.12 – so lets set that up. Select the Networking tab on the vApp, and right-click to Configure Services of the vApp Network in question. Select the “Static Routing” tab, and tick off the option to “Enable static routing“. Next click the Add button to add a route…
So here the Security Servers (192.168.10.x) are being give a route to the View Connection Servers (192.168.11.x) using the External Interface of the vApp Network for the View Servers (172.168.7.12). Conversely….
TIP: I find it handy to slide the Configure Service dialog box to one side – it stops me doing silly things – like specifying route 192.168.10, when it already “knows” how to get to itself! So here the View Server are being given access to the Security Servers on 192.168.10 using their external interface 172.168.7.15.
Of course the proof of the pudding is in the pinging. So here’s the VM corphqCS01 (192.168.11.100) pinging the corpohqSS01 (192.168.10.101), together with a tracert – notice how the View server speaks via its internal gateway address (192.168.11.1) and then through the external gateway of the destination Edge Gateway (172.168.7.15) before arriving at the destination VM (192.168.10.110).
That might leave me us with another question. Can these vApps ping anything on their Organization Network (172.168.7.1)? The answer is YES. Each vApp has an Edge Gateway with a valid interface for 172.168.7.x (172.168.7.15 and 172.168.7.12) if you recall. By default the vApp Edge Gateway is configured to to be NAT. So long as their are no firewalls in place to block traffic a ping should work from the 192.168.10 or 192.168.11 network without further configuration.
So by default the NAT allows an outbound traffic FROM the vApp Network TO the Organization Network – and traffic sent out from the vApp Network will find its way back into the vApp Network by default. The same isn’t true in the opposite direction.
So a VM on the CorpHQ-DevelopmentNetwork cannot communicate from 172.168.7.x to 192.168.11.0. That’s because there’s no corresponding route back to the vApp Network. I can fix that in a number of ways, not least adding a route to the VM sitting on on the Organization Network
And Finally. What if you powered off the vApps and Powered them back on again. There’s a reasonable chance the IP addresses assigned to the External Interface of the vApp Networks could change. I’ve seen it happen. For example I powered off the CorpHQ – View Security Servers vApp and powered it back on again. This had the affect of the 172.168.7.x network IP address being released back to the Organization Network IP pool. When it was it powered back on again, its IP address changed. That meant my route was wrong, and also I had problems powering on a vApp that was expecting to see 172.168.7.15 when it had altered to 172.168.7.10
So first I had to fix the route on the vApp Network for the View vApp, and then make sure this didn’t happen again. To fix the issue I need to put an X next to that option called “X Retain IP/MAC Resources”. With this enabled the IP of the external interface remains the same – and doesn’t get released back to the pool until the vApp is deleted:
Some vApp Thoughts:
Routing. Gee, this is taking me RIGHT back. In the mid-90’s was Microsoft Certified Trainer (MCT), and I remember teaching a 5-day course on the TCP/IP. Can you imagine it – 5-days JUST on a protocol. Mind you back then the dominant protocols weren’t standards based and widespread WWW access was not common – in fact the dominant protocol was probably IPX/SPX from Novel or NetBIEU from Microsoft. So this course would run the gamut of common configurations – IP, IP Subnetting/SuperNetting, DNS, NAT, WINS and so on and also IP routing principles as well. So this article was a little bit of trip down memory lane for me – albeit everything is now software and I’m not messing about with cross-over cables and hunting around for spare switches with which to make networks. Everything has changed, but in another way everything has stayed the same.