Pse rezervi juaj VPN nuk është një pasardhës i pranueshëm i EIGRP
Një pasardhës i pranueshëm duhet të kalojë një pabarazi strikte, jo thjesht të ekzistojë. Krahasoni distancën e raportuar dhe atë të pranueshme përpara se të rregulloni kohëmatësit ose të fajësoni tunelin.
Një tunel i dytë ngrihet, tabela e rrugëzimit vazhdon të tregojë një rrugë të vetme, dhe përfundimi i dukshëm është se protokolli nuk e ka vënë re. Zakonisht e vë re dhe e refuzon. EIGRP instalon një rezervë vetëm kur ajo kalon një provë të caktuar pa sythe, dhe fakti që një tunel është aktiv nuk thotë asgjë nëse distanca e raportuar e fqinjit e kalon atë provë. Ky dallim është e gjithë përgjigja, dhe është aritmetikë, jo kohëmatës.
Kushti, i formuluar saktësisht
RFC 7868 përcakton kushtin e pranueshmërisë si një kontroll të mjaftueshëm për rrugën pa sythe të fqinjit: distanca e raportuar e fqinjit drejt një destinacioni duhet të jetë rreptësisht më e vogël se distanca e pranueshme lokale. Rreptësisht. Jo më e vogël ose e barabartë.
Pikërisht kjo pabarazi e vetme e bën një alternativë pasardhës të pranueshëm. Çdo gjë tjetër këtu është kontabilitet rreth saj.
Dy distanca me detyra të ndryshme
Distanca e raportuar është ajo që fqinji shpall për destinacionin. Distanca e pranueshme është një regjistrim i metrikës totale më të vogël të njohur që nga kalimi i fundit ACTIVE–PASSIVE, prandaj mund të ndryshojë nga metrika e rrugës më të mirë aktuale. Përzierja e këtyre të dyjave prodhon përfundime të gabuara me vetëbesim.
Në një shfaqje operative, disa kolona që duken si distanca qëndrojnë krah për krah. Lexoni kryet e kolonës që po përdorni, dhe mbani mend se metrika e plotë e llogaritur e rrugës së fqinjit nuk është e njëjta madhësi si distanca që ai ju raportoi.
Një krahasim i përpunuar
Merrni një shembull të deklaruar me distancë të pranueshme 1000. Një fqinj që raporton 900 e kalon provën dhe mund të bëhet pasardhës i pranueshëm. Një fqinj që raporton 1000 dështon, sepse kushti është një pabarazi strikte dhe barazia nuk mjafton.
Ata numra janë aritmetikë, jo shpejtësi lidhjeje. Mos i lexoni si parashikim për ndonjë ruter të caktuar ose si metrikë të rekomanduar.
Zbulimi nuk është përshtatshmëri
Një mekanizëm mund të vërë re shpejt një palë të vdekur ndërsa EIGRP ende nuk ka asnjë zëvendësues të përshtatshëm. Vërejtja është një fazë; llogaritja e koordinuar e rrugës është një tjetër, dhe fillon vetëm kur nuk ekziston asnjë pasardhës i pranueshëm. Dështimi në kusht nuk provon që alternativa ka një syth fizik. Do të thotë që prova lokale e shkurtesës nuk e vendosi garancinë, prandaj llogaritja duhet të trajtojë rezultatin.
Shkurtimi i një kohëmatësi të gjallërisë nuk mund të krijojë arritshmëri që nuk ka ekzistuar kurrë, dhe ndryshimi i një gjerësie brezi ose vlerës vonese të konfiguruar nuk është matje e kapacitetit.
Lexoni fushat, pastaj provoni aplikacionin
Regjistroni destinacionin, pasardhësin aktual, fqinjin kandidat, distancën e tij të raportuar, distancën e pranueshme dhe gjendjen e rrugës që rezulton. show ip eigrp topology 10.10.10.0/24 ju jep pjesën më të madhe të kësaj për një prefiks të vetëm. Pastaj lidhni vendimin me rrugën e tunelit që mban vërtet kërcimin tjetër, sepse tabela e rrugëzimit dhe tabela e tuneleve mund të mos bien dakord për ndërfaqen që përdoret.
Nën një vëzhgim të miratuar, ndiqni tre gjëra veçmas: zbulimin, zgjedhjen e rrugës dhe rikuperimin e vetë aplikacionit. Ai sekuencë ju tregon nëse pjesa që mungon është një rezervë e përshtatshme, rruga VPN nën të, apo ngarkesa e punës që rilidhet, në vend që të supozoni se çdo rikuperim i ngadaltë kërkon një kohëmatës tjetër.
Zakoni i dobishëm është të kontrolloni pabarazinë përpara se të prekni çdo gjë tjetër. Kërkon një komandë të vetme dhe e zgjidh debatin.