Mailing-List: contact cloudstack-users-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-users@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of aottonello@gmail.com designates
 209.85.216.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <F95EC5DFF06AE04FA54C508ED869D0D2C0E186@agcex01.CORP.ISWEST.NET>
References: 
 <CACB8oCfy9ik1+U3Z9VcbdUPO8MAc_cL04_2qJE0NcehJJOK6nA@mail.gmail.com>
	<CAA3XVTw61SbzBGnT=N5K3QoW+T=a-mqJV118H3po7g2f7S6oEQ@mail.gmail.com>
	<CACB8oCcmyGfBEv0q=vmoKMR2mzmgntZz9Bq5P4QUDZ7H9VXFww@mail.gmail.com>
	<F95EC5DFF06AE04FA54C508ED869D0D2C0DC17@agcex01.CORP.ISWEST.NET>
	<CABVfzuRZXNfynXoiMEOWyNKU3e6cXPDqwDQTwavqM9RUeKeNKg@mail.gmail.com>
	<F95EC5DFF06AE04FA54C508ED869D0D2C0E186@agcex01.CORP.ISWEST.NET>
Date: Sat, 2 Mar 2013 09:10:42 +0100
Message-ID: 
 <CABVfzuS5bEKKnKdv3cc3Dn8VsWpM22FEwjf9rUHK-KQKdZNpSQ@mail.gmail.com>
Subject: Re: How the vm<->vm communicate each other?
From: Andrea Ottonello <aottonello@gmail.com>
To: cloudstack-users@incubator.apache.org
Content-Type: multipart/alternative; boundary=047d7b676e6e022c4404d6eca9e3

--047d7b676e6e022c4404d6eca9e3
Content-Type: text/plain; charset=ISO-8859-1

Thank you! I first created a zone without sec groups and noticed that there
was no way. I recreated with SG enabled and tried but maybe I missed
something, I will try again now that I'm sure it should work and that I
read the article.


2013/3/1 Clayton Weise <cweise@iswest.net>

