Waarom je VPN-back-up geen haalbare EIGRP-opvolger is

Er komt een tweede tunnel op, de routingtabel toont nog steeds één pad, en de voor de hand liggende conclusie is dat het protocol het niet heeft gemerkt. Meestal heeft het het wel gemerkt en geweigerd. EIGRP installeert alleen een back-up als die een specifieke lusvrije test doorstaat, en dat een tunnel actief is zegt niets over of de gerapporteerde afstand van de buur die test doorstaat. Dat onderscheid is het hele antwoord, en het is rekenwerk, geen timer.

De voorwaarde, precies geformuleerd

RFC 7868 definieert de haalbaarheidsvoorwaarde als een voldoende controle voor het lusvrije pad van een buur: de gerapporteerde afstand van de buur naar een bestemming moet strikt kleiner zijn dan de lokale haalbare afstand. Strikt. Niet kleiner of gelijk.

Die ene ongelijkheid is wat een alternatief een haalbare opvolger maakt. Al het andere hier is boekhouding eromheen.

Twee afstanden met verschillende taken

De gerapporteerde afstand is wat de buur voor de bestemming aankondigt. De haalbare afstand is een registratie van de kleinste bekende totale metriek sinds de laatste ACTIVE–PASSIVE-overgang, en daarom kan die afwijken van de metriek van het huidige beste pad. Die twee door elkaar halen levert zelfverzekerde verkeerde conclusies op.

In een operationele weergave staan verschillende afstandachtige kolommen naast elkaar. Lees de kop van de kolom die je gebruikt, en onthoud dat de volledige berekende padmetriek van een buur niet dezelfde grootheid is als de afstand die hij je heeft gerapporteerd.

Eén uitgewerkte vergelijking

Neem een verklaard voorbeeld met een haalbare afstand van 1000. Een buur die 900 rapporteert doorstaat de test en kan een haalbare opvolger worden. Een buur die 1000 rapporteert faalt, omdat de voorwaarde een strikte ongelijkheid is en gelijkheid niet genoeg is.

Die getallen zijn rekenwerk, geen linksnelheden. Lees ze niet als een voorspelling over een bepaalde router of als een aanbevolen metriek.

Detectie is geen geschiktheid

Een mechanisme kan een dode peer snel opmerken terwijl EIGRP nog geen geschikte vervanging heeft. Opmerken is één fase; gecoördineerde routeberekening is een andere, en die begint pas als er geen haalbare opvolger bestaat. Het niet halen van de voorwaarde bewijst niet dat het alternatief fysiek een lus heeft. Het betekent dat de lokale sluipwegtests de garantie niet hebben vastgesteld, dus de berekening moet met het resultaat omgaan.

Een levendigheidstimer verkorten kan geen bereikbaarheid creëren die er nooit was, en een geconfigureerde bandbreedte of vertragingswaarde wijzigen is geen meting van capaciteit.

Lees de velden en test dan de toepassing

Noteer de bestemming, de huidige opvolger, de kandidaat-buur, zijn gerapporteerde afstand, de haalbare afstand en de resulterende routestatus. show ip eigrp topology 10.10.10.0/24 geeft je het meeste daarvan voor één prefix. Koppel de beslissing vervolgens aan het tunnelpad dat daadwerkelijk de volgende hop draagt, omdat de routingtabel en de tunneltabel het oneens kunnen zijn over welke interface wordt gebruikt.

Volg onder een goedgekeurde observatie drie dingen afzonderlijk: detectie, routekeuze en het eigen herstel van de toepassing. Die volgorde vertelt je of het ontbrekende stuk een geschikte back-up is, het VPN-pad eronder of de werkbelasting die opnieuw verbinding maakt, in plaats van aan te nemen dat elk traag herstel nog een timer nodig heeft.

De nuttige gewoonte is de ongelijkheid te controleren voordat je iets anders aanraakt. Het kost één opdracht en het beslecht de discussie.