Waarom jou VPN-rugsteun nie ’n EIGRP-haalbare opvolger is nie

’n Tweede tonnel kom op, die roetetabel wys steeds een pad, en die ooglopende gevolgtrekking is dat die protokol dit nie opgemerk het nie. Gewoonlik het dit dit opgemerk en van die hand gewys. EIGRP installeer ’n rugsteun slegs wanneer dit ’n spesifieke lusvrye toets slaag, en ’n tonnel wat op is sê niks oor of die buur se gerapporteerde afstand dit slaag nie. Daardie onderskeid is die hele antwoord, en dit is rekenkunde eerder as ’n timer.

Die voorwaarde, presies gestel

RFC 7868 definieer die haalbaarheidsvoorwaarde as ’n voldoende toets vir ’n buur se lusvrye pad: die buur se gerapporteerde afstand vir ’n bestemming moet streng minder as die plaaslike haalbare afstand wees. Streng. Nie minder as of gelyk nie.

Daardie enkele ongelykheid is wat ’n alternatief ’n haalbare opvolger maak. Alles anders hier is boekhouding daaromheen.

Twee afstande met verskillende take

Die gerapporteerde afstand is wat die buur vir die bestemming adverteer. Die haalbare afstand is ’n rekord van die minste bekende totale metriek sedert die laaste ACTIVE-na-PASSIVE-oorgang, en daarom kan dit van die huidige beste pad se metriek verskil. Om daardie twee te verwar lewer selfversekerde verkeerde gevolgtrekkings.

In ’n operasionele vertoning staan verskeie afstandagtige kolomme langs mekaar. Lees die opskrif van die kolom wat jy gebruik, en onthou dat ’n buur se volledige berekende padmetriek nie dieselfde hoeveelheid is as die afstand wat dit aan jou gerapporteer het nie.

Een uitgewerkte vergelyking

Neem ’n verklaarde voorbeeld met ’n haalbare afstand van 1000. ’n Buur wat 900 rapporteer, slaag die toets en kan ’n haalbare opvolger word. ’n Buur wat 1000 rapporteer, slaag dit nie, want die voorwaarde is ’n streng ongelykheid en gelykheid is nie genoeg nie.

Daardie syfers is rekenkunde, nie skakelspoed nie. Moenie hulle lees as ’n voorspelling oor enige spesifieke roeteerder of as ’n aanbevole metriek nie.

Opsporing is nie geskiktheid nie

’n Meganisme kan ’n dooie eweknie vinnig opmerk terwyl EIGRP steeds geen geskikte vervanging het nie. Opmeking is een stadium; gekoördineerde roeteberekening is ’n ander, en dit begin slegs wanneer geen haalbare opvolger bestaan nie. Om die voorwaarde te faal bewys nie dat die alternatief fisies gelus is nie. Dit beteken die plaaslike kortpadtoets het nie die waarborg gevestig nie, so die berekening moet die resultaat hanteer.

Om ’n lewendigheidstimer te verkort kan nie bereikbaarheid skep wat nooit daar was nie, en om ’n gekonfigureerde bandwydte- of vertragingswaarde te verander is nie ’n meting van kapasiteit nie.

Lees die velde en toets dan die toepassing

Teken die bestemming, die huidige opvolger, die kandidaat-buur, sy gerapporteerde afstand, die haalbare afstand en die gevolglike roetetoestand aan. show ip eigrp topology 10.10.10.0/24 gee jou die meeste daarvan vir ’n enkele voorvoegsel. Bind dan die besluit aan die tonnelpad wat werklik die volgende hop dra, want die roetetabel en die tonneltabel kan verskil oor watter koppelvlak in gebruik is.

Volg onder ’n goedgekeurde waarneming drie dinge afsonderlik: opsporing, roetekeuse en die toepassing se eie herstel. Daardie volgorde vertel jou of die ontbrekende stuk ’n geskikte rugsteun is, die VPN-pad daaronder, of die werklading wat weer koppel, in plaas daarvan om te aanvaar dat elke stadige herstel nog ’n timer nodig het.

Die nuttige gewoonte is om die ongelykheid te toets voordat jy enigiets anders aanraak. Dit neem een opdrag en dit besleg die argument.