I created an isolation-backed network for an org to use.
i got one network to work accross esx servers no issues.
however, when i create a server on another subnet routing does not happen.
so my question is how can i get routing to work internal to an org ?
You cannot. Isloation backed is Layer 2 Mac-in-Mac and therefore cannot be routed unless you go external through a vShield edge to do the routing. By definition Isolation backed networks are Layer 2 only inside an Org but between hosts on the same dVSwitch. Routing requires either a vShield edge to bridge the internal Isolation backed and external network, or some other device but by default is is layer 2 by definition.
You cannot. Isloation backed is Layer 2 Mac-in-Mac and therefore cannot be routed unless you go external through a vShield edge to do the routing. By definition Isolation backed networks are Layer 2 only inside an Org but between hosts on the same dVSwitch. Routing requires either a vShield edge to bridge the internal Isolation backed and external network, or some other device but by default is is layer 2 by definition.
ok, then need to get a vshield edge server.
so if I am 10 networks in my private cloud and I want to be able to route all of them internall i should use a vshield edge server ?
if you can point me to some document for this would appreciate.
i have created edge servers for external routing and nating .. never for internal
maybe i was not clear. I understand a vshield edge server will bridge between outside world and inside world.
My question is if i have inside my private cloude 192.10.50 and 192.10.51 can i use a vshield edge server as a router.. and if i can how do i go about it.
You will create a vApp network with your 192 network settings for the VM's within. Then you will connect that network to your organization network. This will setup a VSE which will NAT into each of your VM's.
can you expand on what you are saying ? not clear what you mean
When creating a vApp, on the Configure Virtual Machines section, you select "Add Network" under the Network column. This creates an isolated network as described above for just this vApp and is where you will assign your 192 network settings.
Once that is done and you are on the "Configure Network" section you'll put a check in the box next to "Show networking details." Click the box under "Connection" and select your organization network. In the routing tab you'll want to make sure NAT is selected. You can setup Firewall rules if you'd like as well, or turn it off.
When the vApp is started the VM's inside will get IP's from the vApp Network Pool and then will be NAT'd to an IP on either your organiazation or external network, depending on your organizational network setup.
We use a static IP address within our vApp Network with just 1 IP in the pool. If you have multiple VM's within your vApp you might have to play with the IP Pool and NAT IP info to figure out if they are correct.
As Chris said, at the moment you cannot do a Network Pool that spawns on multiple routed subnets, vCDNI, or VLAN Backed is Layer 2 only.
Therefore, You will soon be able to do it using Cisco Nexus 1000v in conjunction with vCD 1.5 leveraging the VXLAN technlogy. (http://tools.ietf.org/html/draft-mahalingam-dutt-dcops-vxlan-00)
Hope this helps,
getting there .. now that i have my vApp with one vm in it . All my vm's that are NOT part of the vApp (which you suggested only have one vm in the vApp) i will need to route via the Nat'd address
so now i can go ahead create multiple org networks , add the network to the vm in the vapp and then set my os boxes to route to the nat'd address and it should work ..
is that correct ?
ok , i guess i will need to wait for that
You can put all of your VM's in one vApp if you'd like. We do not as we have all of our software on one VM, except a couple vApps in which we build usters. They have 3 or 4 VM's in them. All of the VM's in our vApps have the same hostname and 192.168.10.10 for their IP, except in the "clusters" I just mentioned. The second VM in the clusters will be 192.168.10.11, and so on.
The VM's from one vApp talk to VM's from another vApp via the External IP address, which is then NAT'd to the 192.168.10.10 internal address. The External IP can change each time the vApp is started though. For this reason it is not a good idea to setup production vApps this way.