And is there any documentation on network isolation and GRE versus SST, et cetera, when creating a zone within CloudStack?
Thanks. Quoting Bryan Manske <br...@manske.org>: > All, > > I'm still hung up on network issues with VMs on CloudStack hosts not talking > to the network. I'm currently looking at OpenVSwitch. Maybe the answer > lies there. If anyone has any ideas I would be most appreciative. > > I've decided to provide a link(s) (same content, 3 different formats) to my > CS setup notes so that others can follow along. Please keep in mind that > this > is not quite a pedagogical list of "do this, then do this" when trying to > install CloudStack but that's what I'm aiming for. These are basically my > own adjustments to the documentation for 4.2.0 as I've been building it. > I've also collected and listed the relevant links where I could. I figure it > might help someone else out along the way.... > > > http://mail.manske.org/CS.Setup.Notes.txt > http://mail.manske.org/CS.Setup.Notes.odt > http://mail.manske.org/CS.Setup.Notes.pdf > > Comments are always welcome. > > Thanks. > > Bryan Manske > > > Quoting Bryan Manske <br...@manske.org>: > > > All, > > > > (This is an update on my ongoing network issues within CloudStack 4.2.0. > > Please read the original messages below for more information.) > > > > I've configured a network offering with no services this time, no virtual > > router, no DNS or DCHP, just a live public IP network and default gateway. > > > > A VM running on blade 1 (configured within CloudStack) can ping another VM > > running on blade 1 but can't see VMs running on blade 2. Nor can it see > > the default gateway or other XenCenter-configured VMs running on that > network > > segment. And VMs running on blade 2 can ping each other but can't ping VMs > > running on blade 1, the default gateway, et cetera. > > > > A VM configured within XenCenter on blade 1 or 2 using the "cloud-public" > > labeled ethernet interface can see physical machines, the default gateway, > > and other XenCenter VMs configured on other hosts with or without VLAN > > configurations running on their network interfaces. (The VLAN configs > > didn't make any difference to speak of but, yes, I did verify that VLANs > > were supported by the physical interface type, the kernel supported them, > > and the interface was present and marked as "up".) I've also verified the > > routers and switches for proper VLAN configs. IPTables have also been > > disabled. And the CloudStack 4.2.0 VMs are the only machines that can't > > talk on the public network. > > > > I don't think it's a tagged versus untagged VLAN issue. And I've verified > > that my two starter blades are configured and connected to both public and > > private networks correctly. And the public IPs for the CloudStack System > > VMs work correctly. I might have a network offering issue or a tagging > > issue somewhere but this goes right back to CloudStack and probably > something > > I've missed. > > > > Thanks to: > > > http://blog.remibergsma.com/2012/08/30/going-beyond-cloudstack-advanced-networking-how-i-replaced-the-virtual-router-with-my-own-physical-linux-router/ > > > > and > > > > > http://blog.remibergsma.com/2012/03/10/howto-create-a-network-in-cloudstack-without-a-virtual-router/ > > > > But I'm still non-functional and confused as to what I'm missing in the > > CloudStack networking department. Can anyone offer up more links or > > advice please? > > > > Thanks. > > > > Bryan Manske > > > > > > > > > > Quoting Bryan Manske <br...@manske.org>: > > > > > > > > Sanjeev, > > > > > > I followed a YouTube video explanation and did specify the tags > > > "cloud-public" > > > to the guest and public networks - and "cloud-private" to the management > > > network. The "public" IPs work fine for things like SSVM and Console > Proxy > > > VM, > > > hence my confusion. I also used the "cloud-public" tag in two simple > > > network service offerings, one with no services and one with just DSN, > > DHCP, > > > and userdata. No firewalls or security groups and default egress policy > > > set to "allow", although I'm not sure it was needed there. > > > > > > Thanks. > > > > > > Bryan > > > > > > > > > Quoting Sanjeev Neelarapu <sanjeev.neelar...@citrix.com>: > > > > > > > Hi Bryan Manske, > > > > > > > > Did you specify the tags cloud-public and cloud-private as traffic > lables > > > for > > > > public and private trafifics in the physical network ? > > > > > > > > -Sanjeev > > > > > > > > -----Original Message----- > > > > From: Bryan Manske [mailto:br...@manske.org] > > > > Sent: Tuesday, October 22, 2013 3:30 AM > > > > To: users@cloudstack.apache.org > > > > Subject: Re: Public IPs on Guest VMs within CloudStack 4.2.0 > > > > > > > > All, > > > > > > > > I'm still having issues with my CloudStack instances seeing the outside > > > > network and vice versa. I've verified that other non-CloudStack VMs in > > the > > > > same IP subnet can see the default gateway and each other but they > can't > > > see > > > > the CloudStack instances. The CloudStack instances can ping the VR but > > not > > > > the default gateway or any other non-CS VMs. I'm using Xen Server 6.2 > as > > > the > > > > only hypervisor for the moment and have set the network interface tags > > > > (cloud-public and cloud-private) with "xe network-param-set > > > > name-label=cloud-public uuid=<interface-uuid>" and "xe > > > > network- > > > > list" looks correct. Am I missing tags in the network offering or > > > somewhere > > > > else? I can't imagine that the CS VR would want to be the default > > gateway > > > > itself but I suppose its possible. I've even been looking at VLANs > > (tagged > > > > versus untagged) at my network edge with no luck. > > > > "xe-switch-network-backend" is set to bridged so maybe its an > openvswitch > > > > issue. Big sigh. > > > > > > > > I've debugged as far as I can and need a few suggestions on where to > look > > > > next. > > > > > > > > Thanks. > > > > > > > > Regards, > > > > > > > > Bryan Manske > > > > > > > > > > > > Quoting Bryan Manske <br...@manske.org>: > > > > > > > > > All, > > > > > > > > > > Now I'm curious about public IPs on Guest VMs within CloudStack > 4.2.0. > > > > > > > > > > I have one IPv4 /27 for Public IPs and that's working fine. Now what > > > > > I want to do is assign a live IP address from another /27 to a Guest > > > > > VM, which appears to work but can't actually touch the default > gateway. > > > > > > > > > > So here's the rub: The default gateway is actually provided as a > > > > > virtual IP on two VRRP nodes (for A/B redundancy) by my upstream > > > > > provider. I can ping the two VRRP routers, I can see the VM has the > > > > > proper IP address, netmask, and default gateway; and I can configure > > > > > the VM with a proper IP config which never finds the default gateway > > > > > IP. The arp cache sees the local MAC address and incomplete for the > > > > gateway. > > > > > > > > > > So now I'm thinking; according to cloudstack, is the default gateway > > > > > plumbed on a virtual router? If so, how does THAT route out to the > > > world? > > > > > > > > > > I also have a /64 of IPv6 space, /96 of which I have configured in a > > > > > network offering which has the same upstream infrastructure > situation. > > > > > Same lack of functionality there. > > > > > > > > > > So how do I configure my Guest real IP netblocks? Is it okay to be > > > > > looking for a default gateway IP on a my provider's core router or do > > > > > I need to have them statically route that netblock to something like > > > > > the cloudstack management host? > > > > > > > > > > Of course I could also have the network offering wrong or incomplete. > > > > > > > > > > Any thoughts or pointers to documentation would be appreciated. > > > > > > > > > > I can tell I'm making progress because I keep dealing with > > > > > progressively higher level errors. :) > > > > > > > > > > Thanks. > > > > > > > > > > Bryan Manske > > > > > > > > > > > > > > > --- > > > > > "Earnest falsehoods left unchallenged risk being accepted as fact." > > > > > -- Monty "xiphmont" Montgomery - Xiph Foundation, on the Ogg format > > > > > --- > > > > > > > > > > > > > > > > > --- > > > > "Earnest falsehoods left unchallenged risk being accepted as fact." > > > > -- Monty "xiphmont" Montgomery - Xiph Foundation, on the Ogg format > > > > --- > > > > > > > > > > > > > --- > > > "Earnest falsehoods left unchallenged risk being accepted as fact." > > > -- Monty "xiphmont" Montgomery - Xiph Foundation, on the Ogg format > > > --- > > > > > > > > > --- > > "Earnest falsehoods left unchallenged risk being accepted as fact." > > -- Monty "xiphmont" Montgomery - Xiph Foundation, on the Ogg format > > --- > > > > > --- > "Earnest falsehoods left unchallenged risk being accepted as fact." > -- Monty "xiphmont" Montgomery - Xiph Foundation, on the Ogg format > --- > --- "Earnest falsehoods left unchallenged risk being accepted as fact." -- Monty "xiphmont" Montgomery - Xiph Foundation, on the Ogg format ---
