Thanks. That was helpful. I see there are two more options for network isolation in 4.2.0 (VLAN, GRE, STT, VNS, and SSP) and was wondering about them but couldn't find any documentation.
So how do I determine whether VLAN or GRE is better for my use case? Thanks again. Quoting sebgoa <run...@gmail.com>: > > On Oct 24, 2013, at 10:41 PM, Bryan Manske <br...@manske.org> wrote: > > > > > And is there any documentation on network isolation and GRE versus SST, > > > STT isolation really means that you are using the NICIRA NVP system which is > proprietary. So if you did not buy nicira, then the STT isolation method is > of no use to you. > GRE is the native controller in cloudstack, it's only documented on the wiki: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/OVS+Tunnel+Manager+for+CloudStack > However in master it is supported for both XS and KVM. > > > > > > 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 > > --- > > --- "Earnest falsehoods left unchallenged risk being accepted as fact." -- Monty "xiphmont" Montgomery - Xiph Foundation, on the Ogg format ---
