1
00:00:08,940 --> 00:00:14,220
Trimiteți acest exemplu să presupunem că A trimite un cadru către D.

2
00:00:14,440 --> 00:00:17,260
Deci, adresa sursă care a condus va fi a.

3
00:00:17,380 --> 00:00:19,370
Iar adresa de destinație va fi D.

4
00:00:19,600 --> 00:00:27,010
Eu voi trimite cadru pentru a comuta pe unul care apoi va copia acel cadru la toate porturile bazate încă o dată

5
00:00:27,010 --> 00:00:28,380
pe arhitectura comutator.

6
00:00:28,510 --> 00:00:34,480
Async-ul central va verifica destinația din tabelul taberei și să presupunem că momentan nu răspunde care dintre

7
00:00:34,480 --> 00:00:37,990
ele pot fi tabele sau tabele de adrese MAC.

8
00:00:38,230 --> 00:00:44,050
Deci, cadrul va încerca să iasă din acest port la 0 2, dar deoarece culoarea internă etichetă este roșie pentru

9
00:00:44,050 --> 00:00:44,880
acel cadru.

10
00:00:44,920 --> 00:00:46,590
Și acesta este un Greenport.

11
00:00:46,720 --> 00:00:49,280
Rama nu este permisă din 0 2.

12
00:00:49,600 --> 00:00:52,040
Cu toate acestea, pe acest port pentru că este o legătură trunchi.

13
00:00:52,210 --> 00:00:57,400
Și să presupunem că în momentul în care toate terenurile sunt permise pe acest trunchi

14
00:00:57,400 --> 00:01:04,220
acel cadru va fi trimis din portul 0 3 pentru a trece la totuși chiar înainte ca cadrul să fie trimis.

15
00:01:04,220 --> 00:01:06,760
Trebuie să fie etichetat cu numărul de personaj negativ.

16
00:01:07,100 --> 00:01:10,080
Deci, în acest caz identificatorul ticăloșilor ar fi roșu.

17
00:01:10,130 --> 00:01:15,750
Acum, după cum se menționează în switch-urile villans identificate prin numere, dar pentru a păstra aceste exemple

18
00:01:15,760 --> 00:01:17,310
simple vom folosi culori.

19
00:01:17,330 --> 00:01:24,470
Deci, în realitate, acesta ar fi un număr de la 0 la 4000 și apoi 96 de cadre de

20
00:01:24,830 --> 00:01:32,120
expunere sunt trimise prin trunchi pentru a comuta la cine apoi primește cadrul încă o dată cadrul este procesat intern.

21
00:01:32,120 --> 00:01:37,430
Acum, acest switch citește identificatorul unui identificator editat sau un antet Q și vede

22
00:01:37,430 --> 00:01:44,540
că aparține Villonului roșu care este etichetat intern în cadrul comutatorului care este trimis la Allport 0 2 și 0

23
00:01:44,540 --> 00:01:45,160
1.

24
00:01:45,260 --> 00:01:50,630
Și să presupunem încă o dată că tabela de adresă MAC este comutată nu conține adresa MAC a

25
00:01:50,630 --> 00:01:51,570
lui D.

26
00:01:51,650 --> 00:01:58,040
Deci, atunci când cadoul încearcă să meargă la portul 0 1, este respins deoarece culoarea cadrului este roșie și

27
00:01:58,430 --> 00:02:00,760
această interfață este în Villon verde.

28
00:02:00,920 --> 00:02:02,710
Deci, cadrele sunt scoase.

29
00:02:02,730 --> 00:02:08,840
Cu toate acestea, din această interfață, cadrul este permis deoarece portul se află în personajul roșu

30
00:02:08,840 --> 00:02:14,920
și cadrul este marcat cu personajul negativ roșu, toate etichetarea fiind dezlegată din acest port.

31
00:02:14,960 --> 00:02:19,340
Deci este la fel ca un cadru Ethernet normal pentru PCD.

32
00:02:19,340 --> 00:02:24,080
Încă o dată, PC-urile ignoră faptul că au fost puse în răufăcători.

33
00:02:24,110 --> 00:02:26,660
Ei doar văd Ethernet steniat.

34
00:02:26,660 --> 00:02:32,420
Deci, un cadru standard în care adresa sursă a unei adrese de destinație un D este

35
00:02:32,420 --> 00:02:40,450
transmisă din portul 0 și procesată de PC editată într-o cheie trunchiată are un ticălos spațial cunoscut ca vileanii indigeni nativi care nu

36
00:02:41,050 --> 00:02:46,270
sunt tagificați atunci când un port de pe comutator este creat ca un trunchi.

