A second hub is the first thing added to a DMVPN design and the thing most often added without deciding what it is for. Two hubs can mean two tunnels per spoke or one, active-standby or both-active, preference expressed in the routing protocol or in the registration list. Those are four separate decisions, they interact, and a design that got three of them right and one of them by accident behaves correctly until the day the first hub actually fails.
The reason it is not obvious is that redundancy in DMVPN is split across two independent mechanisms. Registration decides which hubs a spoke has a relationship with. Routing decides which of them traffic uses. They can disagree, and when they do the result is a spoke registered with a hub it never sends anything to, or a route pointing at a hub the spoke has no tunnel relationship with. Both of those look fine in a steady state.
This article covers the two dual-hub topologies and what each one costs, how a spoke registers with two hubs and how that list is controlled, how path preference is expressed and by which protocol, what actually happens during a hub failure and how long it takes, and the failures that only exist because there are two hubs. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.
The two topologies differ in how many tunnel interfaces a spoke has, and that single difference determines whether spoke-to-spoke tunnels can cross between hubs and how naturally per-transport preference can be expressed.What Are the Two Dual-Hub Topologies, and How Do They Differ?
Which one should be built?
Single cloud where both hubs reach the spokes over the same kind of transport, dual cloud where they do not. Single cloud gives each spoke one tunnel interface with two next-hop servers on it, so any spoke can build a direct tunnel to any other regardless of which hub either registered through. Dual cloud gives each spoke two tunnel interfaces on separate subnets, which makes per-transport preference trivial and confines spoke-to-spoke tunnels to within one cloud. The transport is the deciding factor, not the redundancy.
A Deeper Dive into the Two Topologies
What single cloud actually means
One overlay subnet. Both hubs have an address on it, every spoke has an address on it, and the network identifier and tunnel key are the same everywhere. From the spokes' point of view there is one cloud that happens to contain two next-hop servers, and the mapping database that results covers every device in the design.
That last point is the whole benefit. When spoke A wants to reach spoke B, the resolution can succeed regardless of which hub B registered with, because they are all part of the same mapping space. The direct tunnel that results does not involve either hub once it is built.
The cost is that both hubs must be equivalent from the spokes' perspective, and the transport has to support that. Two hubs reachable over the same carrier, or over the public internet generally, satisfy it. Two hubs where one is reached over a private circuit and the other over the internet do not, because they are not the same cloud in any meaningful sense.
What dual cloud actually means
Two independent overlays that happen to connect the same set of sites. Each spoke has two tunnel interfaces, each with its own subnet, its own network identifier, its own key and its own single next-hop server. Nothing is shared between them, and the routing protocol sees two separate paths to the same destinations.
This is the design for two genuinely different transports, and it is the design where preference is easiest to express, because the two paths are two interfaces and every metric mechanism in every routing protocol already operates per interface. Preferring one carrier over another is one line rather than a policy exercise.
The cost is spoke-to-spoke. A tunnel can only be built between two spokes inside the same cloud, so two spokes whose preferred clouds differ will send traffic through a hub rather than directly. On a design where spoke-to-spoke matters — voice between branches, for instance — that is a real limitation rather than a theoretical one.
! Single cloud: one interface, two next-hop servers
Spoke1(config)# interface Tunnel0
Spoke1(config-if)# ip address 10.0.0.11 255.255.255.0
Spoke1(config-if)# ip nhrp network-id 100
Spoke1(config-if)# tunnel key 100
Spoke1(config-if)# ip nhrp nhs 10.0.0.1 nbma 198.51.100.1 multicast
Spoke1(config-if)# ip nhrp nhs 10.0.0.2 nbma 198.51.100.2 multicast
Spoke1(config-if)# ip nhrp shortcut
Spoke1(config-if)# tunnel source GigabitEthernet0/0
Spoke1(config-if)# tunnel mode gre multipoint
! Dual cloud: two interfaces, one next-hop server each,
! distinct network-id and key on each
Spoke1(config)# interface Tunnel0
Spoke1(config-if)# ip address 10.0.0.11 255.255.255.0
Spoke1(config-if)# ip nhrp network-id 100
Spoke1(config-if)# tunnel key 100
Spoke1(config-if)# ip nhrp nhs 10.0.0.1 nbma 198.51.100.1 multicast
Spoke1(config-if)# tunnel source GigabitEthernet0/0
!
Spoke1(config)# interface Tunnel1
Spoke1(config-if)# ip address 10.0.1.11 255.255.255.0
Spoke1(config-if)# ip nhrp network-id 200
Spoke1(config-if)# tunnel key 200
Spoke1(config-if)# ip nhrp nhs 10.0.1.2 nbma 203.0.113.2 multicast
Spoke1(config-if)# tunnel source GigabitEthernet0/1
Why the tunnel key matters more than it looks
Where two tunnel interfaces share a source interface, arriving packets need something to identify which tunnel they belong to. The key provides it. Where the two tunnels use different source interfaces the key is not strictly required, and configuring it anyway is still the right habit — because the day someone consolidates the two uplinks onto one interface, the design either keeps working or fails in a way nobody will connect to the change.
The key must match on every device in a cloud and must differ between clouds. A mismatch produces a tunnel that appears up, with encapsulation happening and nothing being accepted at the other end, which is among the more frustrating symptoms in the technology because every interface counter suggests it is working.
Hub placement, which is a separate question
Both topologies work with the hubs in one data centre or in two. Putting them in one building gives simple hub-to-hub connectivity and a single point of failure that no amount of tunnel configuration addresses. Putting them in two gives real site redundancy and introduces the question of how the hubs reach each other, which becomes a design element in its own right.
Two hubs in two sites need a path between them that does not depend on the overlay. A dedicated circuit, or a routed path through the enterprise core. Relying on the spokes' tunnels to carry hub-to-hub traffic works in the steady state and creates a dependency loop during exactly the failures the second hub exists for.
| Decision | Single cloud | Dual cloud | Determined by |
|---|---|---|---|
| Tunnel interfaces per spoke | One | Two | Topology choice |
| Network ID and key | Same everywhere | Different per cloud | Topology choice |
| Spoke-to-spoke reach | Any spoke to any spoke | Within one cloud only | Topology choice |
| Preference expression | Routing policy | Per-interface metric | Topology choice |
| Suits | One transport type | Two different carriers | The transport, not redundancy |
How Does a Spoke Register With Two Hubs?
What does the registration list do?
A spoke registers with every next-hop server configured on the tunnel interface, and by default it registers with all of them simultaneously. Each registration creates a mapping entry on that hub and lets the hub reach the spoke. Priority and clustering change this: a priority orders the servers, and a cluster with a connection limit makes the spoke register with only the best few and hold the rest in reserve. Without those, both hubs receive registrations and both are fully usable, which is the usual intent.
A Deeper Dive into Registration
What a registration actually establishes
Two things. The hub learns the spoke's public address and can therefore reach it, which is what makes hub-to-spoke traffic possible at all on a dynamically addressed spoke. And the spoke gains a mapping for the hub, which is what lets multicast — and therefore the routing protocol — work over the tunnel.
Neither of those is routing. A spoke can be perfectly registered with a hub and send it no traffic, because the routing protocol chose the other one. That separation is intentional and it is the single most useful thing to internalise about dual-hub designs: registration is the relationship, routing is the decision.
The multicast keyword, and what breaks without it
The next-hop server statement carries a keyword that tells the spoke to send multicast and broadcast traffic to that hub in addition to unicast. Routing protocols that discover neighbours through multicast depend on it entirely. Omit it and the tunnel is up, the registration succeeds, the mapping is present, and the routing adjacency never forms.
This is a common omission on the second hub specifically, because the first hub's statement was written carefully and the second was copied in a hurry. The result is a spoke that is registered with both hubs and has a routing adjacency with one, which is exactly the disagreement between registration and routing described above — and it will not be noticed until the first hub fails.
show ip nhrp multicast lists only the first hub's address. Fix: add the multicast keyword to the second statement — and audit every spoke, because this is copied from one spoke template to all of them.Priority, and what it is for
A priority value orders the next-hop servers, lower being preferred. On its own it changes nothing about which hubs receive registrations, because by default a spoke registers with all of them regardless. Priority becomes meaningful when combined with a connection limit, at which point it decides which servers are used and which are held back.
The reason to use it is scale rather than redundancy. A design with four hubs where every spoke registers with all four puts four times the mapping state on every hub and four routing adjacencies on every spoke. Limiting each spoke to two, chosen by priority, keeps the redundancy and removes most of the state.
Clusters and connection limits
Next-hop servers can be grouped, with a maximum number of active connections per group. The spoke registers with the highest-priority servers in each group up to that limit, and if one fails it promotes the next. This produces genuine active-standby behaviour at the registration layer rather than at the routing layer.
Two groups with a limit of one each is a common arrangement in a design with two data centres and two hubs in each: one active hub per site, one standby behind it, and a failure within a site handled locally without changing which site the spoke uses.
! Two hubs per site, one active in each site
Spoke1(config)# interface Tunnel0
Spoke1(config-if)# ip nhrp nhs cluster 1 max-connections 1
Spoke1(config-if)# ip nhrp nhs cluster 2 max-connections 1
Spoke1(config-if)# ip nhrp nhs 10.0.0.1 nbma 198.51.100.1 multicast priority 1 cluster 1
Spoke1(config-if)# ip nhrp nhs 10.0.0.2 nbma 198.51.100.2 multicast priority 2 cluster 1
Spoke1(config-if)# ip nhrp nhs 10.0.0.3 nbma 198.51.100.3 multicast priority 1 cluster 2
Spoke1(config-if)# ip nhrp nhs 10.0.0.4 nbma 198.51.100.4 multicast priority 2 cluster 2
!
! How long to stay on the backup after the primary returns
Spoke1(config-if)# ip nhrp nhs fallback 60
Reading the registration state
The next-hop server output is the authoritative view and shows each configured server, its priority and cluster, and whether the spoke currently considers it reachable and is using it. An entry shown as configured but not in use is a standby, which is correct in a clustered design and a problem in a design that expected both hubs active.
The mapping table is the complementary view, showing what was actually learned. A hub present in the server list and absent from the mapping table means registration is failing, which is a transport or a key problem rather than a configuration ordering one.
! Which servers exist, and which are in use
Spoke1# show ip nhrp nhs detail
Legend: E=Expecting replies, R=Responding, W=Waiting
Tunnel0:
10.0.0.1 RE priority = 1 cluster = 1 req-sent 148 req-failed 0 repl-recv 147
10.0.0.2 RE priority = 2 cluster = 1 req-sent 148 req-failed 0 repl-recv 148
!
! What was actually learned, and to whom multicast is replicated
Spoke1# show ip nhrp
Spoke1# show ip nhrp multicast
Registration timing, and why it is rarely the detector
A spoke re-registers periodically, based on a fraction of the hold time it was given, and the hub expires a mapping if the registrations stop. That mechanism will eventually detect a dead hub, and it is slow relative to anything a routing protocol does. In practice the routing protocol notices first and reroutes first, and registration state catches up afterwards.
Which means tuning the hold time downward to speed up failover is usually solving the wrong problem. It increases control traffic on every spoke, permanently, to accelerate a detector that was not the one being waited on. Tuning the routing protocol, or adding a dedicated failure detector to it, addresses the actual delay.
How Is Path Preference Controlled, and by Which Protocol?
Where does preference belong?
In the routing protocol, without exception. The registration configuration decides which hubs a spoke has a relationship with; it does not decide where traffic goes. Preference is expressed as a metric or a policy attribute on the routes received from each hub — interface delay with EIGRP, local preference or path length with BGP, cost with OSPF. Which protocol is used changes the mechanism and not the principle, and the mechanism that suits the topology differs between single cloud and dual cloud.
A Deeper Dive into Preference
Dual cloud, where it is easy
Two tunnel interfaces means two interfaces to apply a metric to, and every routing protocol already does this. Raise the delay on the backup tunnel with EIGRP, raise the cost with OSPF, and the primary is preferred for everything with no policy at all. Failover is ordinary routing convergence.
This is the main practical argument for dual cloud beyond the transport one, and it is worth weighing honestly against the spoke-to-spoke limitation. A design where branches talk to a data centre and rarely to each other loses little and gains a great deal of simplicity.
! Dual cloud with EIGRP: prefer Tunnel0, use Tunnel1 on failure
Spoke1(config)# interface Tunnel1
Spoke1(config-if)# delay 5000
!
! Confirm which one won
Spoke1# show ip route eigrp | include 10.100
D 10.100.0.0/16 [90/26880256] via 10.0.0.1, 00:14:22, Tunnel0
Single cloud, where it is a policy question
One interface means an interface metric applies to both hubs equally, so preference has to come from something that distinguishes the two neighbours. With BGP that is straightforward: local preference on routes from one hub, applied by a route map matched on the neighbour. With EIGRP it means an offset list, or accepting hub-side control instead.
Hub-side control is often the better answer. Rather than configuring preference on every spoke, have the backup hub advertise its routes less attractively — a longer path, a worse metric — so every spoke prefers the primary without any spoke configuration at all. One change on one device rather than a change on every branch.
! Single cloud with BGP: prefer hub 1, on the spoke
Spoke1(config)# route-map PREFER-HUB1 permit 10
Spoke1(config-route-map)# set local-preference 200
Spoke1(config)# router bgp 65001
Spoke1(config-router)# neighbor 10.0.0.1 route-map PREFER-HUB1 in
!
! Or centrally, on the backup hub, so no spoke needs changing
Hub2(config)# route-map MAKE-ME-BACKUP permit 10
Hub2(config-route-map)# set as-path prepend 65000 65000
Hub2(config)# router bgp 65000
Hub2(config-router)# neighbor SPOKES route-map MAKE-ME-BACKUP out
EIGRP on the hub, and the two commands it needs
A hub receiving a route from one spoke and needing to advertise it to another is doing something the protocol normally forbids, because the route would be going back out of the interface it arrived on. Split horizon must be disabled on the hub's tunnel interface for the design to work at all.
Separately, the hub advertising a spoke's route to another spoke would ordinarily rewrite the next hop to itself, which forces the traffic through the hub permanently and defeats the direct tunnels the technology exists to build. Preserving the original next hop is the second required command, and it is the one most often missing on a design where spoke-to-spoke was expected and never happens.
! Both are required on the hub tunnel interface
Hub1(config)# interface Tunnel0
Hub1(config-if)# no ip split-horizon eigrp 100
Hub1(config-if)# no ip next-hop-self eigrp 100
Hub1(config-if)# ip nhrp redirect
!
! And on every spoke
Spoke1(config)# interface Tunnel0
Spoke1(config-if)# ip nhrp shortcut
The tunnel bandwidth problem with EIGRP
EIGRP derives its default hello and hold intervals from interface bandwidth, using a slower pair on links at or below T1 speed. A tunnel interface's default bandwidth falls in that category, so an untouched DMVPN tunnel gets the slow timers — a hello every sixty seconds and a hold of one hundred and eighty. A hub failure on such a design takes minutes to be noticed.
The fix is to set the timers explicitly rather than to rely on the bandwidth value, because the bandwidth is also used in metric calculation and changing it for timer purposes has consequences elsewhere. Set both deliberately, document why, and make them consistent across every spoke.
show ip eigrp interfaces detail Tunnel0 shows the hello interval in use. Fix: set the hello and hold intervals explicitly on the tunnel interface at both ends, and consider a dedicated failure detector rather than shorter hellos alone.Summarisation at the hub, and why it usually belongs there
A spoke does not need the data centre's full routing table; it needs a default or a summary and its own specifics. Summarising on the hub's tunnel interface reduces what every spoke holds and what every failure has to reconverge. On a large design this is the single most effective scaling measure available.
It interacts with dual hub in one important way. If both hubs advertise the same summary, the spokes cannot distinguish a hub that has lost its connection to the thing being summarised. The summary keeps being advertised, the spokes keep using it, and traffic is delivered to a hub that cannot forward it. Conditioning the summary on the presence of a real route behind it is the answer, and it is a step that a single-hub design never needed. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.
| Protocol | Dual cloud preference | Single cloud preference | Watch for |
|---|---|---|---|
| EIGRP | Interface delay | Offset list, or hub-side metric | Default timers from tunnel bandwidth |
| BGP | Per-neighbour local preference | Per-neighbour local preference | Hub as reflector; next hop handling |
| OSPF | Interface cost | Awkward — one interface, one cost | Network type and DR election on the cloud |
What Actually Happens When a Hub Fails?
What is the sequence?
The routing adjacency to the failed hub times out and its routes are withdrawn, at which point the spoke installs the backup hub's routes and traffic moves. That is the whole failover, and its duration is the routing protocol's detection time and nothing else. Registration state expires separately and much later, and existing spoke-to-spoke tunnels are unaffected because they do not traverse a hub. The interesting cases are the ones where the hub does not fail cleanly.
A Deeper Dive into Failure Behaviour
The clean failure
A hub that is powered off or whose transport link drops stops answering. The spokes' routing adjacencies expire after the hold interval, the routes go, the backup's routes are already present and simply become best, and forwarding continues. Nothing needs to be signalled and no tunnel needs to be rebuilt, because the backup relationship was established at registration time and has been sitting there unused.
This is why the routing protocol's detection time is the entire answer to "how long does failover take". Everything else in the design was already in place.
The failure that is not clean
A hub that remains reachable but has lost its connection to the network behind it is the case that dual hub handles badly by default. The tunnel is up, the adjacency is up, the routes are still being advertised, and traffic delivered to that hub goes nowhere. Nothing in the overlay knows anything is wrong.
The answer is to make the hub's advertisement conditional on its own reachability of what it is advertising — object tracking driving a conditional advertisement, or an advertisement derived from a real route rather than generated statically. This is the same problem as a default route advertised by a router that has lost its own default, and it has the same class of solution.
What happens to spoke-to-spoke tunnels
Existing direct tunnels are unaffected. They were negotiated through a hub and are not carried by one, so a hub failure does not touch traffic already flowing between two spokes. This is a genuine strength of the design and it is worth stating explicitly because it is often assumed otherwise.
New resolutions are a different matter. A spoke needing to build a new direct tunnel needs a hub to redirect and resolve, so during a failover window new spoke-to-spoke flows go through whichever hub is still there, and build direct tunnels once the routing has settled. Traffic works throughout; it is just not optimal for a short period.
Detecting failure faster
Shorter routing protocol timers are the obvious approach and the least efficient one, because the cost is paid continuously by every spoke and the benefit appears once. A dedicated bidirectional detection mechanism running under the routing protocol is better where the platform supports it over the tunnel, giving sub-second detection without a permanent increase in protocol chatter.
There is a floor worth respecting. Over an internet transport, detection aggressive enough to catch a hub failure in a fraction of a second will also catch ordinary transport jitter, and a design that flaps between hubs during normal congestion is worse than one that takes a few seconds to fail over. Tune toward the transport's real behaviour rather than toward the smallest number the platform accepts.
! Explicit timers, both ends, rather than relying on bandwidth
Spoke1(config)# interface Tunnel0
Spoke1(config-if)# ip hello-interval eigrp 100 5
Spoke1(config-if)# ip hold-time eigrp 100 15
!
! Keep the tunnel line protocol honest about NHS reachability
Spoke1(config-if)# if-state nhrp
!
! Verify what is actually in use
Spoke1# show ip eigrp interfaces detail Tunnel0 | include Hello
Making the tunnel state reflect reality
By default a tunnel interface stays up as long as its source is up and its destination is routable, which on a multipoint tunnel means essentially always. A spoke that has lost every next-hop server still shows the tunnel up, which keeps any static route pointing at it in the table and keeps traffic being sent into a tunnel that goes nowhere.
Tying the line protocol state to next-hop server reachability changes that: lose all the servers and the interface goes down, static routes through it are removed, and a backup path via some other means becomes usable. On a design with a dial backup or a second technology behind the DMVPN, this is what makes that backup actually engage.
Testing it properly
A failover test that consists of shutting the hub's tunnel interface tests the cleanest possible failure and proves the least. The tests worth running are the messy ones: power off a hub without warning, drop its transport link, break its inside connectivity while leaving the tunnel up, and introduce heavy loss on its transport without dropping it entirely.
The third and fourth of those are where designs fail, and neither is exercised by an interface shutdown. Running them once, on a maintenance weekend, with timing measured rather than estimated, is worth more than any amount of configuration review.
Which Dual-Hub Failures Did Not Exist With One Hub?
What is new?
Four things. Registration and routing disagreeing, where a spoke is registered with a hub it never uses or routes to a hub it cannot reach. Asymmetric return paths, where traffic leaves through one hub and comes back through the other. Hub-to-hub dependency, where the two hubs reach each other through the overlay they are supposed to be providing. And configuration drift between two hubs that must remain equivalent. None of these can occur with a single hub.
A Deeper Dive into the New Failure Modes
Registration and routing disagreeing
The general form is a spoke whose next-hop server list and routing table point at different hubs. It arises from a missing multicast keyword, from a cluster limit that made a hub standby while the routing still prefers it, or from a preference policy applied to some spokes and not others.
The check is mechanical and worth automating: for each spoke, compare the hubs in the next-hop server output against the next hop in the routing table for the data centre prefixes. They should correspond. Where they do not, the spoke is one failure away from a problem and looks completely healthy today.
Asymmetric paths
With both hubs active and no preference configured, traffic to a branch may leave through hub 1 while the branch's return traffic goes through hub 2. Pure routing tolerates this. Anything holding state does not — a firewall that sees one direction of a flow will discard it, and the symptom is a connection that establishes and then stalls.
Where stateful devices sit behind the hubs, the design has to be active-standby rather than active-active, or the state has to be shared between the two paths. This is a decision that must be made explicitly, because active-active is the default outcome of simply adding a second hub and configuring nothing further.
Hubs that depend on the overlay to reach each other
Two hubs that are also next-hop servers for each other, or that reach each other through a spoke, have a dependency that is invisible in the steady state. When the underlying path that was actually carrying that traffic fails, the hubs lose each other at the same moment they are most needed.
The requirement is a path between hubs that does not use the overlay at all. In one data centre that is trivial. In two it is a circuit or a routed path through the enterprise core, and it should be verified by disabling the overlay and confirming the hubs still have a routing relationship.
Drift between two hubs that must match
In a single cloud design the two hubs must agree on the network identifier, the tunnel key, the authentication, the summarisation and the protection policy. Each of those is an opportunity for a change made on one and not the other, and most such mismatches produce no symptom until the unchanged hub becomes the active one.
A configuration comparison between the two hubs, run on a schedule, catches this. It is unglamorous and it addresses a failure class that no amount of monitoring will otherwise reveal, because the mismatched hub is passing every health check it has.
! The fields that must match between hubs in a single cloud
Hub1# show running-config interface Tunnel0 | include network-id|tunnel key|authentication|redirect
!
! And the state that proves they do
Hub1# show ip nhrp summary
Hub2# show ip nhrp summary
!
! Spoke counts should be comparable; a large difference is a finding
Hub1# show dmvpn | include Peers
A verification list that covers all four
Five checks, run per spoke or sampled across the estate. Both hubs present in the next-hop server list and both responding. Both hubs present in the mapping table. A routing adjacency with both. The routing table's next hop for data centre prefixes matching the intended primary. And the multicast replication list containing both hub addresses.
All five pass on a healthy design and any one failing identifies the problem precisely. Running them as a scripted collection across every spoke turns a design review from an opinion into a report.
! Five checks, one spoke
Spoke1# show ip nhrp nhs detail
Spoke1# show ip nhrp
Spoke1# show ip eigrp neighbors
Spoke1# show ip route 10.100.0.0
Spoke1# show ip nhrp multicast
!
! And the single most informative command on any DMVPN router
Spoke1# show dmvpn detail
Blueprint framing
The CCIE Enterprise Infrastructure v1.1 blueprint covers DMVPN within its transport technologies domain, and dual hub appears as a design question rather than as a large configuration exercise. Being able to state the difference between single and dual cloud, why the tunnel key differs between clouds, and why preference belongs in the routing protocol rather than in the registration list covers the substance of what is asked.
| New failure mode | Why it only exists with two hubs | Detection |
|---|---|---|
| Registration and routing disagree | There is only one of each with one hub | Compare NHS list to route next hop |
| Asymmetric return path | Requires two viable paths | Trace the flow on both hubs |
| Hub-to-hub via the overlay | There is no hub-to-hub with one hub | Disable the overlay, check adjacency |
| Configuration drift | Nothing to drift from | Scheduled config comparison |
| Hub up, inside path down | Exists with one hub, but has no alternative | Conditional advertisement, tracked |
Conclusion
The topology choice is made by the transport. Two hubs reachable the same way belong in one cloud, with one tunnel interface per spoke and full spoke-to-spoke reach across the whole design. Two genuinely different carriers belong in two clouds, with two tunnel interfaces, trivially expressed preference, and the accepted limitation that a direct tunnel cannot cross between them. Choosing on any other basis produces a design that argues with its own transport.
Redundancy itself is split across two mechanisms that are easy to conflate. The next-hop server list establishes which hubs a spoke has a relationship with, including the multicast replication that the routing protocol depends on. The routing protocol decides where traffic actually goes. A spoke can be perfectly registered with a hub it never uses, and that state is indistinguishable from a healthy one right up until a failure makes it the only hub available.
What is genuinely new with a second hub is a set of disagreements. Registration pointing one way and routing another. Traffic leaving through one hub and returning through the other, which stateful devices will not tolerate. Two hubs that reach each other through the overlay they exist to provide. And two configurations that must stay identical and quietly do not. Every one of these is found by comparing two things that should match, and none of them is found by looking at whether the tunnels are up. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.
External Links
- RFC 2332 — NBMA Next Hop Resolution Protocol
- RFC 2735 — NHRP Support for Virtual Private Networks
- RFC 1701 — Generic Routing Encapsulation
- RFC 2784 — Generic Routing Encapsulation (GRE)
- RFC 2890 — Key and Sequence Number Extensions to GRE
- Cisco — Dynamic Multipoint VPN
- Cisco Learning Network — CCIE Enterprise Infrastructure
Reference Notes
- RFC 2332 defines NHRP, including the next hop server role and the registration by which a client informs a server of its NBMA address.
- RFC 2332 describes the resolution request and reply used by a client to learn the NBMA address associated with an overlay address.
- RFC 2332 specifies the holding time carried in NHRP messages, which determines how long a registration or a cached mapping remains valid.
- RFC 2735 describes the use of NHRP where the NBMA network is itself an IP network, which is the arrangement DMVPN uses.
- RFC 2784 specifies GRE, the encapsulation carried by the multipoint tunnel interfaces used in DMVPN.
- RFC 2890 defines the GRE key extension, which allows packets arriving on a shared tunnel source to be associated with the correct tunnel interface.
- Cisco documentation describes multipoint GRE tunnels and the requirement that the tunnel key, where configured, match across all routers in the same DMVPN cloud.
- Cisco documentation describes NHRP next hop server priority and clustering, in which a maximum connection count per cluster determines how many servers a spoke registers with.
- Cisco documentation describes the multicast keyword on the next hop server statement, which causes multicast and broadcast traffic to be replicated to that server.
- Cisco documentation states that EIGRP selects its default hello and hold intervals according to interface bandwidth, using longer intervals on interfaces at or below T1 speed.
- Cisco documentation describes disabling split horizon and next hop self on a hub tunnel interface running EIGRP, which are required for spoke routes to be advertised between spokes with their original next hop preserved.
- The CCIE Enterprise Infrastructure v1.1 unified exam topics include DMVPN within the transport technologies and virtualisation domain.