BGP Origin, MED and Tiebreakers

In the previous lesson, locally originated routes and the shortest AS-PATH settled the choice. When those tie too, BGP reads the Origin code.

After Weight, Local Preference, locally originated routes, and AS-PATH length, BGP evaluates the next attribute:

Lowest Origin code wins.

The Origin attribute tells BGP how a prefix entered the BGP table in the first place. When all higher attributes are equal, Origin becomes the tiebreaker.

What is Origin?

Origin is a well-known mandatory attribute carried in every BGP update.
It can take only three values:

Figure 1 – BGP Origin Types

• IGP (i) — The prefix was injected into BGP using a network statement.

• EGP (e) — The prefix came from the legacy EGP protocol. You will almost never see this in production.

• Incomplete (?) — The prefix was injected through redistribution from another protocol (OSPF, EIGRP, static, connected).

When BGP compares two paths with the same Weight, Local Preference, Originate, and AS-PATH, it picks the one with the lowest Origin code:

R1# show bgp ipv4 unicast
BGP table version is 5, local router ID is 10.0.23.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
              t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.0.34.0/30     10.0.23.2                0             0 300 i
 * i 10.0.34.0/30     10.0.24.2                0    100      0 300 ?

IGP (i) is preferred over EGP (e), which is preferred over Incomplete (?).
You read the Origin in the last column of the BGP table, right after the AS-PATH.

The Scenario

The topology below reuses the same setup as the AS-PATH lesson, with one critical difference in how each side advertises the prefix 10.0.34.0/30.

Figure 2 – Two paths with different Origin types

R3 advertises the prefix toward R1 using a network statement, so the prefix arrives with Origin i.
R4 advertises the same prefix toward R2 using redistribute connected, so the prefix arrives with Origin ?.

From R1's point of view, both paths share:

• Equal Weight (0)

• Equal Local Preference (100)

• Equal AS-PATH (300, length 1)

The only attribute that differs is the Origin.

Verifying the Result

Check the BGP table on R1:

R1# show bgp ipv4 unicast
BGP table version is 5, local router ID is 10.0.23.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
              t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.0.34.0/30     10.0.23.2                0             0 300 i
 * i 10.0.34.0/30     10.0.24.2                0    100      0 300 ?

Two paths exist for 10.0.34.0/30:

• The eBGP path via R3 carries Origin i (IGP)

• The iBGP path via R2 carries Origin ? (Incomplete)

The best-path marker *> is on the path with Origin i, because IGP is preferred over Incomplete when every higher attribute is equal.