37
00:02:46,630 --> 00:02:53,800
De exemplu, această interfață pe comutatorul unu și trecerea la interfața respectivă poate primi și transmite cadre

38
00:02:53,800 --> 00:03:01,450
etichetate, cadre aparținând idiotului nativ, nu transporta etichete violente atunci când sunt trimise pe acest trunchi cu același simbol

39
00:03:01,450 --> 00:03:07,480
dacă un cadru fără tag a fost primit pe portul portbagajului respectiv ar fi

40
00:03:07,480 --> 00:03:11,030
automat asociat cu terenul nativ pentru acest sport.

41
00:03:11,050 --> 00:03:15,030
Acum, traficul specific de management va trece peste pământul natal.

42
00:03:15,220 --> 00:03:22,090
De exemplu, folosirea BPT pentru copaci va folosi Villon nativ și astfel protocolul dinamic al trunchiurilor dinamice critice este o modalitate

43
00:03:22,930 --> 00:03:28,450
prin care comutatoarele negociază pentru a configura un portbagaj între ele în mod automat și vă voi

44
00:03:28,900 --> 00:03:31,010
arăta un exemplu în acel moment.

45
00:03:32,130 --> 00:03:38,370
Anumite traficuri de management utilizează întotdeauna un rău unul dacă ați părăsit linia unu ca

46
00:03:38,760 --> 00:03:45,480
traficul nativ LAN ca CPV DP AGP și voi DL D va fi transmis pe teritoriul nativ.

47
00:03:45,540 --> 00:03:52,650
Untagged dacă eu vreodată Terenul nativ este schimbat în altceva decât un teren unul aceste protocoale vor fi apoi

48
00:03:52,650 --> 00:03:59,280
etichetate în acel CTP villain specifice a fost explicat în partea ICD 1 a acestui curs.

49
00:03:59,340 --> 00:04:05,190
Aceasta ne permite să vedem dispozitivele conectate direct și protocolul trunking pe care îl vom discuta în

50
00:04:05,190 --> 00:04:06,550
următoarele câteva diapozitive.

51
00:04:06,600 --> 00:04:13,350
Este o modalitate de a actualiza dinamic alte switch-uri cu modificări efectuate pe un singur switch într-un

52
00:04:13,960 --> 00:04:21,330
domeniu VTB AGP sau protocolul de agregare a porturilor este un protocol utilizat pentru crearea automată a canalelor de

53
00:04:21,330 --> 00:04:28,380
eter și vă DLT sau aveți nevoie de detectare direcțională legată este utilizat pentru a monitoriza configurarea fizică

54
00:04:28,380 --> 00:04:32,120
a cablurilor între dispozitive și detectarea legăturilor direcționale unice.

55
00:04:32,130 --> 00:04:35,330
Acest lucru ne permite să detectăm legăturile cablate incorect.

56
00:04:35,340 --> 00:04:40,380
Lucrul important care trebuie luat în considerare aici este că legăturile de trunchi există un ticălos special cunoscut

57
00:04:40,380 --> 00:04:46,770
sub numele de pământ nativ, unde traficul este trimis fără etichetă dacă este lăsat la implicit de Villa și unul o mulțime de

58
00:04:46,770 --> 00:04:49,880
trafic de management vor fi trimise peste acest pământ nativ.

59
00:04:49,890 --> 00:04:56,460
Este important ca pământul nativ de pe ambele părți ale trunchiului să fie același, dacă nu se fixează la fel.

60
00:04:56,460 --> 00:05:00,620
Căutătorii vă vor înștiința, spunându-vă că există o nepotrivire de tip villain.

61
00:05:01,080 --> 00:05:06,990
Problema care apare în cazul în care terenurile native nu sunt aceleași este faptul că traficul de la un ticălos pe

62
00:05:07,170 --> 00:05:11,750
switch va fi asociat automat și se termină într-un altul decât pe un alt switch.

63
00:05:11,760 --> 00:05:17,400
Și, evident, întregul concept al felinelor este de a separa traficul într-un anumit Thielen.

64
00:05:17,430 --> 00:05:23,100
Cu alte cuvinte, un domeniu separat de difuzare sau un trafic separat de subnet de la un VLAN

65
00:05:23,160 --> 00:05:28,320
nu ar trebui să se termine într-un alt personaj negativ din cauza unei configurații eronate native.

66
00:05:28,340 --> 00:05:31,360
Acum este ceva ce probabil nu vă vedeți astăzi în rețele.

67
00:05:31,580 --> 00:05:38,510
În mod teoretic, cu un villain nativ, un comutator ca un comutator, se poate spune că etichetarea cadrelor pentru a comuta

