# BGP Attribute Locally Originated
**URL:** https://forum.networklessons.com/t/bgp-attribute-locally-originated/41407
**Category:** Lessons Discussion
**Created:** [December 14, 2023, 12:57pm UTC](https://forum.networklessons.com/t/bgp-attribute-locally-originated/41407 "2023-12-14T12:57:53Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@ReneMolenaar](https://forum.networklessons.com/u/ReneMolenaar)
#### Post date: [December 14, 2023, 12:57pm UTC](https://forum.networklessons.com/t/bgp-attribute-locally-originated/41407/1 "2023-12-14T12:57:53Z")
This topic is to discuss the following lesson:
> **[BGP Attribute Locally Originated](https://networklessons.com/bgp/bgp-attribute-locally-originated)**
>
> BGP prefers locally originated prefixes over prefixes from other BGP routers. This is the third tiebreaker in the BGP best path selection.
---
### Author:  [@rajni.genius1104](https://forum.networklessons.com/u/rajni.genius1104)
#### Post date: [January 23, 2024, 2:38am UTC](https://forum.networklessons.com/t/bgp-attribute-locally-originated/41407/2 "2024-01-23T02:38:03Z")
Hi
here you have created the route-map `SET_WEIGHT_INBOUND`, but seems like you missed to set the weight to 32768 under it, in the write up. Please check. looks like a small typo.
Great content, thank you.
---
### Author:  [@lagapidis](https://forum.networklessons.com/u/lagapidis)
#### Post date: [January 24, 2024, 5:54am UTC](https://forum.networklessons.com/t/bgp-attribute-locally-originated/41407/3 "2024-01-24T05:54:43Z")
Hello Rajni
Yes, you are correct, thanks for pointing that out. I will let Rene know to make the correction.
Glad to hear tat you’re enjoying the content!
Laz
---
### Author:  [@ReneMolenaar](https://forum.networklessons.com/u/ReneMolenaar)
#### Post date: [January 25, 2024, 7:30pm UTC](https://forum.networklessons.com/t/bgp-attribute-locally-originated/41407/4 "2024-01-25T19:30:50Z")
Thank you @rajni.genius1104 . I just fixed this.
Rene
---
### Author:  [@samirkhair](https://forum.networklessons.com/u/samirkhair)
#### Post date: [August 20, 2024, 1:00pm UTC](https://forum.networklessons.com/t/bgp-attribute-locally-originated/41407/5 "2024-08-20T13:00:40Z")
Hi,
I have an observation regarding the following statement:
> You can recognize these because the next hop is always 0.0.0.0.
I created the following lab:
1.1.1.0/24—**(R1)**—OSPF—**(R2)**—iBGP----**(R3)**----1.1.1.0/24
Redistribution was used for 1.1.1.0/24 on R2 and the network command on R3. On R2, weight was modified to be the same, LocalPref of 100 remained the same. BGP selected the locally redistributed route over the one learned via the network command on R3, as expected.
However, the next hop was not 0.0.0.0 and is set the the IGP’s (OSPF) next hop. It seems next hop is only 0.0.0.0 if it is a directly connected route.
R2:
---
### Author:  [@lagapidis](https://forum.networklessons.com/u/lagapidis)
#### Post date: [August 22, 2024, 5:16am UTC](https://forum.networklessons.com/t/bgp-attribute-locally-originated/41407/6 "2024-08-22T05:16:36Z")
Hello Samir
First of all, you mention that:
> [@samirkhair](#):
>
> Redistribution was used for 1.1.1.0/24 on R2 and the network command on R3.
I think you mean that redistribution was used on **R1** , correct?
Now assuming that is indeed correct, the next thing I’d like to point out is that the locally originated routes attribute refers to routes that have been originated on the **local router**. So the only router you will see 0.0.0.0 as a next hop is the router in which the `network` command or redistribution has been applied. If you look at the BGP table of either R1 or R3, you will see 0.0.0.0 as the next hop for the 1.1.1.0/24 network.
**From the point of view of R2, neither route is locally originated.**
Now having said that, looking at your BGP table, I’m trying to figure out why the second entry has been chosen as the best route. I can infer the following:
1. The route from R3 was learned from an iBGP peering while the route from R1 was an eBGP peering (see the “i” at the beginning of the first entry)
2. The origin code of “i” appears for the first route, which means that the `network` command was indeed used to advertise this into BGP, while the incomplete origin code of “?” is used for the second entry, which means it was redistributed.
3. Since one path is learned via eBGP and the other via iBGP, MED is not considered.
So going through the attributes:
1. Weight is the same
2. Local preference is ignored
3. Neither route is locally originated
4. AS path length is the same
5. Origin code is different, and “i” should be chosen over “?” but it is not.
6. MED is not considered
7. eBGP is chosen over iBGP, and this seems to be what is happening.
It seems like the eBGP route is being chosen over the iBGP route. But that’s not in the correct order of BGP path selection. So there must be some information we’re missing. Can you share with us the configuration of the BGP section of your routers so we can take a closer look?
I hope this has been helpful!
Laz
---
### Author:  [@samirkhair](https://forum.networklessons.com/u/samirkhair)
#### Post date: [August 22, 2024, 5:44am UTC](https://forum.networklessons.com/t/bgp-attribute-locally-originated/41407/7 "2024-08-22T05:44:39Z")
Hi Laz,
Redistribution is occurring on R2 (see below). There is only OSPF on R1, OSPF and BGP on R2, and only BGP on R3. R2 and R3 are in BPG AS 2.
R2:
> router bgp 2
> bgp log-neighbor-changes
> redistribute ospf 1
> neighbor 3.3.3.3 remote-as 2
> neighbor 3.3.3.3 ebgp-multihop 2
> neighbor 3.3.3.3 update-source Loopback0
> neighbor 3.3.3.3 route-map WEIGHT in
The reason I chose to redistribute on R2 and use the network command on R3 was to be certain that it was using the locally originated tie-breaker and not one further down the priority list, such as origin, which it isn’t because igp \> egp \> ?.
Apologies, I should have been clearer.
Btw, I just tried using the network command on R2 instead of redistributing, and the next hop is still retained (and the origin code is now i instead of ?).
> R2(config-router)#do sh run | s bgp
> router bgp 2
> bgp log-neighbor-changes
> network 1.1.1.1 mask 255.255.255.255
> neighbor 3.3.3.3 remote-as 2
> neighbor 3.3.3.3 ebgp-multihop 2
> neighbor 3.3.3.3 update-source Loopback0
> neighbor 3.3.3.3 route-map WEIGHT in
Thanks.
Sam
---
### Author:  [@marcel.schmid2](https://forum.networklessons.com/u/marcel.schmid2)
#### Post date: [May 9, 2025, 1:22pm UTC](https://forum.networklessons.com/t/bgp-attribute-locally-originated/41407/8 "2025-05-09T13:22:43Z")
Hi all, 🙂
I am a bit confused about this attribute.
Referencing to the topology from the lesson where both R1 and R2 propagate their L0 interface to each other via eBGP:
![image]()
```auto
R1#sh ip bgp | beg Net
Network Next Hop Metric LocPrf Weight Path
* 12.12.12.12/32 192.168.12.2 0 32768 2 i
*> 0.0.0.0 0 32768 i
```
```auto
R2#sh ip bgp | beg Net
Network Next Hop Metric LocPrf Weight Path
*> 12.12.12.12/32 0.0.0.0 0 32768 i
* 192.168.12.1 0 32768 1 i
```
According to the path selection process, the locally originated prefix would be prioritized and selected as the best route. However, it will never be visible in the RIB since the AD of eBGP is worse than directly connected routes. In other words, if the prefix with the local next hop on either side is removed from the BGP table, it will always end in a RIB failure on the other side.
So my question is, in which scenario would this attribute have a real effect?
---
### Author:  [@lagapidis](https://forum.networklessons.com/u/lagapidis)
#### Post date: [May 12, 2025, 5:37am UTC](https://forum.networklessons.com/t/bgp-attribute-locally-originated/41407/9 "2025-05-12T05:37:11Z")
Hello Marcel
Indeed, the network is directly connected, and the AD would cause the connected route to be chosen over any eBGP-learned route in the local routing table. This would be the case for any locally originated route that comes from a directly connected route.
Remember, the point of BGP is not necessarily to install a route in the local routing table. The fact that the route has entered the BGP table means that this router is now **advertising this route via BGP**. So in most cases, when you have a locally originated route from a directly connected network, the purpose is to advertise it via BGP, not necessarily to install it in the local routing table. Does that make sense?
I hope this has been helpful!
Laz