EIGRP route filtering and advanced features: distribute-lists, route-maps, add-path, OTP and troubleshooting

Filtering with distribute-lists

A distribute-list controls which routes EIGRP accepts from neighbours (in) or advertises to them (out), on all interfaces or a named one. Because EIGRP is distance vector, a route filtered here really disappears for every router downstream, unlike OSPF's local-only distribute-list.

The distribute-list can reference three kinds of match:

• An ACL: the oldest method. A standard ACL matches the network address only, not the prefix length.
• A prefix-list: matches the network and the prefix length, with ge and le ranges. This is the usual choice.
• A route-map: can match prefix-lists, route tags, metrics or next hops, and is the tool for complex policies such as blocking routes that came from a particular redistribution.

ip prefix-list BRANCH-OUT seq 5 permit 0.0.0.0/0
ip prefix-list BRANCH-OUT seq 10 permit 10.0.0.0/8 le 16
!
route-map NO-TAG-99 deny 10
 match tag 99
route-map NO-TAG-99 permit 20
!
router eigrp 100
 distribute-list prefix BRANCH-OUT out GigabitEthernet0/2
 distribute-list route-map NO-TAG-99 in

The first filter sends branches only a default route and summaries no longer than /16. The second refuses any route tagged 99, a common way to stop routes looping back in a mutual redistribution design.

Features for hub-and-spoke WANs

• Split horizon stops a router advertising a route out of the interface it learned it on. On a hub with one multipoint interface (the old Frame Relay case, and DMVPN today), that stops spokes learning each other's routes, so the hub needs no ip split-horizon eigrp 100 on that interface. In DMVPN designs where spokes talk directly, the hub also keeps the original next hop with no ip next-hop-self eigrp 100. Frame Relay itself is a legacy WAN service, replaced by MPLS, Ethernet services and internet VPNs.
• Add-path (named mode) lets a DMVPN hub advertise up to four paths for the same prefix, so spokes can reach a dual-homed site through either of its routers.
• EIGRP Over the Top (OTP) lets sites form EIGRP neighbours across a provider's Layer 3 network by unicast, with traffic encapsulated using LISP, so the provider does not need to run EIGRP. A central router can act as a route reflector.

Faster and gentler convergence

LFA fast reroute in named mode (fast-reroute per-prefix all under the topology) pre-installs a loop-free backup, often the feasible successor, in hardware so a failure is bypassed almost instantly. Graceful shutdown: when you shut an interface or remove the process, EIGRP sends a goodbye message (a hello with every K value set to 255) so neighbours drop the adjacency at once instead of waiting for the hold time.

EIGRP marks redistributed routes as external (shown as D EX, administrative distance 170) and records the originating router ID, the source protocol and an optional tag. Internal routes (AD 90) are always preferred to external ones for the same prefix. In packet captures you may also notice Cisco IOS sending some EIGRP and RIP packets with an IP TTL of 2 rather than 1; it makes no practical difference, because link-local multicast is never routed.

Troubleshooting missing EIGRP routes

1. Is the network actually advertised? Check show ip protocols for the network statements and passive interfaces on the originating router.
2. Is the route in the topology table of the router that is missing it (show ip eigrp topology all-links)? If yes but not in the routing table, a route with a better administrative distance may exist.
3. Is a distribute-list, summary or leak map hiding it? Is a stub router refusing to pass it on?
4. On hub-and-spoke links, is split horizon blocking it?
5. For external routes, are two routers using the same router ID?
6. Are both ends using compatible metrics (classic and wide) and the same AS?

Real-world example: a housing association connected 40 offices to a DMVPN hub. Offices could reach head office but not each other, even though the tunnels were up. The hub's tunnel interface still had EIGRP split horizon enabled, so routes learned from one spoke were never sent to the others. Disabling split horizon and next-hop-self on the hub tunnel let each office learn the others' subnets with the correct next hop, and direct spoke-to-spoke tunnels started forming as designed.