1
00:00:10,450 --> 00:00:14,410
Is spending tree important in switched networks.

2
00:00:14,430 --> 00:00:17,390
What happens when you disable spending creep.

3
00:00:17,520 --> 00:00:23,880
Do you actually need spending tree in a layer to Ethernet to network.

4
00:00:23,880 --> 00:00:29,300
Okay so let's see what happens after the moment on both of these switches.

5
00:00:29,700 --> 00:00:39,810
A default configuration is being used so show spending tree shows us that spending tree is enabled on

6
00:00:39,810 --> 00:00:40,670
the VLAN one

7
00:00:44,260 --> 00:00:53,330
on switch one all ports of forwarding switch one is the root of the spending tree spending tree is also

8
00:00:53,330 --> 00:01:04,700
running on switch to on VLAN one the switch is not the root switch interface gigabit.

9
00:01:04,730 --> 00:01:18,660
1 0 2 is blocking on this switch so lets a disabled spending tree confetti no spending tree VLAN 1 on

10
00:01:18,660 --> 00:01:28,630
the side no spending tree V Line 1 so on such one shows spending tree shows us that spending tree is

11
00:01:28,630 --> 00:01:37,650
disabled on switch to show spending tree shows us of that spending tree is disabled notice all ports

12
00:01:37,650 --> 00:01:46,250
are now showing green no ports are being blocked please note too that I'm running in simulation mode

13
00:01:46,250 --> 00:01:58,620
in packet tracer and what I'm going to do now is send a ping from P.S. 1 2 P.S. to P.S. 2s IP address

14
00:01:59,700 --> 00:02:09,490
is 10 dot 1 dot 1 to 2 the MAC address of P.S. 2 Is this

15
00:02:13,010 --> 00:02:14,150
on P.S. 1

16
00:02:17,210 --> 00:02:25,190
IP address is 10 1 1 1 MAC address is this.

17
00:02:25,420 --> 00:02:37,420
So what happens if we paying P.C. to we sending an ICMP message but the PCI doesn't know the MAC address

18
00:02:38,260 --> 00:02:49,080
of PCI to so it's going to send an OP into the network which is a broadcast and it's going to try and

19
00:02:49,080 --> 00:02:58,910
find out of the MAC address of P.C. to I'm going to click capture forward the a message is sent to the

20
00:02:58,910 --> 00:02:59,390
switch

21
00:03:02,420 --> 00:03:04,030
notice what happens.

22
00:03:04,020 --> 00:03:14,630
It's sent to switch to switch to however duplicates of the packet and floods it out of all ports so

23
00:03:14,630 --> 00:03:26,950
it goes back to switch one on gigabit wonder 0 1 and it's received by P.C. to CPC to he's receiving

24
00:03:27,160 --> 00:03:28,480
this broadcast.

25
00:03:29,750 --> 00:03:38,140
And now P.S. One is receiving the broadcast or that it's sent notice of the source MAC addresses.

26
00:03:38,140 --> 00:03:48,520
P.S. One destination is broadcast it's looking for the MAC address of P.C. to CPC one will drop that

27
00:03:48,520 --> 00:03:49,660
packet.

28
00:03:49,660 --> 00:03:56,440
But notice we now have multiple packets being flooded through the network.

29
00:03:56,500 --> 00:04:06,760
P.S. One has received the message once again so as P.C. to CPC to is receiving multiple OP requests

30
00:04:06,880 --> 00:04:14,760
from the network the switches are also duplicating packets when we look after the MAC address table

31
00:04:14,760 --> 00:04:15,660
of switch to

32
00:04:18,490 --> 00:04:20,240
we can see that.

33
00:04:20,230 --> 00:04:28,590
P.S. To is found on gigabyte 1 0 3 and P.S. 1 is found on gigabit 1 0 2

34
00:04:31,360 --> 00:04:32,260
capture forward

35
00:04:37,070 --> 00:04:46,700
notice now the switch thinks that P.S. 2 is connected to gigabit 1 02 whereas in actual fact P.S. 2

36
00:04:46,700 --> 00:04:50,060
is connected to gigabit 1 0 3.

37
00:04:50,090 --> 00:05:00,610
Once again this is the MAC address of P.C. to so the switch is receiving conflicting information.

38
00:05:00,640 --> 00:05:05,490
Previously it thought that P.S. 2 is connected to this port.

39
00:05:05,590 --> 00:05:15,350
Now it thinks that P.S. 2 is connected to this port capture forward again.

40
00:05:15,440 --> 00:05:26,960
Now it thinks that P.S. To is connected to gigabit 1 0 1 so the switch previously thought that P.S.

41
00:05:26,960 --> 00:05:35,260
2 is connected to 1 0 3 which is correct then it's photo that P.S. 2 is connected to 1 0 2 and now it

42
00:05:35,260 --> 00:05:47,120
thinks that P.S. 2 is connected to 1 0 1 previously it's thought that P.S. 1 is connected to 1 0 2 then

43
00:05:47,180 --> 00:05:52,570
2 1 0 1 and now 2 1 0 2.

44
00:05:53,660 --> 00:05:56,670
So the MAC address table is constantly being updated.

45
00:05:58,620 --> 00:06:03,390
This is how Broadcom storms happen in life networks.

46
00:06:06,160 --> 00:06:09,250
Which can bring down an entire network.

