BGP ORIGIN Attribute

What ORIGIN Is

ORIGIN (type code 1) is the path attribute that records how a route entered BGP. As covered in BGP Path Attributes and Best Path Selection, it is a well-known mandatory attribute and is always present in an UPDATE. The value is one byte, and it is set by the router that brought the route into BGP.

Once set, the value is not rewritten automatically as the route travels to other ASes. A receiving router can therefore tell how the route originally got into BGP.

The Three Values

Value	Name	Meaning
0	`IGP`	The router running BGP explicitly injected the route as an internal route of its AS.
1	`EGP`	The route was learned from EGP (RFC 904), the predecessor of BGP. EGP is no longer used, so you will not see this in practice.
2	`Incomplete`	The route entered BGP some other way. Routes injected by redistribution fall into this category.

In show bgp output the value appears as a single character at the end of each line, per the Origin codes legend: i for IGP, e for EGP, and ? for Incomplete.

The show bgp legend (IOS XR)
Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*> 192.168.3.0/24     0.0.0.0                  0         32768 i

The i at the start of the Path column (the third character of *>i) is the status code for “internal” (learned via iBGP) and is a different thing from the i at the end of the line. Only the last character represents ORIGIN.

Which Operation Produces Which Value

How the route enters BGP	`ORIGIN`
Declared explicitly with `network`	`IGP` (`i`)
Generated as a summary with `aggregate-address`	`IGP` (`i`)
Redistributed from another protocol, a static route, or a connected route	`Incomplete` (`?`)

network is a method where the administrator declares “advertise this route in BGP” one prefix at a time. The intent is explicit, so the result is IGP. redistribute pours whatever another protocol holds into BGP in bulk; BGP cannot tell where those routes came from, so the result is Incomplete.

Where ORIGIN Sits in Best Path Selection

When several paths exist for the same prefix, ORIGIN is compared at step 5 of best path selection. A lower value wins, so the preference order is:

IGP (0) < EGP (1) < Incomplete (2)

In practice the decision is usually made before reaching ORIGIN, by LOCAL_PREF or AS_PATH length. ORIGIN only matters when every earlier step is a tie — for example when the same prefix is injected into BGP at two points inside one AS, one with network and the other with redistribute.

Normalizing ORIGIN to IGP When Advertising to eBGP

The basic way to inject your own AS’s routes into BGP is network (or aggregate-address), and that already yields ORIGIN = IGP. Injecting your own routes that way is the simplest route to never having to think about ORIGIN at all.

If operational circumstances mean you use redistribute, however, then i and ? end up mixed even among routes originated by your own AS. That mix is purely an internal matter for your AS, but a neighboring AS compares ORIGIN during best path selection, so a configuration change inside your AS (switching from network to redistribute, say) can affect route selection in other ASes. One option for avoiding that is to normalize ORIGIN to IGP with a route policy on the way out to eBGP.

Rewriting ORIGIN also destroys the information about how the route got into BGP. It is not a required configuration — treat it as a remedy for when a mix of ? becomes a problem. In particular, applying it to routes received from other ASes (transit routes) wipes out the ORIGIN those ASes set.

The simplest form sets every route advertised to that peer to IGP.

IOS XR: normalize ORIGIN to IGP for all routes
route-policy EBGP-OUT
  set origin igp
  pass
end-policy
!
router bgp <AS number>
 neighbor <eBGP peer address>
  address-family ipv4 unicast
   route-policy EBGP-OUT out
  !
 !
!

IOS XE: normalize ORIGIN to IGP for all routes
route-map EBGP-OUT permit 10
 set origin igp
!
router bgp <AS number>
 address-family ipv4
  neighbor <eBGP peer address> activate
  neighbor <eBGP peer address> route-map EBGP-OUT out

pass in IOS XR and permit 10 with no match in IOS XE both mean “let every route through”. Forget either one and no routes are advertised at all.

That form also hits transit routes, though. To limit it to routes originated by your own AS, match on an empty AS_PATH (^$). The local AS number is prepended to AS_PATH after the route policy is evaluated, so from the outbound policy’s point of view a locally originated route has an empty AS_PATH. Unlike matching on prefixes, this needs no configuration change when the set of advertised addresses grows or shrinks.

IOS XR: normalize ORIGIN to IGP only for locally originated routes
as-path-set LOCAL-ORIGIN
  ios-regex '^$'
end-set
!
route-policy EBGP-OUT
  if as-path in LOCAL-ORIGIN then
    set origin igp
  endif
  pass
end-policy

