1
00:00:01,060 --> 00:00:07,390
Ce document fournit également de nombreuses informations sur les dépenses multiples qui ont mangé à un moment donné. Vous n'êtes

2
00:00:07,390 --> 00:00:13,610
pas censé connaître tous les détails de ce document, mais il constitue une bonne référence si vous êtes intéressé. Je

3
00:00:14,070 --> 00:00:19,260
vais maintenant aborder certains aspects fondamentaux. et ensuite vous pourrez lire le document si vous souhaitez

4
00:00:20,260 --> 00:00:24,330
plus d'informations. L'arborescence des dépenses multiples est la nouvelle norme de l'industrie.

5
00:00:24,400 --> 00:00:30,700
Inspiré du protocole exclusif gratuit de dépense instantanée instantanée de Cisco, Cisco a développé

6
00:00:30,700 --> 00:00:37,040
plusieurs protocoles d'arborescence de dépense instantanée pour résoudre certains des problèmes que vous rencontriez précédemment.

7
00:00:37,080 --> 00:00:44,820
Donc, à mesure que le nombre de villans configurés dans des réseaux commutés augmente, le temps système nécessaire pour exécuter PV

8
00:00:45,010 --> 00:00:46,440
t augmente également.

9
00:00:46,750 --> 00:00:54,580
Si vous configurez un millier de villans avec la version précédente et rapide de Peavey, vous obtenez un millier d'instances d'arborescence

10
00:00:54,670 --> 00:01:00,640
de dépenses, mais avec plusieurs arborescences de dépenses et l'arborescence de dépenses propriétaire à plusieurs

11
00:01:00,640 --> 00:01:08,020
instances qui existait avant plusieurs arborescences de dépenses, vous pouvez mapper un même nombre de villans sur le même

12
00:01:08,020 --> 00:01:09,440
Spanning Tree instance.

13
00:01:09,490 --> 00:01:16,690
C'est assez simple à faire, mais l'idée est que si vous aviez un millier de villans, vous alloueriez 500 à

14
00:01:16,690 --> 00:01:20,230
une instance et les 500 autres à une autre.

15
00:01:20,350 --> 00:01:28,150
Cela signifie que vous ne disposez que de deux instances de spanning tree plutôt

16
00:01:28,150 --> 00:01:35,320
que de 1000 instances de dépenses. Par conséquent, l'arborescence de dépenses multiple normalise

17
00:01:35,370 --> 00:01:42,310
le concept d'arborescences multiples et incorpore la convergence d'un arbre de dépenses

18
00:01:42,310 --> 00:01:43,450
rapide.

19
00:01:43,450 --> 00:01:49,090
Il définit également un protocole permettant d’interconnecter plusieurs régions de dépenses

20
00:01:49,090 --> 00:01:55,060
en matière de dépenses, et explique comment mettre en œuvre l’architecture d’un

21
00:01:55,060 --> 00:01:59,620
arbre de dépense et présenter les meilleures pratiques.

22
00:02:00,010 --> 00:02:02,110
Mais à titre de comparaison rapide.

23
00:02:02,110 --> 00:02:10,520
Vous avez mentionné que vous aviez un millier de malfaiteurs connectés qui est connecté à la fois aux commutateurs d 1 et D pour

24
00:02:10,550 --> 00:02:11,830
envoyer ces excuses.

25
00:02:11,910 --> 00:02:19,430
Switchy a un millier de villans. D1 sera la racine de l’arbre des dépenses pour les terrains du dimanche et D-2

26
00:02:19,430 --> 00:02:26,050
sera la racine de l’arbre des dépenses pour les autres villans. Le commutateur D-1 est donc configuré pour

27
00:02:26,050 --> 00:02:32,200
être la racine des villans. 501 T-1000 D2 est la racine pour Villines one to 500.

28
00:02:32,230 --> 00:02:38,820
L'interface du commutateur au commutateur D-1 bloque les villans de un à cinq cents et du commutateur

29
00:02:38,830 --> 00:02:42,490
d à deux blocs de 501 à 1000.

30
00:02:42,490 --> 00:02:51,110
Donc, encore une fois, la racine de ces villans sera acheminée hors de ce port mais bloquée

31
00:02:51,130 --> 00:02:54,260
pour les villines 1 à 500.

32
00:02:54,490 --> 00:03:02,210
Le commutateur est la racine de ces villans, ce port acheminera le trafic des villans 1 à

33
00:03:02,870 --> 00:03:06,990
500 mais bloquera 500 et 1 à 1000.

34
00:03:07,010 --> 00:03:14,170
Il est très inefficace de gérer des milliers d'instances de dépenses sur ce réseau.

