EIGRP Offset Lists: Surgical Metric Manipulation

You have two hubs. You want every spoke to prefer HUB1 and fall back to HUB2 only when HUB1 is unreachable. The interface bandwidth and delay are identical, so EIGRP sees two equal paths and load-shares across both - which is not what you asked for.

You could change the interface delay on HUB2, but that affects every route through every neighbour on that interface and drags in the whole metric calculation. What you actually want is a scalpel: "add this much to the metric of these routes, on this interface, in this direction". That is an offset list.

This article shows offset lists working on Cisco IOS XE in a dual-hub DMVPN, with the exact before-and-after metrics. For the fundamentals, start at the complete EIGRP guide.

What an offset list does

An offset list adds a fixed value to the composite metric of routes matching an access list, on a specific interface, in a specific direction. That is the entire feature, and its simplicity is its virtue.

offset-list <acl> {in | out} <offset> [interface]

Crucially, the offset is applied to the composite metric, after the bandwidth/delay calculation. It does not touch the underlying vector metrics (bandwidth, delay, reliability, load, MTU) that get carried onward. It shifts the number the receiving router uses to compare paths, and nothing else.

The named-mode syntax

In classic EIGRP, the offset list goes directly under the router process. In named mode - which is what you should be writing now - it lives under the topology:

access-list 50 permit any
!
router eigrp DMVPN
 address-family ipv4 unicast autonomous-system 100
  topology base
   offset-list 50 out 100000000 Tunnel0

The lab: making HUB2 the backup

Dual-hub DMVPN. SPOKE1 has tunnels to both HUB1 and HUB2, and learns HUB1's campus LAN (192.168.99.0/24) two ways: directly from HUB1, and via HUB2 (which learned it from HUB1 across the tunnel cloud).

SPOKE1#show ip eigrp topology 192.168.99.0/24
  Descriptor Blocks:
  10.0.0.1 (Tunnel0), from 10.0.0.1, Send flag is 0x0
      Composite metric is (9895936000/131072000), route is Internal
  10.0.0.1 (Tunnel0), from 10.0.0.2, Send flag is 0x0
      Composite metric is (13172736000/9895936000), route is Internal

The path via HUB2 already has a worse metric here because it is an extra hop. But in a symmetric design with equal-cost transports - which is the common case - these numbers would be identical, and the spoke would load-share. What we want is an explicit, deterministic preference that survives any topology change.

Apply the offset on HUB2, outbound toward the spokes:

HUB2(config)#access-list 50 permit any
HUB2(config)#router eigrp DMVPN
HUB2(config-router)#address-family ipv4 unicast autonomous-system 100
HUB2(config-router-af)#topology base
HUB2(config-router-af-topology)#offset-list 50 out 100000000 Tunnel0

And on the spoke:

SPOKE1#show ip eigrp topology 192.168.99.0/24
  Descriptor Blocks:
  10.0.0.1 (Tunnel0), from 10.0.0.1, Send flag is 0x0
      Composite metric is (9895936000/131072000), route is Internal
  10.0.0.1 (Tunnel0), from 10.0.0.2, Send flag is 0x0
      Composite metric is (13272736000/9995936000), route is Internal

13,172,736,000 becomes 13,272,736,000. Exactly +100,000,000. Not approximately, not scaled - exactly the value we configured. The offset list is arithmetic, and that predictability is precisely why you would choose it over fiddling with delay.

The route via HUB2 remains in the topology table as a valid alternative. It is a feasible successor, ready to take over the instant HUB1's path disappears, with no reconvergence delay. That is the entire design goal: deterministic primary, instant backup.

Why one command on the hub beats N commands on the spokes

You could achieve the same effect with an inbound offset list on each spoke, applied to routes received from HUB2. It would work. It would also mean touching every spoke every time you add one, and it would mean the policy lives in a hundred places instead of one.

Outbound on the hub is the right answer. One command, one router, and every current and future spoke inherits the behaviour automatically. The design intent - "HUB2 is the backup" - is expressed exactly once, on the router it is about.

The general rule: use out when you are expressing a property of the advertising router; use in when you are expressing a preference local to the receiving router. "HUB2 is my backup hub" is a property of HUB2. "I personally distrust the routes from that neighbour" is local. Most of the time you want out.

Choosing an offset value

EIGRP composite metrics are large. With the classic formula and default K values, a Gigabit link's metric is in the millions; over a DMVPN tunnel with its default 100 Kbps bandwidth, it runs into the billions. An offset of 100 or 1000 is lost in the noise.

The practical rule: look at the actual metrics first with show ip eigrp topology <prefix>, then choose an offset that is unambiguously larger than any legitimate metric variation you expect to see. In the lab we used 100,000,000 against metrics in the 13-billion range - about 0.8%, but comfortably more than the difference between any two real paths in that topology.

Do not reach for an enormous value "to be safe". EIGRP treats a metric of 4,294,967,295 as infinite and will withdraw the route entirely. A grossly oversized offset does not make a path unattractive; it deletes it.

Offset lists vs the alternatives

Never use bandwidth as a metric knob. EIGRP uses the configured bandwidth for its pacing calculation - it will not use more than 50% of the stated bandwidth for EIGRP traffic. Lie about it to change a metric and you also throttle your own routing protocol. Set bandwidth to the interface's real capacity, always, and use delay or an offset list when you want to shift a path.

Troubleshooting

1. No effect at all? Check the interface name in the command. An offset list with no interface applies to every interface, which is rarely what you meant - and one with the wrong interface applies to nothing.
2. Route disappeared instead of being deprioritised? Your offset pushed the metric to EIGRP's infinity. Reduce it.
3. Effect is invisible in the metrics? The offset is too small relative to the composite metric. Look at the real numbers first, then size it.
4. Works on one spoke, not another? If you applied it inbound on the spokes, you have missed one. Apply it outbound on the hub instead.
5. Named mode rejecting the command? It goes under topology base, not directly under the address family.

Key takeaways

• An offset list adds a flat, exact value to the composite metric of matched routes, on one interface, in one direction. Verified: +100,000,000 configured, +100,000,000 observed.
• Named mode puts it under topology base.
• Apply it outbound on the hub to express "this hub is the backup" once, rather than inbound on every spoke.
• Size the offset against the real composite metrics you can see with show ip eigrp topology. Too small and it does nothing; too large and EIGRP withdraws the route as unreachable.
• The deprioritised path stays in the topology table as a feasible successor, so failover is instant.
• Never manipulate bandwidth to change a metric - you throttle EIGRP's own pacing. Use delay or an offset list.

Next: EIGRP over DMVPN: multi-hub design and the split-horizon problem. The full cluster index lives on the EIGRP pillar guide.