Michelle Laverick Music

I’m coming close to the end of my mini-series (think of it a bit like Dallas only without Bobby waking up in the shower – believe me I’ve had nights like that too…) on vApp Networks. I’ve run the gammet of different configurations including…

1. Two vApps on the same isolated development Organization Network
2. Two vApp on the same routed production Organization Network
3. vApp speaking via the routed production Organization Network on to the external network
4. vApps with the same IP address isolated from one another with Fenced Networking…

That really leaves one major configuration I want to setup at least once as part of learning experience. That’s how to get a vApp in one Organization speaking to another vApp in different Organization. As well as one vApp on the Organization Network communicating to another vApp on another Organization Network. Part of me feels a little wierd doing this as I want to obey the laws of multi-tennacy and not allow one Organization to be able to see inside another – yes, I know there will be a firewall, and I have yet touch on Destination NAT yet… But still it makes me feel uncomfortable…

But the way I see it is that Organization is logical construction – so its possible to have one company like COIG that would have two Organizations – one for Production and the other for Development – that might want communication to be possible between their two Organizations that exist WITHIN their businesses. That’s not a model I’ve chosen in my case but I think the principle remains the consistent.

vApp on Organization Network1 speaking to vApp Speaking on Organization Network2

Again, you might want to watch this Whiteboard Video below to help visualize my configuration and what I’m trying to achieve.

Linking two Organization Networks together that are routed to the External Network is relatively easy affair I think – because it so similiar to doing the same tasks to route two vApp Networks together which reside on the same Organization Network. The only real difference I can see is when you make changes on the Organization Network Edge Gateway changes are affective immediately, whereas with the vApp Network you must remember to hit the “Apply” button before you changes are processed. The other big difference is the impact of the change. By creating a route between one network another you allow outbound comms from all the vApps from one Organization to another assuming Firewall rules allow the packets to flow.

As you might recall you to know the network ID of the two networks and the IP address of their externally facing vCNS Edge Gateway interfaces. The network ID can be found on the “Org VDC Networks” tab of each respective Organization/Virtual Datacenter:

COIG Network ID: 172.168.8.x

CORPHQ Network ID: 172.168.5.x

Next I need to find out the IP address of each Organization vDC Networks vCNS Edge Gateway. I remembered that CorpHQ’s was 192.168.3.10, but I couldn’t remember what I had assigned to COIG. This can be found by examining the properties of each Edge Gateway and its “Configure IP Settings”.

COIG vCNS Edge Gateway Address: 192.168.3.21

CORPHQ vCNS EdgeGateway Address: 192.168.3.10

So that means for CORPHQ to get to the 172.168.8.0 network it needs a route to 172.168.8.0/24 via 192.168.3.21

So that means for COIG to get to the 172.168.5.1 network its need a route to 172.168.5.1/24 via 192.168.3.21

This configuration was repeated at the CorpHQ-CorpOrgNetwork Edge Gateway – adding a root To COIG with a network  of 172.168.8.0/24 with the Next Hop IP being 192.168.3.21. With all the firewalls and such like turned off I tried my ping and tracert test:

So here the VM (172.168.5.14) sent the ping via is local default gateway (172.168.5.1 which went across to the external interface of 192.168.3.10) and then on to the external intereface of the COIG Edge Gateway (192.168.3.21 which went across to the internal interface of 192.168.3.21) and then on to the COIG-QuarkServer01 (172.168.8.11). I found this configuration worked for my NAT clients which were behind a vApp Network. That’s because their external interfaces were valid for the 172.168.5.x network – the traffic would leave the vApp Network on their internal router interface (192.168.15.1) on to the Organization Network (172.168.5.12) on to the Organization Network’s Edge Gateway (172.168.5.1) which then had route to take the packet on to the other Organization Network (172.168.5.1>192.168.3.11>192.168.3.21>172.168.8.1>172.168.8.11). This traffic was only possible in one direction – from the vApp to the other Organization Network. That’s because there was no route or destination NAT translation to allow traffic from 172.168.8.x to get to 192.168.15.x.