BGP origin — IGP, EGP, and incomplete in FRR

The ORIGIN attribute is one of the four well-known mandatory BGP attributes. It tells the receiving BGP speaker where the route originated — was it injected via network, via redistribution, or via the legacy EGP protocol? On VyOS 1.5 LTS / FRR 10.x, the ORIGIN is set implicitly by the origination primitive (network sets igp, redistribution sets incomplete), and can be overridden via route-map.

This lesson is the operator’s reference for ORIGIN: the three values, how FRR renders them, the override configuration, and how it fails in production.

What ORIGIN does

ORIGIN is a single-octet attribute carrying one of three values:

The ORIGIN value influences the BGP best-path algorithm: lower ORIGIN wins. IGP is the lowest, EGP is in the middle, Incomplete is the highest.

Where it sits in the decision matters more than the rule itself. FRR compares, in order: weight, LOCAL_PREF, locally-originated, AS_PATH length, ORIGIN, MED, eBGP over iBGP, IGP metric to the next hop, and finally the tie-breakers on router-id and peer address. ORIGIN is the fifth comparison, so it is only ever reached when two paths already agree on weight, LOCAL_PREF, origination and AS_PATH length. That is a narrow window, and it is why an ORIGIN change so often appears to do nothing.

flowchart TB
  subgraph "AS 64512"
    NET["network statement"]
    REDIST["redistribute ospf"]
  end
  PEER["BGP peer\n(5th comparison:\nlowest ORIGIN wins)"]

  NET -- "ORIGIN: IGP (0)" --> PEER
  REDIST -- "ORIGIN: incomplete (2)" --> PEER

If a peer receives two paths to the same prefix, one with ORIGIN IGP and one with ORIGIN incomplete, and all other attributes are equal, the IGP path is preferred.

The FRR rendering

FRR’s show ip bgp shows the ORIGIN in the last column:

vyos@r1:~$ show ip bgp

BGP table version is 4, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.0.2.0/24     0.0.0.0                  0         32768 i
*> 198.51.100.0/24  0.0.0.0                  0         32768 ?

The header Origin codes: i - IGP, e - EGP, ? - incomplete maps to the column values. In the example:

• 192.0.2.0/24 was originated via network — ORIGIN i (IGP).
• 198.51.100.0/24 was originated via redistribute static — ORIGIN ? (incomplete).

The header is included in every show ip bgp output (when routes are present). Operators learn to read the rightmost column for the ORIGIN.

The default per origination primitive

The pattern: network is the only primitive that unconditionally defaults to IGP. Everything else defaults to incomplete — the conservative choice, because the operator has not asserted where the route came from. The aggregate is the one row that is not a constant: it inherits the worst ORIGIN of the routes it summarises, so an aggregate over one network prefix and one redistributed prefix goes out as ?.

The VyOS configuration

The ORIGIN is set via a route-map, typically applied at the outbound or redistribution point:

configure
# Override the default incomplete origin on a redistributed route
set policy route-map REDISTRIBUTE-AS-IGP rule 10 action permit
set policy route-map REDISTRIBUTE-AS-IGP rule 10 match ip address prefix-list INTERNAL-NETWORKS
set policy route-map REDISTRIBUTE-AS-IGP rule 10 set origin igp

set protocols bgp system-as 64512
set protocols bgp address-family ipv4-unicast redistribute static route-map REDISTRIBUTE-AS-IGP
commit
save

Two things about that last line are 1.4/1.5 shape rather than cosmetics. The local ASN is a leaf under system-as, not a tag node that everything else hangs off. And redistribute lives under the address family, because redistribution is per address family — the IPv6 equivalent is set protocols bgp address-family ipv6-unicast redistribute static and it is a separate setting with its own route-map.

After commit, the redistributed static route’s ORIGIN becomes i instead of ?:

vyos@r1:~$ show ip bgp

