Hodiaŭ ni komencos studi la EIGRP-protokolon, kiu, kune kun studado de OSPF, estas la plej grava temo de la CCNA-kurso.
Ni revenos al Sekcio 2.5 poste, sed nuntempe, tuj post Sekcio 2.4, ni pluiros al Sekcio 2.6, "Agordo, Kontrolado kaj Solvado de EIGRP per IPv4 (Ekskludante Aŭtentikigon, Filtrilon, Manan Resumon, Redistribuon kaj Ŝtupon). Agordo)."
Hodiaŭ ni havos enkondukan lecionon, en kiu mi prezentos al vi la koncepton de la Plibonigita Interna Enireja Voja Protokolo EIGRP, kaj en la venontaj du lecionoj ni rigardos agordon kaj solvi problemojn de la robotoj de la protokolo. Sed unue mi volas diri al vi la jenon.
Dum la lastaj kelkaj lecionoj ni lernis pri OSPF. Nun mi volas, ke vi memoru, ke kiam ni rigardis RIP antaŭ multaj monatoj, ni parolis pri vojaj bukloj kaj teknologioj kiuj malhelpas trafikon de buklo. Kiel vi povas malhelpi vojajn buklojn kiam vi uzas OSPF? Ĉu por tio eblas uzi metodojn kiel Route Poison aŭ Split Horizon? Ĉi tiuj estas demandoj, kiujn vi devas respondi mem. Vi povas uzi aliajn temajn rimedojn, sed trovi respondojn al ĉi tiuj demandoj. Mi volas, ke vi lernu kiel trovi la respondojn mem laborante kun malsamaj fontoj, kaj mi instigas vin lasi viajn komentojn sub ĉi tiu video por ke mi povu vidi kiom da miaj studentoj plenumis ĉi tiun taskon.
Kio estas EIGRP? Ĝi estas hibrida vojigprotokolo kiu kombinas la utilajn ecojn de kaj distancvektorprotokolo kiel ekzemple RIP kaj lig-ŝtata protokolo kiel ekzemple OSPF.
EIGRP estas proprieta protokolo de Cisco, kiu fariĝis havebla al publiko en 2013. De la protokolo pri spurado de ligo-ŝtato, li adoptis algoritmon de starigo de kvartalo, male al RIP, kiu ne kreas najbarojn. RIP ankaŭ interŝanĝas vojtablojn kun aliaj partoprenantoj en la protokolo, sed OSPF formas apudecon antaŭ komenci ĉi tiun interŝanĝon. EIGRP funkcias same.
La RIP-protokolo periode ĝisdatigas la plenan vojigtabelon ĉiujn 30 sekundojn kaj distribuas informojn pri ĉiuj interfacoj kaj ĉiuj itineroj al ĉiuj siaj najbaroj. EIGRP ne elfaras periodajn plenajn ĝisdatigojn de informoj, anstataŭe uzante la koncepton de dissendado de Salutaj mesaĝoj en la sama maniero kiel OSPF faras. Ĉiujn kelkajn sekundojn ĝi sendas Saluton por certigi, ke la najbaro ankoraŭ estas "viva".
Male al distanca vektora protokolo, kiu ekzamenas la tutan retan topologion antaŭ ol decidi formi itineron, EIGRP, kiel RIP, kreas itinerojn bazitajn sur onidiroj. Kiam mi diras onidirojn, mi volas diri, ke kiam najbaro raportas ion, EIGRP konsentas kun tio sen demando. Ekzemple, se najbaro diras, ke li scias kiel atingi 10.1.1.2, EIGRP kredas lin sen demandi: "Kiel vi sciis tion? Diru al mi pri la topologio de la tuta reto!
Antaŭ 2013, se vi uzus nur Cisco-infrastrukturon, vi povus uzi EIGRP, ĉar ĉi tiu protokolo estis kreita reen en 1994. Tamen, multaj kompanioj, eĉ uzante Cisco-ekipaĵon, ne volis labori kun ĉi tiu breĉo. Laŭ mi, EIGRP estas la plej bona dinamika enruta protokolo hodiaŭ ĉar ĝi estas multe pli facile uzebla, sed homoj ankoraŭ preferas OSPF. Mi pensas, ke ĉi tio estas pro la fakto, ke ili ne volas esti ligitaj al Cisco-produktoj. Sed Cisco disponigis ĉi tiun protokolon publike ĉar ĝi subtenas triajn retajn ekipaĵojn kiel Juniper, kaj se vi kuniĝas kun kompanio, kiu ne uzas Cisco-ekipaĵojn, vi ne havos problemojn.
Ni faru mallongan ekskurson en la historion de retaj protokoloj.
La RIPv1-protokolo, kiu aperis en la 1980-aj jaroj, havis kelkajn limigojn, ekzemple, maksimuman nombron da saltetoj de 16, kaj tial ne povis disponigi vojigon tra grandaj retoj. Iom poste, ili evoluigis la internan enirejon-enrutigan protokolon IGRP, kiu estis multe pli bona ol RIP. Tamen, ĝi estis pli de distanca vektora protokolo ol ligŝtatprotokolo. En la malfruaj 80-aj jaroj, malferma normo aperis, la OSPFv2 ligŝtatprotokolo por IPv4.
En la fruaj 90'oj, Cisco decidis ke IGRP devis esti plibonigita kaj publikigis la Plibonigitan Internal Gateway Routing Protocol EIGRP. Ĝi estis multe pli efika ol OSPF ĉar ĝi kombinis ecojn de kaj RIP kaj OSPF. Dum ni komencas esplori ĝin, vi vidos, ke EIGRP estas multe pli facile agordebla ol OSPF. Cisco provis krei protokolon kiu certigus la plej rapidan eblan retan konverĝon.
En la malfruaj 90'oj, ĝisdatigita senklasa versio de la RIPv2-protokolo estis publikigita. En la 2000-aj jaroj, aperis la tria versio de OSPF, RIPng kaj EIGRPv6, kiuj subtenis la IPv6-protokolon. La mondo iom post iom alproksimiĝas al plena transiro al IPv6, kaj programistoj de enrutaj protokoloj volas esti pretaj por ĉi tio.
Se vi memoras, ni studis, ke elektante la optimuman itineron, RIP, kiel distanca vektora protokolo, estas gvidata de nur unu kriterio - la minimuma nombro da lupolo, aŭ la minimuma distanco al la celinterfaco. Do, enkursigilo R1 elektos rektan vojon al enkursigilo R3, malgraŭ tio, ke la rapido sur ĉi tiu itinero estas 64 kbit/s - plurajn fojojn malpli ol la rapideco sur la itinero R1-R2-R3, egala al 1544 kbit/s. La RIP-protokolo konsideros malrapidan itineron de unu saltolongo esti optimuma prefere ol rapida itinero de 2 saltoj.
OSPF studos la tutan retan topologion kaj decidos uzi la itineron tra R3 kiel la pli rapidan itineron por komunikado kun enkursigilo R2. RIP utiligas la nombron da lupolo kiel ĝian metrikon, dum la metriko de OSPF estas kosto, kiu en la plej multaj kazoj estas proporcia al la bendolarĝo de la ligo.
EIGRP ankaŭ temigas itinerkoston, sed ĝia metriko estas multe pli kompleksa ol OSPF kaj dependas de multaj faktoroj, inkluzive de Bandwidth, Prokrasto, Fidindeco, Ŝargado kaj maksimuma MTU. Ekzemple, se unu nodo estas pli ŝarĝita ol aliaj, EIGRP analizos la ŝarĝon sur la tuta itinero kaj elektos alian nodon kun malpli da ŝarĝo.
En la CCNA-kurso ni nur konsideros tiajn metrikajn formajn faktorojn kiel Bandwidth kaj Prokrasto; ĉi tiuj estas tiuj, kiujn la metrika formulo uzos.
La distanca vektora protokolo RIP uzas du konceptojn: distanco kaj direkto. Se ni havas 3 enkursigilojn, kaj unu el ili estas konektita al la reto 20.0.0.0, tiam la elekto estos farita per distanco - ĉi tiuj estas lupolo, ĉi-kaze 1 salto, kaj laŭ direkto, tio estas, laŭ kiu vojo - supra. aŭ pli malalta - sendi trafikon.
Krome, RIP uzas periodan ĝisdatigon de informoj, distribuante kompletan vojigtabelon tra la reto ĉiujn 30 sekundojn. Ĉi tiu ĝisdatigo faras 2 aferojn. La unua estas la reala ĝisdatigo de la vojtabelo, la dua kontrolas la viveblecon de la najbaro. Se la aparato ne ricevas ĝisdatigon de respondtabelo aŭ novajn informojn pri itinero de la najbaro ene de 30 sekundoj, ĝi komprenas, ke la itinero al la najbaro ne plu povas esti uzata. La enkursigilo sendas ĝisdatigon ĉiujn 30 sekundojn por ekscii ĉu la najbaro ankoraŭ vivas kaj ĉu la itinero ankoraŭ validas.
Kiel mi diris, Split Horizon-teknologio estas uzata por malhelpi itinerajn buklojn. Ĉi tio signifas, ke la ĝisdatigo ne estas resendita al la interfaco de kiu ĝi venis. La dua teknologio por malhelpi buklojn estas Route Poison. Se la konekto kun la reto 20.0.0.0 montrita en la bildo estas interrompita, la enkursigilo al kiu ĝi estis konektita sendas "venenitan itineron" al siaj najbaroj, en kiu ĝi informas, ke ĉi tiu reto nun estas alirebla en 16 saltoj, tio estas, praktike neatingebla. Tiel funkcias la RIP-protokolo.
Kiel funkcias EIGRP? Se vi memoras el la lecionoj pri OSPF, ĉi tiu protokolo plenumas tri funkciojn: ĝi establas najbarecon, uzas LSA por ĝisdatigi la LSDB konforme al ŝanĝoj en la reto-topologio, kaj konstruas vojtablon. Establi najbarecon estas sufiĉe kompleksa proceduro, kiu uzas multajn parametrojn. Ekzemple, kontroli kaj ŝanĝi 2WAY-konekton - kelkaj konektoj restas en la dudirekta komunika stato, kelkaj iras al la PLENA stato. Male al OSPF, tio ne okazas en la protokolo EIGRP - ĝi kontrolas nur 4 parametrojn.
Kiel OSPF, ĉi tiu protokolo sendas Saluton mesaĝon enhavantan 10 parametrojn ĉiujn 4 sekundojn. La unua estas la aŭtentikiga kriterio, se ĝi estis antaŭe agordita. En ĉi tiu kazo, ĉiuj aparatoj kun kiuj proksimeco estas establita devas havi la samajn aŭtentigajn parametrojn.
La dua parametro estas uzata por kontroli ĉu aparatoj apartenas al la sama aŭtonoma sistemo, tio estas, por establi apudecon uzante la EIGRP-protokolon, ambaŭ aparatoj devas havi la saman aŭtonomian sisteman nombron. La tria parametro estas uzata por kontroli, ke Saluton-mesaĝoj estas senditaj de la sama Fonta IP-adreso.
La kvara parametro estas uzata por kontroli la konsekvencon de la variaj K-valoraj koeficientoj. La EIRGP-protokolo uzas 5 tiajn koeficientojn de K1 ĝis K5. Se vi memoras, se K=0 la parametroj estas ignoritaj, sed se K=1, tiam la parametroj estas uzataj en la formulo por kalkuli la metrikon. Tiel, la valoroj de K1-5 por malsamaj aparatoj devas esti la samaj. En la CCNA-kurso ni prenos la defaŭltajn valorojn de ĉi tiuj koeficientoj: K1 kaj K3 estas egalaj al 1, kaj K2, K4 kaj K5 estas egalaj al 0.
Do, se ĉi tiuj 4 parametroj kongruas, EIGRP establas najbaran rilaton kaj la aparatoj eniras unu la alian en la najbaran tablon. Poste, ŝanĝoj estas faritaj al la topologia tabelo.
Ĉiuj Salut-mesaĝoj estas senditaj al la multielsenda IP-adreso 224.0.0.10, kaj ĝisdatigoj, depende de la agordo, estas senditaj al la unuelsendaj adresoj de najbaroj aŭ al la multielsenda adreso. Ĉi tiu ĝisdatigo ne venas super UDP aŭ TCP, sed uzas malsaman protokolon nomitan RTP, Reliable Transport Protocol. Ĉi tiu protokolo kontrolas ĉu la najbaro ricevis ĝisdatigon, kaj kiel ĝia nomo sugestas, ĝia ŝlosila funkcio estas certigi fidindecon de komunikado. Se la ĝisdatigo ne atingas la najbaron, la transdono estos ripetita ĝis la najbaro ricevos ĝin. OSPF ne havas mekanismon por kontroli la ricevan aparaton, do la sistemo ne scias ĉu najbaraj aparatoj ricevis la ĝisdatigon aŭ ne.
Se vi memoras, RIP sendas ĝisdatigon de la kompleta retotopologio ĉiujn 30 sekundojn. EIGRP nur faras tion se nova aparato aperis en la reto aŭ se iuj ŝanĝoj okazis. Se la subreta topologio ŝanĝiĝis, la protokolo sendos ĝisdatigon, sed ne la plenan topologiotabelon, sed nur la rekordojn kun ĉi tiu ŝanĝo. Se subreto ŝanĝiĝas, nur ĝia topologio estos ĝisdatigita. Ĉi tio ŝajnas esti parta ĝisdatigo, kiu okazas kiam necesas.
Kiel vi scias, OSPF sendas LSAojn ĉiujn 30 minutojn, sendepende de ĉu estas ŝanĝoj al la reto. EIGRP ne sendos iujn ajn ĝisdatigojn por plilongigita tempo ĝis estos iu ŝanĝo en la reto. Tial, EIGRP estas multe pli efika ol OSPF.
Post kiam la enkursigiloj interŝanĝis ĝisdatigajn pakaĵojn, komenciĝas la tria etapo - la formado de vojtabelo bazita sur la metriko, kiu estas kalkulita per la formulo montrita en la figuro. Ŝi kalkulas la koston kaj faras decidon surbaze de ĉi tiu kosto.
Ni supozu, ke R1 sendis Saluton al enkursigilo R2, kaj tiu enkursigilo sendis Saluton al enkursigilo R1. Se ĉiuj parametroj kongruas, la enkursigiloj kreas tabelon de najbaroj. En ĉi tiu tabelo, R2 skribas enskribon pri la enkursigilo R1, kaj R1 kreas enskribon pri R2. Post ĉi tio, enkursigilo R1 sendas la ĝisdatigon al la reto 10.1.1.0/24 konektita al ĝi. En la enrutiga tabelo, ĉi tio aspektas kiel informoj pri la IP-adreso de la reto, la enkursigilo, kiu provizas komunikadon kun ĝi, kaj la kosto de la itinero tra ĉi tiu interfaco. Se vi memoras, la kosto de EIGRP estas 90, kaj tiam la Distancvaloro estas indikita, pri kiu ni parolos poste.
La kompleta metrika formulo aspektas multe pli komplika, ĉar ĝi inkluzivas la valorojn de la K-koeficientoj kaj diversaj transformoj. La retejo de Cisco provizas kompletan formon de la formulo, sed se vi anstataŭigas la defaŭltajn koeficientajn valorojn, ĝi estos konvertita en pli simplan formon - la metriko egalos al (bendolarĝo + Prokrasto) * 256.
Ni uzos nur ĉi tiun simpligitan formon de la formulo por kalkuli la metrikon, kie la bendolarĝo en kilobitoj estas egala al 107, dividita per la plej malgranda bendolarĝo de ĉiuj interfacoj kondukantaj al la celreto malplej-bendolarĝo, kaj la akumula-prokrasto estas la totala. prokrasto en dekoj da mikrosekundoj por ĉiuj interfacoj kondukantaj al la celreto.
Dum lernado de EIGRP, ni devas kompreni kvar difinojn: Realigebla Distanco, Raportita Distanco, Posteulo (najbara enkursigilo kun la plej malalta vojo kosto al la celreto), kaj Realigebla Posteulo (rezerva najbara enkursigilo). Por kompreni kion ili signifas, konsideru la sekvan retan topologion.
Ni komencu kreante vojtablon R1 por elekti la plej bonan vojon al reto 10.1.1.0/24. Apud ĉiu aparato la trairo en kbit/s kaj latencia en ms estas montritaj. Ni uzas 100 Mbps aŭ 1000000 kbps GigabitEthernet interfacoj, 100000 kbps FastEthernet, 10000 kbps Ethernet, kaj 1544 kbps seriaj interfacoj. Ĉi tiuj valoroj povas esti trovitaj rigardante la karakterizaĵojn de la respondaj fizikaj interfacoj en la enkursigilo-agordoj.
La defaŭlta trafluo de Seriaj interfacoj estas 1544 kbps, kaj eĉ se vi havas 64 kbps linion, la trairo ankoraŭ estos 1544 kbps. Tial, kiel retadministranto, vi devas certigi, ke vi uzas la ĝustan bendolarĝan valoron. Por specifa interfaco, ĝi povas esti agordita per la bendolarĝa komando, kaj uzante la prokrastan komandon, vi povas ŝanĝi la defaŭltan prokrastan valoron. Vi ne devas zorgi pri la defaŭltaj bendolarĝaj valoroj por GigabitEthernet aŭ Ethernet-interfacoj, sed atentu elektante la liniorapidecon se vi uzas Serian interfacon.
Bonvolu noti, ke en ĉi tiu diagramo la prokrasto estas supozeble indikita en milisekundoj ms, sed fakte ĝi estas mikrosekundoj, mi simple ne havas la literon μ por ĝuste indiki mikrosekundojn μs.
Bonvolu tre atenti la jenan fakton. Se vi eldonas la komandon show interface g0/0, la sistemo montros la latentecon en dekoj da mikrosekundoj prefere ol nur mikrosekundoj.
Ni rigardos ĉi tiun aferon detale en la sekva video pri agordo de EIGRP, nun memoru, ke kiam oni anstataŭigas latenciajn valorojn en la formulon, 100 μs de la diagramo iĝas 10, ĉar la formulo uzas dekojn da mikrosekundoj, ne unuojn.
En la diagramo, mi indikos per ruĝaj punktoj la interfacojn al kiuj rilatas la montritaj trafluoj kaj prokrastoj.
Antaŭ ĉio, ni devas determini la eblan Fareblan Distancon. Ĉi tio estas la FD-metriko, kiu estas kalkulita per la formulo. Por la sekcio de R5 al la ekstera reto, ni devas dividi 107 per 106, kiel rezulto ni ricevas 10. Poste, al ĉi tiu bendolarĝa valoro ni devas aldoni prokraston egalan al 1, ĉar ni havas 10 mikrosekundojn, tio estas, unu dek. La rezulta valoro de 11 devas esti multobligita per 256, tio estas, la metrika valoro estos 2816. Ĉi tiu estas la FD-valoro por ĉi tiu sekcio de la reto.
Enkursigilo R5 sendos ĉi tiun valoron al enkursigilo R2, kaj por R2 ĝi fariĝos la deklarita Raportita Distanco, tio estas, la valoro, kiun la najbaro diris al ĝi. Tiel, la anoncita RD-distanco por ĉiuj aliaj aparatoj estos egala al la ebla FD-distanco de la aparato, kiu raportis ĝin al vi.
Enkursigilo R2 faras FD-kalkulojn surbaze de siaj datumoj, tio estas, ĝi dividas 107 per 105 kaj ricevas 100. Tiam ĝi aldonas al ĉi tiu valoro la sumon de prokrastoj sur la vojo al la ekstera reto: la malfruo de R5, egala al unu dek mikrosekundoj, kaj sia propra malfruo, egala al dek dekoj. La totala prokrasto estos 11 dekoj da mikrosekundoj. Ni aldonas ĝin al la rezulta cent kaj ricevas 111, multobligu ĉi tiun valoron per 256 kaj ricevas la valoron FD = 28416. Enkursigilo R3 faras same, ricevante post la kalkuloj la valoron FD=281856. Enkursigilo R4 kalkulas la valoron FD=3072 kaj transdonas ĝin al R1 kiel RD.
Bonvolu noti, ke dum kalkulado de FD, enkursigilo R1 ne anstataŭigas sian propran bendolarĝon de 1000000 kbit/s en la formulon, sed la pli malaltan bendolarĝon de enkursigilo R2, kiu estas egala al 100000 kbit/s, ĉar la formulo ĉiam uzas la minimuman bendolarĝon de la interfaco kondukanta al la celreto. En ĉi tiu kazo, enkursigiloj R10.1.1.0 kaj R24 situas sur la vojo al reto 2/5, sed ĉar la kvina enkursigilo havas pli grandan bendolarĝon, la plej malgranda bendolarĝa valoro de enkursigilo R2 estas anstataŭigita en la formulon. La totala prokrasto laŭ la vojo R1-R2-R5 estas 1+10+1 (dekoj) = 12, la reduktita trafluo estas 100, kaj la sumo de ĉi tiuj nombroj multobligita per 256 donas la valoron FD=30976.
Do, ĉiuj aparatoj kalkulis la FD de siaj interfacoj, kaj enkursigilo R1 havas 3 itinerojn kondukantajn al la celreto. Ĉi tiuj estas itineroj R1-R2, R1-R3 kaj R1-R4. La enkursigilo elektas la minimuman valoron de la ebla distanco FD, kiu estas egala al 30976 - ĉi tiu estas la vojo al la enkursigilo R2. Ĉi tiu enkursigilo fariĝas la Posteulo aŭ "posteulo". La vojtabelo ankaŭ indikas Feasible Successor (rezerva posteulo) - tio signifas, ke se la ligo inter R1 kaj Posteulo estas rompita, la itinero estos direktita per la rezerva Feasible Successor-enkursigilo.
Realigeblaj Posteuloj estas asignitaj laŭ ununura regulo: la anoncita distanco RD de ĉi tiu enkursigilo devas esti malpli ol la FD de la enkursigilo en la segmento al la Posteulo. En nia kazo, R1-R2 havas FD = 30976, RD en la sekcio R1-K3 estas egala al 281856, kaj RD en la sekcio R1-R4 estas egala al 3072. Ĉar 3072 < 30976, enkursigilo R4 estas elektita kiel Realigeblaj Posteuloj.
Ĉi tio signifas, ke se komunikado estas interrompita sur la retsekcio R1-R2, trafiko al la reto 10.1.1.0/24 estos sendita laŭ la itinero R1-R4-R5. Ŝanĝi itineron dum uzado de RIP daŭras plurajn dekojn da sekundoj, kiam vi uzas OSPF ĝi daŭras plurajn sekundojn, kaj en EIGRP ĝi okazas tuj. Tio estas alia avantaĝo de EIGRP super aliaj vojprotokoloj.
Kio okazas se ambaŭ Posteulo kaj Realigebla Posteulo estas malkonektitaj samtempe? En ĉi tiu kazo, EIGRP uzas la DUAL-algoritmon, kiu povas kalkuli rezervan itineron tra verŝajna posteulo. Ĉi tio povas daŭri plurajn sekundojn, dum kiuj EIGRP trovos alian najbaron, kiu povas esti uzata por plusendi la trafikon kaj meti ĝiajn datumojn en la vojigtabelon. Post ĉi tio, la protokolo daŭrigos sian normalan enrutigan laboron.
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, 30% rabato por uzantoj de Habr sur unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com