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 <[email protected]> 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 <[email protected]> > Sent: Tuesday, February 28, 2017 12:58 PM > To: [email protected] > 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 <[email protected]> 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 <[email protected]> > > Sent: Tuesday, February 28, 2017 12:41 PM > > To: [email protected] > > 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 < > [email protected]> > > 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" < > [email protected]> > > > 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 < > > > [email protected]> > > > 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" < > > > [email protected]> > > > > 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 > > > > > > > > > > > > > > > > [email protected] > > > > 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 > > > > > > > > > > > > [email protected] > > > 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