68
00:05:38,600 --> 00:05:40,680
pe cadrele neclasificate pe acest MacBook.

69
00:05:40,820 --> 00:05:47,030
Prin folosirea nativului Villon, acest MacBook sau PC ar putea totuși să comunice cu rețeaua, chiar dacă

70
00:05:47,330 --> 00:05:53,360
nu înțelege cadrele etichetate editate sau un cadru cheie sau rame etichetate sunt utilizate pentru comunicarea

71
00:05:53,360 --> 00:05:58,040
prin intermediul informațiilor între dispozitive de rețea, cum ar fi switch-urile.

72
00:05:58,040 --> 00:06:03,410
Acest dispozitiv nu ar înțelege neapărat o ediție sau un cadru cheie, dar putea încă să comunice

73
00:06:03,410 --> 00:06:05,840
cu rețeaua utilizând tipul de rău indigen.

74
00:06:06,110 --> 00:06:07,800
Cu toate acestea, acest lucru nu este comun astăzi.

75
00:06:07,970 --> 00:06:16,130
Ce este mai tipic Astăzi este un scenariu ca acesta în cazul în care aveți un PC conectat la un telefon IP conectat

76
00:06:16,130 --> 00:06:17,770
la un switch Cisco.

77
00:06:17,780 --> 00:06:25,010
Acum, telefonul Cisco IP are un switch construit în trei moduri, un port este conectat la infrastructura rețelei.

78
00:06:25,130 --> 00:06:32,030
Deci, un switch Cisco un al doilea port permite PC-ului să se conecteze la infrastructură prin telefon și un al

79
00:06:32,030 --> 00:06:38,600
treilea port permite ca traficul vocal de la receptor să fie prioritizat față de date când este trimis la

80
00:06:38,600 --> 00:06:40,000
infrastructura de rețea.

81
00:06:40,340 --> 00:06:46,970
Deci, telefonul are un switch construit în trei moduri mereu mândru creșterea voce peste date.

82
00:06:47,020 --> 00:06:52,510
Lucrul de luat in seama aici este faptul ca telefonul poate fi configurat intr-un Villon separat

83
00:06:52,510 --> 00:06:53,380
pe PC.

84
00:06:53,380 --> 00:06:57,900
Deci, telefonul ar putea fi în vioara roșie și PC-ul ar putea fi în linia verde.

85
00:06:58,030 --> 00:07:00,610
Există multe avantaje pentru a face acest lucru în acest fel.

86
00:07:00,850 --> 00:07:07,270
Deci, de obicei, din punct de vedere al securității, acest PC nu va fi capabil să deranjeze traficul vocal

87
00:07:07,330 --> 00:07:09,760
și, prin urmare, să asculte conversația vocală.

88
00:07:09,760 --> 00:07:14,600
Acum există o mulțime de avertismente referitoare la telefoanele Cisco și diferite modele sunt configurate

89
00:07:14,830 --> 00:07:21,160
în moduri diferite, dar teoretic conceptul este că telefonul este într-un mod separat violent față de PC și, prin urmare,

90
00:07:21,160 --> 00:07:24,090
PC-ul nu este capabil să vadă traficul vocal.

91
00:07:24,100 --> 00:07:29,740
Există aplicații precum Cain și Abel, care reprezintă un instrument foarte puternic de hacking care

92
00:07:29,740 --> 00:07:36,820
vă permit să adulți în rețea captarea traficului vocal și apoi reluați traficul ca fișier pe PC-ul local pentru

93
00:07:36,820 --> 00:07:39,000
a putea relua conversația vocală.

94
00:07:39,340 --> 00:07:44,950
Dar dacă telefonul se află într-o securitate separată Villon este îmbunătățită deoarece PC-ul nu poate vedea traficul

95
00:07:44,950 --> 00:07:47,920
vocal dintr-un punct de vedere al calității serviciului.

96
00:07:47,920 --> 00:07:53,130
Acest lucru este, de asemenea, mult mai bun, deoarece este mai ușor să prioritizeze traficul de voce peste traficul de date.

97
00:07:53,290 --> 00:07:59,530
Dacă aceasta într-o configurație separată VM a rețelei dvs. are și avantajele unei gestionări mai ușoare a

98
00:07:59,530 --> 00:08:03,680
adresei IP, deoarece puteți atribui o subrețea separată telefoanelor dvs.

99
00:08:03,690 --> 00:08:07,380
Acestea sunt PC-urile dvs. și astfel scalarea adresării dvs. IP.

100
00:08:07,420 --> 00:08:13,030
Deci, ceea ce se întâmplă este comutatorul este configurat cu ceea ce se numește Freelon de voce și