BGP table version is 5, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 198.51.100.0/24  0.0.0.0                  0         32768 i

The i at the right confirms the override is effective.

EGP origin

EGP (the Exterior Gateway Protocol, RFC 904) was the predecessor to BGP. EGP-origin routes (ORIGIN code 1) are historical.

Modern BGP implementations do not originate EGP-origin routes. FRR and Cisco IOS both default EGP-origin routes to incomplete on receipt.

If the operator sees an EGP-origin route in their BGP table, it is almost certainly a sign of:

• A legacy peer that still uses EGP (extremely rare).
• A misconfigured peer that is explicitly setting origin egp in its route-map (operator error).
• A simulation or test environment that does not match production reality.

For practical purposes, EGP-origin is “you will never see this in production”.

The override pattern

The most common override is set origin igp on a redistribution route-map. The pattern:

# A production example: redistribute OSPF into BGP, but
# stamp the route with IGP origin (the operator is asserting
# the route is part of the local AS)
set policy prefix-list INTERNAL-NETWORKS rule 10 action permit
set policy prefix-list INTERNAL-NETWORKS rule 10 prefix 192.168.0.0/16 le 19
set policy prefix-list INTERNAL-NETWORKS rule 20 action deny

set policy route-map OSPF-TO-BGP-IGP rule 10 action permit
set policy route-map OSPF-TO-BGP-IGP rule 10 match ip address prefix-list INTERNAL-NETWORKS
set policy route-map OSPF-TO-BGP-IGP rule 10 set origin igp
set policy route-map OSPF-TO-BGP-IGP rule 10 set metric 100

set protocols bgp system-as 64512
set protocols bgp address-family ipv4-unicast redistribute ospf route-map OSPF-TO-BGP-IGP

Note the le 19 on the prefix-list. Without it, prefix 192.168.0.0/16 matches the /16 and nothing else, so every more-specific OSPF route falls past rule 10 to the route-map’s implicit deny and is not redistributed at all. A prefix-list that is missing its le is the single most common reason an origin override appears to have been ignored.

The set origin igp makes the OSPF-redistributed routes preferred by peers that follow the best-path tie-breaker.

The override is also useful on outbound route-maps. If the operator wants to influence a peer’s selection by changing the ORIGIN, the route-map is applied outbound:

set policy route-map OUT-CHANGE-ORIGIN rule 10 action permit
set policy route-map OUT-CHANGE-ORIGIN rule 10 match ip address prefix-list CHANGE-THESE
set policy route-map OUT-CHANGE-ORIGIN rule 10 set origin igp
set policy route-map OUT-CHANGE-ORIGIN rule 20 action permit

set protocols bgp neighbor 10.0.0.2 address-family ipv4-unicast route-map export OUT-CHANGE-ORIGIN

This changes the ORIGIN of routes advertised to peer 10.0.0.2. The peer may select a different best path based on the new ORIGIN.

The direction keyword is route-map export, under the address family, and it takes the name after the direction. Pre-1.4 VyOS and FRR’s own CLI say out; on 1.5 that node does not exist. Rule 20 exists because a route-map that ends after rule 10 denies everything rule 10 did not match — an outbound policy written without it stops advertising every prefix outside CHANGE-THESE.

Validation

# 1. The ORIGIN of one prefix in the local table
show ip bgp 198.51.100.0/24

# 2. The route-map is actually bound to the neighbour
show ip bgp neighbors 10.0.0.2

# 3. The override is in the route-map as VyOS rendered it
show policy route-map OUT-CHANGE-ORIGIN

# 4. The route-map is being reached, and how often
vtysh -c 'show route-map OUT-CHANGE-ORIGIN'

# 5. The override is effective on what the peer receives
show ip bgp neighbors 10.0.0.2 advertised-routes

Step 1 is the per-path detail form rather than the table form. It prints one stanza per path, each ending with a line that names the attributes — the word to find is Origin IGP or Origin incomplete, spelled out rather than abbreviated to the i / ? of the table view.