35
00:03:14,230 --> 00:03:23,780
Nous avons 500 instances de dépenses avec D-1 en tant que racine et 500 avec D2 en tant que racine.

36
00:03:23,800 --> 00:03:30,010
Mais logiquement, nous n’avons en fait besoin que de deux instances. D-1 devrait être la racine.

37
00:03:30,040 --> 00:03:35,890
Par exemple, celui qui contient ces méchants et D2 devrait être la racine.

38
00:03:35,890 --> 00:03:39,690
Par exemple 2 qui contient ces méchants.

39
00:03:40,150 --> 00:03:45,660
Vous associez ces villans à un exemple et faites de D-1 la racine.

40
00:03:45,760 --> 00:03:51,510
Vous associez ces méchants à l'instance deux et faites de D2 la racine.

41
00:03:51,640 --> 00:03:55,970
Cela signifie que vous devez gérer deux instances plutôt que mille.

42
00:03:57,170 --> 00:04:03,280
Donc, ce genre de détail est expliqué ici, je vais le passer rapidement dans un environnement précédent de Cecka.

43
00:04:03,290 --> 00:04:10,400
Vous avez besoin d'une instance de dépense pour chaque réseau local, ce qui signifie que vous avez mille

44
00:04:10,640 --> 00:04:18,280
instances pour les deux typologies logiques finales différentes, D-1 étant la racine d'une typologie et D2 la racine de l'autre.

45
00:04:18,290 --> 00:04:23,500
Cela gaspille beaucoup de cycles de veille pour tous les commutateurs du réseau.

46
00:04:23,780 --> 00:04:30,980
En plus de la bande passante utilisée par les utilisateurs de TPB, un millier d’utilisations

47
00:04:30,980 --> 00:04:40,310
seront envoyés de chaque port toutes les deux secondes, car Peavey est un BPU pour chaque méchant, car nous avons

48
00:04:40,310 --> 00:04:43,770
une instance individuelle mappée à chaque méchant.

49
00:04:43,850 --> 00:04:50,930
Donc, l’idée avec plusieurs arbres de dépenses est d’obtenir le meilleur du thé et des arbres de dépenses traditionnels

50
00:04:50,930 --> 00:04:52,100
de Peavey.

51
00:04:52,300 --> 00:04:56,000
Vous avez rencontré plusieurs méchants deux fois.

52
00:04:56,000 --> 00:05:04,250
Ainsi, dans notre typologie, une fois de plus, vous feriez une route par exemple, un commutateur vers une route

53
00:05:04,280 --> 00:05:11,120
par exemple vers ce port transférerait par exemple un bloc de vente par exemple

54
00:05:11,150 --> 00:05:20,560
vers ce port transférerait par exemple vers un bloc noir par exemple un seul deux les arbres sont entretenus plutôt que mille.

55
00:05:20,570 --> 00:05:26,300
Vous obtenez donc toujours un équilibrage de charge car la moitié des méchants suivent une instance distincte et vous économisez sur

56
00:05:26,300 --> 00:05:30,120
le CPQ car vous ne disposez que de deux instances d'arborescence de dépenses.

57
00:05:30,290 --> 00:05:36,800
Donc, d’un point de vue technique, le meilleur protocole à utiliser dans cet exemple est le meilleur protocole

58
00:05:37,100 --> 00:05:44,060
à utiliser, mais la configuration de plusieurs arbres de dépenses est plus complexe que l’opération précédente et l’interaction avec

59
00:05:44,090 --> 00:05:46,860
les commutateurs existants peut parfois s'avérer difficile.

60
00:05:46,880 --> 00:05:52,250
Donc, vous ne voudriez utiliser plusieurs Spanning Tree que si vous avez beaucoup de méchants.

61
00:05:52,250 --> 00:05:54,590
Donc, dans cet exemple, nous en avons mille.

62
00:05:54,800 --> 00:05:57,160
Il est donc logique d’utiliser plusieurs arbres de dépenses.

63
00:05:57,440 --> 00:06:06,020
Si vous n’avez que 10 ou 20 villans dans votre réseau, vous pouvez continuer à utiliser le thé Peavey's

64
00:06:06,040 --> 00:06:07,760
ou Rapid Peavey's.

65
00:06:07,780 --> 00:06:13,480
Le document continue avec beaucoup de détails sur la façon de configurer plusieurs régions de l’arbre de dépenses.

66
00:06:13,700 --> 00:06:16,130
Mais cela sort du cadre de la CCMA.

67
00:06:16,480 --> 00:06:19,140
Alors regardez ce document si cela vous intéresse.

68
00:06:19,160 --> 00:06:22,390
Attendez d'avoir obtenu votre certification CC MP.
