Unnumbered Tunnel: Which Address Does It Borrow?

An unnumbered tunnel skips the step where you invent a subnet for the logical interface, but it does not skip addressing altogether. The implementation still needs a local IP identity, so it borrows the address of another configured interface. That donor is now part of your design: if its address changes or its interface flaps, the tunnel's IP behaviour follows. Three decisions get conflated in most write-ups, and separating them prevents a configuration that looks correct and routes nothing.

Treat the donor as a design choice, not a syntax detail.

Three Address Roles, Kept Apart

The outer source is the address that carries tunnel packets across the underlay, and it is what the peer must be able to reach. The borrowed address is the identity the unnumbered logical interface uses for IP processing once packets are decapsulated. The protected prefixes are the LAN networks whose traffic is supposed to cross the tunnel, and they are advertised by a routing protocol rather than by the tunnel address. Marking an interface unnumbered assigns none of these roles to the others.

That separation explains a common confusion: borrowing an address does not hand the donor's whole Ethernet segment to the remote peer.

Choosing the Donor Interface

A loopback is usually the better donor because its address is stable, always up and independent of any single physical link. Borrowing from a LAN interface couples the tunnel to that interface's state and address assignment, which is a different operational trade: convenient in a lab, fragile when the LAN is re-addressed. Confirm the platform supports unnumbered operation on the tunnel type you are building before committing to either.

Whichever donor you pick, document it as a dependency in the change record next to the tunnel configuration itself.

Configure and Read Back the Tunnel

The example below is a multipoint GRE tunnel on IOS-family routers, borrowing a loopback and pointing its outer source at the underlay interface. The NHRP identity is separate from the borrowed address and must be configured explicitly.

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

Read the interface line first: an unnumbered tunnel that reports down will not route regardless of the borrowed address. Then check that the donor is up and that its address is the one you intended, because a re-addressed loopback silently changes the identity the tunnel presents.

Finish by checking the routing table for the protected prefixes and the adjacency over the tunnel, since a correct interface state proves reachability of neither.

What the Borrowed Address Does Not Provide

DMVPN needs NHRP registrations and mappings so spokes can resolve each other; an unnumbered line supplies none of that. Authentication, permitted forwarding and return routes are still required, and a routing protocol must form an adjacency across the tunnel before any prefix is exchanged. Each of those can fail while the interface reports up, which is why verification runs from address to mapping to route.

Command syntax and addressing rules also vary by product and release, so match the interface model of the device in front of you instead of copying a configuration from a different platform. The goal may be identical while the required lines are not.

Write the donor, the outer source and the advertised prefixes into the tunnel's documentation, then add one check that fails loudly if the donor address changes. That single check catches the failure mode unnumbered designs are most likely to hide.