No, we use only software VR. Client "reserves" IP from the pool and assigns to VM it wants. Cloudstack manages it well. I guess you may partition the public IP range for every client separately, but haven't tried to do it.
Vadim. -----Original Message----- From: Andrija Panic [mailto:[email protected]] Sent: Thursday, October 30, 2014 12:50 PM To: [email protected] Subject: Re: Best practive for public cloud isolation method ? Hi Vadim, how do you do SNAT - on hardware firewall I guess ? Manually for each VM that want's to be on public IP? On 30 October 2014 11:36, Vadim Kimlaychuk <[email protected]> wrote: > Hi, > > I would also like to hear more about best practices for > network architecture, but so far have found only VLAN isolation > described more or less thoroughly. > 1. We have recently set up VLANs and didn't fill the limit yet. > :) GRE is one of the options, but can't say how it works. Haven't > even tried yet. Would be interesting indeed. > 2. We use VPC-s only. To enable guest VM to be on public IP > we just do SNAT for those who need it. If guest is under "soft LB > network offer" then you may need port forwarding, but not sure for > 100%. It is better probably to add another network offer go guest VM to > enable SNAT. > > Vadim. > > -----Original Message----- > From: Andrija Panic [mailto:[email protected]] > Sent: Tuesday, October 28, 2014 10:40 AM > To: [email protected] > Subject: Best practive for public cloud isolation method ? > > Hi guys, > > I'm asking somewhat dump question and generic one, since I'm designing > new public cloud infrastructure: > > We are about to go with KVM, Advanced zone vlan/vxlan/other isolation > method, ACS 4.4.1 or possibly revert back to 4.3. We plan on using VPC > extensively and still provide let's call it "VPS" style VMs if possible. > > So: > > 1. Per your experience, what is the best isolation method to be used > for Guest traffic - I'm talking here about usability of the solution, > productional one: > -- vlans - works fine, limited to theoretical maximum of 4095 > -- vxlan - don't really work fine for public cloud, since default MTU > of > 1500 bytes is lowered on vxlan bridge/interface to be 1450 bytes so > the MTU inside VM must be also lowered...1450 bytes MTU is > default/hardcoded into iproute/cloudstack, with no option to choose > larger MTU on vxlan interface/bridge (and ask ADMIN to adjust MTU to a > larger one on physical > network) - also this does not allow us to use jumbo frames, but would > be a really good thing to do. > -- GRE - I'm just evaluating/researching this > > > 2. Another quetion - since we want to go heavily with VPC, but still > want to be able to provide let's call it "VPS" style VMs - what is the > best aproach to do so? > We already have Shared/Guest network with access to Internet - so this > is the way we acomplished single VM to be on a public IP network. > Or is it better to really dump the VPS style, and just go with normal > VPC with port forwarding to internal VM - I'm just not so clear if/how > much CloudStack was designed to support this kind of "VPS" style VMs - > my understanding is that the focus is really cloud-like/VPC > functionality, and not VPS style, at least not on Advanced zone > together with VPCs - so any advice is really welcomed. > > > My experience with vlans is that it works like charm, but has it's > limitations. Vxlans experience is fine if you can control MTU inside > VMs - not good for public cloud... > > > Again, generic questions, but I'm looking into some hints if possible > and your experience that you are wiling to share > > Thanks, > > -- > > Andrija Panić > -- Andrija Panić -------------------------------------- http://admintweets.com --------------------------------------
