EIGRP susjed ili DMVPN tranzit? Prvo provjerite ulogu

Susjedstvo nedostaje, a usmjerivač u sredini izgleda kao očigledan osumnjičeni. Možda je nevin. Prosljeđivanje vanjskih tunel paketa i sudjelovanje u overlay protokolu usmjeravanja dva su 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 usmjerivača, a zatim nacrtajte underlay usmjerivače koji prenose njegove tunel pakete. Isti uređaj ne mora biti na oba popisa, a miješanje popisa najčešći je razlog zašto se zdrav tranzitni usmjerivač optužuje da kvari susjedstvo.

Tranzitni usmjerivač prosljeđuje vanjske pakete svojim uobičajenim IP usmjeravanjem i politikom. Ne mora pokretati protokol koji se prenosi unutar zaštićenog tunela i ne treba mu EIGRP proces da bi te pakete proslijedio dalje.

Korak 2: provjerite što srednji uređaj prekida

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

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 točaka.

Korak 3: provjerite kontrolnu ravninu susjeda

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

RFC 7868 opisuje EIGRP kao IP protokol s multicast razmjenom kontrole, zato susjedski odnos nije nešto što posredni usmjerivač može posredovati usmjeravanjem 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 promet stvarno između predviđenih krajnjih točaka. Pregledajte NHRP mapiranje za partnera i vanjsku rutu koja do njega vodi, pa potvrdite da je tunelsko sučelje aktivno i da propušta promet. Uspješan underlay ping dokazuje da vanjski put postoji; ne dokazuje da je overlay kontrolna razmjena dostavljena.

Transparentna Layer 2 usluga, točka-na-točku tunel i višetočkovni DMVPN oblak prenose multicast na različite načine. Slijedite podržani model sučelja, 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 sudjelovati

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 točke koje stvarno razgovaraju jedna s drugom. Ne pretpostavljajte da statička ruta pretvara nesudionika 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 prosljeđivanjem.

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