Step 2 does not have its own sub-command. show ip bgp neighbors prints the peer’s full state, and the policy binding appears in it as a line naming the route map for outgoing (or incoming) advertisements. If that line is absent, the route-map is not bound and nothing else in this list will explain the ORIGIN.

Step 4 is the one that separates “the rule did not match” from “the rule was never reached”. FRR reports an invocation count per route-map and per rule. A rule with a zero count is not being consulted at all — usually the binding in step 2, or the wrong address family. A rule with a non-zero count and no effect is a match problem, which is step 3.

Step 5 is the only one of the five that shows what the peer will actually act on, because it is taken after the outbound policy has run.

Failure modes

ORIGIN is ? when the operator expected i

The operator expected IGP origin but the BGP table shows incomplete. Likely causes:

• The route is being originated via redistribution, not via network. The default for redistribution is incomplete.
• The route-map’s match clause does not match the prefix, and a later action permit rule lets the route through unmodified. The prefix-list without le is the usual culprit.
• The route-map’s set origin igp is on a rule whose action is deny. The set clauses on a deny rule never execute — and on a redistribution route-map, deny also means the route is not redistributed, so the symptom is a missing route rather than a wrongly-stamped one. If the prefix is absent from show ip bgp entirely, this is the branch to check.

The fix: audit the origination primitive first, then the match clause, then the rule actions — in that order, because each one makes the next one meaningless if it is wrong.

ORIGIN is i when the operator expected ?

The operator expected incomplete but the BGP table shows IGP. Likely causes:

• The route is being originated via network (which defaults to IGP).
• A route-map on the outbound side is setting set origin igp unintentionally.
• A peer is advertising the route with set origin igp and the local router is not modifying it.

The fix: audit the route-maps.

The peer is not honouring the ORIGIN tie-breaker

The operator set set origin igp expecting the peer’s best-path algorithm to prefer their route, but the peer chose a different path.

Almost always, the decision was already made before ORIGIN was reached. ORIGIN is the fifth comparison; weight, LOCAL_PREF, locally-originated and AS_PATH length are all checked first, and any difference in one of those settles the choice. Two paths that differ in AS_PATH length never get as far as ORIGIN.

There is also a limit on what you can see: the peer’s decision happens in the peer’s RIB under the peer’s policy, so the local show ip bgp neighbors 10.0.0.2 advertised-routes only proves what was sent, not what was chosen. Confirming the rest needs the peer’s own show ip bgp output or a looking glass.

The fix: use an attribute the peer evaluates earlier. AS_PATH prepend works across an eBGP boundary; LOCAL_PREF does not — it is non-transitive and the peer sets its own. Prepend is the lever for “make the peer prefer someone else’s path”; ORIGIN is a tie-breaker you reach for only when everything else already matches.

Rollback

# Remove the origin override, keeping the rest of the route-map
delete policy route-map REDISTRIBUTE-AS-IGP rule 10 set origin
commit

# Or unbind the route-map from the neighbour entirely
delete protocols bgp neighbor 10.0.0.2 address-family ipv4-unicast route-map export
commit

The rollback for an ORIGIN override is straightforward: the default ORIGIN returns when the route-map is removed. The second form is the blunter one — unbinding the export policy removes every set clause in it, not only the origin, so check what else that route-map was doing before reaching for it.

Production discipline

Cross-course references

• Part XXV (XXV-VyOS-BGPAdvertise) covers the origination primitives that set the default ORIGIN.
• Part XXVI-01 (XXVI-VyOS-BGPAttributes / local-preference) is the higher-precedence attribute in the best-path algorithm.
• Part XXVI-02 (XXVI-VyOS-BGPAttributes / as-path) is the next attribute in the best-path algorithm.
• Part XXVII (XXVII-VyOS-BGPBestPath) covers the best-path algorithm in full.

Quiz