101
00:08:13,420 --> 00:08:19,780
un idiot nativ, simțul vocii este etichetat, astfel încât cadrele etichetate să fie trimise la telefon, iar telefonul cu comutatorul

102
00:08:19,840 --> 00:08:26,650
său boltin triunghi este capabil să citească cadrele editate sau un cadru cheie neatagiat sunt salvate pe ceea ce se numește

103
00:08:26,660 --> 00:08:28,960
linia nativă sau linia de date.

104
00:08:29,110 --> 00:08:34,730
Aceste informații sunt trimise la telefon și telefonul doar comută acest lucru pe PC.

105
00:08:34,840 --> 00:08:41,440
Deci, PC-ul primește netichetat pe cadrele de pământ nativ, iar telefonul primește acel fișier etichetat sau vocal și nu

106
00:08:41,440 --> 00:08:46,040
încadrează nicio configurație și telefonul este necesar pentru a activa acest lucru.

107
00:08:46,150 --> 00:08:51,280
Ați scris literalmente câteva comenzi pe comutator, spunând comutator, ce voce este terenul și ce

108
00:08:51,280 --> 00:08:52,550
este DTV Bil'in.

109
00:08:52,750 --> 00:08:59,020
Și acest lucru se întâmplă automat, pentru că atunci când telefonul pornește, interoghează comutatorul prin CGP pentru

110
00:08:59,020 --> 00:09:01,010
a afla care sunt ele.

111
00:09:01,270 --> 00:09:06,530
Asadar, comutarea se face prin configurarea telefonului prin utilizarea CTP.

112
00:09:06,850 --> 00:09:11,580
Deci, aceasta este o implementare foarte comună a terenurilor native din lumea reală de azi.

113
00:09:12,530 --> 00:09:18,410
Deci, doar pentru a rezuma modul în care porturile sunt atribuite în mod serios villans ei pot fi atribuite static de

114
00:09:18,410 --> 00:09:19,490
către un administrator.

115
00:09:19,520 --> 00:09:25,460
Deci, pentru a folosi un administrator, intrați într-o interfață și puneți constant acel port într-un răufăcător.

116
00:09:25,460 --> 00:09:30,980
Cea de-a doua opțiune este de a crea ceea ce se numește răufăcători dinamici folosind un server de

117
00:09:31,700 --> 00:09:39,170
politicieni de rău, dinamic villans, care să permită o afacere a porturilor și să se facă emic actualizat pe baza adresei Mac a dispozitivului

118
00:09:39,170 --> 00:09:40,600
atașat la acel port.

119
00:09:40,910 --> 00:09:46,400
Deci, într-o sală de consiliu, de exemplu, atunci când un regizor se conectează într-un laptop

120
00:09:46,490 --> 00:09:52,640
bazat pe adresa Mac a acelui laptop, acest port este alocat dinamic directorilor planului atunci când un manager

121
00:09:52,640 --> 00:09:59,020
se conectează laptop-ul în același port în ziua următoare, de exemplu, că Villon este automat actualizat la managerii Villon.

122
00:09:59,030 --> 00:10:04,400
Deci, pe baza sursei MAC a cadrelor recepționate în port, portul este

123
00:10:04,580 --> 00:10:12,400
alocat automat unor terenuri diferite, iar anul trecut avem villani vocali care sunt utilizați special pentru telefoanele IP BTP

124
00:10:12,490 --> 00:10:19,720
sau protocolul trunkingul rău este un nivel de proprietate Cisco la protocol care permite Propagarea informațiilor de

125
00:10:19,720 --> 00:10:25,980
la un comutator la altul, mai degrabă decât de a efectua telneturi către comutatoare multiple.

126
00:10:26,080 --> 00:10:32,710
Puteți să ștergeți sau să redenumiți terenurile de pe un singur switch și să transmiteți aceste informații în mod

127
00:10:33,100 --> 00:10:35,610
automat către alte switch-uri prin legăturile trunchiului.

128
00:10:35,620 --> 00:10:38,750
Observați numele protocolului de trădare ticălos.

129
00:10:38,770 --> 00:10:42,820
Această informație poate fi propagată numai prin legăturile trunchiului.

130
00:10:42,820 --> 00:10:48,820
Acum ETP vă poate economisi o mulțime de timp care are o mulțime de ingineri Sisk va spune BTP poate provoca o mulțime

131
00:10:48,850 --> 00:10:50,190
de dureri de cap.

132
00:10:50,200 --> 00:10:55,960
Întrerupătoarele pot avea întreaga configurație de personaj rău, dacă se adaugă un nou switch în rețea fără

