BGP Attribute Locally Originated

Hello Samir

First of all, you mention that:

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