EIGRP susjed ili DMVPN tranzit? Prvo provjerite ulogu

Susjedstvo nedostaje, a ruter u sredini izgleda kao očigledan osumnjičeni. Možda je nevin. Prosleđivanje spoljnih paketa tunela i učešće u overlay protokolu rutiranja su dva različita posla, a uređaj može raditi prvo bez drugoga. Prođite kroz pet provjera ispod redom i zaustavite se na prvoj koja ne uspije.

Korak 1: nacrtajte dvije uloge

Nacrtajte predviđeno EIGRP susjedstvo kao logičku vezu između dva rutera, a zatim nacrtajte underlay rutere koji prenose njegove pakete tunela. Isti uređaj ne mora biti na oba spiska, a miješanje spiskova je najčešći razlog zašto se zdrav tranzitni ruter optužuje da kvari susjedstvo.

Tranzitni ruter prosleđuje spoljne pakete svojim uobičajenim IP rutiranjem i politikom. Ne mora pokretati protokol koji se prenosi unutar zaštićenog tunela i ne treba mu EIGRP proces da bi te pakete prosledio dalje.

Korak 2: provjerite šta srednji uređaj prekida

Ako srednji ruter prekida tunel i treba da tvori EIGRP susjedstva sa spoke uređajima, odgovor se potpuno mijenja. Tom uređaju treba podržano overlay ponašanje rutiranja, a naziv tranzit ne uklanja zahtjev za susjedom. Pročitajte konfiguraciju tunela prije konfiguracije rutiranja. Taj odgovor određuje svaku sljedeću provjeru.

Prvo pravo pitanje zato nije koji protokol podesiti. Nego je li kutija hub, spoke, čisti underlay hop ili Layer 2 usluga koja prenosi okvire između krajnjih tačaka.

Korak 3: provjerite kontrolnu ravan susjeda

Na svakom uređaju koji treba biti susjed potvrdite četiri stvari: EIGRP instancu i broj autonomnog sistema, parametre autentifikacije, interfejs koji učestvuje u procesu i mrežnu naredbu koja pokriva taj interfejs. Neusklađenost u bilo kojoj od njih drži susjedstvo dolje dok interfejs ostaje gore i ping nastavlja raditi.

RFC 7868 opisuje EIGRP kao IP protokol sa multicast razmjenom kontrole, zato susjedski odnos nije nešto što posredni ruter može posredovati rutiranjem paketa prema odredištu. Ili kontrolna razmjena stigne do partnera ili se susjedstvo ne uspostavi.

Korak 4: provjerite prenosi li transport kontrolnu razmjenu

Zatim, provjerite prenosi li overlay kontrolni saobraćaj stvarno između predviđenih krajnjih tačaka. Pregledajte NHRP mapiranje za partnera i spoljnu rutu koja do njega vodi, pa potvrdite da je interfejs tunela aktivan i da propušta saobraćaj. Uspješan underlay ping dokazuje da spoljni put postoji; ne dokazuje da je overlay kontrolna razmjena dostavljena.

Transparentna Layer 2 usluga, tačka-na-tačku tunel i višetačkasti DMVPN oblak prenose multicast na različite načine. Slijedite podržani model interfejsa, NHRP-a i multicasta za ono što je stvarno implementirano, umjesto da pretpostavite da se sva tri ponašaju isto.

Korak 5: redizajnirajte granicu ako ne može učestvovati

Ako potrebni overlay uređaj ne može pokretati protokol, promijenite dizajn izričito. Upotrijebite podržani protokol ili model razmjene na toj granici ili uredite odgovarajući end-to-end tunel tako da susjedi budu krajnje tačke koje stvarno razgovaraju jedna s drugom. Ne pretpostavljajte da statička ruta pretvara neučesnika u relej za svaki kontrolni paket.

Zabilježite ulogu svakog uređaja na dijagramu i čuvajte je uz konfiguraciju. RFC 7868 definiše protokolnu razmjenu, a ta definicija je referenca za to zašto se susjedski odnos ne može simulirati tranzitnim prosleđivanjem.

Kada susjedstvo i dalje ne uspijeva nakon svih pet provjera, preostali osumnjičeni su karakteristike platforme poput obrade multicasta na interfejsu tunela i politike koja filtrira protokol 88. To su konkretni uzroci koji se mogu testirati i vrijede više od još jedne runde okrivljavanja rutera u sredini.