Named vs Numbered DMVPN Hub: What the FQDN Changes

A DMVPN spoke can locate its hub by hostname on platforms that support the feature, and the first temptation is to read that hostname as another way of writing the hub tunnel address. It is not. The name resolves to a transport endpoint, while the hub protocol address identifies the next hop inside the overlay, and the two roles survive every configuration form. That distinction decides what a rename can and cannot fix.

Two addresses, two jobs

In a declared example, hub.example.net tells the spoke where to send transport traffic, and 10.90.0.1 identifies the NHS inside the tunnel. Discovery operates on the first; registration and routing operate on the second. A change to the name affects the path to the endpoint, while a change to the protocol address affects the overlay relationship itself.

Keeping the roles separate is what makes the named form debuggable. When a spoke fails to register, you can ask two different questions: did the name resolve to the address I expected, and did that address match the protocol address the configuration claims? Neither answer implies the other.

Compare the two configuration forms

One form configures the NHS protocol address explicitly alongside the name. The other lets the spoke learn that protocol address from the registration reply. Both are documented, and both end with the same kind of NHS relationship when they succeed.

The explicit form carries a restriction worth remembering: a resolved transport address that does not map to the configured protocol address prevents registration. That is not a DNS failure, even though the symptom appears right after a DNS change. The name resolved correctly and the result was rejected for a different reason. Read the resolved address and the configured protocol address side by side.

The learning form removes one manual step and one source of drift, at the cost of depending on the reply to establish the mapping. Choose the explicit form when the hub address is stable and you want the mismatch to fail loudly. Choose the learning form when the hub protocol address may change and you would rather the spoke follow it. Either way, record which form the design uses.

Compare DNS caching with a static hub

A static hub address changes when someone edits the configuration. A named hub changes when DNS changes, and DNS answers are cached for their lifetime. The documentation notes that cached information remains usable until it expires, and a later query can then return the new address.

That difference is a timing difference, not an instant migration. A long cache lifetime delays adoption of a renamed endpoint, and the delay is invisible if you only watch the DNS record. Plan a rename around the cache lifetime and the registration behavior of the installed release rather than assuming every tunnel moves at once.

The static form has its own lag, of course: nothing changes until every spoke is edited. The comparison is between a coordinated configuration push and a cached discovery refresh, not between slow and instant.

Compare what stays the same

Peer authentication does not move. A hostname that locates the transport endpoint does not replace the configured IKE identity or the authentication policy that validates the peer. If the identity is wrong, a successful DNS resolution only gets you to a rejected tunnel faster.

Protected traffic is also unchanged. A responding NHS does not prove that the customer route exists or that the application flow is permitted. Registration, routing and policy are three checks, and the name affects only the first step that feeds them.

A comparison you can verify

Cisco documents separate observations for the session and the NHS relationship. Use show dmvpn to read peer and session state, and show ip nhrp nhs to read the NHS registration view. Compare the resolved transport address, the overlay peer and the registration state in that order.

The IOS XE FQDN-DMVPN chapter documents the discovery, caching and restriction behavior behind this comparison. Read it against your installed release before you treat a renamed hub as a drop-in replacement for a numbered one.