> With security groups enabled, you should be able to go into the network
> and make the changes required.  You can find instructions here:
>
>
> http://incubator.apache.org/cloudstack/docs/en-US/Apache_CloudStack/4.0.0-incubating/html/Installation_Guide/security-groups.html
>
> If that's not available then your network isn't using security groups.
>  I've seen this happen before where security groups _should_ be disabled
> but aren't because of a global setting called
> "network.securitygroups.defaultadding" which is true by default.  That
> throws all instances into the default security group, which (by default)
> blocks all traffic except for established traffic.  The problem though is
> if the network offering chosen doesn't support security groups, it still
> seems to throw them in there anyway which means all traffic to an instance
> is blocked with no way to actually _change_ that since security groups
> aren't enabled.  It's one of the weird ways that CloudStack will screw
> itself into the ground without knowing that little piece of knowledge...
>
> -----Original Message-----
> From: Andrea Ottonello [mailto:aottonello@gmail.com]
> Sent: Friday, March 1, 2013 9:16 AM
> To: cloudstack-users@incubator.apache.org
> Subject: Re: How the vm<->vm communicate each other?
>
> Hallo Clayton a little question on scenario I Basic: could you please tell
> me how can I permit traffic between VMs? I would like to permit VMs to
> "talk" with each other. From what you say, default for Basic is that every
> machine only allows outgoing traffic and answers to its requests. And
> actually I tried unsuccessfully to ping from a VM to another...
> Thank you.
>
>
> 2013/3/1 Clayton Weise <cweise@iswest.net>
>
> > Wang, I replied to your question on LinkedIn as well.  I'll respond to
> > each of your questions as they relate to both basic AND advanced
> networks:
> >
> > > Scenario I :
> > > All VMs belong to one account in the same vlan deploy to the same host.
> >
> > Basic network: All VMs belong to one account but they each have separate
> > security group rules (a set of rules for each instance).  Unlike
> > Amazon/Eucalyptus there is no private network with NAT going on in a
> basic
> > network.  In a basic network public ip addresses are assigned _directly_
> to
> > the VM.  Each VM has its own security group rules, which by default, only
> > allow established traffic.  The virtual router does not route, it only
> > provides DHCP and DNS services.
> >
> > Advanced network: VMs belonging to one account and one network (accounts
> > can have more than one network) are all on the same VLAN or SDN group and
> > no filtering is done between them (all traffic between VMs in the same
> > network is permitted).  Only established traffic is permitted and
> anything
> > else must be mapped through via NAT.  In advanced networks, all traffic
> > routes through the virtual router (NAT).
> >
> > Scenario II:
> > > VMs in the same vlan deploy to the same host but belong to different
> > > accouts.
> >
> > Basic network: Same as above -- _Every_ VM has its own security rules.
>  It
> > does not matter which account owns them, by default all traffic that is
> not
> > established from the instance is blocked.
> >
> > Advanced network: This scenario is impossible in advanced networks.  Two
> > accounts cannot have VMs on the same VLAN.  In advanced networking each
> > account would have separate networks and separate VLANs.
> >
> > > Scenario III:
> > > VMs in different vlan deploy to the same host and belong to same
> account.
> >
> > Basic network: I believe this is possible in basic networking if two
> > different public subnets had different VLAN tags.  The same security
> group
> > rules would apply as previously stated.  Only established traffic would
> be
> > permitted unless a security group rule permitted otherwise.  No inherent
> > trust exists just because they belong to the same account.
> >
> > Advanced network: With a VPC enabled, inter-vlan routing can be
> permitted.
> >  By default only established traffic is permitted and the two VLANs
> cannot
> > communicate to each other.  But rules can be enabled which will allow the
> > different VLANs to communicate with one-another on specific ports and
> > protocols.  Without VPCs, traffic from one VLAN would NAT out through a
> > public IP address to talk to the public IP address of another VLAN and
> > through that other virtual router.  If you're familiar with Amazon EC2
> and
> > Eucalyptus, this is exactly the same way that they operate.
> >
> > > Scenario IV:
> > > All VMs belong to one account in the same vlan deploy to the different
> > > hosts.
> >
> > Basic network: Same as Scenario I, assuming your switch supports VLAN
> > tagging and allows the traffic across.
> >
> > Advanced networking: Same as Scenario I, assuming your switch supports
> > VLAN tagging and allows the traffic across.
> >
> > -----Original Message-----
> > From: Wang Fei [mailto:pythonee@gmail.com]
> > Sent: Thursday, February 28, 2013 6:31 PM
> > To: Bryan Whitehead
> > Cc: cloudstack-users@incubator.apache.org
> > Subject: Re: How the vm<->vm communicate each other?
> >
> > What if scenario 1 in basic network?
> >
> > It have to support security group to isolate resource belong to different
> > accounts.
> >
> > in that way VMs have to communicate with VR!
> >
> > is that correct?
> >
> >
> >
> >
> > ----
> > best regards
> >
> >
> > On Fri, Mar 1, 2013 at 9:09 AM, Bryan Whitehead <driver@megahappy.net
> > >wrote:
> >
> > > As long as VM's are in the same vlan all VM's can communicate. Account
> > > settings or where the VM's are running should be irrelevant  Your
> > switches
> > > should support tagging and should be setup in trunk mode or some other
> > vlan
> > > access mode.
> > >
> > >
> > >
> > > On Thu, Feb 28, 2013 at 4:35 AM, Wang Fei <pythonee@gmail.com> wrote:
> > >
> > >> Scenario I :
> > >> All VMs belong to one account in the same vlan deploy to the same
> host.
> > >>
> > >> Scenario II:
> > >> VMs in the same vlan deploy to the same host but belong to different
> > >> accouts.
> > >>
> > >>
> > >> Scenario III:
> > >> VMs in different vlan deploy to the same host and belong to same
> > account.
> > >>
> > >> Scenario IV:
> > >> All VMs belong to one account in the same vlan deploy to the different
> > >> hosts.
> > >>
> > >>
> > >>
> > >> ----
> > >> best regards
> > >>
> > >
> > >
> >
>
>
>
> --
> Andrea Ottonello
>


-- 
Andrea Ottonello

--047d7b676e6e022c4404d6eca9e3--