[or how I learned to connect vApp Network1 on Organization Network1 speaking to vApp Network2 Speaking on Organization Network2]
Again – you might be assisted by watching this little whiteboard video I did which explains my configuration.
This configuration was a little bit easier to get going than some of my earlier attempts – that was mainly because a lot of the routes needed to make this happen were already in place from earlier experiments. For example at CorpHQ location I had already input routes that would allow one vApp to speak to another vApp (on the same Organization Network) called “DB” and “WEB” – so the 172.168.5.0 network already had route to the “web servers” via 172.168.5.12
I found out this IP by looking at the vApp Network settings for the Web vApp like so:
So to get traffic flowing from vApp Network (192.168.30.x) in OrgB to another vApp Network (192.168.15.x) in OrgA, all I needed was to add a route. The route I needed was to 192.168.15.0/24 and the first hop was the external interface of the vCNS Edge Gateway in OrgA (192.168.3.10). Once packets arrived at 192.168.3.10, then the CorpHQ-CorpOrgNetwork Edge Gateway already had a route in place to take traffic on to 192.168.15.0/24.
To get traffic going in the opposite direction require a bit of work. Firstly the vCNS Edge Gateway needed a route to the 192.168.30.x network as well as the next hop to complete the journey. This would be set to be sent across the Corporate Network along to the external router interface at OrgB (192.168.3.21)…
This on its own wouldn’t be enough – because when packets arrived at OrgB external interface (192.168.3.21) it would need a route to take the packet on to 192.168.30.x. Notice how in this case the applied on is the Organization Network, as packets are coming IN through the external network, on to the Organization Network and then inbound to the vApp…
