Cisco Support Community
Community Member

BGP and IGP administrative distance strange behavior


Please see attached config. and topology layout. (ignore AS 30)

Both Meribel and Lillehammer runs RIP as an internal IGP in their AS's and both routers runs RIP on the serial interfaces that are connecting them. In this scenario, i want to use BGP backdoor so i can restrict communications between certain subnets in both AS's to use only the RIP connection. However, i didn't use the backdoor because actually the issue that the backdoor used to solve, is not there.

As we know, RIP AD is 120 and EBGP is 20, therefore the routers will choose EBGP. The strange thing is that the routers are still choosing RIP. This is actually my requirement but i wonder why the routers didn't shift to EBGP so i can use the backdoor.

I worked on this by shutting down the serial interfaces of both routers to break the RIP connection and i can see that EBGP is chosen. Then, i brought the interfaces back again. Everything is fine now but this is not practical.

Appreciate if someone can shed some light on this behavior.



Hall of Fame Super Bronze

BGP and IGP administrative distance strange behavior

What you encountered was a 'race condition'. Both routers had the redistribution command applied at the same time and before they saw each others eBGP routes, they were both locally originating the routes.

If you see the following URL:

step 3.



Community Member

BGP and IGP administrative distance strange behavior

HI Edison,

Thx for your reply.

Well, here is the thing.

The redistribution would advertise both AS's subnets to the BGP process. Let's say, Lillehammer would see subnets and come from the BGP process (advertised by Cervenia), so it will prefer EBGP routes (AD 20) over the RIP routes (AD 120) but this doesn't happen. I still can see that RIP routes are preferred over EBGP routes even though its AD is higher.

My goal is i want Lillehammer to reach those subnets through Meribel (RIP link) not through EBGP (which is now happening). The solution to this is to change those EBGP routes into Local BGP routes wil AD of 200. Therefore, i use network statements using the "backdoor" keyword. However, i didn't include those network statements in the uploaded config file because i want to solve this odd behavior first.

In other words, i expect a problem to happen in order to solve it but the problem doesn't happen.

Re: BGP and IGP administrative distance strange behavior


as Edison mentioned, it's a "race".

When you are redistributing your RIP to BGP, it really depends on which prefix comes first, if the RIP one or eBGP one.

Let's say your router had recieved the prefix by RIP first.

It redistributed the prefix to its BGP table.

Then the same prefix comes via eBGP.

Will it be the best from the router  BGP process point of view?


As there is the same prefix within the BGP table already with weight attribute=32768 (redistributed by this router from RIP originally).

So the prefix received by eBGP is not the best one from BGP process point of view.

So it can't get to the RIB and the old RIP prefix stays there.

So IMHO, you would need to decrease the weight to 0 when redistributing from RIP to BGP (applying a route-map, e.g.).

Or you can apply a route-map increasing the weight of the prefixes (or some of them) received from the eBGP  neighbor to 40000.

So remember: Only the best BGP prefix can be chosen for RIB. And then the AD starts to play its role.



Community Member

BGP and IGP administrative distance strange behavior

The problem is solved.

Redistribution RIP to BGP on both routers are turned  off and using the "network backdoor" statements worked. Now, all the  subnets in both AS's are learned via the RIP link only. However, i noticed an  RIB failure symbol r> beside those subnets' entries in the BGP table  and i guess it's normal since the backdoor prevents the advertisement  of the subnets in BGP updates.

Thx to all.

CreatePlease to create content