EIGRP-naapuri vai DMVPN-läpikulku? Tarkista rooli ensin

Naapuruus puuttuu, ja keskellä oleva reititin näyttää ilmeiseltä epäillyltä. Se voi olla syytön. Ulompien tunnelipakettien välittäminen ja overlay-reititysprotokollaan osallistuminen ovat kaksi eri työtä, ja laite voi tehdä ensimmäisen tekemättä toista. Käy alla olevat viisi tarkistusta järjestyksessä läpi ja pysähdy ensimmäiseen, joka epäonnistuu.

Vaihe 1: piirrä kaksi roolia

Piirrä aiottu EIGRP-naapuruus kahden reitittimen välisenä loogisena yhteytenä ja piirrä sitten underlay-reitittimet, jotka kuljettavat sen tunnelipaketteja. Saman laitteen ei tarvitse esiintyä molemmissa listoissa, ja listojen sekoittaminen on yleisin syy siihen, että tervettä läpikulkureititintä syytetään naapuruuden rikkomisesta.

Läpikulkureititin välittää ulommat paketit tavallisella IP-reitityksellään ja käytännöillään. Sen ei tarvitse ajaa suojatun tunnelin sisällä kuljetettavaa protokollaa, eikä se tarvitse EIGRP-prosessia näiden pakettien eteenpäin välittämiseen.

Vaihe 2: tarkista, mitä keskimmäinen laite päättää

Jos keskimmäinen reititin päättää tunnelin ja sen on tarkoitus muodostaa EIGRP-naapuruuksia spoke-laitteiden kanssa, vastaus muuttuu täysin. Se laite tarvitsee tuetun overlay-reitityskäyttäytymisen, eikä sen kutsuminen läpikuluksi poista naapurivaatimusta. Lue tunnelin kokoonpano ennen reitityksen kokoonpanoa. Tämä vastaus ratkaisee jokaisen seuraavan tarkistuksen.

Ensimmäinen todellinen kysymys ei siis ole, mitä protokollaa säädetään. Kysymys on, onko laite hub, spoke, pelkkä underlay-hyppy vai Layer 2 -palvelu, joka kuljettaa kehyksiä päätepisteiden välillä.

Vaihe 3: tarkista naapurin ohjaustaso

Vahvista jokaisella laitteella, jonka pitäisi olla naapuri, neljä asiaa: EIGRP-instanssi ja autonomisen järjestelmän numero, todennusparametrit, prosessiin osallistuva liitäntä ja liitännän kattava verkkokäsky. Poikkeama missä tahansa niistä pitää naapuruuden alhaalla, kun taas liitäntä pysyy ylhäällä ja ping toimii edelleen.

RFC 7868 kuvaa EIGRP:n IP-protokollaksi, jossa on multicast-ohjausvaihto, minkä vuoksi naapurisuhde ei ole jotain, minkä välissä oleva reititin voisi korvata reitittämällä paketit kohti kohdetta. Joko ohjausvaihto saavuttaa vastapuolen tai naapuruutta ei synny.

Vaihe 4: tarkista, että kuljetus toimittaa ohjausvaihdon

Tarkista seuraavaksi, kuljettaako overlay todella ohjausliikennettä aiottujen päätepisteiden välillä. Tutki vastapuolen NHRP-kartoitus ja ulompi reitti, joka siihen johtaa, ja vahvista sitten, että tunneliliitäntä on ylhäällä ja välittää liikennettä. Onnistunut underlay-ping todistaa, että ulompi polku on olemassa; se ei todista, että overlaun ohjausvaihto toimitettiin.

Läpinäkyvä Layer 2 -palvelu, pisteestä pisteeseen -tunneli ja monipisteinen DMVPN-pilvi toimittavat multicastin eri tavoin. Noudata käytössä olevan ratkaisun tuettua liitäntä-, NHRP- ja multicast-mallia sen sijaan, että olettaisit kaikkien kolmen käyttäytyvän samoin.

Vaihe 5: suunnittele raja uudelleen, jos se ei voi osallistua

Jos vaadittu overlay-laite ei voi ajaa protokollaa, muuta suunnittelua eksplisiittisesti. Käytä kyseisellä rajalla tuettua protokollaa tai vaihtomallia tai järjestä sopiva päästä päähän -tunneli, jotta naapurit ovat ne päätepisteet, jotka todella puhuvat keskenään. Älä oleta, että staattinen reitti muuttaa osallistumattoman laitteen releeksi jokaiselle ohjauspaketille.

Kirjaa kunkin laitteen rooli kaavioon ja säilytä se kokoonpanon kanssa. RFC 7868 määrittelee protokollavaihdon, ja tuo määritelmä on viite sille, miksi naapurisuhdetta ei voi simuloida läpikulkureitityksellä.

Kun naapuruus ei vieläkään synny kaikkien viiden tarkistuksen jälkeen, jäljellä olevat epäillyt ovat alustan ominaisuuksia, kuten multicastin käsittely tunneliliitännällä ja käytäntö, joka suodattaa protokollan 88. Ne ovat konkreettisia, testattavia syitä, ja ne ovat arvokkaampia kuin uusi kierros keskimmäisen reitittimen syyttämistä.