DMVPN maršrutų suvestinė prieš NHRP suvestinės žemėlapį: skirtingos lentelės
Maršrutų suvestinė pakeičia skelbiamą prefiksą ir kitą šuolį. NHRP suvestinės žemėlapis pakeičia tai, ką grąžina sprendimo atsakymas. Tas pats žodis, kita lentelė.
Kažkas paprašo apibendrinti spoke’us, ir bilietas uždaromas su mažiau prefiksų hub’e. Po savaitės tarp filialų einantis srautas, kuris anksčiau ėjo tiesiogiai, vėl eina per hub’ą, ir niekas nesieja šių dviejų pakeitimų. Frazė apibendrinti spoke’us apima dvi skirtingas operacijas, kurios paliečia dvi skirtingas lenteles. Įvardykite, kurią būseną mažinate, prieš pasiskolindami komandą iš kito DMVPN pavyzdžio.
Simptomas: tiesioginis spoke srautas grįžo į hub’ą
Šis skirtumas svarbiausias tada, kai Phase 2 diskusija pritaikoma Phase 3 projektui. Tie patys žodžiai pasirodo abiejuose pokalbiuose, o poveikis persiuntimui nėra toks pat.
Štai kodėl pakeitimas atrodė teisingas peržiūros metu: peržiūra patikrino maršrutizavimo lentelę, o tai yra tik viena iš trijų susijusių būsenų.
Viena agregacija, dvi lentelės
Dvi operacijos atrodo taip:
| Operation | What it actually changes |
|---|---|
| Routing summary | Aggregates the prefixes the routing protocol advertises and changes the next hop the receiver installs |
| NHRP summary map | Changes the network returned in a resolution reply, so a requesting spoke resolves to a different address |
| Protection path | IPsec state for the peer you actually resolved; neither aggregation changes it |
Maršrutų suvestinė yra teiginys apie tai, ką skelbia hub’as ir ką priimantis spoke įdiegia kaip maršrutą. NHRP suvestinės žemėlapis yra teiginys apie atsakymą, kurį spoke siunčia, kai kitas spoke klausia, kaip pasiekti adresą. Tai skirtingi klausimai su skirtingais gedimo būdais, ir projektas gali pakeisti vieną, palikdamas kitą lygiai tokią, kokia buvo. Elgtis su jais kaip su viena svirtimi – tai kelias, kuriuo agregacijos pakeitimas tyliai tampa persiuntimo pakeitimu.
Nė viena operacija nėra teiginys apie apsaugos kelią, nes jis derinamas tam peer’ui, kurį iš tikrųjų išsprendėte.
Ką iš tikrųjų pakeičia hub’o suvestinė
Cisco vadovas apie NHRP suvestinės žemėlapius tarp spoke’ų aprašo Phase 3 išdėstymą, kuriame hub’as skelbia suvestinę ir lieka maršrutizavimo kitu šuoliu. Tada peradresavimas ir vėlesnis NHRP sprendimas suteikia tiesesnį persiuntimo kelią. Todėl skaityti tik agreguotą maršrutą nereiškia aprašyti visos persiuntimo būsenos, ir tai nereiškia, kad kiekvienas paketas amžinai turi eiti per hub’ą. Suvestinė yra apie pasiekiamumą, o ne apie kelią.
Todėl projekto peržiūra, kuri sustoja ties maršrutizavimo lentele, gali patvirtinti pakeitimą, kuris keičia sprendimo elgseną. Patikrinkite pasirinktą maršrutą, NHRP rezultatą ir apsaugos kelią kaip tris atskirus stebėjimus.
Jei negalite pasakyti, kuris iš trijų pasikeitė, pakeitimo nebaigėte.
Ką pakeičia NHRP suvestinės žemėlapis
Paimkite spoke’ą, kuris valdo 10.32.0.0/19 per kelis konkretesnius LAN maršrutus, o hub’as skelbia didesnę agregaciją kitiems spoke’ams. Užklausa 10.32.12.10 kitu atveju gautų atitinkamo mažesnio tinklo sprendimo informaciją. Dokumentuota NHRP suvestinės žemėlapio funkcija leidžia spoke’ui vietoj to grąžinti sukonfigūruotą dengiamąjį prefiksą, o tai gali sumažinti pasikartojantį sprendimo darbą tinklams, priklausantiems tam spoke’ui. Tai nepadaro hub’o maršrutų suvestinės ir spoke’o sprendimo suvestinės tuo pačiu objektu.
Suteikite tam dengiamajam prefiksui apgalvotą nuosavybės modelį. Platus atsakymas, apimantis adresus, priklausančius kitur, arba nepasiekiamos spragos, gali nukreipti vėlesnį srautą netinkamam peer’ui.
Patikrinkite faktinius maršrutus ir numatytus atmestus atvejus prieš padidindami prefiksą, o ne po to.
Palyginkite pirmąją paskirties vietą ir vieną suvestinės viduje
Pasirinkite dvi paskirties vietas: pirmąją, kurią išbandėte, ir kitą, esančią siūlomos suvestinės viduje. Kiekvienai užrašykite pasirinktą maršrutą, pasiekti naudotą NHRP būseną ir tikrąjį atsakymo kelią. Šis palyginimas pasako, ar pakeitėte maršrutizavimo mastą, sprendimo mastą, ar persiuntimo klaidą, ir tai vienintelė naudinga išvada. Ekranas su mažiau prefiksų nėra nė vieno iš jų įrodymas.
Patvirtinkite įdiegtą fazę ir maršrutizavimo protokolo kito šuolio elgseną prieš taikydami Phase 3 pavyzdį savo tinklui. Trumpas pavyzdys neįrodo, kad kitas projektas išlaiko tą patį tiesioginį spoke kelią.
Biliete turi būti pasakyta, kurią lentelę sumažinote ir kurią palikote ramybėje. Viskas, kas mažiau, po mėnesio bus diagnozuojama iš naujo nuo nulio.