DMVPN fáze 3: čtení zkratky v obou směrech

Sledujete, jak jeden ping jde od spoke ke spoke dlouhou cestou přes hub a druhý jde přímo. V tu chvíli je lákavé prohlásit zkratku za funkční. Ten závěr je z poloviny správný. Cesta tam může být zkratkou, zatímco cesta zpět stále vede přes hub, a stav, který dokazuje každý směr, je jiný stav. Projděte oba směry a přečtěte tři tabulky, než design přijmete jako zdravý.

Začněte cestou paketu, kterou skutečně vidíte

Začněte na spoke s cílem, který má být přímý. Sledujte první paket: jde po trase spoke směrem k hubu, protože zkratka ještě neexistuje. Hub ho přepošle a v designu fáze 3 také pošle zdroji přesměrování s informací, že existuje lepší cesta.

Toto přesměrování je spouštěč, ne důkaz. Říká, že hub viděl provoz, který lze optimalizovat. Neříká, že zdroj zkratku vytvořil, že cíl odpověděl na rezoluci nebo že ji cesta odpovědi používá.

První užitečné pozorování je tedy před a po: první tok přes hub, pozdější tok přímo.

Tři stavy, které vypadají jako jeden tunel

Zkratka závisí na třech částech stavu a každá má svou vlastní životnost a svůj vlastní příkaz.

Záznam v cache NHRP přiřazuje overlay adresu k transportní adrese NBMA. Routa nebo zkratka rozhoduje, kam se přeposílá jeden vnitřní cíl. Asociace IPsec chrání provoz, který z toho vznikne. Chybějící odpověď může přijít z kterékoli ze tří částí a příkazy řeknou, která chybí.

Čtěte je v tomto pořadí, protože chybějící mapování dělá ostatní dvě nezajímavými.

Projděte požadavek a odpověď odděleně

Ze spoke A si vyžádejte rezoluci a sledujte, co se vrátí. Požadavek jde podporovanou cestou přesměrování NHRP a cíl může odpovědět přímo, místo aby šel přes hub. Tato asymetrie je normální, a proto je odpověď zajímavější polovinou výměny.

Teď vyměňte role. Pošlete z B do A a zopakujte stejná tři čtení. Design, který dělá zkratku v jednom směru a ve druhém ne, není symetrický a asymetrie obvykle pochází z chybějícího prefixu na jedné straně nebo z rezoluce, která nikdy nedostala odpověď.

Odpověď protějšku nemusí projít hubem jen proto, že přes něj šel požadavek. Nečtěte to jako chybu a nezačínejte honit směrovací závadu, která neexistuje.

Čtěte přesměrování hubu, ne jen jeho routu

Směrovací tabulka hubu vám řekne, kam by hub paket poslal. Přesměrování vám řekne, co hub zdroji přikázal s tím udělat. To jsou různé skutečnosti a hub se správnou routou a bez přesměrování udrží každý tok na dlouhé cestě neomezeně dlouho. Zkontrolujte události NHRP na hubu a potvrďte, že se přesměrování generují pro provoz, na kterém vám záleží.

Fáze 3 také mění, co znamená sumarizace. S chováním zkratky spokes nepotřebují celou sadu konkrétních vzdálených rout, kterou očekával design fáze 2, takže sumarizovaná routa na spoke není automaticky chybějící síť. Potvrďte fázi a směrovací politiku, než sumarizaci přečtete jako závadu.

Právě toto jedno nedorozumění vytváří více DMVPN tiketů než cokoli jiného.

Zapište závěr jako chybějící objekt

Skončete autorizovaným tokem aplikace a jeho odpovědí a u každého směru poznamenejte, zda použil přímou cestu. Poté napište závěr jako objekt, který chyběl: mapování, zkratku přesměrování, asociaci ochrany nebo odpověď aplikace.

Směrovací sousedství a společná bezpečnostní asociace jsou dokladem zdraví, ne dokladem cesty. Obě mohou být dokonalé, zatímco každý paket stále obchází dlouhou cestou. Nejprve zkontrolujte rozhodnutí o přeposílání, potom asociaci, která ho nese. Pořadí je důležité, protože asociace vzniká tak jako tak.

Tento návyk se vyplatí u dalšího tiketu. „Tunel je nahoře, ale pomalý“ se změní na „B nemá zkratku k hostiteli A“ a druhé tvrzení je oprava na pět minut. Uchovávejte výstup příkazů u závěru a mějte u toho průvodce fází 3 od dodavatele.