Original subtitles

This document also provides a lot of information about multiple spending tree who ate at one s You're

not expected to know all the detail in this document but it provides a nice reference if you're interested

I'll cover some of the basics now and then you can read the document if you are interested in more information

multiple spending tree is the new industry standard.

Inspired by Cisco's proprietary multiple instant spending free protocol Cisco developed multiple instant

spending tree protocol to solve some of the issues that you have with previous t.

So as the number of villans configured in switched networks increases the overhead when running PV t

also increases.

If you configure a thousand villans with previous t and rapid Peavey's t you end up having a thousand

spending tree instances but with multiple spending tree and the proprietary multiple instance spending

tree that existed before multiple spending tree you can map a number of villans to the same spanning

tree instance.

It's fairly simple to do this but the idea is if you had a thousand villans you would allocate 500 to

one instance and the other 500 to another instance.

Which means you only have two spanning tree instances rather than 1000 spending instances so multiple

spending tree standardizes the concept of multiple spanning trees and incorporates the convergence of

a rapid spending tree multiple spending tree allows you to group the villains to a shared spending tree

instance.

It also defines a protocol for interconnecting multiple spending Creve regions how to interrupt borate

with existing attitude of one D and attitude at one key spending tree implementations and provide some

best practices so look at this document if you're interested in a lot of detail.

But as a quick comparison.

You mentioned you had a thousand villans on switchy which is connected to both switch d 1 and D to send

this apology.

Switchy has a thousand villans D1 is going to be the spending tree root for Sunday lands and D-2 is

going to be the spending tree root for other villans So switch D-1 is configured to be the root for

villans 501 T-1000 D2 is the root for Villines one to 500.

The interface from switch to switch D-1 blocks villans one to five hundred and from switch a to d two

blocks villans 501 to 1000.

So once again root for these villans traffic will be forwarded out of this port for those villans but

blocked for Villines 1 to 500.

The switch is the root for these villans this port will forward traffic out of it for villans 1 to 500

but will block of villans 500 and one to 1000.

It's very inefficient to maintain a thousand spending instances in this network.

We have 500 spending instances with D-1 as the root and we have 500 with D2 as the root.

But logically we actually only require two instances D-1 should be the root.

For instance one that contains these villains and D2 should be the root.

For instance 2 that contains these villains.

You associate these villans to instance one and make D-1 the root.

You associate these villains to instance two and make D2 the root.

That means you have to maintain two instances rather than a thousand instances.

So that kind of detail is explained here I'll go through it quickly in a Cecka previous environment.

You need one spending instance for every LAN which means you have a thousand instances for the two different

final logical typologies with D-1 is the root for one typology and D2 the root for the other typology.

This wastes a lot of sleep cycles for all the switches in the network.

In addition to the bandwidth used by sinning BPT use a thousand BPT use are going to be sent out of

every port every two seconds because Peavey's t since a BPU for every villain because we have an individual

instance mapped to every villain.

So the idea with multiple spending tree is that you get to the best of Peavey's tea and traditional

spending tree.

You met several villans two specific instances.

So in our typology once again you'd make one the route for instance one switch to the route for instance

to this port would forward for instance one put block for instance to this port would forward for instance

to black block for instance one only two spanning trees are maintained rather than a thousand.

So you still get load balancing because half of the villains follow a separate instance and you save

on the CPQ because you only have two instances of spending tree.

So from a technical point of view multiple spending trees the best protocol to use in this example but

multiple spending tree is more complex to configure than previous t and interaction with legacy switches

can be challenging at times.

So you would only want to use multiple spanning tree if you have many villans.

So in this example we have a thousand.

So it makes sense to use multiple spending tree.

If you only had 10 or 20 villans in your network you could continue using Peavey's tea or rapid Peavey's

te.

The document continues with a lot of detail on how to configure multiple spending tree regions.

But that is out of the scope of the CCMA.

So have a look at this document if you interested.

Wait till you get to your CC MP certification.