DMVPN-rutesamandrag kontra NHRP-samandragskart: ulike tabellar

Nokon ber deg samanfatte spoke-ane, og billetten blir lukka med færre prefiks på hub-en. Ei veke seinare går trafikken mellom filialane, som før gjekk direkte, gjennom hub-en igjen, og ingen knyter dei to endringane saman. Uttrykket samanfatte spoke-ane dekkjer to ulike operasjonar som rører to ulike tabellar. Nemn kva for ein tilstand du reduserer før du låner ein kommando frå eit anna DMVPN-døme.

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

Skilnaden tel mest når ein Phase 2-diskusjon blir brukt på eit Phase 3-design. Dei same orda dukkar opp i begge samtalane, og verknaden på videresending er ikkje den same.

Det er også grunnen til at endringa såg rett ut då ho vart gjennomgått: gjennomgangen kontrollerte rutetabellen, som berre er éin av dei tre involverte tilstandane.

Éin aggregering, to tabellar

Dei to operasjonane ser slik ut:

Eit rutesamandrag er ein påstand om kva hub-en annonserer og kva den mottakande spoke-en installerer som ei rute. Eit NHRP-samandragskart er ein påstand om svaret ein spoke sender når ein annan spoke spør korleis ein når ei adresse. Det er ulike spørsmål med ulike feilmønster, og eit design kan endre det eine og la det andre vere nøyaktig som det var. Å handsame dei som éin knapp er måten ei aggregeringsendring stille blir ei videresendingsendring.

Ingen av operasjonane er ein påstand om vernestien, for han blir forhandla for peer-en du faktisk løyste opp.

Kva samandraget på hub-en faktisk endrar

Ciscom sin vegvisar for NHRP-samandragskart mellom spokes skildrar eit Phase 3-oppsett der hub-en annonserer eit samandrag og blir verande rutings neste hopp. Ei omdirigering og ei påfølgjande NHRP-oppløysing gir då ein meir direkte videresendingsveg. Å lese berre den aggregerte ruta skildrar difor ikkje heile videresendingstilstanden, og det tyder ikkje at kvar pakke må passere hub-en for alltid. Samandraget handlar om tilgjenge, ikkje om vegen.

Difor kan ein designgjennomgang som stoppar ved rutetabellen godkjenne ei endring som endrar oppløysingsåtferda. Undersøk den valde ruta, NHRP-resultatet og vernestien som tre separate observasjonar.

Viss du ikkje kan seie kva for ein av dei tre som endra seg, er endringa ikkje ferdig.

Kva NHRP-samandragskartet endrar

Ta ein spoke som eig 10.32.0.0/19 gjennom fleire meir spesifikke LAN-ruter, medan hub-en annonserer ei større aggregering til dei andre spoke-ane. Ei førespurnad om 10.32.12.10 ville elles fått oppløysingsinformasjon for det samsvarande mindre nettet. Den dokumenterte NHRP-samandragskartfunksjonen lèt spoke-en returnere sitt konfigurerte dekkjeprefiks i staden, noko som kan redusere gjenteke oppløysingsarbeid for nett som høyrer til den spoke-en. Det gjer ikkje rutesamandraget til hub-en og oppløysingssamandraget til spoke-en til det same objektet.

Gi det dekkjeprefikset ein medviten eigarskapsmodell. Eit breitt svar som omfattar adresser som høyrer til andre stader, eller hol som er utilgjengelege, kan sende seinare trafikk mot ein ueigna peer.

Kontroller dei faktiske rutene og dei tiltenkte avviste tilfella før du større opp prefikset, ikkje etterpå.

Samanlikn den første destinasjonen og ein inne i samandraget

Vel to destinasjonar: den første du testa, og ein annan som ligg inne i det føreslåtte samandraget. For kvar av dei registrerer du ruta som vart vald, NHRP-tilstanden som vart brukt for å nå henne, og den faktiske svarvegen. Den samanlikninga fortel deg om du endra rutingsskalaen, oppløysingsskalaen eller ein videresendingsfeil, og det er den einaste nyttige konklusjonen. Ei vising med færre prefiks er ikkje bevis for nokon av dei.

Stadfest den utrulla fasen og neste-hopp-åtferda til rutingsprotokollen før du brukar eit Phase 3-døme på nettet ditt. Eit kort døme er ikkje bevis for at eit anna design held på den same direkte spoke-vegen.

Billetten bør seie kva tabell du reduserte og kva ein du lét vere. Alt mindre vil bli diagnostisert på nytt frå botnen om ein månad.