You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Bryan Whitehead <dr...@megahappy.net> on 2013/03/01 02:09:04 UTC
Re: How the vm<->vm communicate each other?
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 <py...@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
>
Re: How the vm<->vm communicate each other?
Posted by Andrea Ottonello <ao...@gmail.com>.
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 <cw...@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 <cw...@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 <py...@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
RE: How the vm<->vm communicate each other?
Posted by Clayton Weise <cw...@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 <cw...@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 <py...@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
Re: How the vm<->vm communicate each other?
Posted by Andrea Ottonello <ao...@gmail.com>.
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 <cw...@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 <py...@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
RE: How the vm<->vm communicate each other?
Posted by Clayton Weise <cw...@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 <dr...@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 <py...@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
>>
>
>
Re: How the vm<->vm communicate each other?
Posted by Wang Fei <py...@gmail.com>.
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 <dr...@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 <py...@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
>>
>
>