Tunnel utan nummer: vilken adress lånar den?

En tunnel utan nummer hoppar över steget där du hittar på ett subnät för det logiska gränssnittet, men hoppar inte över adressering helt. Implementationen behöver fortfarande en lokal IP-identitet, så den lånar adressen från ett annat konfigurerat gränssnitt. Den donatorn är nu en del av din design: om adressen ändras eller gränssnittet flappar följer tunneln IP-beteendet efter. Tre beslut blandas ihop i de flesta texter, och att skilja dem åt förhindrar en konfiguration som ser korrekt ut och inte routar något.

Behandla donatorn som ett designval, inte som en syntaxdetalj.

Tre adressroller, hållna isär

Den yttre källan är adressen som bär tunnelpaket över underlagret, och det är den som peeren måste kunna nå. Den lånade adressen är identiteten som det logiska gränssnittet utan nummer använder för IP-behandling när paketen har dekapsulerats. De skyddade prefixen är LAN-näten vars trafik ska korsa tunneln, och de annonseras av ett routingprotokoll i stället för av tunneladressen. Att markera ett gränssnitt som utan nummer tilldelar ingen av dessa roller till de andra.

Den åtskillnaden förklarar en vanlig förvirring: att låna en adress överlämnar inte donatorns hela Ethernet-segment till den avlägsna peeren.

Välja donatorgränssnittet

En loopback är oftast den bättre donatorn eftersom adressen är stabil, alltid uppe och oberoende av en enskild fysisk länk. Att låna från ett LAN-gränssnitt kopplar tunneln till det gränssnittets tillstånd och adresstilldelning, vilket är en annan driftsmässig avvägning: bekvämt i ett labb, ömtåligt när LAN-et får nya adresser. Bekräfta att plattformen stöder drift utan nummer för den tunneltyp du bygger innan du väljer någon av dem.

Vilken donator du än väljer ska du dokumentera den som ett beroende i ändringsloggen bredvid själva tunnelkonfigurationen.

Konfigurera och läs tillbaka tunneln

Exemplet nedan är en multipoint GRE-tunnel på routrar i IOS-familjen, som lånar en loopback och pekar sin yttre källa mot underlagsgränssnittet. NHRP-identiteten är skild från den lånade adressen och måste konfigureras explicit.

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

Läs gränssnittsraden först: en tunnel utan nummer som rapporterar down routar inte oavsett den lånade adressen. Kontrollera sedan att donatorn är uppe och att adressen är den du avsåg, eftersom en loopback med ny adress tyst ändrar den identitet tunneln presenterar.

Avsluta med att kontrollera routingtabellen för de skyddade prefixen och grannskapet över tunneln, eftersom ett korrekt gränssnittstillstånd inte bevisar att någon av dem går att nå.

Vad den lånade adressen inte ger

DMVPN behöver NHRP-registreringar och -mappningar så att spokes kan hitta varandra; en linje utan nummer ger inget av det. Autentisering, tillåten vidarebefordran och returvägar krävs fortfarande, och ett routingprotokoll måste bilda ett grannskap över tunneln innan något prefix utbyts. Var och en av dessa kan misslyckas medan gränssnittet rapporterar att det är uppe, därför går verifieringen från adress till mappning till rutt.

Kommandosyntax och adresseringsregler varierar också efter produkt och version, så anpassa dig till gränssnittsmodellen på enheten framför dig i stället för att kopiera en konfiguration från en annan plattform. Målet kan vara identiskt medan de nödvändiga raderna inte är det.

Skriv donatorn, den yttre källan och de annonserade prefixen i tunnelns dokumentation och lägg sedan till en kontroll som misslyckas högt om donatorns adress ändras. Den enda kontrollen fångar det felmod som designer utan nummer oftast döljer.