Short answer: BGP ORIGIN is a well-known mandatory attribute that records how a route entered BGP: IGP (i), EGP (e, historical), or INCOMPLETE (?). It is a late tie-breaker in many best-path implementations—not a measure of route quality or a traffic-engineering knob by itself.[1]
What the ORIGIN attribute means
ORIGIN describes the route’s origination mechanism. The values are IGP, EGP, and INCOMPLETE. Despite the names, the EGP value does not mean “learned from a modern eBGP neighbor”; it is a legacy indication from early BGP. Routes introduced with a network statement are generally marked IGP, while redistribution into BGP commonly yields INCOMPLETE. Exact behavior can depend on platform and policy.
ORIGIN is transitive and well-known mandatory: BGP speakers must understand and propagate it. It is separate from AS_PATH, which records autonomous systems traversed, and NEXT_HOP, which identifies the forwarding next hop.[1]
How it affects best-path selection
When more-preferred decision criteria do not distinguish paths, many implementations prefer IGP over EGP over INCOMPLETE. The attribute rarely decides a route when LOCAL_PREF, AS_PATH length, origin code’s earlier/later platform-specific rules, MED, or eBGP/iBGP status already differ. Consult the vendor’s documented decision sequence for the deployed release.
Example: two otherwise equal paths to 203.0.113.0/24 arrive, one with ORIGIN IGP and one with INCOMPLETE. If all preceding criteria tie, the IGP-origin path may win. This is not proof it is operationally better; verify its next hop and policy.
Configuration and route-policy walkthrough
Cisco-style origination:
router bgp 65000
network 198.51.100.0 mask 255.255.255.0
The network must exist in the local routing table (subject to platform behavior). Redistribution is a different path:
router bgp 65000
redistribute static
Redistributed routes are commonly shown with origin ?. Avoid broad redistribution: filter explicitly and tag routes to prevent feedback loops. If policy changes the origin attribute, use route maps/policy statements only for a specific, justified design; do not treat origin rewriting as a substitute for sound LOCAL_PREF or export policy.
Traffic-engineering impact: what it can and cannot do
- Outbound: It can break a late best-path tie locally if earlier criteria are equal; it does not reliably steer traffic when higher-priority attributes differ.
- Inbound influence: ORIGIN may be propagated and could affect a remote AS’s late tie-break, but remote policy and other path attributes dominate. It is not a dependable inbound-control method.
- Cannot: force a remote AS to select your path, ensure symmetric routing, override LOCAL_PREF, or make an unreachable next hop usable.
Verification commands
show ip bgp 203.0.113.0
show ip bgp
show ip route 203.0.113.0
show ip bgp neighbors 192.0.2.1 advertised-routesLook for the origin code at the end of the BGP path: i for IGP, e for EGP, and ? for INCOMPLETE. Confirm the selected path separately from received alternatives, then check RIB installation and next-hop reachability. Command syntax varies by platform.
Troubleshooting checklist
- Confirm which paths are actually received and their ORIGIN values.
- Compare LOCAL_PREF, AS_PATH, MED, peer type, and earlier platform tie-breaks before blaming ORIGIN.
- Check whether redistribution created an unexpected
?path. - Verify route-map/policy matches and whether the policy is applied inbound or outbound in the correct address family.
- Check next-hop resolution and the global routing table; ORIGIN alone does not explain a route missing from forwarding.
- Review vendor-specific best-path documentation and confirm behavior on the running release.
Modern network context
In dual-ISP and cloud-edge designs, use LOCAL_PREF for internal egress choice and deliberate provider communities or AS_PATH policy for externally advertised routes; ORIGIN is usually not the main control. In BGP EVPN/VXLAN and fabric deployments, evaluate the complete route type, route target/import policy, next hop, and overlay-specific attributes rather than interpreting ORIGIN in isolation. Cisco ACI-like policy fabrics likewise add control-plane policy layers: validate the actual advertised and selected routes at the border leaf.
Interview answer
“BGP ORIGIN tells how a route was introduced—IGP, legacy EGP, or incomplete/redistributed. It is mandatory and transitive, and commonly serves as a late tie-breaker, preferring IGP over EGP over incomplete when preceding criteria tie. It is not a reliable traffic-engineering control.”
Related reading
Continue with the BGP NEXT_HOP and next-hop-self guide, plus our BGP LOCAL_PREF and MED deep dives on Network freak.
Post a Comment