BGP Locally Originated attribute

Learn how BGP selects the best path using the ‘Originated Locally’ attribute. Understand route origination via network, redistribution, and aggregate commands with examples, configuration, and verification to simplify BGP path selection.

When multiple routes exist to reach the same destination, BGP (Border Gateway Protocol) applies a step-by-step decision process to select the “best path.” Each attribute plays a role in influencing this decision.

In our earlier discussions, we covered:

• Weight (Cisco-specific, highest priority attribute)
• Local Preference (industry-standard, next preferred attribute)

Now, we’ll move to the third attribute: Originated Locally.

What is “Originated Locally” in BGP?

The Originated Locally attribute comes into play when multiple paths exist with the same Weight and Local Preference values.

A route is considered locally originated if:

• It is injected into the BGP table via network command in the router configuration.
• It is redistributed into BGP from another routing protocol (like OSPF, EIGRP, or static routes).
• It is created via aggregate-address command.

In simple terms, if a router itself is the source of the BGP advertisement, that path is preferred over paths learned from neighbors.

Why Does BGP Prefer Locally Originated Routes?

Think of it this way:

• A router always trusts its own sourced routes more than routes learned externally.
• If a route is configured locally, it is likely more authoritative for that router’s own AS (Autonomous System).
• This avoids unnecessary dependency on neighbors for prefixes that can be generated internally.

Verification in BGP Table

When you look at the BGP routing table (Cisco IOS example), you will see markers that indicate if a route is locally originated.

• *> → Best path
• i → Learned from an iBGP peer
• > → Indicates the selected best path
• *> + > + Origin codes help you verify the source

Origin Codes:

• i → IGP (Route originated using the network command)
• e → EGP (Old External Gateway Protocol, rarely seen today)
• ? → Incomplete (Redistributed into BGP, e.g., static/IGP route)

Example Scenario

Network Topology

In the above topology, we have two routers connected via eBGP:

• R1 (ASN 100)
  • Loopback address: 100.100.100.100/32
  • Interface: 12.1.1.1/24 (g1/0)
• R2 (ASN 200)
  • Interface: 12.1.1.2/24 (g1/0)

An eBGP session runs between R1 and R2.

After completing the configuration, I verified the BGP session and confirmed that it is now established.

Next, we will configure a loopback interface on R2 and advertise its IP address into BGP. This will allow R1 to receive the route from R2. Let’s set this up and verify the results.

R2(config)#interface loopback 0 R2(config-if)#ip address 100.100.100.100 255.255.255.255 R2(config-if)#router bgp 200 R2(config-router)#network 100.100.100.100 mask 255.255.255.255

In the abive snap, we saw that R1 successfully received the loopback prefix advertised from R2.

Now, let’s create the same loopback interface on R1 using the same IP address, and then advertise it into BGP.

R1(config)#interface loopback 0 R1(config-if)#ip address 100.100.100.100 255.255.255.255 R1(config-if)#router bgp 100 R1(config-router)#network 100.100.100.100 mask 255.255.255.255

Great, let’s now check the BGP routing table on R1 once again to observe the results.

• *> → Indicates best path selected.
• 0.0.0.0 → This prefix is originated locally.
• Weight = 32768 → Default Cisco value for locally originated routes.
• Origin code = i → Injected into BGP via network command.

As shown in the above output, R1 is selecting the best path which is locally originated (next-hop is 0.0.0.0, indicating a locally originated route).

However, there’s a catch — since we are running this lab on a Cisco router, the first attribute evaluated is Weight. For locally originated routes, Cisco automatically assigns a default weight of 32768. That’s why, instead of the third attribute (Originated Locally), the router is actually using the Weight attribute as the tiebreaker in path selection.

So, how can we test the ‘Originated Locally’ behavior in this scenario? One option is to adjust the weight of the route received from R2.

By default, it shows weight 0. If we manually set its weight to 32768, the weight attribute will no longer decide the best path, forcing the router to move down the decision process and use the next attribute — in this case, Originated Locally. Let’s configure this on R1 and verify the results.

R1(config)#ip prefix-list loc_ori permit 100.100.100.100/32 R1(config)#route-map loc_ori 100 R1(config-route-map)#match ip address loc_ori R1(config-route-map)#set weight 32768

Take a look at this output — the weight is now the same for both the locally originated prefix and the prefix received from neighbor R2.

Since both the Weight and Local Preference attributes are equal, they are no longer considered in the tie-breaking process. The router then moves on to the next attribute: Originated Locally. As a result, R1 prefers the prefixes that it has originated itself.

• 0.0.0.0 as next-hop → indicates the route originated locally.
• 32768 is the default weight for locally originated routes in Cisco devices.

Key Points to Remember

1. Order of Preference:
   • Weight → Local Preference → Originated Locally.
2. Routes that originate inside the router are always preferred over routes learned externally.
3. Origin can be injected by:
   • network statement
   • redistribute
   • aggregate-address
4. Check using show ip bgp → look for 0.0.0.0 as next-hop and origin code.

Conclusion

The “Originated Locally” attribute may not always be visible in day-to-day operations, but it plays a critical role in tie-breaking when multiple equal BGP paths exist. By preferring self-originated routes, BGP ensures that locally configured routes take precedence, providing more predictable routing behavior.

Understanding this attribute helps network engineers fine-tune BGP path selection and troubleshoot why certain routes are preferred over others, even when Weight and Local Preference are the same.