47
00:06:09,310 --> 00:06:11,450
We have duplication of packets.

48
00:06:11,650 --> 00:06:21,500
We have mac address table instability we have hosts receiving the packets that they sent out into the

49
00:06:21,500 --> 00:06:28,300
network such as here P.S. 1 receiving its own op request message.

50
00:06:29,980 --> 00:06:38,530
Generally we don't talk to ourselves and in the same way a P.C. doesn't send a broadcast to itself like

51
00:06:38,530 --> 00:06:40,710
we see in this network.

52
00:06:40,900 --> 00:06:50,200
And if I continued doing that notice we constantly we constantly have these op messages being duplicated

53
00:06:52,190 --> 00:06:58,470
and flooded through the network packet tracer isn't showing all the duplication here.

54
00:06:59,580 --> 00:07:08,250
But notice that this just continues on and on and on and can cause a broadcast storm and network meltdown

55
00:07:08,730 --> 00:07:11,620
in a real network.

56
00:07:12,060 --> 00:07:17,930
The same original packet is being duplicated multiple times.

57
00:07:17,940 --> 00:07:20,670
Notice this is stolen off message.

58
00:07:20,670 --> 00:07:26,250
Looking for the mac address of P.S. 10 1 1 2.

59
00:07:26,600 --> 00:07:35,430
And if I continue to capture forward we just see those messages being sent continuously by the switches

60
00:07:35,860 --> 00:07:38,280
throughout the network.

61
00:07:38,280 --> 00:07:40,740
So is spending three important.

62
00:07:40,740 --> 00:07:50,370
Definitely should you disable spending tree in a layer to network in most cases no late to switch networks

63
00:07:50,910 --> 00:07:53,160
or a single broadcast domain.

64
00:07:53,310 --> 00:07:57,270
A broadcast gets flooded throughout the Layer 2 domain.

65
00:07:57,420 --> 00:08:02,700
If you had a more complex network like this your broadcast form would be even worse.

66
00:08:02,700 --> 00:08:10,300
Here's a very simple example of what happens when spending tree is disabled so get back on to switch

67
00:08:10,300 --> 00:08:16,870
one and all enable spending tree.

68
00:08:16,870 --> 00:08:23,140
I'll do something similar on switch to enable spanning tree.

69
00:08:23,610 --> 00:08:23,950
Notice.

70
00:08:23,950 --> 00:08:29,740
Now we see spending tree messages being sent between the switches.

71
00:08:29,940 --> 00:08:34,010
That's how the switches learn about one another.

72
00:08:34,010 --> 00:08:36,290
They are sending out BP to use

73
00:08:41,060 --> 00:08:46,250
to inspect trace so we can see the actual BP EU messages.

74
00:08:46,250 --> 00:08:54,470
I'll turn this back to real time and what should happen now is the ports should transition to green.

75
00:08:54,470 --> 00:08:56,690
Once the switches have learnt about one another

76
00:08:59,900 --> 00:09:08,630
and decided to the root bridge is notice the ports are currently in the learning state show spanning

77
00:09:08,630 --> 00:09:11,780
tree on switch to we see something similar.

78
00:09:11,780 --> 00:09:19,040
These ports are now forwarding this port is blocking on switch 1 all ports have transitioned to the

79
00:09:19,040 --> 00:09:25,800
forwarding state so we can now see that this port is blocking in Packet Tracer.

80
00:09:26,060 --> 00:09:28,530
So let's do that ping again.

81
00:09:28,690 --> 00:09:38,180
We've got an op message being sent into the network that now gets sent to switch to a cross port gigabit

82
00:09:38,190 --> 00:09:39,270
wonder 0 1

83
00:09:42,900 --> 00:09:49,870
it's sent to P.S. 2 but notice of this packet is going to be dropped.

84
00:09:49,870 --> 00:09:58,420
The packet will not be forwarded out of port 1 0 2 spanning trees blocking that broadcast the packet

85
00:09:58,420 --> 00:10:00,850
is only forwarded to P.S. To

86
00:10:04,260 --> 00:10:16,970
we now have the OP or reply from P.S. 2 back to P.S. 1 in the inbound PD you we can see Target MAC address

87
00:10:16,980 --> 00:10:18,580
target IP address.

88
00:10:18,780 --> 00:10:21,490
Source MAC address is P.C. 2.

89
00:10:21,570 --> 00:10:31,760
This is an op a reply message gets sent across the top link to switch 1 and gets sent to P.S. 1 and

90
00:10:31,760 --> 00:10:34,730
now P.S. 1 can send the ICMP message

91
00:10:37,590 --> 00:10:45,180
using the top link to P.S. 2 and the reply can be sent back.

92
00:10:47,330 --> 00:10:48,790
2 P.S. 1.

93
00:10:48,800 --> 00:10:52,750
That's what we want to see in an ether net network.

94
00:10:52,790 --> 00:10:59,530
We want to have the devices communicating with each other so hopefully this package trace a demonstration

95
00:10:59,530 --> 00:11:08,980
has shown you how important spanning tree is in a layer to switched network even into this small topology.

96
00:11:08,980 --> 00:11:15,730
The network breaks when spending tree is disabled on both such as make sure that you have a spending

97
00:11:15,730 --> 00:11:23,440
tree enabled on layer to switch networks unless you have a very good reason to disable spanning tree

98
00:11:23,710 --> 00:11:24,610
on your switches.