1
00:00:02,120 --> 00:00:09,920
Și apoi mi-a pierdut pavilionul zonei de stâlpi trebuie să fie același cu steagul zonei pasului indică dacă aceasta este o

2
00:00:09,920 --> 00:00:12,870
zonă de stub sau o zonă normală.

3
00:00:12,890 --> 00:00:16,780
Vom vorbi mai multe despre zonele de stub în încă o dată în diapozitivele ulterioare.

4
00:00:17,210 --> 00:00:24,480
Acum, să vorbim despre drumurile desemnate și rutele de rezervă desemnate, deoarece în aceste tipologii au șase

5
00:00:24,490 --> 00:00:32,470
routere conectate la același segment Ethan, astfel că curând D6 este conectat la un switch sau un hub care

6
00:00:32,470 --> 00:00:41,370
împărtășesc aceleași segmente ethernet desemnate de routere sau Dior sunt utilizate pe difuzarea mediilor cu mai multe axe, cum ar fi

7
00:00:41,460 --> 00:00:47,640
Ethernet și așa mai departe, atunci când implementările, cum ar fi mediile multi-axe non-difuzate

8
00:00:47,640 --> 00:00:57,140
în Frame Relay Deci, explică de ce avem o Harada desemnat să presupunem că această rețea 10 1 1 0 este conectată la

9
00:00:57,140 --> 00:01:00,710
una și router-ele sunt conectate la acest lucru.

10
00:01:00,710 --> 00:01:04,820
Etan segmentul și să presupunem că această rețea merge în jos.

11
00:01:05,770 --> 00:01:10,460
Deci, să presupunem pentru moment că nu există un ruter desemnat pe acest segment al lui Ethan.

12
00:01:10,690 --> 00:01:16,960
Și, sperăm, veți vedea rapid de ce există o cerință pentru desemnarea lui Harada pentru a desemna RATO.

13
00:01:16,980 --> 00:01:24,650
Toate aceste routere ar avea o adiacentă completă într-o elysées de proximitate care se schimbă între routere.

14
00:01:24,680 --> 00:01:31,650
Deci, în acest exemplu, toate trebuie să notifice celelalte router-uri utilizând link-urile pe care le actualizează că

15
00:01:31,650 --> 00:01:39,180
a apărut o modificare în topologia rețelei sau una va trimite o actualizare sau trei va trimite o actualizare echipei

16
00:01:39,700 --> 00:01:49,010
noastre 2 sau 4 2 sau 5 sau 6 notificând toate din tije că sa produs o schimbare în tipologia sau două atunci când primești

17
00:01:49,020 --> 00:01:51,150
acea actualizare din sau una.

18
00:01:51,240 --> 00:01:56,560
În acest caz, deoarece nu există nici o desemnată Rodda are o relație deplină cu toate celelalte routere.

19
00:01:56,760 --> 00:02:01,500
Deci, trimite o actualizare tuturor vecinilor săi, pentru ai anunța că există o problemă.

20
00:02:01,560 --> 00:02:07,740
Același lucru se va întâmpla și în cazul celor trei sau trei care primesc o actualizare din partea noastră, astfel încât acesta

21
00:02:07,740 --> 00:02:14,320
să notifice tuturor vecinilor săi că a apărut o schimbare în acel scuz sau vom face același lucru că a primit o actualizare de

22
00:02:14,320 --> 00:02:15,630
la una sau una.

23
00:02:15,910 --> 00:02:21,130
Deci, trimite o actualizare tuturor vecinilor săi și sunt sigur că primești fotografia acum sau cinci au primit acea

24
00:02:21,130 --> 00:02:22,430
actualizare din partea noastră.

25
00:02:22,450 --> 00:02:29,200
Prin urmare, trimite o actualizare tuturor vecinilor săi și în mod legal sau șase trimite o actualizare tuturor vecinilor săi.

26
00:02:29,230 --> 00:02:36,540
Deci, există o mulțime de trafic duplicat atunci când o singură rețea coboară și aceste șase routere au o apropiere

27
00:02:36,780 --> 00:02:38,630
completă una cu cealaltă.

28
00:02:39,000 --> 00:02:45,150
Deci, mai degrabă decât de a face că un traseu desemnat este selectat pe segmentul specific.

29
00:02:45,150 --> 00:02:53,280
Să presupunem că aceștia sau doi au fost aleși ca un traseu desemnat Rodda desemnat pe două criterii.

30
00:02:53,370 --> 00:02:55,720
Primul este prioritatea cea mai mare.

31
00:02:55,890 --> 00:03:03,510
Puteți specifica prioritatea pe o interfață, prioritatea implicită fiind 1 0 exclude Arado de a deveni o Rodda

32
00:03:03,510 --> 00:03:10,150
desemnat sau de rezervă Harada desemnați valorile pentru prioritate sunt de la 1 la 255.

33
00:03:10,200 --> 00:03:15,690
Astfel, primele criterii sunt prioritare în cazul în care prioritățile sunt aceleași, atunci Rotto cu

34
00:03:15,690 --> 00:03:20,460
cel mai înalt Identificator Rodda este ales drept ruta desemnată pentru acel segment.

35
00:03:20,460 --> 00:03:23,970
Deci, în acest exemplu, am ales sau să folosim ruta desemnată.

36
00:03:24,340 --> 00:03:28,310
Și să presupunem din nou că această rețea coboară.

37
00:03:28,380 --> 00:03:35,620
Dar ceea ce se întâmplă acum este sau trimiteți o actualizare numai către cei desemnați sau desemnați ca o

38
00:03:35,630 --> 00:03:42,700
ascultătoare pe această adresă multicast 2 2 4 0 0 6 alți alegători nu ascultă acea adresă multicast.

