Sen-numera tunelo: kiun adreson ĝi pruntas?

Sen-numera tunelo preterlasas la paŝon, en kiu vi elpensas subreton por la logika interfaco, sed ĝi ne tute preterlasas adresadon. La efektivigo ankoraŭ bezonas lokan IP-identecon, do ĝi pruntas la adreson de alia konfigurita interfaco. Tiu donanto nun estas parto de via dezajno: se ĝia adreso ŝanĝiĝas aŭ ĝia interfaco svingiĝas, la IP-konduto de la tunelo sekvas ĝin. Tri decidoj miksiĝas en la plej multaj priskriboj, kaj ilia apartigo malhelpas konfiguraĵon, kiu aspektas ĝusta kaj enkursigas nenion.

Traktu la donanton kiel dezajnan elekton, ne kiel sintaksan detalon.

Tri adresaj roloj, tenataj aparte

La ekstera fonto estas la adreso, kiu portas tunelajn pakojn tra la suba reto, kaj ĝi estas tio, kion la samtavolano devas povi atingi. La pruntita adreso estas la identeco, kiun la sen-numera logika interfaco uzas por IP-traktado post kiam pakoj estas malenkapsuligitaj. La protektitaj prefiksoj estas la LAN-retoj, kies trafiko devas trapasi la tunelon, kaj ili estas anoncitaj de enkursiga protokolo, ne de la tunela adreso. Marki interfacon kiel sen-numeran ne asignas iun ajn el tiuj roloj al la aliaj.

Tiu apartigo klarigas oftan konfuzon: prunti adreson ne transdonas la tutan Ethernet-segmenton de la donanto al la malproksima samtavolano.

Elekti la donantan interfacon

Loopback estas kutime la pli bona donanto, ĉar ĝia adreso estas stabila, ĉiam aktiva kaj sendependa de iu unuopa fizika ligilo. Prunti de LAN-interfaco ligas la tunelon al la stato kaj adresatribuo de tiu interfaco, kio estas alia operacia kompromiso: oportuna en laboratorio, fragila kiam la LAN estas re-adresita. Konfirmu, ke la platformo subtenas sen-numeran funkciadon por la tunela tipo, kiun vi konstruas, antaŭ ol decidi pri iu ajn.

Kiun ajn donanton vi elektos, dokumentu ĝin kiel dependecon en la ŝanĝprotokolo apud la tunela konfiguraĵo mem.

Konfiguri kaj relegi la tunelon

La suba ekzemplo estas plurpunkta GRE-tunelo sur enkursigiloj de la familio IOS, kiu pruntas loopback kaj direktas sian eksteran fonton al la suba interfaco. La NHRP-identeco estas aparta de la pruntita adreso kaj devas esti eksplicite konfigurita.

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

Unue legu la interfacan linion: sen-numera tunelo, kiu raportas down, ne enkursigos sendepende de la pruntita adreso. Poste kontrolu, ke la donanto estas aktiva kaj ke ĝia adreso estas la intencita, ĉar re-adresita loopback silente ŝanĝas la identecon, kiun la tunelo prezentas.

Finu per kontrolo de la enkursiga tabelo por la protektitaj prefiksoj kaj la najbareco super la tunelo, ĉar ĝusta interfaca stato pruvas atingeblon de nek unu nek la alia.

Kion la pruntita adreso ne provizas

DMVPN bezonas NHRP-registraĵojn kaj -mapojn, por ke spokes povu trovi unu la alian; sen-numera linio provizas nenion el tio. Aŭtentigo, permesita plusendo kaj revenaj vojradoj ankoraŭ necesas, kaj enkursiga protokolo devas formi najbarecon trans la tunelo antaŭ ol iu ajn prefikso interŝanĝiĝas. Ĉiu el tiuj povas malsukcesi dum la interfaco raportas sin aktiva, tial la kontrolo iras de adreso al mapo al vojrado.

Komanda sintakso kaj adresaj reguloj ankaŭ varias laŭ produkto kaj eldono, do adaptiĝu al la interfaca modelo de la aparato antaŭ vi anstataŭ kopii konfiguraĵon de alia platformo. La celo povas esti identa dum la bezonataj linioj ne estas.

Skribu la donanton, la eksteran fonton kaj la anoncitajn prefiksojn en la dokumentaron de la tunelo, poste aldonu unu kontrolon, kiu laŭte malsukcesas se la donanta adreso ŝanĝiĝas. Tiu sola kontrolo kaptas la malsukcesan reĝimon, kiun sen-numeraj dezajnoj plej verŝajne kaŝas.