133
00:10:56,200 --> 00:10:58,320
a urma o procedură adecvată.

134
00:10:58,570 --> 00:11:04,540
Deci, mulți ingineri Cisco nu vor permite VCP în medii moderne datorită riscurilor inerente

135
00:11:04,540 --> 00:11:06,340
asociate cu acest protocol.

136
00:11:07,440 --> 00:11:13,650
Mesajele GTP sunt trimise la următoarea adresă Mac, care este o adresă binecunoscută pentru

137
00:11:13,770 --> 00:11:16,950
multicast pentru inundarea protocoalelor CTP și DTP.

138
00:11:16,950 --> 00:11:19,400
Există trei tipuri de mesaje în DTP.

139
00:11:19,410 --> 00:11:25,950
Aveți niște reclame și anunțuri de publicitate gratuite și le voi explica

140
00:11:25,950 --> 00:11:28,790
în detaliu în următoarele diapozitive.

141
00:11:28,890 --> 00:11:35,380
Dar, vă rugăm să fiți conștienți de faptul că există trei mesaje tastate atunci când configurarea dispozitivelor DP va

142
00:11:35,380 --> 00:11:38,560
fi, implicit, aparținând domeniului VDB null pentru a funcționa.

143
00:11:38,560 --> 00:11:45,490
Trebuie să configurați și să puneți dispozitivele într-un anumit domeniu VTB, numai dispozitivele din același domeniu

144
00:11:45,490 --> 00:11:49,460
DTP vor fi actualizate cu informațiile de linie.

145
00:11:49,480 --> 00:11:56,920
Un switch poate fi configurat într-un singur domeniu VTB la un moment dat în mod prestabilit. Switch-urile Cisco se află

146
00:11:56,920 --> 00:12:04,450
în domeniul nold sau în niciun domeniu de management până când nu primesc o publicitate pentru un domeniu pe o legătură

147
00:12:04,450 --> 00:12:04,980
trunchiată.

148
00:12:05,080 --> 00:12:08,350
Sau până când configurați manual un domeniu de gestionare.

149
00:12:08,580 --> 00:12:14,830
În acest exemplu, să presupunem că aceste dispozitive au fost introduse în domeniul VTB cu numele

150
00:12:14,830 --> 00:12:15,750
de Cecka.

151
00:12:16,030 --> 00:12:22,300
Amintiți-vă că aceste VCP sunt un strat de protocol și necesită legături trunchiate pentru comunicare.

152
00:12:22,540 --> 00:12:29,860
Deci VDB nu va traversa Harada un concept important de înțeles NVP este conceptul unui număr de

153
00:12:29,860 --> 00:12:30,490
revizie.

154
00:12:31,380 --> 00:12:38,260
De fiecare dată când se fac modificări în baza de date a ticăloșilor, numărul de revizie din BTP va crește cu 1.

155
00:12:38,460 --> 00:12:45,410
Deci, să presupunem că toate dispozitivele din acest scuze au un număr de revizie de 1 al tău într-un minister al

156
00:12:45,600 --> 00:12:51,720
unui răufăcător spunem că noi trei la comutator numărul de revizie va crește apoi de la un număr

157
00:12:51,720 --> 00:12:59,320
de viziune numărul 1 la revizia numărul 2 că informațiile vor fi apoi publicate la toți ceilalți comutatori din domeniul VTB, astfel încât

158
00:12:59,650 --> 00:13:05,410
aceștia să poată sincroniza bazele de date cu cel mai recent număr de revizie care este numărul

159
00:13:05,410 --> 00:13:06,440
reviziei 2.

160
00:13:06,550 --> 00:13:11,680
Deci, comutatorul din partea de sus va trimite ceea ce se numește o reclamă sumară GTP tuturor

161
00:13:11,710 --> 00:13:14,860
comutatoarelor care le informează că sa făcut o schimbare.

162
00:13:14,860 --> 00:13:17,610
Rețineți că acest lucru este trimis utilizând o adresă multicast.

163
00:13:17,740 --> 00:13:21,070
Deci, toate aceste dispozitive vor vedea acel mesaj.

164
00:13:21,070 --> 00:13:26,440
Apoi, vor solicita cele mai recente informații utilizând o solicitare de publicitate, iar comutatorul de

165
00:13:26,620 --> 00:13:31,800
la început le va trimite informații detaliate despre schimbare utilizând o reclamă din subset.

166
00:13:31,810 --> 00:13:37,150
Rezultatul net este că numerele de revizie și toate aceste comutatoare vor crește la același număr de

167
00:13:37,150 --> 00:13:40,740
revizie ca un comutator în care a fost efectuată modificarea.

