DMVPN-routesammanfattning kontra NHRP-sammanfattningskarta: olika tabeller
En routesammanfattning ändrar det annonserade prefixet och nästa hopp. En NHRP-sammanfattningskarta ändrar vad ett upplösningssvar returnerar. Samma ord, en annan tabell.
Någon ber dig sammanfatta spoke-noderna, och ärendet stängs med färre prefix på hubben. En vecka senare går trafiken mellan filialerna, som förut gick direkt, genom hubben igen, och ingen kopplar ihop de två ändringarna. Uttrycket sammanfatta spoke-noderna omfattar två olika operationer som rör två olika tabeller. Namnge vilket tillstånd du minskar innan du lånar ett kommando från ett annat DMVPN-exempel.
Symtomet: direkt spoke-trafik flyttade tillbaka till hubben
Skillnaden spelar störst roll när en Phase 2-diskussion tillämpas på en Phase 3-design. Samma ord förekommer i båda samtalen, och effekten på vidarebefordran är inte densamma.
Det är också därför ändringen såg korrekt ut vid granskningen: granskningen kontrollerade routingtabellen, som bara är ett av de tre inblandade tillstånden.
En aggregering, två tabeller
De två operationerna ser ut så här:
| 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 |
En routesammanfattning är ett påstående om vad hubben annonserar och vad den mottagande spoke-noden installerar som en route. En NHRP-sammanfattningskarta är ett påstående om svaret en spoke-nod skickar när en annan spoke-nod frågar hur en adress nås. Det är olika frågor med olika felmoder, och en design kan ändra den ena och lämna den andra exakt som den var. Att behandla dem som en enda ratt är hur en aggregeringsändring tyst blir en vidarebefordringsändring.
Ingen av operationerna är ett påstående om skyddsvägen, eftersom den förhandlas för den peer du faktiskt löste upp.
Vad sammanfattningen på hubben faktiskt ändrar
Ciscos vägledning för NHRP-sammanfattningskartor mellan spoke-noder beskriver ett Phase 3-arrangemang där hubben annonserar en sammanfattning och förblir routningens nästa hopp. En omdirigering och en efterföljande NHRP-upplösning ger då en mer direkt vidarebefordringsväg. Att bara läsa den aggregerade routen beskriver därför inte hela vidarebefordringstillståndet, och det betyder inte att varje paket måste passera hubben för alltid. Sammanfattningen handlar om nåbarhet, inte om vägen.
Därför kan en designgranskning som stannar vid routingtabellen godkänna en ändring som ändrar upplösningsbeteendet. Granska den valda routen, NHRP-resultatet och skyddsvägen som tre separata observationer.
Om du inte kan säga vilken av de tre som ändrades har du inte avslutat ändringen.
Vad NHRP-sammanfattningskartan ändrar
Ta en spoke-nod som äger 10.32.0.0/19 via flera mer specifika LAN-rutter, medan hubben annonserar en större aggregering till de andra spoke-noderna. En begäran om 10.32.12.10 skulle annars få upplösningsinformation för det matchande mindre nätet. Den dokumenterade funktionen för NHRP-sammanfattningskartor låter spoke-noden returnera sitt konfigurerade täckningsprefix i stället, vilket kan minska upprepat upplösningsarbete för nät som tillhör den spoke-noden. Det gör inte hubbens routesammanfattning och spoke-nodens upplösningssammanfattning till samma objekt.
Ge det täckningsprefixet en medveten ägarmodell. Ett brett svar som omfattar adresser som hör hemma någon annanstans, eller luckor som inte går att nå, kan skicka senare trafik mot en olämplig peer.
Kontrollera de faktiska rutterna och de avsedda avvisade fallen innan du förstorar prefixet, inte efteråt.
Jämför den första destinationen och en inne i sammanfattningen
Välj två destinationer: den första du testade, och en annan som ligger inne i den föreslagna sammanfattningen. För var och en registrerar du den valda routen, det NHRP-tillstånd som användes för att nå den, och den faktiska svarsvägen. Den jämförelsen säger om du ändrade routningsskalan, upplösningsskalan eller ett vidarebefordringsfel, och det är den enda användbara slutsatsen. En visning med färre prefix är inte bevis för något av dem.
Bekräfta den utrullade fasen och routingprotokollets nästa-hopp-beteende innan du tillämpar ett Phase 3-exempel på ditt nät. Ett kort exempel är inte bevis för att en annan design behåller samma direkta spoke-väg.
Ärendet bör säga vilken tabell du minskade och vilken du lämnade ifred. Allt mindre kommer att diagnostiseras om från början inom en månad.