«

I have got a problem with BGP routes.
Got 2 Gateways. They are connected to BGP and to OSPF and they do
mutual redistribution of the routes.
For the route below I got the following problem.
Got two BGP and one OSPF routes for the same subnet 10.0.0.0/24.
One is announced via EBGP (peer 1.144.126.12 and the other one come
from the redistribution (origin incomplete).
I expect the BGP to take over, but this does not happen. My thought is
that BGP process see two different BGP entries for the same subnet and
it thinks that there is a loop and it does not insert a BGP route in
the routing table.

Looking to the following output it is the only idea I have got.

Any other explanation? Any Cisco web site link to explain this?




Router1#sh ip bgp | include 10.0.0.0

BGP routing table entry for 10.0.0.0/24, version 698
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
1.144.126.128
2856 64530
1.144.126.128 from 1.144.126.128 (1.144.126.12
Origin IGP, localpref 100, valid, external
Local
1.9.205.200 from 0.0.0.0 (10.97.8.200)
Origin incomplete, metric 199, localpref 100, weight 32768, valid,
sourced, best


O E1 10.0.0.0/24 [110/199] via 1.9.205.200, 01:37:36, FastEthernet0/0


Any help is appreciated

Matteo

Hi,

schrieb:
> I have got a problem with BGP routes.
> Got 2 Gateways. They are connected to BGP and to OSPF and they do

>
> Router1#sh ip bgp | include 10.0.0.0
>
> BGP routing table entry for 10.0.0.0/24, version 698
> Paths: (2 available, best #2, table Default-IP-Routing-Table)
> Advertised to non peer-group peers:
> 1.144.126.128
> 2856 64530
> 1.144.126.128 from 1.144.126.128 (1.144.126.12
> Origin IGP, localpref 100, valid, external
> Local
> 1.9.205.200 from 0.0.0.0 (10.97.8.200)
> Origin incomplete, metric 199, localpref 100, weight 32768, valid,
> sourced, best
>
That indicates, that the route #2 is the best route, because the WEIGHT
is 32768, which is better than the weight of the first route (0). That
route would be installed in the FIB but
>
> O E1 10.0.0.0/24 [110/199] via 1.9.205.200, 01:37:36, FastEthernet0/0
you also have an OSPF-process running and this one has the same route too.
Now, while external BGP (that would be BGP-Route #1) has an
administrative distance of 20 (which ist better than OSPF 110), the
second BGP-route is an internal route (AFAIR, because of being
redistributed into BGP on the local router), and therefore has an AD of 200.

So, when coosing the right route to be entered into the FIB, the ospf
has preference over the bgp-route, because that would be route#2, an
internal bgp-route.

Mathias
--
CCIE #11220
Everything written is MY opinion only, not the one of my company or
employer unless otherwise noted

The early bird gets the worm, but the second mouse gets the cheese

My signature is certified by Fraunhofer Society.
The root-ca IS trusted but the browser-manufacturers want big $ to have
it included

Thanks,

it seems that BGP is shooting himself on the feet, iBGP is taking over
and then it is losing against the OSPF.
So the fact that the two BGP routes are in the BGP table it means that
the routes are valid.Correct?
Two routes are invalidating each other is not a valid explanation.

Well,
VALID is a crucial word here.
The BGB-Table holds a lot of routes, not all of them CAN and WILL make
it in the FIB.
Do NOT confuse the routing-table of a routing-protocol with the FIB, the
actual routing-table you see with "show ip route".

In your case, the iBGP-route has precedence IN THE BGP-PROCESS since
it's weight (a locally adminstered parameter) is higher then that of the
eBPG-Route. So this route is considered the best-route, aka the
candidate-route to be entered into the FIB.
But it is an iBGP-learned route and therefore has an administrative
distance of 200 associated with it.
The FIB-rule is:
Take all routes from all routing-processes into FIB. If two (or more)
equal routes exist, take the one with the lower AD.
And OSPF has a lower AD (110).
It's the normal behaviour and no shooting in the foot

How to solve?


You really should reconsider your routing-policy so that this will not
happen at all.
Why is it that the route appears as iBGP AND eBGP anyway?
Do you really have to redistribute all of these OSPF-routes into BGP at
THIS place or AT all?

Mathias

schrieb:
> Thanks,
>
> it seems that BGP is shooting himself on the feet, iBGP is taking over
> and then it is losing against the OSPF.
> So the fact that the two BGP routes are in the BGP table it means that
> the routes are valid.Correct?
> Two routes are invalidating each other is not a valid explanation.
>

--
CCIE #11220
Everything written is MY opinion only, not the one of my company or
employer unless otherwise noted

The early bird gets the worm, but the second mouse gets the cheese

My signature is certified by Fraunhofer Society.
The root-ca IS trusted but the browser-manufacturers want big $ to have
it included