Varför din VPN-säkerhetskopia inte är en möjlig EIGRP-efterträdare
En möjlig efterträdare måste klara en strikt olikhet, inte bara existera. Jämför rapporterat och möjligt avstånd innan du justerar timers eller skyller på tunneln.
En andra tunnel kommer upp, routingtabellen visar fortfarande en enda väg, och den uppenbara slutsatsen är att protokollet inte har märkt det. Vanligtvis har det märkt det och avvisat det. EIGRP installerar bara en säkerhetskopia när den klarar ett specifikt test utan loopar, och att en tunnel är uppe säger ingenting om huruvida grannens rapporterade avstånd klarar det testet. Den skillnaden är hela svaret, och det är aritmetik snarare än en timer.
Villkoret, exakt formulerat
RFC 7868 definierar möjlighetsvillkoret som en tillräcklig kontroll av grannens loopfria väg: grannens rapporterade avstånd till ett mål måste vara strikt mindre än det lokala möjliga avståndet. Strikt. Inte mindre än eller lika med.
Det enda olikhetstecknet är det som gör en alternativ väg till en möjlig efterträdare. Allt annat här är bokföring runt det.
Två avstånd med olika uppgifter
Det rapporterade avståndet är vad grannen annonserar för målet. Det möjliga avståndet är en registrering av den minst kända totala metriken sedan den senaste ACTIVE–PASSIVE-övergången, och därför kan det skilja sig från metriken för den nuvarande bästa vägen. Att blanda de två ger självsäkra felaktiga slutsatser.
I en operativ visning står flera avståndsliknande kolumner sida vid sida. Läs rubriken för den kolumn du använder, och kom ihåg att grannens fullt beräknade vägmetrik inte är samma storhet som avståndet den rapporterade till dig.
En genomräknad jämförelse
Ta ett deklarerat exempel med ett möjligt avstånd på 1000. En granne som rapporterar 900 klarar testet och kan bli en möjlig efterträdare. En granne som rapporterar 1000 klarar det inte, eftersom villkoret är en strikt olikhet och likhet inte räcker.
De siffrorna är aritmetik, inte länkhastigheter. Läs dem inte som en förutsägelse om en viss router eller som ett rekommenderat metrikvärde.
Upptäckt är inte behörighet
En mekanism kan snabbt upptäcka en död peer medan EIGRP fortfarande inte har någon lämplig ersättare. Att upptäcka är en fas; koordinerad ruttberäkning är en annan, och den börjar bara när det inte finns någon möjlig efterträdare. Att misslyckas med villkoret bevisar inte att alternativet fysiskt har en loop. Det betyder att det lokala genvägstestet inte etablerade garantin, så beräkningen måste hantera resultatet.
Att förkorta en livslängdstimer kan inte skapa nåbarhet som aldrig fanns, och att ändra en konfigurerad bandbredd eller fördröjningsvärde är inte en mätning av kapacitet.
Läs fälten och testa sedan applikationen
Notera målet, den nuvarande efterträdaren, kandidatgrannen, dess rapporterade avstånd, det möjliga avståndet och det resulterande ruttillståndet. show ip eigrp topology 10.10.10.0/24 ger dig det mesta av detta för ett enda prefix. Bind sedan beslutet till tunnelvägen som faktiskt bär nästa hopp, eftersom routingtabellen och tunneltabellen kan vara oense om vilket gränssnitt som används.
Under en godkänd observation, följ tre saker var för sig: upptäckt, ruttval och applikationens egen återhämtning. Den sekvensen berättar om den saknade delen är en lämplig säkerhetskopia, VPN-vägen under eller arbetsbelastningen som återansluter, i stället för att anta att varje långsam återhämtning behöver ännu en timer.
Den användbara vanan är att kontrollera olikheten innan du rör något annat. Det krävs ett enda kommando och det avgör diskussionen.