39
00:03:42,700 --> 00:03:50,500
Deci, din punct de vedere al IP-ului, aceștia nu primesc sau nu văd că actualizarea numai Harada

40
00:03:50,700 --> 00:03:53,290
desemnată primește această actualizare multicast.

41
00:03:53,310 --> 00:03:55,480
Multicastarea nu este acoperită în acest curs.

42
00:03:56,220 --> 00:04:02,880
Dar, pe scurt, această infrastructură era un hub, astfel că drumurile erau conectate printr-un hub cel puțin unul care

43
00:04:02,880 --> 00:04:05,400
multicastul urma să meargă la toate routerele.

44
00:04:05,400 --> 00:04:10,430
Cu toate acestea, numai anumite routere asculta sau accepta multicastul.

45
00:04:10,520 --> 00:04:14,200
Deci, numai anumite routere s-au abonat la multicastul respectiv.

46
00:04:14,280 --> 00:04:21,770
În acest caz, numai Iranul desemnează și ascultă și acceptă multi-proces pentru a aborda 2 2 4 0

47
00:04:21,780 --> 00:04:22,880
0 6.

48
00:04:22,950 --> 00:04:27,240
Deci celălalt ciudat este că cel puțin două vor renunța la această actualizare.

49
00:04:27,590 --> 00:04:32,310
OSPF rezident cel puțin pentru moment este modelul nostru nu va vedea această actualizare.

50
00:04:32,310 --> 00:04:39,330
Pe de alți roders serratus 3 4 5 și 6 dintr-un punct de vedere OSPF scăzut nu va primi actualizarea de

51
00:04:39,750 --> 00:04:44,140
pe router pentru a primi actualizarea atât de logic ce se întâmplă.

52
00:04:44,140 --> 00:04:49,960
Legătura se duce în jos. Traseul 1 actualizează Rodek către ruterul desemnat prin trimiterea unui mesaj

53
00:04:50,050 --> 00:04:57,070
multicast către adresa de pe router la routerele desemnate care primesc routerul multicast pentru a trimite apoi o actualizare tuturor

54
00:04:57,130 --> 00:05:02,170
celorlalți piloți de pe această adresă multicast pentru a face 0 0 5.

55
00:05:02,470 --> 00:05:09,370
Toate routerele OSPF asculta această adresă multicast, astfel încât vor primi actualizarea Router-ul care

56
00:05:09,430 --> 00:05:10,500
primește actualizarea.

57
00:05:10,510 --> 00:05:15,220
Nu ar fi procesat-o pentru că întotdeauna tabelele de tipologii sunt deja actualizate.

58
00:05:15,250 --> 00:05:21,370
Deci, logic, ceea ce se întâmplă este actualizarea de la una sau două părți trimite o actualizare la toate

59
00:05:21,370 --> 00:05:22,290
celelalte routere.

60
00:05:22,540 --> 00:05:28,210
Aceștia procesează actualizarea și consideră că baza de date de scuze este actualizată cu noile informații

61
00:05:28,210 --> 00:05:30,470
pe care această rețea le-a pierdut.

62
00:05:30,940 --> 00:05:38,230
După cum puteți vedea aici, este mult mai eficient să utilizați un router desemnat decât să permiteți

63
00:05:38,230 --> 00:05:43,140
accesul complet între toate routerele și să aveți toate actualizările duplicate.

64
00:05:43,180 --> 00:05:49,090
Este important să înțelegeți că numai designatorul exterior și designatorul de rezervă Rotto vor

65
00:05:49,090 --> 00:05:52,680
avea relații complete cu toate celelalte corpuri.

66
00:05:53,170 --> 00:06:00,900
Deci, de exemplu, rutele 4 și 5 vor avea doar o stare cunoscută sub numele de "Două cale în două feluri".

67
00:06:00,940 --> 00:06:05,960
Ei știu unul despre celălalt, dar nu vor fi schimbate actualizări între routere.

68
00:06:05,980 --> 00:06:09,010
Deci, cu alte cuvinte, 4 sau 5 nu se vor actualiza reciproc.

69
00:06:09,070 --> 00:06:15,820
Nici unul nu va fi cinci sau șase și așa mai departe și așa mai departe, toți piloții vor actualiza

70
00:06:16,000 --> 00:06:22,290
doar ruterul desemnat exterior și de rezervă cu modificări în topologie, astfel încât să aibă o relație deplină cu

71
00:06:22,290 --> 00:06:23,100
ruterul desemnat.

72
00:06:23,530 --> 00:06:30,110
Aceasta permite salvarea actualizărilor și a duplicării traficului pe un singur segment.

73
00:06:30,290 --> 00:06:37,610
Încă o dată, este important să constatăm că Rochus pe segmentul va crea doar relații complete cu routerele de

74
00:06:37,610 --> 00:06:40,580
desemnare și exemplele de designer de rezervă.

75
00:06:40,580 --> 00:06:42,830
Acum, în acest exemplu, am doar un router desemnat.

76
00:06:43,000 --> 00:06:48,860
Problema care are doar un router desemnat este că, dacă acest router se dezactivează, actualizările nu vor fi trimise

77
00:06:48,860 --> 00:06:50,480
și primite în mod corespunzător.

78
00:06:50,480 --> 00:06:56,990
Deci, pe un segment va fi ales un router desemnat și în mod normal ar fi ales și un auto-designator

79
00:06:56,990 --> 00:06:57,930
de rezervă.

80
00:06:58,250 --> 00:07:05,510
Deci, ați avea atât un router desemnat, cât și un designator de rezervă, iar BBR va deveni Diyar dacă

81
00:07:05,510 --> 00:07:06,840
tranzacția nu reușește.