skip to content

Why does an EIGRP router choose an internal route to a prefix as successor even when an external route to it has a lower metric?

level: seniorimportance: nice to knowfreq 12%

answer

  1. where the route originated
  2. redistributed routes carry extra tags
  3. metric compared within one class
  4. a MUST in RFC 7868

basics

~20 s

RFC 7868 requires EIGRP to prefer internal routes over external ones regardless of metric: while any internal path exists, successors are chosen only among internal routes, which keeps redistributed copies from overriding routes that originate inside the EIGRP domain.

solid answer

~40 s

EIGRP's topology table marks every route as **internal**, originated inside the EIGRP autonomous system, or **external**, redistributed from another source such as another protocol or a static route. RFC 7868 says internal routes **MUST** be preferred over external routes **independent of the metric**: when an internal route exists, the computation considers only internal routes, and external ones are chosen only when no internal path exists. External metrics are imported from a foreign protocol and not comparable to EIGRP's own, and a prefix leaking back into EIGRP through a redistribution point is a classic source of loops and detours; the rule shuts that out. External entries carry the redistributing router's ID, the external AS, the external protocol and its metric, and an administrator tag that border routers can filter on.

go deeper

for a junior

Recall that EIGRP marks routes as internal, originated in the domain, or external, redistributed in, and that internal routes win even with a worse metric.

for a middle

Explain the order: exclude external candidates whenever an internal path exists, then pick successors and feasible successors within that class as usual.

for a senior

Diagnose the router that skips a shorter path, separate the rule from administrative distance, and use external tags to stop redistribution feedback between two border routers.

for a principal

Plan redistribution boundaries so origin class gives predictable paths, and anticipate that moving a prefix into EIGRP changes path selection across the whole domain at once.

## Two classes of route in one table An EIGRP router stores every destination it hears about in its **topology table**, and RFC 7868, EIGRP's Informational specification, divides those entries into two classes: - **Internal routes** were originated within the same EIGRP autonomous system, such as a directly attached network on which EIGRP runs. They carry the router ID of the originating router and an administrator-set tag. - **External routes** were learned from another source, such as a different routing protocol or a static route, and redistributed into EIGRP by a border router. They carry more: - the router ID of the router that redistributed the route; - the external AS number where the destination resides; - an administrator tag that EIGRP never alters; - the external protocol's identifier; - the metric from the external protocol; - flags for default routing. ## The rule RFC 7868 section 5.4.1 states it plainly: internal routes **MUST** be preferred over external routes, independent of the metric. In practice, if an internal route is present, the diffusing computation runs considering only internal routes, and the successor is chosen from external routes only when no internal route for that destination exists. So the comparison is not "lowest metric wins" across the whole entry. It is: 1. Is there any internal path to this destination? If so, discard the external candidates from consideration. 2. Among the remaining class, pick successors and feasible successors in the usual way: lowest computed distance, then each neighbour's reported distance against the feasible distance. ## A worked case Router R1 holds two paths to 172.16.8.0/24, abstract metric units: | Path | Class | Computed distance | |---|---|---| | via A | internal | 50,000 | | via B | external, redistributed from OSPF by border router BR2 | 20,000 | The external path is cheaper by metric, yet A becomes the successor. B stays in the topology table and takes over only if every internal path to the prefix is gone. ## Why the protocol insists on it - **Metrics from different worlds do not compare.** An external route's EIGRP metric is whatever the redistributing router assigned when it imported the route. A low value can be an artefact of configuration, not a short path. - **Redistribution feedback.** In a design with two border routers exchanging routes between EIGRP and another protocol, a prefix that originates inside EIGRP can leave through one border router and return through the other as an external route. If metric alone decided, that returned copy could win, sending traffic out of the domain and back in, or round a loop. Preferring internal origin breaks the loop at its root. - **Predictability.** Operators know that a prefix originated inside the domain is reached inside the domain. ## Using the external tags The fields on an external route exist for policy. RFC 7868 explains that the administrator tag lets other border routers filter routes on its value, and that a border router can use the origin, protocol and metric to decide whether to use a route or re-advertise it back into the other protocol. Tagging routes at the point of redistribution and filtering on the tag is the standard guard in mutual redistribution designs; the filter syntax is each implementation's own. ## What this rule is not - **Not administrative distance.** Many implementations also give internal and external EIGRP routes different administrative distances, which decides between EIGRP and other protocols for the same prefix in the routing table. That is a separate, implementation-level ranking; the internal-first rule acts earlier, inside EIGRP's own topology table. - **Not a tie-break.** It does not wait for equal metrics; it applies however large the metric gap is. - **Not variance-sensitive.** An implementation's unequal-cost load balancing does not mix an external path into the set while an internal successor exists, because external candidates are excluded from the computation first. ## Where it bites The symptom in production is a router "ignoring" an obviously shorter path. Before suspecting a metric or feasibility problem, check the route's class in the topology table. Equally, after a migration in which a prefix moves from another protocol into EIGRP, the internal origin flips path selection everywhere at once, which is worth planning for.

  • When does an EIGRP router choose a successor from external routes?
    Only when no internal route exists for that destination. Then the external routes are compared among themselves in the usual way, lowest computed distance for the successor and reported distance below the feasible distance for feasible successors.
  • What do EIGRP's external-route tags let a border router do in a mutual redistribution design?
    Recognise where a route came from: the redistributing router's ID, the external protocol, its AS and an administrator tag EIGRP never changes. A border router can filter on the tag so a route redistributed into EIGRP at one point is not redistributed back out at another, which breaks the classic feedback loop.

saying these in an interview costs you the question

  • EIGRP always installs the path with the lowest metric, whatever its origin.
  • Internal versus external preference only matters when the metrics tie.
  • An external EIGRP route's metric is directly comparable to an internal route's metric.
  • The internal-first rule is just administrative distance under another name.
  • Variance lets an external path share load with an internal successor.