Miért nem megvalósítható utód a VPN-tartalékod az EIGRP-ben

Egy második tunel feljön, az útválasztási tábla továbbra is egy útvonalat mutat, és a kézenfekvő következtetés az, hogy a protokoll nem vette észre. Általában észreveszi és elutasítja. Az EIGRP csak akkor telepít tartalékot, ha az átmegy egy adott hurokmentes teszten, és az, hogy egy tunel fel van jönve, semmit nem mond arról, hogy a szomszéd jelentett távolsága átmegy-e ezen a teszten. Ez a különbség a teljes válasz, és ez aritmetika, nem időzítő.

A feltétel, pontosan megfogalmazva

RFC 7868 a megvalósíthatósági feltételt a szomszéd hurokmentes útvonalának elegendő ellenőrzéseként határozza meg: a szomszéd célhoz jelentett távolságának szigorúan kisebbnek kell lennie a helyi megvalósítható távolságnál. Szigorúan. Nem kisebb vagy egyenlő.

Ez az egyetlen egyenlőtlenség teszi az alternatívát megvalósítható utóddá. Minden más itt könyvelés körülötte.

Két távolság, különböző feladatokkal

A jelentett távolság az, amit a szomszéd a célhoz hirdet. A megvalósítható távolság a legkisebb ismert teljes metrika nyilvántartása az utolsó ACTIVE–PASSIVE átmenet óta, ezért eltérhet a jelenlegi legjobb útvonal metrikájától. A kettő összekeverése magabiztosan téves következtetéseket ad.

Egy üzemeltetési kijelzőn több távolságszerű oszlop áll egymás mellett. Olvasd el annak az oszlopnak a fejlécét, amelyiket használod, és ne feledd, hogy a szomszéd teljes számított útvonalmetrikája nem ugyanaz a mennyiség, mint a neked jelentett távolság.

Egy kidolgozott összehasonlítás

Vegyünk egy kinyilvánított példát 1000 megvalósítható távolsággal. A 900-at jelentő szomszéd átmegy a teszten, és megvalósítható utód lehet. Az 1000-et jelentő szomszéd elbukik, mert a feltétel szigorú egyenlőtlenség, és az egyenlőség nem elég.

Ezek a számok aritmetika, nem kapcsolatsebességek. Ne olvasd őket jóslatként egy adott routerről vagy javasolt metrikaként.

Az észlelés nem alkalmasság

Egy mechanizmus gyorsan észlelhet egy halott partnert, miközben az EIGRP-nek még nincs alkalmas helyettesítője. Az észlelés az egyik szakasz; a koordinált útvonalszámítás egy másik, és csak akkor indul, ha nincs megvalósítható utód. A feltétel elbukása nem bizonyítja, hogy az alternatívának fizikai hurka van. Azt jelenti, hogy a helyi rövidítésteszt nem teremtette meg a garanciát, ezért a számításnak kezelnie kell az eredményt.

Egy életképességi időzítő lerövidítése nem hozhat létre olyan elérhetőséget, ami soha nem volt, és egy beállított sávszélesség vagy késleltetési érték megváltoztatása nem kapacitásmérés.

Olvasd el a mezőket, aztán teszteld az alkalmazást

Rögzítsd a célt, a jelenlegi utódot, a jelölt szomszédot, annak jelentett távolságát, a megvalósítható távolságot és az eredményül kapott útvonalállapotot. show ip eigrp topology 10.10.10.0/24 a legtöbbet megadja ebből egyetlen előtaghoz. Ezután kösd a döntést ahhoz a tunelútvonalhoz, amely ténylegesen hordozza a következő ugrást, mert az útválasztási tábla és a tuneltábla vitatkozhat arról, melyik interfész van használatban.

Jóváhagyott megfigyelés mellett három dolgot kövess külön: észlelés, útvonalválasztás és az alkalmazás saját helyreállása. Ez a sorrend megmondja, hogy a hiányzó darab egy alkalmas tartalék, az alatta lévő VPN-útvonal vagy a munkaterhelés újracsatlakozása-e, ahelyett hogy feltételeznéd, minden lassú helyreálláshoz még egy időzítő kell.

A hasznos szokás, hogy az egyenlőtlenséget bármi más megérintése előtt ellenőrizzük. Egyetlen parancs kell hozzá, és eldönti a vitát.