168
00:13:40,780 --> 00:13:46,210
Viola și trei vor apărea în toate bazele de date ale comutatoarelor, iar numărul de revizie va fi

169
00:13:46,210 --> 00:13:48,100
setat la numărul doi de revizuire.

170
00:13:48,250 --> 00:13:54,430
Întregul concept cu VTB este că poți face schimbări pe un dispozitiv individual, pe măsură ce se fac

171
00:13:54,430 --> 00:13:55,190
aceste schimbări.

172
00:13:55,300 --> 00:14:00,700
Toți ceilalți comutatori sunt informați despre schimbare și își vor sincroniza bazele de date la cel mai

173
00:14:00,700 --> 00:14:06,130
recent număr de revizie, astfel încât aceștia să aibă aceleași planuri B și poate baze de date Lenn.

174
00:14:06,130 --> 00:14:11,680
Asta inseamna ca tu ca administrator doar sa faci schimbari pe un switch, mai degraba decat

175
00:14:11,680 --> 00:14:18,300
cinci switch-uri in scuze, va rugam sa notati ca porturile sunt puse in villans individuale de exemplu de catre un administrator.

176
00:14:18,610 --> 00:14:25,300
DP nu pune porturi în villans individuale doar actualizează baza de date, astfel încât comutatoarele știu care

177
00:14:25,300 --> 00:14:31,770
sunt răufăcătorii folosesc un administrator încă mai trebuie să pună acele porturi în villans relevante.

178
00:14:31,990 --> 00:14:38,230
Deci, acesta este doar un mecanism de actualizare a bazei de date a ticăloșilor, astfel încât comutatoarele

179
00:14:38,230 --> 00:14:40,810
să cunoască răufăcătorii care există în tipologie.

180
00:14:40,820 --> 00:14:43,500
Așadar, să analizăm mai detaliat mesajele VDB.

181
00:14:43,520 --> 00:14:46,760
Prima oprire a mesajului VDB este o publicitate sumară.

182
00:14:46,760 --> 00:14:51,620
Acest lucru este trimis la fiecare cinci minute sau ori de câte ori există o schimbare.

183
00:14:51,620 --> 00:14:58,340
Deci, ori de câte ori un administrator face o schimbare pe un comutator, de exemplu prin adăugarea unui Villon, o

184
00:14:58,340 --> 00:15:03,590
reclamă sumară va fi trimisă pe adresa binecunoscută a multicast pentru toate comutatoarele din domeniu.

185
00:15:03,590 --> 00:15:10,190
Deci, acest lucru este folosit pentru a informa alte switch-uri ale domeniului VCP curent și numărul curent de revizie

186
00:15:10,190 --> 00:15:10,910
a configurației.

187
00:15:11,210 --> 00:15:17,510
Deci, ca un exemplu de comutare, administratorul adaugă un alt răufăcător, să zicem că răufăcătorul pentru numărul de

188
00:15:17,510 --> 00:15:19,150
revizie va fi incrementat.

189
00:15:19,150 --> 00:15:23,160
Deci, dacă numărul de revizie a fost de trei, nu ar fi crescut la 4.

190
00:15:23,660 --> 00:15:29,660
Acest comutator va spune într-o reclamă sumară tuturor comutatoarelor vecine care le informează despre

191
00:15:29,660 --> 00:15:36,740
domeniul VTB curent și noile comutatoare ale numărului de revizie a configurației care primesc anunțul sumar

192
00:15:37,060 --> 00:15:43,310
vor trimite înapoi o cerere sumară solicitând informații detaliate despre modificările care au fost

193
00:15:43,310 --> 00:15:44,160
făcute.

194
00:15:44,180 --> 00:15:50,240
Există trei situații în care sunt utilizate câteva solicitări. În primul rând, atunci când un comutator a

195
00:15:50,240 --> 00:15:57,250
fost resetat sau când numele domeniului VTB este schimbat sau când comutatorul a primit o publicitate sumară VTB cu un

196
00:15:57,250 --> 00:16:00,500
număr de revizie mai mare decât cea proprie.

197
00:16:00,500 --> 00:16:07,370
Deci, pentru că a trecut la primirea anunțului sumar de la unul care indică un număr de revizie ridicat.

198
00:16:07,490 --> 00:16:12,170
Cu alte cuvinte numărul reviziei și care este revizuirea înainte și numărul reviziei pe

199
00:16:12,170 --> 00:16:20,090
comutatorul 2 este revizia numărul 3 comutatorul 2 va cere acum informații de la comutatorul 1 astfel încât să își poată actualiza baza de

