Uten nummer tunnel: hvilken adresse låner den?
En tunnel uten nummer låner adressen til et annet grensesnitt, og gjør dermed donoren til en avhengighet. Skill ytre kilde, lånt identitet og rutede prefikser.
En tunnel uten nummer hopper over trinnet der du finner opp et subnett for det logiske grensesnittet, men hopper ikke over adressering helt. Implementasjonen trenger fortsatt en lokal IP-identitet, så den låner adressen til et annet konfigurert grensesnitt. Den donoren er nå en del av designet ditt: hvis adressen endres eller grensesnittet flapper, følger IP-oppførselen til tunnelen etter. Tre beslutninger blandes sammen i de fleste beskrivelser, og å skille dem hindrer en konfigurasjon som ser riktig ut og ikke ruter noe.
Behandle donoren som et designvalg, ikke som en syntaksdetalj.
Tre adresseroller, holdt atskilt
Den ytre kilden er adressen som bærer tunnelpakker over underlaget, og det er den peer-en må kunne nå. Den lånte adressen er identiteten det logiske grensesnittet uten nummer bruker for IP-behandling når pakkene er dekapslet. De beskyttede prefiksene er LAN-nettene hvis trafikk skal krysse tunnelen, og de annonseres av en rutingsprotokoll fremfor av tunneladressen. Å merke et grensesnitt som uten nummer tildeler ingen av disse rollene til de andre.
Den adskillelsen forklarer en vanlig forvirring: å låne en adresse overleverer ikke hele Ethernet-segmentet til donoren til den fjerne peer-en.
Velge donorgrensesnittet
En loopback er vanligvis den bedre donoren fordi adressen er stabil, alltid oppe og uavhengig av en enkelt fysisk lenke. Å låne fra et LAN-grensesnitt kobler tunnelen til tilstanden og adressetildelingen til det grensesnittet, som er et annet driftsmessig bytte: praktisk i et laboratorium, skjørt når LAN-et får nye adresser. Bekreft at plattformen støtter drift uten nummer på tunneltypen du bygger, før du velger noen av dem.
Uansett hvilken donor du velger, dokumenter den som en avhengighet i endringsloggen ved siden av selve tunnelkonfigurasjonen.
Konfigurere og lese tilbake tunnelen
Eksempelet nedenfor er en multipoint GRE-tunnel på rutere i IOS-familien, som låner en loopback og peker den ytre kilden mot underlagsgrensesnittet. NHRP-identiteten er atskilt fra den lånte adressen og må konfigureres eksplisitt.
interface Loopback0 ip address 10.255.255.1 255.255.255.255 interface Tunnel0 ip unnumbered Loopback0 tunnel source GigabitEthernet0/0 tunnel mode gre multipoint ip nhrp network-id 100 ! verify show interfaces Tunnel0 | include line protocol|Tunnel source show ip interface brief | include Tunnel|Loopback show ip nhrp
Les grensesnittlinjen først: en tunnel uten nummer som rapporterer down, ruter ikke uansett hvilken lånt adresse den har. Kontroller deretter at donoren er oppe og at adressen er den du hadde tenkt, fordi en loopback med ny adresse stille endrer identiteten tunnelen presenterer.
Avslutt med å kontrollere rutetabellen for de beskyttede prefiksene og nabolaget over tunnelen, fordi en korrekt grensesnitttilstand beviser ikke at noen av delene er tilgjengelige.
Hva den lånte adressen ikke gir
DMVPN trenger NHRP-registreringer og -mappinger slik at spokes kan slå opp hverandre; en linje uten nummer gir ingenting av det. Autentisering, tillatt videresending og returruter er fortsatt nødvendig, og en rutingsprotokoll må danne et nabolag over tunnelen før noe prefiks utveksles. Hver av disse kan svikte mens grensesnittet rapporterer at det er oppe, derfor går verifiseringen fra adresse til mapping til rute.
Kommandosyntaks og adresseringsregler varierer også etter produkt og versjon, så tilpass deg grensesnittmodellen til enheten foran deg i stedet for å kopiere en konfigurasjon fra en annen plattform. Målet kan være identisk mens de nødvendige linjene ikke er det.
Skriv donoren, den ytre kilden og de annonserte prefiksene inn i tunnelens dokumentasjon, og legg deretter til én sjekk som feiler høyt hvis donoradressen endres. Den ene sjekken fanger feilmodusen som design uten nummer oftest skjuler.