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" <rafaelweingart...@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 <swel...@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 <rafaelweingart...@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.sonst...@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" <rafaelweingart...@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.sonst...@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" <
> > rafaelweingart...@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.sonst...@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.sonst...@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.sonst...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