200
00:16:20,090 --> 00:16:26,750
date cu cea mai recentă informație din care sunt trimise informații detaliate pe care să o schimbați folosind ceea ce

201
00:16:26,750 --> 00:16:28,520
se numește un subset.

202
00:16:28,550 --> 00:16:29,780
Publicitate.

203
00:16:29,780 --> 00:16:36,890
Aceasta conține o listă a informațiilor și, dacă sunt mai multe villani, mai mult de o reclamă subset poate

204
00:16:36,890 --> 00:16:42,280
fi necesară pentru a actualiza și sincroniza bazele de date ale altor switch-uri.

205
00:16:42,290 --> 00:16:47,370
Deci, în esență, ceea ce este acesta este informarea detaliată a schimbărilor care au fost făcute.

206
00:16:47,540 --> 00:16:52,910
Anunțul sumar doar informează comutatorul în format sumar al ultimului număr revizie și

207
00:16:52,910 --> 00:16:54,290
al domeniului BTP.

208
00:16:54,500 --> 00:17:00,860
Dacă comutatorul local vede că este depășit, va cere informații detaliate pentru a-și putea sincroniza baza

209
00:17:00,860 --> 00:17:06,500
de date și că informațiile vor fi furnizate utilizând o reclamă de subset.

210
00:17:06,530 --> 00:17:12,290
Comutatorul este acum capabil să sincronizeze bazele de date locale cu baza de date a comutatorului cu cele mai

211
00:17:12,290 --> 00:17:13,140
recente informații.

212
00:17:14,310 --> 00:17:16,910
Acum există trei moduri în BTP.

213
00:17:17,100 --> 00:17:25,500
Modul implicit este serverul un comutator VTB în modul server poate crea villans modifica răufăcătorii și șterge

214
00:17:25,500 --> 00:17:26,370
villans.

215
00:17:26,400 --> 00:17:29,650
De asemenea, trimite și transmite anunțuri.

216
00:17:29,790 --> 00:17:34,040
Deci, dacă ar primi o reclamă de la un alt comutator, ar transmite acest lucru.

217
00:17:34,290 --> 00:17:39,070
Dacă ați efectuat modificări la comutatorul local, acesta va trimite câteva anunțuri reale.

218
00:17:39,090 --> 00:17:43,340
De asemenea, sincronizează baza de date locală cu cel mai recent număr de revizie.

219
00:17:43,650 --> 00:17:47,460
Și salvează, de asemenea, informațiile de configurare a ticăloșilor la nivel local.

220
00:17:47,460 --> 00:17:52,500
Deci, acesta este dispozitivul în cazul în care aveți de gând să facă schimbările dvs. comutatoare multiple pot

221
00:17:52,500 --> 00:17:56,530
fi configurate ca servere VTB, dar trebuie să fiți foarte atenți cu asta.

222
00:17:56,580 --> 00:18:03,780
Cel de-al doilea mod este clientul VTB, un client VTB nu poate crea schimbări sau șterge villani.

223
00:18:04,020 --> 00:18:10,050
Este, de asemenea, capabil să trimită anunțuri în față, astfel încât să poată spune în orice violență

224
00:18:10,050 --> 00:18:17,310
listată în prezent în baza sa de date altor switch-uri VTB, de asemenea, poate transmite reclame primite de la alte switch-uri.

225
00:18:17,310 --> 00:18:23,760
În al treilea rând, s-ar sincroniza, de asemenea, baza de date cu cel mai recent număr de revizie

226
00:18:23,760 --> 00:18:29,970
a configurației, aceasta fiind o problemă majoră cu GTP și a ars multor ingineri Cisco în trecut.

227
00:18:29,970 --> 00:18:33,670
Mulți ingineri Cisco nu vor folosi VTB din cauza acestei probleme.

228
00:18:33,930 --> 00:18:36,020
Deci are o tipologie de probă.

229
00:18:36,240 --> 00:18:41,850
Acum avem un server VTB și este o scenă în care toți comutatoarele din partea superioară sunt

230
00:18:41,850 --> 00:18:48,600
configurate ca clienți VTB mașinile gazdă sunt în raidul Villano verde Bil'in și în prezent numărul de revizie pentru domeniu

231
00:18:48,660 --> 00:18:50,320
este numărul de revizie.

232
00:18:51,790 --> 00:18:57,200
Deci, ultimul număr de revizie a configurației se referă la domeniul VTB.

233
00:18:57,220 --> 00:19:03,580
Este Cisco și răufăcătorii care au fost configurați pe switch-uri sunt rău roșii și verzi.

234
00:19:03,580 --> 00:19:06,880
Rețineți încă o dată faptul că întrerupătoarele au o bază de date de personaj negativ.

