Ongenommerde tonnel: watter adres leen dit?

'n Ongenommerde tonnel slaan die stap oor waar jy 'n subnet vir die logiese koppelvlak uitdink, maar dit slaan adressering nie heeltemal oor nie. Die implementering het steeds 'n plaaslike IP-identiteit nodig, so dit leen die adres van 'n ander gekonfigureerde koppelvlak. Daardie skenker is nou deel van jou ontwerp: as sy adres verander of sy koppelvlak flap, volg die tonnel se IP-gedrag. Drie besluite word in die meeste beskrywings vermeng, en om hulle te skei verhoed 'n konfigurasie wat korrek lyk en niks roeteer nie.

Behandel die skenker as 'n ontwerpkeuse, nie as 'n sintaksdetail nie.

Drie adresrolle, apart gehou

Die buitenste bron is die adres wat tonnelpakkette oor die onderlaag dra, en dit is wat die eweknie moet kan bereik. Die geleende adres is die identiteit wat die ongenommerde logiese koppelvlak vir IP-verwerking gebruik sodra pakkette gedekapsuleer is. Die beskermde prefikse is die LAN-netwerke wie se verkeer deur die tonnel moet gaan, en hulle word deur 'n roeteringsprotokol geadverteer, nie deur die tonneladres nie. Om 'n koppelvlak as ongenommerd te merk, gee nie een van hierdie rolle aan die ander nie.

Daardie skeiding verduidelik 'n algemene verwarring: om 'n adres te leen gee nie die skenker se hele Ethernet-segment aan die afgeleë eweknie nie.

Die keuse van die skenkerkoppelvlak

'n Loopback is gewoonlik die beter skenker, want sy adres is stabiel, altyd op en onafhanklik van enige enkele fisiese skakel. Om van 'n LAN-koppelvlak te leen, koppel die tonnel aan daardie koppelvlak se toestand en adrestoekenning, wat 'n ander operasionele ruil is: gerieflik in 'n laboratorium, broos wanneer die LAN her-geadresseer word. Bevestig dat die platform ongenommerde werking op die tipe tonnel wat jy bou, ondersteun voordat jy jou tot een van die twee verbind.

Watter skenker jy ook al kies, dokumenteer dit as 'n afhanklikheid in die veranderingsrekord langs die tonnelkonfigurasie self.

Konfigureer en lees die tonnel terug

Die voorbeeld hieronder is 'n multipunt-GRE-tonnel op roeteerders van die IOS-familie wat 'n loopback leen en sy buitenste bron na die onderlaagkoppelvlak wys. Die NHRP-identiteit is apart van die geleende adres en moet eksplisiet gekonfigureer word.

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

Lees eers die koppelvlaklyn: 'n ongenommerde tonnel wat af wys, sal nie roeteer nie, ongeag die geleende adres. Kontroleer dan dat die skenker op is en dat sy adres die een is wat jy bedoel het, want 'n her-geadresseerde loopback verander stilweg die identiteit wat die tonnel voorhou.

Sluit af deur die roetertabel vir die beskermde prefikse en die aangrensendheid oor die tonnel na te gaan, want 'n korrekte koppelvlaktoestand bewys bereikbaarheid van nie een van die twee nie.

Wat die geleende adres nie verskaf nie

DMVPN benodig NHRP-registrasies en -karterings sodat spake mekaar kan oplos; 'n ongenommerde lyn verskaf niks daarvan nie. Outentifikasie, toegelate deurverkeer en terugroetes is steeds nodig, en 'n roeteringsprotokol moet 'n aangrensendheid oor die tonnel vorm voordat enige prefiks uitgeruil word. Elkeen van dié kan misluk terwyl die koppelvlak op wys, daarom loop verifikasie van adres na kartering na roete.

Opdragtaalsintaksis en adresseringsreëls verskil ook per produk en vrystelling, so pas by die koppelvlakmodel van die toestel voor jou eerder as om 'n konfigurasie van 'n ander platform te kopieer. Die doel kan identies wees terwyl die vereiste reëls dit nie is nie.

Skryf die skenker, die buitenste bron en die geadverteerde prefikse in die tonnel se dokumentasie, en voeg dan een kontrole by wat hardop misluk as die skenkeradres verander. Daardie enkele kontrole vang die foutmodus wat ongenommerde ontwerpe die maklikste verberg.