IOS XE: normalize ORIGIN to IGP only for locally originated routes
ip as-path access-list 1 permit ^$
!
route-map EBGP-OUT permit 10
 match as-path 1
 set origin igp
!
route-map EBGP-OUT permit 20

The permit 20 entry in IOS XE is an empty entry that passes routes which did not match. Without it, every route other than the locally originated ones is discarded.

Verification on Real Devices

A lab of six XRd routers (IOS XR 26.1.1) confirms two things:

That ORIGIN decides the best path when every earlier comparison is a tie
What happens when an outbound eBGP policy rewrites ORIGIN — the difference between applying it to all routes and limiting it to locally originated routes with ^$

ORIGIN attribute verification topology. AS 65001 (R1, R2, R3, with R2 as route reflector) has AS 65004 (R6) on one side and AS 65002 (R4) / AS 65003 (R5) on the other

The same prefix 192.168.99.0/24 is injected into BGP at two points inside AS 65001, by two different methods.

R1 (injects 192.168.99.0/24 with network -> i)
router bgp 65001
 address-family ipv4 unicast
  network 192.168.1.0/24
  network 192.168.99.0/24
 !

R3 (injects the same prefix with redistribute static -> ?)
router static
 address-family ipv4 unicast
  192.168.99.0/24 Null0
 !
!
router bgp 65001
 address-family ipv4 unicast
  network 192.168.3.0/24
  redistribute static
 !

R2 is the route reflector, so it receives both routes at once.

AS 65004 (R6) additionally sends one i route and one ? route. These serve as transit routes passing through AS 65001, and are used from STEP 3 onward.

R6 (192.168.6.0/24 is i, 192.168.66.0/24 is ?)
router static
 address-family ipv4 unicast
  192.168.66.0/24 Null0
 !
!
router bgp 65004
 address-family ipv4 unicast
  network 192.168.6.0/24
  redistribute static
 !

STEP 0: ORIGIN Decides the Best Path

This is R2’s BGP table. Only 192.168.99.0/24 occupies two lines; as the trailing Processed 8 prefixes, 9 paths says, R2 holds nine paths for eight prefixes.

R2 show bgp (STEP 0)
Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*>i192.168.1.0/24     10.0.0.1                 0    100      0 i
*> 192.168.2.0/24     0.0.0.0                  0         32768 i
*>i192.168.3.0/24     10.0.0.3                 0    100      0 i
*>i192.168.4.0/24     10.3.4.4                 0    100      0 65002 i
*>i192.168.5.0/24     10.3.4.4                      100      0 65002 65003 i
*>i192.168.6.0/24     10.1.6.6                 0    100      0 65004 i
*>i192.168.66.0/24    10.1.6.6                 0    100      0 65004 ?
*>i192.168.99.0/24    10.0.0.1                 0    100      0 i
* i                   10.0.0.3                 0    100      0 ?

Processed 8 prefixes, 9 paths

The Network column is blank on the second line, which means it is the same prefix as the line above. The line starting with *> (next hop 10.0.0.1, R1, ending in i) is the best path, and the * i line without the > (next hop 10.0.0.3, R3, ending in ?) is a valid path that was not selected.

Specifying the prefix shows the detail of each path. 192.168.99.0/24 has two paths: Path #1 (from R1) with Origin IGP is best, while Path #2 (from R3) with Origin incomplete is not selected.

R2 show bgp 192.168.99.0/24 (STEP 0)
RP/0/RP0/CPU0:R2#show bgp 192.168.99.0/24

