Day 17 — BGP ORIGIN: IGP, EGP and Incomplete Without the Common Misconceptions
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:
ie?
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
AS65050S 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 incompleteThe 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 outP1 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.128Identify 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 igpAfter 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 incompleteIf 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 originroute-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-mapIf the best path changes, verify the RIB and data plane as well:
show ip route 192.0.2.128 255.255.255.12814. 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 outPreserve 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 preferenceIf 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.
