Stream of Knowledge: Day 17 — BGP ORIGIN: IGP, EGP and Incomplete Without the Common Misconceptions

Day 17 — BGP ORIGIN: IGP, EGP and Incomplete Without the Common Misconceptions

at September 13, 2026

Learning objective

Interpret the ORIGIN attribute correctly, explain the preference order IGP < EGP < incomplete in Cisco best-path selection, and troubleshoot a policy that changes ORIGIN without confusing it with route ownership or the IGP protocol running in the network.

BGP ORIGIN: IGP, EGP and Incomplete Without the Common Misconceptions

1. Opening — the word “origin” causes more confusion than the attribute

BGP's ORIGIN attribute has three values:

IGP
EGP
INCOMPLETE

Cisco commonly displays them as:

The names are historical. They do not mean “this prefix is currently carried by OSPF,” “this prefix belongs to the AS shown here,” or “BGP does not know the AS that owns it.”

ORIGIN indicates how the route information was introduced into BGP according to the attribute semantics. In Cisco configurations, a prefix originated with a BGP network statement commonly appears with ORIGIN IGP, while redistribution commonly creates ORIGIN incomplete unless policy changes it.

2. ORIGIN classification

RFC 4271 defines ORIGIN as a well-known mandatory attribute with three values.

IGP

Indicates the NLRI was learned through an interior routing mechanism in the original BGP semantics. In modern Cisco operations, network-originated routes are typically displayed with i.

EGP

Represents the historical Exterior Gateway Protocol origin value. The old EGP protocol is obsolete in modern networks, but the ORIGIN value remains defined.

INCOMPLETE

Indicates the origin cannot be represented as IGP or EGP under the attribute semantics. Redistributed routes commonly appear as ? on Cisco.

3. Best-path preference

After earlier Cisco selection criteria such as Weight, LOCAL_PREF, local origination and AS_PATH length, Cisco prefers the route with the lowest ORIGIN type in this order:

IGP (i)  preferred over  EGP (e)  preferred over  incomplete (?)

Do not translate that into “IGP routes are always preferred over redistributed routes.” The comparison applies at this stage only if all higher-priority criteria have tied and the routes are eligible.

4. ORIGIN is not the same as ORIGINATOR_ID

These are completely different attributes.

ORIGIN is the base BGP attribute described here.
ORIGINATOR_ID is a route-reflection attribute used to prevent reflection loops.

The route-reflector module will treat ORIGINATOR_ID separately.

5. Scenario — Delta Origin-Code Tie Break

Illustrative lab — not a real incident.

Topology

           Service S AS65100
              /          \
             /            \
       P1 AS65010      P2 AS65020
             \            /
              \          /
             Enterprise E
                AS65050

S originates 192.0.2.128/25 and both providers carry it to E.

P1 advertises the path without changing ORIGIN, so E sees an IGP-origin code.

P2 uses an outbound route map toward E:

set origin incomplete

The AS_PATH lengths are intentionally equal:

P1: 65010 65100 i
P2: 65020 65100 ?

If earlier attributes tie, E should prefer the IGP-origin path via P1.

6. Prerequisites

Four-router topology similar to Day 16.
Equal Weight and LOCAL_PREF at E.
Equal AS_PATH length.
Reachable next hops.
No MED difference used to decide earlier/later unexpectedly.

The lab isolates ORIGIN by controlling other variables.

7. Topic-specific configuration excerpt

P2 policy toward E

route-map MARK-INCOMPLETE permit 10
 set origin incomplete
!
router bgp 65020
 address-family ipv4 unicast
  neighbor 203.0.113.6 route-map MARK-INCOMPLETE out

P1 has no ORIGIN-changing policy toward E.

The full topology configuration is stored in the companion lab directory.

8. Verification before modification

At E:

show ip bgp 192.0.2.128
show ip route 192.0.2.128 255.255.255.128

Identify the Path field and origin code at the end of each path.

Expected conceptual view:

65010 65100 i
65020 65100 ?

The exact formatting depends on the IOS XE image; do not fabricate a full command output.

9. Controlled modification

Change P2's route map from incomplete to IGP for the lab comparison:

route-map MARK-INCOMPLETE permit 10
 set origin igp

After a safe outbound refresh, both paths should have equal ORIGIN. E then proceeds to later best-path criteria.

This demonstrates that ORIGIN is one comparison step, not an absolute winner independent of the rest of the algorithm.

10. Fault injection

Illustrative lab — not a real incident.

Lab name

Delta Origin Rewrite

Fault

A broad outbound route map on P1 accidentally marks all advertisements as incomplete:

route-map BROAD-ORIGIN permit 10
 set origin incomplete

If P2 continues advertising IGP origin and earlier attributes tie, E can switch to P2.

Why this is subtle

The prefix, AS_PATH and next hop all look legitimate. The only policy difference is the one-character origin code at the end of the path display.

11. Troubleshooting sequence

Confirm the candidate paths and best path.
Check Weight and LOCAL_PREF.
Compare AS_PATH length.
Read the ORIGIN code at the end of each path.
Determine whether the value is natural from route origination or modified by policy.
Inspect set origin route-map clauses.
Confirm the route-map direction and scope.
Do not confuse ORIGIN with route ownership or ORIGINATOR_ID.
Correct the smallest unintended rewrite.
Refresh safely and confirm the path-selection result.

12. Root cause and correction