Sat Sep  5 12:11:21.522 UTC
BGP routing table entry for 192.168.99.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 15           15
Last Modified: Sep  5 12:09:04.774 for 00:02:16
Paths: (2 available, best #1)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  Local, (Received from a RR-client)
    10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 15
  Path #2: Received by speaker 0
  Not advertised to any peer
  Local, (Received from a RR-client)
    10.0.0.3 (metric 2) from 10.0.0.3 (10.0.0.3)
      Origin incomplete, metric 0, localpref 100, valid, internal
      Received Path ID 0, Local Path ID 0, version 0

Steps 1 through 4 of best path selection are all ties.

Step	Compared	Path #1 (R1)	Path #2 (R3)	Result
1	`WEIGHT`	0	0	Tie
2	`LOCAL_PREF`	100	100	Tie
3	Locally originated route	Both learned via iBGP	Both learned via iBGP	Tie
4	`AS_PATH` length	0 (originated inside the AS)	0 (originated inside the AS)	Tie
5	`ORIGIN`	`IGP`	`Incomplete`	Path #1 wins

The decision is made at step 5, by ORIGIN.

STEP 1: Remove the `i` Route and the `?` Route Is Selected

To confirm that ORIGIN was the deciding factor, remove network from R1 so that the i route disappears.

Configuration applied to R1 (STEP 1)
router bgp 65001
 address-family ipv4 unicast
  no network 192.168.99.0/24
 !
!

R2’s best path switched to the Origin incomplete route received from R3.

R2 show bgp 192.168.99.0/24 (STEP 1)
RP/0/RP0/CPU0:R2#show bgp 192.168.99.0/24

Sat Sep  5 12:15:34.272 UTC
BGP routing table entry for 192.168.99.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 16           16
Last Modified: Sep  5 12:14:04.774 for 00:01:29
Paths: (1 available, best #1)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  Local, (Received from a RR-client)
    10.0.0.3 (metric 2) from 10.0.0.3 (10.0.0.3)
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 16

The change is visible from the neighboring AS 65004 (R6) as well: the last character went from i to ?.

R6 show bgp (difference between STEP 0 and STEP 1)
(STEP 0) *> 192.168.99.0/24    10.1.6.1                 0             0 65001 i
(STEP 1) *> 192.168.99.0/24    10.1.6.1                               0 65001 ?

A difference of “which method injected it into BGP” inside AS 65001 propagates straight to the neighboring AS. The steps below start from the state with network 192.168.99.0/24 restored on R1 (STEP 2).

STEP 3: Rewrite ORIGIN to IGP for All Routes with an Outbound Policy

Apply a policy on the eBGP session from R3 to R4 (AS 65002) that sets ORIGIN to IGP on every route.

Configuration applied to R3 (STEP 3)
route-policy EBGP-OUT-ALL
  set origin igp
  pass
end-policy
!
router bgp 65001
 neighbor 10.3.4.4
  address-family ipv4 unicast
   route-policy EBGP-OUT-ALL out
  !
 !
!

Compare the AS Path column (whose last character is the ORIGIN) of the routes R3 advertises to R4, before and after applying the policy.

R3 show bgp neighbors 10.3.4.4 advertised-routes (STEP 2 -> STEP 3)
(STEP 2: before the policy)
Network            Next Hop        From            AS Path
192.168.1.0/24     10.3.4.3        10.0.0.2        65001i
192.168.2.0/24     10.3.4.3        10.0.0.2        65001i
192.168.3.0/24     10.3.4.3        Local           65001i
192.168.6.0/24     10.3.4.3        10.0.0.2        65001 65004i
192.168.66.0/24    10.3.4.3        10.0.0.2        65001 65004?
192.168.99.0/24    10.3.4.3        Local           65001?

Processed 6 prefixes, 6 paths

(STEP 3: after applying EBGP-OUT-ALL)
Network            Next Hop        From            AS Path
192.168.1.0/24     10.3.4.3        10.0.0.2        65001i
192.168.2.0/24     10.3.4.3        10.0.0.2        65001i
192.168.3.0/24     10.3.4.3        Local           65001i
192.168.6.0/24     10.3.4.3        10.0.0.2        65001 65004i
192.168.66.0/24    10.3.4.3        10.0.0.2        65001 65004i
192.168.99.0/24    10.3.4.3        Local           65001i

Processed 6 prefixes, 6 paths

The locally originated 192.168.99.0/24 going from ? to i is the intended effect, but the transit route 192.168.66.0/24 received from AS 65004 was rewritten from ? to i as well. The ORIGIN information set by AS 65004 was lost by passing through AS 65001.

The rewrite is visible from AS 65003 (R5), two ASes away.

R5 show bgp (STEP 3)
Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*> 192.168.1.0/24     10.4.5.4                               0 65002 65001 i
*> 192.168.2.0/24     10.4.5.4                               0 65002 65001 i
*> 192.168.3.0/24     10.4.5.4                               0 65002 65001 i
*> 192.168.4.0/24     10.4.5.4                 0             0 65002 i
*> 192.168.5.0/24     0.0.0.0                  0         32768 i
*> 192.168.6.0/24     10.4.5.4                               0 65002 65001 65004 i
*> 192.168.66.0/24    10.4.5.4                               0 65002 65001 65004 i
*> 192.168.99.0/24    10.4.5.4                               0 65002 65001 i

Processed 8 prefixes, 8 paths

STEP 4: Normalize Only the Locally Originated Routes

Add the condition that AS_PATH is empty (^$) so that only locally originated routes are affected.

Configuration applied to R3 (STEP 4)
as-path-set LOCAL-ORIGIN
  ios-regex '^$'
end-set
!
route-policy EBGP-OUT-LOCAL
  if as-path in LOCAL-ORIGIN then
    set origin igp
  endif
  pass
end-policy
!
router bgp 65001
 neighbor 10.3.4.4
  address-family ipv4 unicast
   route-policy EBGP-OUT-LOCAL out
  !
 !
!

These are the routes R3 advertises to R4.

R3 show bgp neighbors 10.3.4.4 advertised-routes (STEP 4)
RP/0/RP0/CPU0:R3#show bgp neighbors 10.3.4.4 advertised-routes

Sat Sep  5 12:30:48.096 UTC
Network            Next Hop        From            AS Path
192.168.1.0/24     10.3.4.3        10.0.0.2        65001i
192.168.2.0/24     10.3.4.3        10.0.0.2        65001i
192.168.3.0/24     10.3.4.3        Local           65001i
192.168.6.0/24     10.3.4.3        10.0.0.2        65001 65004i
192.168.66.0/24    10.3.4.3        10.0.0.2        65001 65004?
192.168.99.0/24    10.3.4.3        Local           65001i

Processed 6 prefixes, 6 paths

The locally originated 192.168.99.0/24 is normalized to i, while the transit route 192.168.66.0/24 stays ?. R5 sees the same thing.

R5 show bgp (STEP 4)
Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*> 192.168.1.0/24     10.4.5.4                               0 65002 65001 i
*> 192.168.2.0/24     10.4.5.4                               0 65002 65001 i
*> 192.168.3.0/24     10.4.5.4                               0 65002 65001 i
*> 192.168.4.0/24     10.4.5.4                 0             0 65002 i
*> 192.168.5.0/24     0.0.0.0                  0         32768 i
*> 192.168.6.0/24     10.4.5.4                               0 65002 65001 65004 i
*> 192.168.66.0/24    10.4.5.4                               0 65002 65001 65004 ?
*> 192.168.99.0/24    10.4.5.4                               0 65002 65001 i

Processed 8 prefixes, 8 paths

The AS Path column of advertised-routes shows 65001 already prepended, but that 65001 is added after the policy has been evaluated. The AS_PATH the policy saw was empty, so it matched ^$ and set origin igp was applied. 192.168.66.0/24, by contrast, already had AS_PATH 65004 at policy evaluation time, so it did not match and its ORIGIN was preserved.

192.168.1.0/24 (R1’s network) and 192.168.2.0/24 (R2’s network) also have an empty AS_PATH and therefore match ^$, but their ORIGIN was already IGP, so nothing visibly changes.

Verification Configs and show Output

At every STEP the following three files were captured from all six routers, kept separate per router. The verification configs are these ..._run.txt files (the final state is the one from the last STEP).

File	Contents
`..._show.txt`	`show version` / `show interface description` / `show route` / `show route bgp` / `show bgp` / `show bgp summary` / `show bgp <prefix>` (for all 8 prefixes) / `show bgp neighbors <peer> advertised-routes` / `show bgp neighbors <peer> routes` / `show bgp neighbor` / `show bgp update-group` / `show rpl route-policy` / `show ospf neighbor`
`..._log.txt`	`show logging` limited to that STEP. A marker was written with `logmsg` at the start of each STEP and its timestamp passed to `show logging start`
`..._run.txt`	`show running-config` at that point in the STEP (i.e. the verification config for that STEP)

In the final state (STEP 4), only R3 has as-path-set LOCAL-ORIGIN and route-policy EBGP-OUT-LOCAL (the EBGP-OUT-ALL used in STEP 3 was removed in STEP 4).

STEP 0: initial state

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

STEP 1: after removing network 192.168.99.0/24 from R1

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

STEP 2: after restoring network 192.168.99.0/24 on R1

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

STEP 3: after applying EBGP-OUT-ALL on R3

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

STEP 4: after applying EBGP-OUT-LOCAL on R3 (final state)

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

References

Source	Title	Summary
RFC 4271	A Border Gateway Protocol 4 (BGP-4)	Section 4.3 defines the three `ORIGIN` values, and section 9.1.2.2 defines the comparison order in best path selection.
RFC 904	Exterior Gateway Protocol Formal Specification	The specification of the protocol the `ORIGIN` value `EGP` refers to. No longer in use.
IANA	Border Gateway Protocol (BGP) Parameters	The registry of numbers used by BGP, including path attribute type codes.