public ip of system vm and public ip of guest vm on same network segment overlaps

[Domenico De Monte <d....@netsons.com>]

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 )

2 nic connected to physical private switch ( vSwitch1 standard )

On CS i create a zone with advanced network and 5 physical interface:
1 physical interface for Public traffic connected to vSwitch0 ( i think 
it's system vm public traffic ).
1 physical interface for Guest traffic connected to vSwitch0 ( i think 
it's guest vm public traffic ).
1 physical interface for Guest traffic connected to vSwitch1 ( i think 
it's guest vm lan traffic ).
1 physical interface for Storage traffic connected to vSwitch1 ( i am 
sure it's storage traffic for snapshot, deploy and so on ).
1 physical interface for Management traffic connected to vSwitch1 ( i am 
sure it's for system vm traffic and so on ).


I do not want use vlan and i read on ml that if i do not setup them, 
they are just ignore from CS.

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


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.

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.
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.

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 ?

2) There is no other solution ? Can i skip somehow CS warning about 
netmask/gw overlap ?


Waiting for your reply


Best regards

Re: public ip of system vm and public ip of guest vm on same network segment overlaps

[Domenico De Monte <d....@netsons.com>]

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....@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....@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 <sh...@shapeblue.com> ha scritto:
>>> 
>>>> Comments inline.
>>>> 
>>>> On 04-Dec-2013, at 6:18 am, Domenico De Monte <d....@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.balan@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.demonte@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.balan@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.demonte@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.demonte@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.

Re: public ip of system vm and public ip of guest vm on same network segment overlaps

[Domenico De Monte <d....@netsons.com>]

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....@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 <sh...@shapeblue.com> ha scritto:
>>
>>> Comments inline.
>>>
>>> On 04-Dec-2013, at 6:18 am, Domenico De Monte <d....@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.balan@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.demonte@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.balan@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* <http://www.netsons.com> 	
*Domenico De Monte*
CEO
//

*t. *(+39) 085 45 100 52
*m. *(+39) 339 79 033 98
*e. *d.demonte@netsons.com <ma...@netsons.com>


View Domenico De Monte's profile on LinkedIn 
<http://it.linkedin.com/in/domenicodemonte>



/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.

Re: public ip of system vm and public ip of guest vm on same network segment overlaps

[Shanker Balan <sh...@shapeblue.com>]

On 04-Dec-2013, at 1:35 pm, Domenico De Monte <d....@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 <sh...@shapeblue.com> ha scritto:
>
>> Comments inline.
>>
>> On 04-Dec-2013, at 6:18 am, Domenico De Monte <d....@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.balan@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.demonte@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.balan@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.

Re: public ip of system vm and public ip of guest vm on same network segment overlaps

[Domenico De Monte <d....@netsons.com>]

Before all, thank you for your reply. You explain me many concepts, really important to know, that were not clear in CS documentation. 

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 )
1 physical interface for internal traffic ( Management traffic, Storage traffic, guest internal traffic both connected to vSwitch1 ). I want separate guest internal traffic with guest public traffic for many reasons. 

You said that for guest traffic, a hard requirement is VLAN usage. Meanwhile for public traffic, management and storage VLAN is not needed.

This point here is crucial because i still do not understand difference between public traffic and guest public traffic.

If i understand, public traffic of a zone is for system vm only ? And guest public traffic is for guest vm only ?

If so, why if we use basic network configuration, we do not have “overlaps” network issue ? Of course in this case we can not let users use internal physical switch ( vswitch1 ) for lan traffic.


Anyway my target is still to reduce public IPs usage and of course do not use SNAT.

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 :) )

But following this i still have problem of CS network overlaps if i want use same /24 for both type of public traffic.


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.

Assign for each vm a VLAN for public traffic, we will lose many ips just for subnetting. 


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 ?

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.


Waiting for your reply

Best regards


Il giorno 04/dic/2013, alle ore 05:24, Shanker Balan <sh...@shapeblue.com> ha scritto:

> Comments inline.
> 
> On 04-Dec-2013, at 6:18 am, Domenico De Monte <d....@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.balan@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.demonte@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.

Re: public ip of system vm and public ip of guest vm on same network segment overlaps

[Shanker Balan <sh...@shapeblue.com>]

Comments inline.

On 04-Dec-2013, at 6:18 am, Domenico De Monte <d....@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.balan@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.