Root cause

An outbound policy rewrote ORIGIN to incomplete on the path that was intended to remain preferred.

Correction

Remove the unnecessary set origin statement or constrain it to the prefixes that genuinely require that policy.

Why it works

With the artificial ORIGIN disadvantage removed, the route can tie or win according to the remaining best-path criteria.

13. Post-fix verification

show ip bgp 192.0.2.128
show route-map
show running-config | section route-map

If the best path changes, verify the RIB and data plane as well:

show ip route 192.0.2.128 255.255.255.128

14. Rollback

Remove the route-map from the neighbor or restore the previous set origin value, depending on the intended policy.

Example:

router bgp 65010
 address-family ipv4 unicast
  no neighbor <E-peer> route-map BROAD-ORIGIN out

Preserve the original route display so the origin-code difference remains documented.

15. Production lessons

Terminology lesson

ORIGIN is historical BGP metadata; it is not a statement of legal prefix ownership or current IGP reachability.

Selection lesson

IGP origin is preferred over EGP, which is preferred over incomplete—but only after earlier criteria tie.

Troubleshooting lesson

The tiny i, e or ? at the end of a path can explain a best-path decision when more obvious attributes are equal.

Policy lesson

Avoid rewriting ORIGIN without a clear, documented reason. LOCAL_PREF and communities are often clearer tools for policy expression.

Documentation lesson

Never confuse ORIGIN with ORIGINATOR_ID; their names overlap but their purposes do not.

15A. Four common ORIGIN misconceptions

Misconception 1 — `i` means OSPF or IS-IS

It does not. The ORIGIN code is BGP metadata. A route can display i even when no OSPF adjacency exists anywhere near the originating router.

Misconception 2 — `?` means the prefix owner is unknown

It does not. ? represents ORIGIN incomplete. Ownership and authorization are separate questions handled through routing policy, registry data and mechanisms such as RPKI—not the ORIGIN code.

Misconception 3 — ORIGIN tells you where the route entered your AS

It does not. For that operational question, inspect the BGP peer, next hop, AS_PATH, communities and route-policy evidence.

Misconception 4 — ORIGIN should be rewritten to make a path primary

It can influence best-path selection, but it is usually a poor first choice for expressing enterprise policy because LOCAL_PREF is clearer and evaluated earlier. Rewriting ORIGIN can also make troubleshooting harder by obscuring how the route was originally introduced.

15B. When `set origin` is useful in a lab

set origin is valuable for education because it isolates the ORIGIN comparison without requiring multiple route-injection mechanisms. In production, use it only when a documented interconnection or migration design calls for it.

Before deploying a route map that changes ORIGIN, record:

which prefixes match;
whether the route map is inbound or outbound;
whether other route-map clauses continue processing;
the intended best-path effect;
which routers can observe the rewritten value;
how the change will be rolled back.

That discipline prevents a one-line policy change from becoming an invisible tie-breaker across a large prefix set.

15C. Observability: how to prove ORIGIN actually caused the decision

When investigating a production path-selection question, do not stop at seeing i on the best path and ? on an alternate path. Prove that all earlier criteria tied.

A defensible evidence chain is:

1. Both paths valid and next hops reachable
2. Weight equal
3. LOCAL_PREF equal
4. Neither path wins on local origination
5. AS_PATH length equal
6. ORIGIN differs
7. Selected path matches the documented ORIGIN preference

If any earlier item differs, ORIGIN may be visible but not causative.

This distinction matters for incident reports. Saying “the route won because of ORIGIN” is a technical claim that should be supported by the full comparison, not merely by noticing different origin codes after the fact.

For automated validation, collect structured path attributes before and after the change and compare only the fields relevant to the intended experiment. That approach will be developed further in the automation module.

15D. Why the EGP origin code still exists

The e value is easy to misread because modern engineers rarely operate the historical Exterior Gateway Protocol that gave the value its name. BGP retained the three-value ORIGIN field for protocol compatibility and path semantics even as EGP itself disappeared from ordinary production use.

That means a modern route displaying e should trigger a policy investigation rather than an assumption that an ancient EGP session is running somewhere. It may have been created by explicit policy, migrated configuration, imported routing information or a lab exercise.

The operational response is the same evidence-based method used throughout this series: identify the neighbor that supplied the path, inspect the full set of attributes, trace any route map that can rewrite ORIGIN, and compare the observed value against the intended policy. Historical names are not substitutes for current-state evidence.

16. Knowledge check

Q1

Does ORIGIN i mean the route is currently learned through OSPF?

Answer: No. It is the BGP ORIGIN attribute value. On Cisco, routes introduced with a BGP network statement commonly display i, regardless of which IGP may exist elsewhere.

Q2

Which ORIGIN value is preferred if all earlier criteria tie?

Answer: IGP is preferred over EGP, and EGP is preferred over incomplete.

Q3

Is ORIGIN the same as ORIGINATOR_ID?

Answer: No. ORIGIN is a base path attribute; ORIGINATOR_ID is a route-reflection loop-prevention attribute.

17. Sources

RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)* — ORIGIN attribute values and Decision Process.
Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.18.x: Configuring BGP* — origin type in the Cisco best-path sequence.
Cisco — *Connecting to a Service Provider Using External BGP, IOS XE 17.x* — route-map policy and BGP output origin codes.
Cisco — route-map command references for set origin.

Accessed: 2026-08-11.