235
00:19:06,880 --> 00:19:13,030
Asta este ceea ce VTB actualizeaza porturile individuale si comutatoarele trebuie sa fie introduse

236
00:19:13,030 --> 00:19:14,460
manual in corecta.

237
00:19:14,500 --> 00:19:21,000
Acum, cineva conectă un switch nother în topologie, de exemplu, dintr-un mediu de laborator.

238
00:19:21,400 --> 00:19:27,270
Motivul pentru care acest lucru este periculos este că într-un mediu de laborator obiectivul poate fi adăugat și eliminat

239
00:19:27,610 --> 00:19:32,200
și, astfel, numărul de revizie poate fi mult mai mare decât rețeaua de producție.

240
00:19:32,200 --> 00:19:38,020
Să presupunem, deci, că numărul de revizie este de 50. Acest comutator nu are decât un defect

241
00:19:38,020 --> 00:19:39,430
albastru configurat pe el.

242
00:19:39,430 --> 00:19:44,140
Deci villanele verzi și roșii nu există în baza de date a ticăloșilor.

243
00:19:44,140 --> 00:19:49,750
Mulți oameni fac greșeala de a presupune că atâta timp cât switch-urile configurate ca un

244
00:19:50,260 --> 00:19:53,290
client VTB nu vor cauza probleme în rețea.

245
00:19:53,290 --> 00:19:58,210
Deci, un administrator a conectat comutatorul și configurează acest port ca un portbagaj.

246
00:19:58,510 --> 00:20:02,610
Rețineți încă o dată că publicitatea ETP a trimis doar prin porturile portbagajului.

247
00:20:02,710 --> 00:20:08,880
Să presupunem că în întreaga rețea toate aceste linkuri sunt configurate ca trunchi de îndată ce acest

248
00:20:08,880 --> 00:20:11,380
client este adăugat la domeniul VCP.

249
00:20:11,520 --> 00:20:17,980
Ceea ce este cu adevărat înfricoșător este că acest client poate fi actualizat automat cu informațiile VCP.

250
00:20:18,030 --> 00:20:23,130
Cu alte cuvinte, dacă este configurat cu un domeniu nold, acesta se poate conecta automat la domeniul VCP curent

251
00:20:23,130 --> 00:20:23,920
al Cisco.

252
00:20:24,180 --> 00:20:29,490
Și de îndată ce se întâmplă acest lucru, dispozitivele vor sincroniza bazele de date cu cel mai

253
00:20:29,490 --> 00:20:35,160
recent număr de revizie a configurației, care în acest caz este de 50 de soare toate switch-urile din domeniul live.

254
00:20:35,160 --> 00:20:41,730
Numărul reviziei este modificat la 50 deoarece toate comutatoarele, inclusiv serverul VTB, se vor sincroniza

255
00:20:41,760 --> 00:20:49,080
automat cu clientul VTB, villanul roșu și verdele curent sunt îndepărtate automat din baza de date

256
00:20:49,080 --> 00:20:55,230
violentă și singura persoană care va fi acum disponibilă în bazele de date

257
00:20:55,230 --> 00:20:58,800
violente ale toate aceste comutatoare sunt violente.

258
00:20:58,800 --> 00:21:05,960
Acum, toate porturile de pe toate switch-urile care au fost introduse manual în Villon verde sau roșu

259
00:21:06,090 --> 00:21:07,650
sau heire dezactivate.

260
00:21:07,650 --> 00:21:14,810
Problema este că un port aparține Villon roșu, dar Villon roșu nu există în baza de date.

261
00:21:14,910 --> 00:21:17,510
Deci portul este automat dezactivat.

262
00:21:17,790 --> 00:21:23,500
Asta inseamna ca traficul nu poate fi trimis sau primit pe sport si acelasi lucru se intampla si pe

263
00:21:23,520 --> 00:21:24,720
toate celelalte switch-uri.

264
00:21:24,750 --> 00:21:30,030
În esență, ceea ce se întâmplă este că întreaga rețea este redusă prin introducerea

265
00:21:30,030 --> 00:21:31,200
comutatorului unic.

266
00:21:31,200 --> 00:21:37,350
Este extrem de îngrijorător să spunem cel puțin că introducerea unui singur switch poate aduce

267
00:21:37,350 --> 00:21:39,690
o întreagă rețea de întreprinderi.

268
00:21:39,810 --> 00:21:46,830
Singura modalitate de a rezolva aceasta este conectarea fizică la serverul VTB și apoi adăugarea manuală a

269
00:21:46,920 --> 00:21:49,200
villanilor care au fost șterși.