You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Rafael Weingärtner <ra...@gmail.com> on 2017/02/28 16:16:22 UTC
CloudStack Advanced networking doubt
Hi folks,
I was checking some information regarding ACS advanced networking
deployment mode, and I ran into this figure [1]. This made me wonder, what
would happen with the following scenario.
Let`s say I have a similar scenario as the one depicted in figure [1], a
set of pods with a set of clusters that have a set of hosts. Each host in a
pod is linked directly using a Layer-2 switch. Let’s assume there exist
network/aggregation layers that are configured properly and provide access
to VMs in the cloud using the public IP net. Let’s also assume that the
public IP net is 1.1.1.0/24; the management and storage networks are on
isolated networks and are properly set up (Assume also that we are using
the advanced networking mode).
Now, I create a guest network 2.2.2.0/24. When I deploy a user VM, ACS will
deploy a VR (let’s call x) with an IP (1.1.1.1) in the public net, and
other on the guest network (2.2.2.1). Then, this VR(x) will execute the
firewalling/forwarding for my newly created user VM.
Let’s now imagine that I keep deploying user VMs to a point in which the
POD gets full. The next VM I create ACS will have to deploy in other PODs
of the environment. Because this new user VM will be in a different POD,
the communication with other user VMs is not straightforward anymore (not a
matter of using the same VLAN and net). What will ACS do to link users VMs
that are on the same virtual network, but deployed in different PODs?
Will it deploy other VR(y) with an IP (let's say 1.1.1.2) on the new POD
and create a route between VR(x) and VR(y) using the public network, so
that the communication for VMs in network 2.2.2.0/24 is transparent?
http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.8/_images/network-setup-zone.png
--
Rafael Weingärtner
Re: CloudStack Advanced networking doubt
Posted by Rafael Weingärtner <ra...@gmail.com>.
Sorry Dag, I probably did not express myself clearly. I knew that ACS had
nothing to do with it. I wanted only to check the underlying structure
requirements, so the scenario I described would work.
Thanks for your explanation, I now understood it ;)
On Tue, Feb 28, 2017 at 2:09 PM, Simon Weller <sw...@ena.com> wrote:
> So, it's actually a higher level than that. Each vlan is a broadcast
> domain (it's a virtual LAN). Managed switches support the ability of
> tagging (or trunking depending on the vendor) various sets of vlans to
> physical ports. When you need a vlan to be sent to a different switch and
> you want to keep the vlan tags, you tag the port with the vlan and it gets
> transported to the connected switch. This can introduce network loops
> (broadcast storms), so spanning tree serves to shut down redundant paths to
> protect the switch fabric from experiencing loops. Each vlan operates as
> you articulated below, but each switch can handle many virtual lans (vlans).
>
>
> Within a cloudstack zone, each host within that zone (regardless of
> cluster or pod) needs access to every vlan provisioned as an isolated
> network, or vpc. This requires the network to support the transport of
> vlans across all switches providing connectivity to the zone so that all
> VMs within the isolated network can see each other.
>
> ________________________________
> From: Rafael Weingärtner <ra...@gmail.com>
> Sent: Tuesday, February 28, 2017 12:58 PM
> To: users@cloudstack.apache.org
> Subject: Re: CloudStack Advanced networking doubt
>
> Ok, let’s see if I understood what we are doing.
>
> Within a switch domain, we send packets using the mac address of network
> interface cards. The switch has a table matching mac addresses to ports
> they are being used in; therefore, it can efficiently execute the
> forwarding. When you say that we expect broadcast domain across a zone, you
> mean that switches of this zone are exchanging information regarding the
> mac address of the network interfaces they "know". Is that it?
>
> If there is a packet (Frame) that is addressed to a mac address to a
> network interface that is not within a domain of a switch, this switch may
> forward this packet to another switch that “knows” the interface that has
> the destination mac address. is that what you guys mean by "expecting
> broadcast domain across a zone"?
>
> On Tue, Feb 28, 2017 at 1:45 PM, Simon Weller <sw...@ena.com> wrote:
>
> > Rafael,
> >
> >
> > ACS expects the same layer 2 broadcast domain across all pods in a zone.
> > So your switches have to trunk all vlans. This can get really nasty for
> > larger typologies (due to vlan limits and spanning tree), hence why
> > technologies like vxlan, stt and gre were invented.
> >
> >
> > - Si
> >
> > ________________________________
> > From: Rafael Weingärtner <ra...@gmail.com>
> > Sent: Tuesday, February 28, 2017 12:41 PM
> > To: users@cloudstack.apache.org
> > Subject: Re: CloudStack Advanced networking doubt
> >
> > Great, thanks for the explanation Dag.
> > So, for two VMs that are on the same virtual network, but different PODs
> > (consequently in a different layer -2 domain switch) how does ACS handle
> in
> > this situation?
> >
> >
> > On Tue, Feb 28, 2017 at 1:36 PM, Dag Sonstebo <
> Dag.Sonstebo@shapeblue.com>
> > wrote:
> >
> > > Hi Rafael,
> > >
> > > in the confines of that zone yes. All switches serving one zone need to
> > > trunk the same VLANs, no matter how you configure your PODs or
> clusters.
> > >
> > > Regards,
> > > Dag Sonstebo
> > > Cloud Architect
> > > ShapeBlue
> > >
> > > On 28/02/2017, 18:31, "Rafael Weingärtner" <
> rafaelweingartner@gmail.com>
> > > wrote:
> > >
> > > You mean, once a user allocates a VLAN’s (let’s say tag 1), in all
> of
> > > the
> > > switches this VLAN tag is reserved?
> > >
> > > On Tue, Feb 28, 2017 at 12:48 PM, Dag Sonstebo <
> > > Dag.Sonstebo@shapeblue.com>
> > > wrote:
> > >
> > > > Hi Rafael,
> > > >
> > > > Keep in mind for an advanced zone the broadcast domain for VLANs
> is
> > > the
> > > > zone rather than the POD, i.e. VMs in the new POD would use the
> > same
> > > VLANs
> > > > as the previous VMs in the original POD.
> > > >
> > > > Regards,
> > > > Dag Sonstebo
> > > > Cloud Architect
> > > > ShapeBlue
> > > >
> > > > On 28/02/2017, 16:16, "Rafael Weingärtner" <
> > > rafaelweingartner@gmail.com>
> > > > wrote:
> > > >
> > > > Hi folks,
> > > > I was checking some information regarding ACS advanced
> > networking
> > > > deployment mode, and I ran into this figure [1]. This made me
> > > wonder,
> > > > what
> > > > would happen with the following scenario.
> > > >
> > > > Let`s say I have a similar scenario as the one depicted in
> > > figure [1],
> > > > a
> > > > set of pods with a set of clusters that have a set of hosts.
> > > Each host
> > > > in a
> > > > pod is linked directly using a Layer-2 switch. Let’s assume
> > > there exist
> > > > network/aggregation layers that are configured properly and
> > > provide
> > > > access
> > > > to VMs in the cloud using the public IP net. Let’s also
> assume
> > > that the
> > > > public IP net is 1.1.1.0/24; the management and storage
> > > networks are
> > > > on
> > > > isolated networks and are properly set up (Assume also that
> we
> > > are
> > > > using
> > > > the advanced networking mode).
> > > >
> > > > Now, I create a guest network 2.2.2.0/24. When I deploy a
> user
> > > VM,
> > > > ACS will
> > > > deploy a VR (let’s call x) with an IP (1.1.1.1) in the public
> > > net, and
> > > > other on the guest network (2.2.2.1). Then, this VR(x) will
> > > execute the
> > > > firewalling/forwarding for my newly created user VM.
> > > >
> > > > Let’s now imagine that I keep deploying user VMs to a point
> in
> > > which
> > > > the
> > > > POD gets full. The next VM I create ACS will have to deploy
> in
> > > other
> > > > PODs
> > > > of the environment. Because this new user VM will be in a
> > > different
> > > > POD,
> > > > the communication with other user VMs is not straightforward
> > > anymore
> > > > (not a
> > > > matter of using the same VLAN and net). What will ACS do to
> > link
> > > users
> > > > VMs
> > > > that are on the same virtual network, but deployed in
> different
> > > PODs?
> > > >
> > > > Will it deploy other VR(y) with an IP (let's say 1.1.1.2) on
> > the
> > > new
> > > > POD
> > > > and create a route between VR(x) and VR(y) using the public
> > > network, so
> > > > that the communication for VMs in network 2.2.2.0/24 is
> > > transparent?
> > > >
> > > > http://docs.cloudstack.apache.org/projects/cloudstack-
> > > > administration/en/4.8/_images/network-setup-zone.png
> > > >
> > > > --
> > > > Rafael Weingärtner
> > > >
> > > >
> > > >
> > > > Dag.Sonstebo@shapeblue.com
> > > > www.shapeblue.com<http://www.shapeblue.com>
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > www.shapeblue.com<http://www.shapeblue.com>
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > Introduction Upgrading CloudStack can sometimes be a little daunting -
> but
> > as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
> >
> >
> >
> > > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > > > @shapeblue
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Rafael Weingärtner
> > >
> > >
> > >
> > > Dag.Sonstebo@shapeblue.com
> > > www.shapeblue.com<http://www.shapeblue.com>
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > www.shapeblue.com<http://www.shapeblue.com>
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > Introduction Upgrading CloudStack can sometimes be a little daunting -
> but
> > as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
> >
> >
> >
> > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Rafael Weingärtner
> >
>
>
>
> --
> Rafael Weingärtner
>
--
Rafael Weingärtner
Re: CloudStack Advanced networking doubt
Posted by Simon Weller <sw...@ena.com>.
So, it's actually a higher level than that. Each vlan is a broadcast domain (it's a virtual LAN). Managed switches support the ability of tagging (or trunking depending on the vendor) various sets of vlans to physical ports. When you need a vlan to be sent to a different switch and you want to keep the vlan tags, you tag the port with the vlan and it gets transported to the connected switch. This can introduce network loops (broadcast storms), so spanning tree serves to shut down redundant paths to protect the switch fabric from experiencing loops. Each vlan operates as you articulated below, but each switch can handle many virtual lans (vlans).
Within a cloudstack zone, each host within that zone (regardless of cluster or pod) needs access to every vlan provisioned as an isolated network, or vpc. This requires the network to support the transport of vlans across all switches providing connectivity to the zone so that all VMs within the isolated network can see each other.
________________________________
From: Rafael Weingärtner <ra...@gmail.com>
Sent: Tuesday, February 28, 2017 12:58 PM
To: users@cloudstack.apache.org
Subject: Re: CloudStack Advanced networking doubt
Ok, let’s see if I understood what we are doing.
Within a switch domain, we send packets using the mac address of network
interface cards. The switch has a table matching mac addresses to ports
they are being used in; therefore, it can efficiently execute the
forwarding. When you say that we expect broadcast domain across a zone, you
mean that switches of this zone are exchanging information regarding the
mac address of the network interfaces they "know". Is that it?
If there is a packet (Frame) that is addressed to a mac address to a
network interface that is not within a domain of a switch, this switch may
forward this packet to another switch that “knows” the interface that has
the destination mac address. is that what you guys mean by "expecting
broadcast domain across a zone"?
On Tue, Feb 28, 2017 at 1:45 PM, Simon Weller <sw...@ena.com> wrote:
> Rafael,
>
>
> ACS expects the same layer 2 broadcast domain across all pods in a zone.
> So your switches have to trunk all vlans. This can get really nasty for
> larger typologies (due to vlan limits and spanning tree), hence why
> technologies like vxlan, stt and gre were invented.
>
>
> - Si
>
> ________________________________
> From: Rafael Weingärtner <ra...@gmail.com>
> Sent: Tuesday, February 28, 2017 12:41 PM
> To: users@cloudstack.apache.org
> Subject: Re: CloudStack Advanced networking doubt
>
> Great, thanks for the explanation Dag.
> So, for two VMs that are on the same virtual network, but different PODs
> (consequently in a different layer -2 domain switch) how does ACS handle in
> this situation?
>
>
> On Tue, Feb 28, 2017 at 1:36 PM, Dag Sonstebo <Da...@shapeblue.com>
> wrote:
>
> > Hi Rafael,
> >
> > in the confines of that zone yes. All switches serving one zone need to
> > trunk the same VLANs, no matter how you configure your PODs or clusters.
> >
> > Regards,
> > Dag Sonstebo
> > Cloud Architect
> > ShapeBlue
> >
> > On 28/02/2017, 18:31, "Rafael Weingärtner" <ra...@gmail.com>
> > wrote:
> >
> > You mean, once a user allocates a VLAN’s (let’s say tag 1), in all of
> > the
> > switches this VLAN tag is reserved?
> >
> > On Tue, Feb 28, 2017 at 12:48 PM, Dag Sonstebo <
> > Dag.Sonstebo@shapeblue.com>
> > wrote:
> >
> > > Hi Rafael,
> > >
> > > Keep in mind for an advanced zone the broadcast domain for VLANs is
> > the
> > > zone rather than the POD, i.e. VMs in the new POD would use the
> same
> > VLANs
> > > as the previous VMs in the original POD.
> > >
> > > Regards,
> > > Dag Sonstebo
> > > Cloud Architect
> > > ShapeBlue
> > >
> > > On 28/02/2017, 16:16, "Rafael Weingärtner" <
> > rafaelweingartner@gmail.com>
> > > wrote:
> > >
> > > Hi folks,
> > > I was checking some information regarding ACS advanced
> networking
> > > deployment mode, and I ran into this figure [1]. This made me
> > wonder,
> > > what
> > > would happen with the following scenario.
> > >
> > > Let`s say I have a similar scenario as the one depicted in
> > figure [1],
> > > a
> > > set of pods with a set of clusters that have a set of hosts.
> > Each host
> > > in a
> > > pod is linked directly using a Layer-2 switch. Let’s assume
> > there exist
> > > network/aggregation layers that are configured properly and
> > provide
> > > access
> > > to VMs in the cloud using the public IP net. Let’s also assume
> > that the
> > > public IP net is 1.1.1.0/24; the management and storage
> > networks are
> > > on
> > > isolated networks and are properly set up (Assume also that we
> > are
> > > using
> > > the advanced networking mode).
> > >
> > > Now, I create a guest network 2.2.2.0/24. When I deploy a user
> > VM,
> > > ACS will
> > > deploy a VR (let’s call x) with an IP (1.1.1.1) in the public
> > net, and
> > > other on the guest network (2.2.2.1). Then, this VR(x) will
> > execute the
> > > firewalling/forwarding for my newly created user VM.
> > >
> > > Let’s now imagine that I keep deploying user VMs to a point in
> > which
> > > the
> > > POD gets full. The next VM I create ACS will have to deploy in
> > other
> > > PODs
> > > of the environment. Because this new user VM will be in a
> > different
> > > POD,
> > > the communication with other user VMs is not straightforward
> > anymore
> > > (not a
> > > matter of using the same VLAN and net). What will ACS do to
> link
> > users
> > > VMs
> > > that are on the same virtual network, but deployed in different
> > PODs?
> > >
> > > Will it deploy other VR(y) with an IP (let's say 1.1.1.2) on
> the
> > new
> > > POD
> > > and create a route between VR(x) and VR(y) using the public
> > network, so
> > > that the communication for VMs in network 2.2.2.0/24 is
> > transparent?
> > >
> > > http://docs.cloudstack.apache.org/projects/cloudstack-
> > > administration/en/4.8/_images/network-setup-zone.png
> > >
> > > --
> > > Rafael Weingärtner
> > >
> > >
> > >
> > > Dag.Sonstebo@shapeblue.com
> > > www.shapeblue.com<http://www.shapeblue.com>
ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
www.shapeblue.com
Introduction Upgrading CloudStack can sometimes be a little daunting - but as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
www.shapeblue.com
Introduction Upgrading CloudStack can sometimes be a little daunting - but as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
> www.shapeblue.com<http://www.shapeblue.com>
ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
www.shapeblue.com
Introduction Upgrading CloudStack can sometimes be a little daunting - but as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Rafael Weingärtner
> >
> >
> >
> > Dag.Sonstebo@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
www.shapeblue.com
Introduction Upgrading CloudStack can sometimes be a little daunting - but as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
www.shapeblue.com
Introduction Upgrading CloudStack can sometimes be a little daunting - but as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
> www.shapeblue.com<http://www.shapeblue.com>
ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
www.shapeblue.com
Introduction Upgrading CloudStack can sometimes be a little daunting - but as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>
>
> --
> Rafael Weingärtner
>
--
Rafael Weingärtner
Re: CloudStack Advanced networking doubt
Posted by Dag Sonstebo <Da...@shapeblue.com>.
Hi Rafael,
I think you’re overcomplicating things a bit. As Simon said – all switches used in the same zone need to be configured to trunk the same VLAN range. If your zone uses VLANs 100-200 then all switches serving the PODs and clusters in that zone need to be able to trunk VLANs 100-200, such that you maintain traffic between VMs in the same isolated network. When UserA spins up a network and a VM, he e.g. gets allocated VLAN 101 – and it should not matter where in the zone his VMs end up – i.e. they are spread across PODs and clusters – the VM should always be able to connect to VLAN 101.
With regards to the nuts and bolts of this – yes you are working at Layer 2 on the switches, but the mechanism used to transfer traffic between them has nothing to do with CloudStack.
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
On 28/02/2017, 18:58, "Rafael Weingärtner" <ra...@gmail.com> wrote:
Ok, let’s see if I understood what we are doing.
Within a switch domain, we send packets using the mac address of network
interface cards. The switch has a table matching mac addresses to ports
they are being used in; therefore, it can efficiently execute the
forwarding. When you say that we expect broadcast domain across a zone, you
mean that switches of this zone are exchanging information regarding the
mac address of the network interfaces they "know". Is that it?
If there is a packet (Frame) that is addressed to a mac address to a
network interface that is not within a domain of a switch, this switch may
forward this packet to another switch that “knows” the interface that has
the destination mac address. is that what you guys mean by "expecting
broadcast domain across a zone"?
On Tue, Feb 28, 2017 at 1:45 PM, Simon Weller <sw...@ena.com> wrote:
> Rafael,
>
>
> ACS expects the same layer 2 broadcast domain across all pods in a zone.
> So your switches have to trunk all vlans. This can get really nasty for
> larger typologies (due to vlan limits and spanning tree), hence why
> technologies like vxlan, stt and gre were invented.
>
>
> - Si
>
> ________________________________
> From: Rafael Weingärtner <ra...@gmail.com>
> Sent: Tuesday, February 28, 2017 12:41 PM
> To: users@cloudstack.apache.org
> Subject: Re: CloudStack Advanced networking doubt
>
> Great, thanks for the explanation Dag.
> So, for two VMs that are on the same virtual network, but different PODs
> (consequently in a different layer -2 domain switch) how does ACS handle in
> this situation?
>
>
> On Tue, Feb 28, 2017 at 1:36 PM, Dag Sonstebo <Da...@shapeblue.com>
> wrote:
>
> > Hi Rafael,
> >
> > in the confines of that zone yes. All switches serving one zone need to
> > trunk the same VLANs, no matter how you configure your PODs or clusters.
> >
> > Regards,
> > Dag Sonstebo
> > Cloud Architect
> > ShapeBlue
> >
> > On 28/02/2017, 18:31, "Rafael Weingärtner" <ra...@gmail.com>
> > wrote:
> >
> > You mean, once a user allocates a VLAN’s (let’s say tag 1), in all of
> > the
> > switches this VLAN tag is reserved?
> >
> > On Tue, Feb 28, 2017 at 12:48 PM, Dag Sonstebo <
> > Dag.Sonstebo@shapeblue.com>
> > wrote:
> >
> > > Hi Rafael,
> > >
> > > Keep in mind for an advanced zone the broadcast domain for VLANs is
> > the
> > > zone rather than the POD, i.e. VMs in the new POD would use the
> same
> > VLANs
> > > as the previous VMs in the original POD.
> > >
> > > Regards,
> > > Dag Sonstebo
> > > Cloud Architect
> > > ShapeBlue
> > >
> > > On 28/02/2017, 16:16, "Rafael Weingärtner" <
> > rafaelweingartner@gmail.com>
> > > wrote:
> > >
> > > Hi folks,
> > > I was checking some information regarding ACS advanced
> networking
> > > deployment mode, and I ran into this figure [1]. This made me
> > wonder,
> > > what
> > > would happen with the following scenario.
> > >
> > > Let`s say I have a similar scenario as the one depicted in
> > figure [1],
> > > a
> > > set of pods with a set of clusters that have a set of hosts.
> > Each host
> > > in a
> > > pod is linked directly using a Layer-2 switch. Let’s assume
> > there exist
> > > network/aggregation layers that are configured properly and
> > provide
> > > access
> > > to VMs in the cloud using the public IP net. Let’s also assume
> > that the
> > > public IP net is 1.1.1.0/24; the management and storage
> > networks are
> > > on
> > > isolated networks and are properly set up (Assume also that we
> > are
> > > using
> > > the advanced networking mode).
> > >
> > > Now, I create a guest network 2.2.2.0/24. When I deploy a user
> > VM,
> > > ACS will
> > > deploy a VR (let’s call x) with an IP (1.1.1.1) in the public
> > net, and
> > > other on the guest network (2.2.2.1). Then, this VR(x) will
> > execute the
> > > firewalling/forwarding for my newly created user VM.
> > >
> > > Let’s now imagine that I keep deploying user VMs to a point in
> > which
> > > the
> > > POD gets full. The next VM I create ACS will have to deploy in
> > other
> > > PODs
> > > of the environment. Because this new user VM will be in a
> > different
> > > POD,
> > > the communication with other user VMs is not straightforward
> > anymore
> > > (not a
> > > matter of using the same VLAN and net). What will ACS do to
> link
> > users
> > > VMs
> > > that are on the same virtual network, but deployed in different
> > PODs?
> > >
> > > Will it deploy other VR(y) with an IP (let's say 1.1.1.2) on
> the
> > new
> > > POD
> > > and create a route between VR(x) and VR(y) using the public
> > network, so
> > > that the communication for VMs in network 2.2.2.0/24 is
> > transparent?
> > >
> > > http://docs.cloudstack.apache.org/projects/cloudstack-
> > > administration/en/4.8/_images/network-setup-zone.png
> > >
> > > --
> > > Rafael Weingärtner
> > >
> > >
> > >
> > > Dag.Sonstebo@shapeblue.com
> > > www.shapeblue.com<http://www.shapeblue.com>
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Rafael Weingärtner
> >
> >
> >
> > Dag.Sonstebo@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>
>
> --
> Rafael Weingärtner
>
--
Rafael Weingärtner
Dag.Sonstebo@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Re: CloudStack Advanced networking doubt
Posted by Rafael Weingärtner <ra...@gmail.com>.
Ok, let’s see if I understood what we are doing.
Within a switch domain, we send packets using the mac address of network
interface cards. The switch has a table matching mac addresses to ports
they are being used in; therefore, it can efficiently execute the
forwarding. When you say that we expect broadcast domain across a zone, you
mean that switches of this zone are exchanging information regarding the
mac address of the network interfaces they "know". Is that it?
If there is a packet (Frame) that is addressed to a mac address to a
network interface that is not within a domain of a switch, this switch may
forward this packet to another switch that “knows” the interface that has
the destination mac address. is that what you guys mean by "expecting
broadcast domain across a zone"?
On Tue, Feb 28, 2017 at 1:45 PM, Simon Weller <sw...@ena.com> wrote:
> Rafael,
>
>
> ACS expects the same layer 2 broadcast domain across all pods in a zone.
> So your switches have to trunk all vlans. This can get really nasty for
> larger typologies (due to vlan limits and spanning tree), hence why
> technologies like vxlan, stt and gre were invented.
>
>
> - Si
>
> ________________________________
> From: Rafael Weingärtner <ra...@gmail.com>
> Sent: Tuesday, February 28, 2017 12:41 PM
> To: users@cloudstack.apache.org
> Subject: Re: CloudStack Advanced networking doubt
>
> Great, thanks for the explanation Dag.
> So, for two VMs that are on the same virtual network, but different PODs
> (consequently in a different layer -2 domain switch) how does ACS handle in
> this situation?
>
>
> On Tue, Feb 28, 2017 at 1:36 PM, Dag Sonstebo <Da...@shapeblue.com>
> wrote:
>
> > Hi Rafael,
> >
> > in the confines of that zone yes. All switches serving one zone need to
> > trunk the same VLANs, no matter how you configure your PODs or clusters.
> >
> > Regards,
> > Dag Sonstebo
> > Cloud Architect
> > ShapeBlue
> >
> > On 28/02/2017, 18:31, "Rafael Weingärtner" <ra...@gmail.com>
> > wrote:
> >
> > You mean, once a user allocates a VLAN’s (let’s say tag 1), in all of
> > the
> > switches this VLAN tag is reserved?
> >
> > On Tue, Feb 28, 2017 at 12:48 PM, Dag Sonstebo <
> > Dag.Sonstebo@shapeblue.com>
> > wrote:
> >
> > > Hi Rafael,
> > >
> > > Keep in mind for an advanced zone the broadcast domain for VLANs is
> > the
> > > zone rather than the POD, i.e. VMs in the new POD would use the
> same
> > VLANs
> > > as the previous VMs in the original POD.
> > >
> > > Regards,
> > > Dag Sonstebo
> > > Cloud Architect
> > > ShapeBlue
> > >
> > > On 28/02/2017, 16:16, "Rafael Weingärtner" <
> > rafaelweingartner@gmail.com>
> > > wrote:
> > >
> > > Hi folks,
> > > I was checking some information regarding ACS advanced
> networking
> > > deployment mode, and I ran into this figure [1]. This made me
> > wonder,
> > > what
> > > would happen with the following scenario.
> > >
> > > Let`s say I have a similar scenario as the one depicted in
> > figure [1],
> > > a
> > > set of pods with a set of clusters that have a set of hosts.
> > Each host
> > > in a
> > > pod is linked directly using a Layer-2 switch. Let’s assume
> > there exist
> > > network/aggregation layers that are configured properly and
> > provide
> > > access
> > > to VMs in the cloud using the public IP net. Let’s also assume
> > that the
> > > public IP net is 1.1.1.0/24; the management and storage
> > networks are
> > > on
> > > isolated networks and are properly set up (Assume also that we
> > are
> > > using
> > > the advanced networking mode).
> > >
> > > Now, I create a guest network 2.2.2.0/24. When I deploy a user
> > VM,
> > > ACS will
> > > deploy a VR (let’s call x) with an IP (1.1.1.1) in the public
> > net, and
> > > other on the guest network (2.2.2.1). Then, this VR(x) will
> > execute the
> > > firewalling/forwarding for my newly created user VM.
> > >
> > > Let’s now imagine that I keep deploying user VMs to a point in
> > which
> > > the
> > > POD gets full. The next VM I create ACS will have to deploy in
> > other
> > > PODs
> > > of the environment. Because this new user VM will be in a
> > different
> > > POD,
> > > the communication with other user VMs is not straightforward
> > anymore
> > > (not a
> > > matter of using the same VLAN and net). What will ACS do to
> link
> > users
> > > VMs
> > > that are on the same virtual network, but deployed in different
> > PODs?
> > >
> > > Will it deploy other VR(y) with an IP (let's say 1.1.1.2) on
> the
> > new
> > > POD
> > > and create a route between VR(x) and VR(y) using the public
> > network, so
> > > that the communication for VMs in network 2.2.2.0/24 is
> > transparent?
> > >
> > > http://docs.cloudstack.apache.org/projects/cloudstack-
> > > administration/en/4.8/_images/network-setup-zone.png
> > >
> > > --
> > > Rafael Weingärtner
> > >
> > >
> > >
> > > Dag.Sonstebo@shapeblue.com
> > > www.shapeblue.com<http://www.shapeblue.com>
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Rafael Weingärtner
> >
> >
> >
> > Dag.Sonstebo@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
> ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
> www.shapeblue.com
> Introduction Upgrading CloudStack can sometimes be a little daunting - but
> as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
>
>
>
> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>
>
> --
> Rafael Weingärtner
>
--
Rafael Weingärtner
Re: CloudStack Advanced networking doubt
Posted by Simon Weller <sw...@ena.com>.
Rafael,
ACS expects the same layer 2 broadcast domain across all pods in a zone. So your switches have to trunk all vlans. This can get really nasty for larger typologies (due to vlan limits and spanning tree), hence why technologies like vxlan, stt and gre were invented.
- Si
________________________________
From: Rafael Weingärtner <ra...@gmail.com>
Sent: Tuesday, February 28, 2017 12:41 PM
To: users@cloudstack.apache.org
Subject: Re: CloudStack Advanced networking doubt
Great, thanks for the explanation Dag.
So, for two VMs that are on the same virtual network, but different PODs
(consequently in a different layer -2 domain switch) how does ACS handle in
this situation?
On Tue, Feb 28, 2017 at 1:36 PM, Dag Sonstebo <Da...@shapeblue.com>
wrote:
> Hi Rafael,
>
> in the confines of that zone yes. All switches serving one zone need to
> trunk the same VLANs, no matter how you configure your PODs or clusters.
>
> Regards,
> Dag Sonstebo
> Cloud Architect
> ShapeBlue
>
> On 28/02/2017, 18:31, "Rafael Weingärtner" <ra...@gmail.com>
> wrote:
>
> You mean, once a user allocates a VLAN’s (let’s say tag 1), in all of
> the
> switches this VLAN tag is reserved?
>
> On Tue, Feb 28, 2017 at 12:48 PM, Dag Sonstebo <
> Dag.Sonstebo@shapeblue.com>
> wrote:
>
> > Hi Rafael,
> >
> > Keep in mind for an advanced zone the broadcast domain for VLANs is
> the
> > zone rather than the POD, i.e. VMs in the new POD would use the same
> VLANs
> > as the previous VMs in the original POD.
> >
> > Regards,
> > Dag Sonstebo
> > Cloud Architect
> > ShapeBlue
> >
> > On 28/02/2017, 16:16, "Rafael Weingärtner" <
> rafaelweingartner@gmail.com>
> > wrote:
> >
> > Hi folks,
> > I was checking some information regarding ACS advanced networking
> > deployment mode, and I ran into this figure [1]. This made me
> wonder,
> > what
> > would happen with the following scenario.
> >
> > Let`s say I have a similar scenario as the one depicted in
> figure [1],
> > a
> > set of pods with a set of clusters that have a set of hosts.
> Each host
> > in a
> > pod is linked directly using a Layer-2 switch. Let’s assume
> there exist
> > network/aggregation layers that are configured properly and
> provide
> > access
> > to VMs in the cloud using the public IP net. Let’s also assume
> that the
> > public IP net is 1.1.1.0/24; the management and storage
> networks are
> > on
> > isolated networks and are properly set up (Assume also that we
> are
> > using
> > the advanced networking mode).
> >
> > Now, I create a guest network 2.2.2.0/24. When I deploy a user
> VM,
> > ACS will
> > deploy a VR (let’s call x) with an IP (1.1.1.1) in the public
> net, and
> > other on the guest network (2.2.2.1). Then, this VR(x) will
> execute the
> > firewalling/forwarding for my newly created user VM.
> >
> > Let’s now imagine that I keep deploying user VMs to a point in
> which
> > the
> > POD gets full. The next VM I create ACS will have to deploy in
> other
> > PODs
> > of the environment. Because this new user VM will be in a
> different
> > POD,
> > the communication with other user VMs is not straightforward
> anymore
> > (not a
> > matter of using the same VLAN and net). What will ACS do to link
> users
> > VMs
> > that are on the same virtual network, but deployed in different
> PODs?
> >
> > Will it deploy other VR(y) with an IP (let's say 1.1.1.2) on the
> new
> > POD
> > and create a route between VR(x) and VR(y) using the public
> network, so
> > that the communication for VMs in network 2.2.2.0/24 is
> transparent?
> >
> > http://docs.cloudstack.apache.org/projects/cloudstack-
> > administration/en/4.8/_images/network-setup-zone.png
> >
> > --
> > Rafael Weingärtner
> >
> >
> >
> > Dag.Sonstebo@shapeblue.com
> > www.shapeblue.com<http://www.shapeblue.com>
ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
www.shapeblue.com
Introduction Upgrading CloudStack can sometimes be a little daunting - but as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>
>
> --
> Rafael Weingärtner
>
>
>
> Dag.Sonstebo@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
ShapeBlue - The CloudStack Company<http://www.shapeblue.com/>
www.shapeblue.com
Introduction Upgrading CloudStack can sometimes be a little daunting - but as the 5P's proverb goes - Proper Planning Prevents Poor Performance.
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
>
>
>
>
--
Rafael Weingärtner
Re: CloudStack Advanced networking doubt
Posted by Rafael Weingärtner <ra...@gmail.com>.
Great, thanks for the explanation Dag.
So, for two VMs that are on the same virtual network, but different PODs
(consequently in a different layer -2 domain switch) how does ACS handle in
this situation?
On Tue, Feb 28, 2017 at 1:36 PM, Dag Sonstebo <Da...@shapeblue.com>
wrote:
> Hi Rafael,
>
> in the confines of that zone yes. All switches serving one zone need to
> trunk the same VLANs, no matter how you configure your PODs or clusters.
>
> Regards,
> Dag Sonstebo
> Cloud Architect
> ShapeBlue
>
> On 28/02/2017, 18:31, "Rafael Weingärtner" <ra...@gmail.com>
> wrote:
>
> You mean, once a user allocates a VLAN’s (let’s say tag 1), in all of
> the
> switches this VLAN tag is reserved?
>
> On Tue, Feb 28, 2017 at 12:48 PM, Dag Sonstebo <
> Dag.Sonstebo@shapeblue.com>
> wrote:
>
> > Hi Rafael,
> >
> > Keep in mind for an advanced zone the broadcast domain for VLANs is
> the
> > zone rather than the POD, i.e. VMs in the new POD would use the same
> VLANs
> > as the previous VMs in the original POD.
> >
> > Regards,
> > Dag Sonstebo
> > Cloud Architect
> > ShapeBlue
> >
> > On 28/02/2017, 16:16, "Rafael Weingärtner" <
> rafaelweingartner@gmail.com>
> > wrote:
> >
> > Hi folks,
> > I was checking some information regarding ACS advanced networking
> > deployment mode, and I ran into this figure [1]. This made me
> wonder,
> > what
> > would happen with the following scenario.
> >
> > Let`s say I have a similar scenario as the one depicted in
> figure [1],
> > a
> > set of pods with a set of clusters that have a set of hosts.
> Each host
> > in a
> > pod is linked directly using a Layer-2 switch. Let’s assume
> there exist
> > network/aggregation layers that are configured properly and
> provide
> > access
> > to VMs in the cloud using the public IP net. Let’s also assume
> that the
> > public IP net is 1.1.1.0/24; the management and storage
> networks are
> > on
> > isolated networks and are properly set up (Assume also that we
> are
> > using
> > the advanced networking mode).
> >
> > Now, I create a guest network 2.2.2.0/24. When I deploy a user
> VM,
> > ACS will
> > deploy a VR (let’s call x) with an IP (1.1.1.1) in the public
> net, and
> > other on the guest network (2.2.2.1). Then, this VR(x) will
> execute the
> > firewalling/forwarding for my newly created user VM.
> >
> > Let’s now imagine that I keep deploying user VMs to a point in
> which
> > the
> > POD gets full. The next VM I create ACS will have to deploy in
> other
> > PODs
> > of the environment. Because this new user VM will be in a
> different
> > POD,
> > the communication with other user VMs is not straightforward
> anymore
> > (not a
> > matter of using the same VLAN and net). What will ACS do to link
> users
> > VMs
> > that are on the same virtual network, but deployed in different
> PODs?
> >
> > Will it deploy other VR(y) with an IP (let's say 1.1.1.2) on the
> new
> > POD
> > and create a route between VR(x) and VR(y) using the public
> network, so
> > that the communication for VMs in network 2.2.2.0/24 is
> transparent?
> >
> > http://docs.cloudstack.apache.org/projects/cloudstack-
> > administration/en/4.8/_images/network-setup-zone.png
> >
> > --
> > Rafael Weingärtner
> >
> >
> >
> > Dag.Sonstebo@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>
>
> --
> Rafael Weingärtner
>
>
>
> Dag.Sonstebo@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
>
>
>
>
--
Rafael Weingärtner
Re: CloudStack Advanced networking doubt
Posted by Dag Sonstebo <Da...@shapeblue.com>.
Hi Rafael,
in the confines of that zone yes. All switches serving one zone need to trunk the same VLANs, no matter how you configure your PODs or clusters.
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
On 28/02/2017, 18:31, "Rafael Weingärtner" <ra...@gmail.com> wrote:
You mean, once a user allocates a VLAN’s (let’s say tag 1), in all of the
switches this VLAN tag is reserved?
On Tue, Feb 28, 2017 at 12:48 PM, Dag Sonstebo <Da...@shapeblue.com>
wrote:
> Hi Rafael,
>
> Keep in mind for an advanced zone the broadcast domain for VLANs is the
> zone rather than the POD, i.e. VMs in the new POD would use the same VLANs
> as the previous VMs in the original POD.
>
> Regards,
> Dag Sonstebo
> Cloud Architect
> ShapeBlue
>
> On 28/02/2017, 16:16, "Rafael Weingärtner" <ra...@gmail.com>
> wrote:
>
> Hi folks,
> I was checking some information regarding ACS advanced networking
> deployment mode, and I ran into this figure [1]. This made me wonder,
> what
> would happen with the following scenario.
>
> Let`s say I have a similar scenario as the one depicted in figure [1],
> a
> set of pods with a set of clusters that have a set of hosts. Each host
> in a
> pod is linked directly using a Layer-2 switch. Let’s assume there exist
> network/aggregation layers that are configured properly and provide
> access
> to VMs in the cloud using the public IP net. Let’s also assume that the
> public IP net is 1.1.1.0/24; the management and storage networks are
> on
> isolated networks and are properly set up (Assume also that we are
> using
> the advanced networking mode).
>
> Now, I create a guest network 2.2.2.0/24. When I deploy a user VM,
> ACS will
> deploy a VR (let’s call x) with an IP (1.1.1.1) in the public net, and
> other on the guest network (2.2.2.1). Then, this VR(x) will execute the
> firewalling/forwarding for my newly created user VM.
>
> Let’s now imagine that I keep deploying user VMs to a point in which
> the
> POD gets full. The next VM I create ACS will have to deploy in other
> PODs
> of the environment. Because this new user VM will be in a different
> POD,
> the communication with other user VMs is not straightforward anymore
> (not a
> matter of using the same VLAN and net). What will ACS do to link users
> VMs
> that are on the same virtual network, but deployed in different PODs?
>
> Will it deploy other VR(y) with an IP (let's say 1.1.1.2) on the new
> POD
> and create a route between VR(x) and VR(y) using the public network, so
> that the communication for VMs in network 2.2.2.0/24 is transparent?
>
> http://docs.cloudstack.apache.org/projects/cloudstack-
> administration/en/4.8/_images/network-setup-zone.png
>
> --
> Rafael Weingärtner
>
>
>
> Dag.Sonstebo@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
>
>
>
>
--
Rafael Weingärtner
Dag.Sonstebo@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Re: CloudStack Advanced networking doubt
Posted by Rafael Weingärtner <ra...@gmail.com>.
You mean, once a user allocates a VLAN’s (let’s say tag 1), in all of the
switches this VLAN tag is reserved?
On Tue, Feb 28, 2017 at 12:48 PM, Dag Sonstebo <Da...@shapeblue.com>
wrote:
> Hi Rafael,
>
> Keep in mind for an advanced zone the broadcast domain for VLANs is the
> zone rather than the POD, i.e. VMs in the new POD would use the same VLANs
> as the previous VMs in the original POD.
>
> Regards,
> Dag Sonstebo
> Cloud Architect
> ShapeBlue
>
> On 28/02/2017, 16:16, "Rafael Weingärtner" <ra...@gmail.com>
> wrote:
>
> Hi folks,
> I was checking some information regarding ACS advanced networking
> deployment mode, and I ran into this figure [1]. This made me wonder,
> what
> would happen with the following scenario.
>
> Let`s say I have a similar scenario as the one depicted in figure [1],
> a
> set of pods with a set of clusters that have a set of hosts. Each host
> in a
> pod is linked directly using a Layer-2 switch. Let’s assume there exist
> network/aggregation layers that are configured properly and provide
> access
> to VMs in the cloud using the public IP net. Let’s also assume that the
> public IP net is 1.1.1.0/24; the management and storage networks are
> on
> isolated networks and are properly set up (Assume also that we are
> using
> the advanced networking mode).
>
> Now, I create a guest network 2.2.2.0/24. When I deploy a user VM,
> ACS will
> deploy a VR (let’s call x) with an IP (1.1.1.1) in the public net, and
> other on the guest network (2.2.2.1). Then, this VR(x) will execute the
> firewalling/forwarding for my newly created user VM.
>
> Let’s now imagine that I keep deploying user VMs to a point in which
> the
> POD gets full. The next VM I create ACS will have to deploy in other
> PODs
> of the environment. Because this new user VM will be in a different
> POD,
> the communication with other user VMs is not straightforward anymore
> (not a
> matter of using the same VLAN and net). What will ACS do to link users
> VMs
> that are on the same virtual network, but deployed in different PODs?
>
> Will it deploy other VR(y) with an IP (let's say 1.1.1.2) on the new
> POD
> and create a route between VR(x) and VR(y) using the public network, so
> that the communication for VMs in network 2.2.2.0/24 is transparent?
>
> http://docs.cloudstack.apache.org/projects/cloudstack-
> administration/en/4.8/_images/network-setup-zone.png
>
> --
> Rafael Weingärtner
>
>
>
> Dag.Sonstebo@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
>
>
>
>
--
Rafael Weingärtner
Re: CloudStack Advanced networking doubt
Posted by Dag Sonstebo <Da...@shapeblue.com>.
Hi Rafael,
Keep in mind for an advanced zone the broadcast domain for VLANs is the zone rather than the POD, i.e. VMs in the new POD would use the same VLANs as the previous VMs in the original POD.
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
On 28/02/2017, 16:16, "Rafael Weingärtner" <ra...@gmail.com> wrote:
Hi folks,
I was checking some information regarding ACS advanced networking
deployment mode, and I ran into this figure [1]. This made me wonder, what
would happen with the following scenario.
Let`s say I have a similar scenario as the one depicted in figure [1], a
set of pods with a set of clusters that have a set of hosts. Each host in a
pod is linked directly using a Layer-2 switch. Let’s assume there exist
network/aggregation layers that are configured properly and provide access
to VMs in the cloud using the public IP net. Let’s also assume that the
public IP net is 1.1.1.0/24; the management and storage networks are on
isolated networks and are properly set up (Assume also that we are using
the advanced networking mode).
Now, I create a guest network 2.2.2.0/24. When I deploy a user VM, ACS will
deploy a VR (let’s call x) with an IP (1.1.1.1) in the public net, and
other on the guest network (2.2.2.1). Then, this VR(x) will execute the
firewalling/forwarding for my newly created user VM.
Let’s now imagine that I keep deploying user VMs to a point in which the
POD gets full. The next VM I create ACS will have to deploy in other PODs
of the environment. Because this new user VM will be in a different POD,
the communication with other user VMs is not straightforward anymore (not a
matter of using the same VLAN and net). What will ACS do to link users VMs
that are on the same virtual network, but deployed in different PODs?
Will it deploy other VR(y) with an IP (let's say 1.1.1.2) on the new POD
and create a route between VR(x) and VR(y) using the public network, so
that the communication for VMs in network 2.2.2.0/24 is transparent?
http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.8/_images/network-setup-zone.png
--
Rafael Weingärtner
Dag.Sonstebo@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue