Original subtitles

So what is a previous t plus or Rapide previous t plus extended bridge ID now spending tree requires

that every switch have a unique bridge ID in the past.

Those simply consisted of the bridge priority and a MAC address.

So bridge ID consists of eight bytes with two bytes being the bridge priority and six bytes being the

MAC address.

However when configuring multiple villans and running Poovey and spending tree a different MAC address

would have to be allocated for every villaine previous t creates an instance on a Poovey land basis.

So to ensure that the bridge idea is unique on a per violent basis a different MAC address would have

to be allocated.

Now that works fine if you only have a few villans But if you configuring hundreds or thousands of lines

it's not scalable.

If a vendor was supporting Peavey's t the vendor would need to assign a unique MAC address on a Poovey

land basis.

So in theory if four thousand ninety four villains were supported on the switch four thousand ninety

four unique MAC addresses would need to be assigned to every switch.

That's simply not scalable.

So to conserve MAC addresses the system has changed and an extended system id is also known as MAC address

reduction.

So with extended bridge IDs the bridge ID is still 8 bytes in size but the priority is now split into

two parts so the two by two per already portion consists of a 4 but bridge priority and a toll.

But extended system id the MAC address is still 6 bytes in size.

So please note bridge Purdy's for bits extended system IDs 12 bits which equates to two bytes be extended

system IDs populated with the villain number and the bridge priority is a value that you can set.

Default is 3 2 7 6 8 in decimal.

In the past at the bridge party consisted of two bites and you could set the property to a value such

as 1.

However that's no longer supported on the switch as an example if I type spending tree movieland one

per priority and try and set it to 1 I'm told that I need to set it in increments of four thousand ninety

six so the value is allowed on one of these.

The reason for that is that the bridge party has been split into two portions with only the most significant

4 bits being available for the priority.

So if you set the bridge pro-ID portion the Philpots to binary 1 and you take the full 2 points into

account.

That would equate to four thousand ninety six in decimal.

So if the priority but is set to 1 the extended bridge ID priority works out to four thousand ninety

six.

If you take into account the full two bytes.

If you set the bridge Prodi portion 2 to say 0 0 1 0 in binary and look at the full 16 bits or two bytes

it equates to 8 1 9 2 in decimal.

On some vendor's equipment you can set the party to one and it will automatically be converted to 8

1 9 2 but on Cisco switches you need to set the bridge priority in multiples of four thousand ninety

six.

So once again if I try and set the party to one it's not allowed.

Set it to 4000 and 96 that's allowed to show spending tree.

Notice the priority of the switch because it's running previously plus is four thousand ninety seven

so the priority Plus the villain number.

If you are looking at a violent 10 is an example.

The priority would be for 0 9 6 plus 10.

If you're looking at villaine 20 it would be 4 0 9 6 plus 20.

I'll demonstrate that in a separate video now over the years various enhancements have been made to

spending try to reduce convergence time.

So in a switched environment various enhancements have been made to the protocol to make sure that things

happen quicker.

A stented port on the switch could take us 30 seconds to converge and that's not acceptable in modern

day networks.

As an example if the PC was booting up and needed to connect to a DHP server the PC would boot up and

send out a DHP request before the switch porters converged.

So the PC would have already booted up and requested an IP address before 30 seconds have expired and

hence the PC wouldn't receive an IP address from the DHP server because the DHP request from the PC

would be dropped by this port which is blocking wireless converging.

So to improve performance in switched environments edge ports in other words ports connected to edge

devices such as PCs some servers and routers would be configured as port FOSS ports in a Cisco environment

or edge ports on other vendor equipment Cecka use the term port fust.

Other vendors use the term edge ports in some terminology Cisco will use the term port first and in

other terminology it will be referred to as an edge port.

Now it's important that you only enable port FOSS ports on access ports and not trunk ports.

In other words you shouldn't enable port Fost on links between switches because that will introduce

loops in your topology and edge port or a port phos port immediately transitions to the forwarding state.

So bypasses the listening and learning states it goes directly from blocking to forwarding.

Once again skipping both listening and learning states that allows for much quicker convergence because

rather than waiting for spending tree to go through various stages such as blocking listening learning

forwarding the Portus starts immediately forwarding traffic and hence convergence is a lot quicker.

Spending trees still running on that port.

But transition's immediately to forwarding.

So we for some reason a be PDU was received in the port the port can get back to the blocking state.

It's good practice to do this because you don't want to inadvertently introduce loops because someone

plugged in a switch as an example by mistake on a port Fosset port.