cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Domenico De Monte <>
Subject Re: public ip of system vm and public ip of guest vm on same network segment overlaps
Date Wed, 04 Dec 2013 08:05:03 GMT
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:
( 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 <> ha

> Comments inline.
> On 04-Dec-2013, at 6:18 am, Domenico De Monte <> 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
>> On public traffic ( system vm i think ) i setup a range like following ( example
>> gw:
>> netmask:
>> start ip:
>> 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:
>> netmask:
>> start ip:
>> end ip:
>> 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
> 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: 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 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 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.
> 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
> | | 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
Domenico De Monte

t. (+39) 085 45 100 52
m. (+39) 339 79 033 98


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message