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
