I confirm that CS complain about overlapping ranges. After many tests i did not reach my goal.
I want to assign a public IP directly to vm without NAT/SNAT ( like in your blog article, Shanker ). I want also to let customer have his lan isolated between 2 or more vm. I understand that with network base, CS let you assign public IPs to vm directly but you can not create guest network ( connect 2 vm with private address ) on UI. I do not via api if you can do it. I understand also that with network advanced it’s possible to create many isolated network but NOT assign public IP directly to vm without NAT/SNAT. Am i wrong ? This is much important to let me understand how network works inside CS. Best regards Il giorno 05/dic/2013, alle ore 10:32, Domenico De Monte <d.demo...@netsons.com> ha scritto: > Now i understand :) > > Thank you for all those answers. You clarify me a crucial point. > > So there is no difference between guest traffic ( public or internal ). > > That means that all guest traffic will use just one switch. > > For example if i create an instance with 2 nic, one for public traffic and > one for private traffic, private traffic goes to internet switch instead of > internal switch. > > I understand now how it works but in my personal opinion i do not think it's > correct. > > Best solution i believe is to let administrator choose on which switch > separate private and public traffic. > > Just my 2 cents to CS. > > > Thank you again shanker! > > Il 04/12/2013 11:45, Shanker Balan ha scritto: >> On 04-Dec-2013, at 1:35 pm, Domenico De Monte <d.demo...@netsons.com> wrote: >> >>> Before all, thank you for your reply. You explain me many concepts, really >>> important to know, that were not clear in CS documentation. >> There are four traffic types in CloudStack: >> >> (1) Management >> (2) Storage >> (3) Guest >> (4) Public >> >> Don’t call it by any other name, just use the ones listed above. :) >> >>> In total there are 4 NIC on each server, 2 assigned to vSwitch0 and 2 to >>> vSwitch1. >>> >>> In according of what you replied, my new zone configuration will be: >>> >>> 1 physical interface for internet traffic ( Public traffic, Guest Public >>> traffic both connected to vSwitch0 ) >> There is no “guest public” traffic type. >> >> vSwitch0 will carry GUEST *and* PUBLIC traffic. >> >> >>> 1 physical interface for internal traffic ( Management traffic, Storage >>> traffic, >>> guest internal traffic both connected to vSwitch1 ). >> There is no “internal" traffic type. You have Management and Storage >> traffic on vSwitch1. >> >>> I want separate guest internal traffic with guest public traffic for many >>> reasons. >> Again, there is no “guest internal” traffic type and “guest public” traffic >> type. Its just GUEST traffic and PUBLIC traffic. :) >> >>> You said that for guest traffic, a hard requirement is VLAN usage. Meanwhile >>> for public traffic, management and storage VLAN is not needed. >> Thats correct. >> >>> This point here is crucial because i still do not understand difference >>> between >>> public traffic and guest public traffic. >> :) >> >> So there is no “guest public” traffic type. Just “GUEST” and “PUBLIC” >> traffic types. Ok? >> >> Q. What is “GUEST" traffic? >> >> A. From >> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html-single/Installation_Guide/#advanced-zone-network-traffic-types >> >> "Guest. When end users run VMs, they generate guest traffic. The guest >> VMs communicate with each other over a network that can be referred to >> as the guest network. This network can be isolated or shared. In an isolated >> guest network, the administrator needs to reserve VLAN ranges to provide >> isolation for each CloudStack account’s network (potentially a large number >> of VLANs). In a shared guest network, all guest VMs share a single network” >> >> Q. What is “PUBLIC” traffic? >> >> Again, from >> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html-single/Installation_Guide/#advanced-zone-network-traffic-types: >> >> "Public traffic is generated when VMs in the cloud access the Internet. >> Publicly accessible IPs must be allocated for this purpose. End users can >> use the CloudStack UI to acquire these IPs to implement NAT between their >> guest network and the public network, as described in “Acquiring a New IP >> Address” >> in the Administration Guide.” >> >> The same link also described Management and Storage traffic types also. >> >>> If i understand, public traffic of a zone is for system vm only ? >> Incorrect. See >> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html-single/Installation_Guide/#advanced-zone-network-traffic-types >> >>> And guest public traffic is for guest vm only ? >> There is no such traffic type as “guest public”. Its just PUBLIC traffic. >> >> Again, see >> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html-single/Installation_Guide/#advanced-zone-network-traffic-types >> >> >>> If so, why if we use basic network configuration, we do not have “overlaps” >>> network issue ? >> Basic networks is a shared network and does not have PUBLIC traffic type. >> Only Management, Storage and GUEST. >> >> The documentation at >> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html-single/Installation_Guide/#basic-zone-network-traffic-types >> is not >> very clear in the regard. >> >> A basic network is a big flat network similar to AWS EC2 while advanced >> network is like an AWS VPC. >> >> >>> Of course in this case we can not let users use internal physical >>> switch ( vswitch1 ) for lan traffic. >> >> What is LAN traffic here? There is Management, Storage, Guest and Public >> traffic only. Guest traffic (traffic between the customer’s VM) is isolated >> with VLANs. >> >> In your case, it will be over vSwitch0. >> >>> Anyway my target is still to reduce public IPs usage and of course do not >>> use SNAT. >> By default CloudStack will provision *one* Public IP per customer. This >> single >> public IP is assigned to the customer’s Virtual Router automatically. The >> customer can then >> create Egress/Ingress rules to filer traffic and enable port forwarding >> to his VMs. >> >> All of the customer’s VMs will be on a dedicated VLAN with private IPs >> in the 10.1.1.0/24 (default) range. >> >> A customer can have many VMs. Each of these VMs will only have private IPs >> and the single public IP enabled Virtual Router will continue to provide NAT >> services. >> >> So, if you had 10 customers: >> >> 1) There would be 10 VLANs created >> 2) Each VLAN will have 1 Virtual Router >> 3) Each Virtual Router will have one public IP address used to provide >> NAT/SNAT services >> 4) Many many VMs which are on private subnet >> >> >>> In order to do so, i want definitively follow your guide: >>> http://shankerbalan.net/blog/create-a-shared-network-with-public-ips-in-cloudstack/ >>> ( i read it also before, very well done :) ) >> Thanks. >> >> That post refers to directly assigning public IPs to the VMs. I am not sure >> if >> thats what you want to do since you want to save on public IPs. >> >>> But following this i still have problem of CS network overlaps if i want >>> use same /24 for both type of public traffic. >> I think I already explained this earlier. Feel free to be more specific if >> the whole >> GUEST Vs Public Vs Shared network refuses to make sense. :) >> >> >>> Consider that we want let customers use a public IP and a private IP >>> directly >>> on their vm. For internet traffic without vlan. This is our goal. >> Yep. The steps would be as below: >> >> 1) Create Advanced Zone with MGMT+STORAGE and GUEST+PUBLIC on the >> appropriate vSwitches >> 2) Subnet your /24 even further and assign the first /26 chunk to the Public >> range >> 3) Create a shared network with the 2nd /26 subnet >> 4) Create a VM on the isolated network. It will end up having its primary >> interface having a 10.1.1.0/24 on a VLAN >> 5) Attach a second interface on the shared network. The 2nd interface would >> have a public IP from the 2nd /26 public subnet >> >> The SSVM, CPVM and Virtual Router will have their public IPs auto assigned >> from the 1st /26 subnet. >> >> >>> Assign for each vm a VLAN for public traffic, we will lose many ips just >>> for sub netting. >> I don’t see how you can lose IPs. The VLANs are strictly for guest IP ranges >> which by default end up in the 10.1.1.0/24 subnet. >> >>> So there is no way to use a single /24 for public system traffic and guests >>> public traffic without split this /24 in smaller subnet ? >> While I haven’t personally tried assigning the same subnet to both the public >> range and the shared network range, my guess is that CloudStack will complain >> about overlapping ranges. >> >> Please do try it. :) >> >>> I think key is to assign just 2 physical interface as you suggest and try >>> to see if overlaps issue goes away, like it was for basic network >>> configuration. >> Advanced network can “seem” very complicated. But once you under the >> (powerful) >> concept of traffic types, it will all make sense. >> >> If you can, get yourself an AWS a/c and try their classic-EC2 features and >> then >> their EC2 VPC features. :) >> >>> Waiting for your reply >> Hth. >> @shankerbalan >> >> >> >>> Best regards >>> >>> >>> Il giorno 04/dic/2013, alle ore 05:24, Shanker Balan >>> <shanker.ba...@shapeblue.com> ha scritto: >>> >>>> Comments inline. >>>> >>>> On 04-Dec-2013, at 6:18 am, Domenico De Monte <d.demo...@netsons.com> >>>> wrote: >>>> >>>>> Hello, >>>>> i added a zone with advanced network with following network configuration >>>>> on >>>>> CS 4.2 but i was not able to setup same IP class on public traffic ( of >>>>> system vm ) >>>>> and guest traffic ( of guest vm ). >>>>> >>>>> Scenario >>>>> Servers with VMware ESXi 5.1 have multiple nic: >>>>> 2 nic connected to physical internet switch ( vSwitch0 standard ) >>>> Am not intricately familiar with ESXi but I assume these 2 NICs >>>> are in a bond (LACP/LAGG) and configured as vSwitch0 for Internet traffic. >>>> >>>>> 2 nic connected to physical private switch ( vSwitch1 standard ) >>>> vSWitch1 is also a LACAP/LAGG bond of 2 NICs? >>>> >>>>> On CS i create a zone with advanced network and 5 physical interface: >>>> You would only require 2 CloudStack physical interface. “Physical >>>> Interface 1” >>>> for Internet vSwitch0 traffic and “Physical Interface 2” for Internal >>>> vSwitch1 traffic. >>>> >>>>> 1 physical interface for Public traffic connected to vSwitch0 >>>>> ( i think it's system vm public traffic ). >>>> The “untrusted” public Internet traffic would go to “Physical Interface 1”. >>>> The “Public Traffic” includes all public Internet traffic (Guest VM Public >>>> traffic + SSVM Public Traffic + CPVM Public Traffic etc). >>>> >>>>> 1 physical interface for Guest traffic connected to vSwitch0 >>>>> ( i think it's guest vm public traffic ). >>>> The “untrusted” guest traffic would also go to “Physical Interface 1”. >>>> >>>>> 1 physical interface for Guest traffic connected to vSwitch1 >>>>> ( i think it's guest vm lan traffic ). >>>> So basically all Guest VM traffic and any Public traffic gets combined >>>> onto “Physical Interface 1” which is mapped to vSwitch0 >>>> >>>> >>>>> 1 physical interface for Storage traffic connected to >>>>> vSwitch1 ( i am sure it's storage traffic for snapshot, deploy and so on >>>>> ). >>>> Yep, so storage traffic is on “Physical Interface 2” which is mapped to >>>> vSwitch1 >>>> >>>> >>>>> 1 physical interface for Management traffic connected to vSwitch1 >>>>> ( i am sure it's for system vm traffic and so on ). >>>> Yep, so Management traffic is also on “Physical Interface 2”. >>>> >>>>> I do not want use vlan and i read on ml that if i do not setup them, >>>>> they are just ignore from CS. >>>> You require VLANs for “GUEST” VM traffic. This is a hard requirement. >>>> VLAN is optional for the other traffic types of “PUBLIC”, “MANAGEMENT” and >>>> “STORAGE”. >>>> >>>> To sum up, >>>> >>>> Public Traffic -> Physical Interface 1 -> vSwitch0 -> 2xNICs (LACP/LAGG) >>>> Guest Traffic -> Physical Interface 1 -> vSwitch0 -> 2xNICs (LACP/LAGG) >>>> Management Traffic -> Physical Interface 2 -> vSwitch1 -> 2xNICs >>>> (LACP/LAGG) >>>> Storage Traffic -> Physical Interface 2 -> vSwitch1 -> 2xNICs >>>> (LACP/LAGG) >>>> >>>>> Assuming that i have a public ip class like 1.2.3.0/24. >>>>> >>>>> On public traffic ( system vm i think ) i setup a range like following ( >>>>> example ): >>>>> gw: 1.2.3.1 >>>>> netmask: 255.255.255.0 >>>>> start ip: 1.2.3.21 >>>>> end ip: 12.3.30 >>>> The same public IP range is used for both system VMs and guest VMs SNAT. >>>> >>>>> On guest traffic ( on vSwitch0 so guest public traffic ) i want setup a >>>>> different range but in SAME subnet: >>>>> gw: 1.2.3.1 >>>>> netmask: 255.255.255.0 >>>>> start ip: 1.2.3.31 >>>>> end ip: 1.2.3.128 >>>>> >>>>> I can not do this cause CS stop me, warning about netmask/gw overlaps. >>>> The guest subnets are private RFC1918 ranges. By default, CloudStack uses >>>> 10.1.1.0/24 for all tenants. You should leave it as is. >>>> >>>> If your trying to assign public IPs directly to the guest instances, >>>> you can certainly do that later once your Zone is online by creating >>>> a “shared network” with a public subnet. >>>> >>>>> So i came to 2 possible solution: >>>>> >>>>> 1) Do subnetting for network: 1.2.3.0/24 and assign a /29 to public >>>>> traffic >>>>> ( system vm ) and different /28 to guest traffic. >>>> I would do it as below: >>>> >>>> (1) Assign a public range for the public traffic from the "Add zone" >>>> creation wizard >>>> (2) Use the default 10.1.1.0/24 for guest networks and specify the VLAN >>>> ranges >>>> (3) Create a new shared network for tenants with public IPs >>>> >>>> If your pool of public IPs is a single /24, then split it into multiple >>>> /26. >>>> Assign the the 1st /26 range for (1) and then create a shared network with >>>> the >>>> remaining /26 blocks once the Zone is online. >>>> >>>> >>>>> 2) Assign to public traffic ( system vm ), private IPs that will be >>>>> natted to >>>>> my router, so i can assign all public IPs that i want to guest vm. Also >>>>> here >>>>> i am not sure if everything works after that. >>>> Leave your guest subnets on 10.1.1.0/24 defaults and create a shared >>>> network >>>> later with your smaller /26 subnets. >>>> >>>> >>>>> So my questions are: >>>>> >>>>> 1) Why system vm should have internet connection ? They need to >>>>> receive incoming connection or i can nat them in order to reduce public >>>>> ip usage ? >>>> System VMs require a public interface for various reasons. SSVM for >>>> example allows >>>> tenants to upload their templates. CPVM allows tenants to remote console >>>> into their >>>> guest instances. >>>> >>>> If you want tenants to use these functionalities, you will require >>>> routable addresses. >>>> >>>> Since you mentioned conserving public IPs, that IS the default CloudStack >>>> behaviour. >>>> RFC1918 private space is used to assign guest VM instances and ONE public >>>> IP is >>>> assigned per tenant for NAT/SNAT on the Virtual Router. >>>> >>>>> 2) There is no other solution ? Can i skip somehow CS warning about >>>>> netmask/gw overlap ? >>>> Have a look at the following URLs. >>>> >>>> http://shankerbalan.net/blog/create-a-shared-network-with-public-ips-in-cloudstack/ >>>> http://shapeblue.com/cloudstack/understanding-cloudstacks-physical-networking-architecture/ >>>> >>>> Guest traffic are private RFC1918 subnets and are VLAN tagged. Public >>>> traffic >>>> are routable subnets. It is possible to assign public IP addresses >>>> directly to >>>> instances by creating a shared network. >>>> >>>> Hth. :) >>>> @shankerbalan >>>> >>>> -- >>>> @shankerbalan >>>> >>>> M: +91 98860 60539 | O: +91 (80) 67935867 >>>> shanker.ba...@shapeblue.com | www.shapeblue.com | Twitter:@shapeblue >>>> ShapeBlue Services India LLP, 22nd floor, Unit 2201A, World Trade Centre, >>>> Bangalore - 560 055 >>>> >>>> This email and any attachments to it may be confidential and are intended >>>> solely for the use of the individual to whom it is addressed. Any views or >>>> opinions expressed are solely those of the author and do not necessarily >>>> represent those of Shape Blue Ltd or related companies. If you are not the >>>> intended recipient of this email, you must neither take any action based >>>> upon its contents, nor copy or show it to anyone. Please contact the >>>> sender if you believe you have received this email in error. Shape Blue >>>> Ltd is a company incorporated in England & Wales. ShapeBlue Services India >>>> LLP is a company incorporated in India and is operated under license from >>>> Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company >>>> incorporated in Brasil and is operated under license from Shape Blue Ltd. >>>> ShapeBlue is a registered trademark. >>> >>> >>> >>> Supernova s.r.l. >>> Via G. Misiticoni, 3 >>> 65126 - Pescara >>> ITALY >>> >>> >>> www.netsons.com >>> Domenico De Monte >>> CEO >>> >>> >>> t. (+39) 085 45 100 52 >>> m. (+39) 339 79 033 98 >>> e. d.demo...@netsons.com >>> >>> >>> >>> >>> Netsons è un marchio registrato dalla Supernova s.r.l. >>> >>> Le informazioni trasmesse sono riservate alla persona o alla società >>> indicata come destinatario, e possono includere contenuti considerati >>> confidenziali. Ogni elaborazione, comunicazione, trasmissione o altro >>> utilizzo, anche azioni conseguenti alla conoscenza di queste informazioni >>> da parte di chiunque non sia espressamente indicato come destinatario è >>> proibita. Nel caso abbiate ricevuto per errore questa comunicazione, siete >>> pregati di darne avviso a info [at] netsons.com ed eliminare ogni stampa ed >>> ogni traccia informatica. Il ricevente dovrà inoltre accertarsi che gli >>> eventuali allegati non contengano virus prima di aprirli. Qualunque >>> opinione o affermazione presentata in questo messaggio è da ritenersi >>> propria dell'autore e non rappresenta necessariamente la posizione della >>> Società. >>> >>> The information transmitted is intended only for the person or entity to >>> which it is addressed and may contain confidential material. Any review, >>> retransmission, dissemination or other use of, or taking of any action in >>> reliance upon this information by persons or entities other than the >>> intended recipient is prohibited. If you received this in error, please >>> contact: info [at] netsons.com and delete the material from any computer. >>> If this email contains attachments you should ensure they are checked for >>> viruses before opening them. Any views or opinions presented are solely >>> those of the author and do not necessarily represent those of the company. >>> >> -- >> @shankerbalan >> >> M: +91 98860 60539 | O: +91 (80) 67935867 >> shanker.ba...@shapeblue.com | www.shapeblue.com | Twitter:@shapeblue >> ShapeBlue Services India LLP, 22nd floor, Unit 2201A, World Trade Centre, >> Bangalore - 560 055 >> >> This email and any attachments to it may be confidential and are intended >> solely for the use of the individual to whom it is addressed. Any views or >> opinions expressed are solely those of the author and do not necessarily >> represent those of Shape Blue Ltd or related companies. If you are not the >> intended recipient of this email, you must neither take any action based >> upon its contents, nor copy or show it to anyone. Please contact the sender >> if you believe you have received this email in error. Shape Blue Ltd is a >> company incorporated in England & Wales. ShapeBlue Services India LLP is a >> company incorporated in India and is operated under license from Shape Blue >> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil >> and is operated under license from Shape Blue Ltd. ShapeBlue is a registered >> trademark. > > -- > > <netsons-logo-email.png> > > Supernova s.r.l. > Via G. Misiticoni, 3 > 65126 - Pescara > ITALY > > > www.netsons.com > Domenico De Monte > CEO > > > t. (+39) 085 45 100 52 > m. (+39) 339 79 033 98 > e. d.demo...@netsons.com > > > <btn_viewmy_160x25.png> > > Netsons® è un marchio registrato dalla Supernova s.r.l. > > Le informazioni trasmesse sono riservate alla persona o alla società indicata > come destinatario, e possono includere contenuti considerati confidenziali. > Ogni elaborazione, comunicazione, trasmissione o altro utilizzo, anche azioni > conseguenti alla conoscenza di queste informazioni da parte di chiunque non > sia espressamente indicato come destinatario è proibita. Nel caso abbiate > ricevuto per errore questa comunicazione, siete pregati di darne avviso a > info [at] netsons.com ed eliminare ogni stampa ed ogni traccia informatica. > Il ricevente dovrà inoltre accertarsi che gli eventuali allegati non > contengano virus prima di aprirli. Qualunque opinione o affermazione > presentata in questo messaggio è da ritenersi propria dell'autore e non > rappresenta necessariamente la posizione della Società. > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential material. Any review, > retransmission, dissemination or other use of, or taking of any action in > reliance upon this information by persons or entities other than the intended > recipient is prohibited. If you received this in error, please contact: info > [at] netsons.com and delete the material from any computer. If this email > contains attachments you should ensure they are checked for viruses before > opening them. Any views or opinions presented are solely those of the author > and do not necessarily represent those of the company. Supernova s.r.l. Via G. Misiticoni, 3 65126 - Pescara ITALY www.netsons.com Domenico De Monte CEO t. (+39) 085 45 100 52 m. (+39) 339 79 033 98 e. d.demo...@netsons.com Netsons è un marchio registrato dalla Supernova s.r.l. Le informazioni trasmesse sono riservate alla persona o alla società indicata come destinatario, e possono includere contenuti considerati confidenziali. Ogni elaborazione, comunicazione, trasmissione o altro utilizzo, anche azioni conseguenti alla conoscenza di queste informazioni da parte di chiunque non sia espressamente indicato come destinatario è proibita. Nel caso abbiate ricevuto per errore questa comunicazione, siete pregati di darne avviso a info [at] netsons.com ed eliminare ogni stampa ed ogni traccia informatica. Il ricevente dovrà inoltre accertarsi che gli eventuali allegati non contengano virus prima di aprirli. Qualunque opinione o affermazione presentata in questo messaggio è da ritenersi propria dell'autore e non rappresenta necessariamente la posizione della Società. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact: info [at] netsons.com and delete the material from any computer. If this email contains attachments you should ensure they are checked for viruses before opening them. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company.
