DMVPN-rutesammendrag kontra NHRP-sammendragskart: forskjellige tabeller

Noen ber deg oppsummere spoke-ene, og billetten lukkes med færre prefikser på hub-en. En uke senere går trafikken mellom filialene, som før gikk direkte, gjennom hub-en igjen, og ingen kobler de to endringene. Uttrykket oppsummer spoke-ene dekker to forskjellige operasjoner som berører to forskjellige tabeller. Navngi hvilken tilstand du reduserer før du låner en kommando fra et annet DMVPN-eksempel.

Symptomet: direkte spoke-trafikk flyttet tilbake til hub-en

Forskjellen betyr mest når en Phase 2-diskusjon brukes på et Phase 3-design. De samme ordene dukker opp i begge samtalene, og virkningen på videresending er ikke den samme.

Det er også derfor endringen så riktig ut da den ble gjennomgått: gjennomgangen kontrollerte rutetabellen, som bare er én av de tre involverte tilstandene.

Én aggregering, to tabeller

De to operasjonene ser slik ut:

Et rutesammendrag er en påstand om hva hub-en annonserer og hva den mottakende spoke-en installerer som en rute. Et NHRP-sammendragskart er en påstand om svaret en spoke sender når en annen spoke spør hvordan man når en adresse. Det er forskjellige spørsmål med forskjellige feilmønstre, og et design kan endre det ene og la det andre være nøyaktig som det var. Å behandle dem som én knapp er måten en aggregeringsendring stille blir en videresendingsendring.

Ingen av operasjonene er en påstand om beskyttelsesstien, for den forhandles for peer-en du faktisk løste opp.

Hva sammendraget på hub-en faktisk endrer

Ciscos veiledning for NHRP-sammendragskart mellom spokes beskriver et Phase 3-oppsett der hub-en annonserer et sammendrag og forblir rutings neste hopp. En omdirigering og en påfølgende NHRP-oppløsning gir da en mer direkte videresendingsvei. Å lese bare den aggregerte ruten beskriver derfor ikke hele videresendingstilstanden, og det betyr ikke at hver pakke må passere hub-en for alltid. Sammendraget handler om tilgjengelighet, ikke om veien.

Derfor kan en designgjennomgang som stopper ved rutetabellen godkjenne en endring som endrer oppløsningsatferden. Undersøk den valgte ruten, NHRP-resultatet og beskyttelsesstien som tre separate observasjoner.

Hvis du ikke kan si hvilken av de tre som endret seg, er endringen ikke ferdig.

Hva NHRP-sammendragskartet endrer

Ta en spoke som eier 10.32.0.0/19 gjennom flere mer spesifikke LAN-ruter, mens hub-en annonserer en større aggregering til de andre spoke-ene. En forespørsel om 10.32.12.10 ville ellers fått oppløsningsinformasjon for det samsvarende mindre nettverket. Den dokumenterte NHRP-sammendragskartfunksjonen lar spoke-en returnere sitt konfigurerte dekningsprefiks i stedet, noe som kan redusere gjentatt oppløsningsarbeid for nettverk som tilhører den spoke-en. Det gjør ikke hub-ens rutesammendrag og spoke-ens oppløsningssammendrag til det samme objektet.

Gi det dekningsprefikset en bevisst eierskapsmodell. Et bredt svar som omfatter adresser som hører til andre steder, eller hull som er utilgjengelige, kan sende senere trafikk mot en uegnet peer.

Kontroller de faktiske rutene og de tiltenkte avviste tilfellene før du forstørrer prefikset, ikke etterpå.

Sammenlign den første destinasjonen og en inne i sammendraget

Velg to destinasjoner: den første du testet, og en annen som ligger inne i det foreslåtte sammendraget. For hver av dem registrerer du ruten som ble valgt, NHRP-tilstanden som ble brukt for å nå den, og den faktiske svarveien. Den sammenligningen forteller deg om du endret rutingsskalaen, oppløsningsskalaen eller en videresendingsfeil, og det er den eneste nyttige konklusjonen. En visning med færre prefikser er ikke bevis for noen av dem.

Bekreft den utrullede fasen og rutingsprotokollens neste-hopp-atferd før du bruker et Phase 3-eksempel på nettverket ditt. Et kort eksempel er ikke bevis for at et annet design beholder den samme direkte spoke-veien.

Billetten bør si hvilken tabell du reduserte og hvilken du lot være. Alt mindre vil bli diagnostisert på nytt fra bunnen om en måned.