Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Strange problem with EIGRP and BGP

I have a router that is running both eBGP and EIGRP. EBGP out to one of my wan clouds and EIGRP into the core.

I am redistributing BGP into EIGRP and EIGRP into BGP. I know this isn't ideal but it is necessary for the moment.

The problem I am having is that I need this router to prefer the BGP route over the EIGRP learned route which comes through our other WAN cloud.

As I understand it the router SHOULD select the eBGP route since the administrative distance is 20 for eBGP learned routes. But for some reason it is using the EIGRP learned routes with an administrative distance of 90.

I can "fix" this by changing the administrative distance of EIGRP on the router to 200. But I shouldn't need to do this. When I make this "fix" the bgp route is selected and it has an admin distance of 20.

I don't get it.

Note: I did have the BGP distances changed earlier but I removed that command and clear the route tables and BGP process.

Any ideas?

Hall of Fame Super Silver

Re: Strange problem with EIGRP and BGP


On the face of it, the BGP route should have been preferred to the EIGRP route. If it was not then there must be something going on. Can you recreate the situation? If so it would be very helpful if you could post the output of show ip route (at least for the route involved) as well as the output of show ip bgp for that route and the output of show ip eigrp topology for that prefix.



Re: Strange problem with EIGRP and BGP


This is a classic example of a redistribution problem with BGP

Here's an excerpt from a previous post by Martin and Paresh on similar issues

first the announcement of a network will for sure be faster through EIGRP than through BGP. Once you have the EIGRP route in the routing table you redistribute it into BGP. Now BGP learns the network through EBGP.

At this point BGP path selection determines which of the two is the better path. And the winner is: locally redistributed route

Just to expand

When BGP injects a local route into the BGP table, it gives it a weight of 32768, by default. In your case, it is the EIGRP-learned route that is getting injected into BGP with a weight of 32768. The same route is also being learned via EBGP. EBGP routes, by default, will be given a weight of 0 and a local preference of 100. Since weight is the highest ranked parameter in the BGP best path selection process, the locally-injected route will take preference and will be selected as the best route.

Administrative distance does not play a role in BGP path selection.

Solution would be to redistribute the EIGRP routes to BGP but make it less attractive by manipulating weight

HTH, rate if it does


Re: Strange problem with EIGRP and BGP

That was a very nice input from Narayan. So can he just use a route-map statement appended to his redistribute eigrp command right? Then the route-map command should be like this to lower the weight of redistributed routes from EIGRP?

route-map redist permit 10

set weight 200



Re: Strange problem with EIGRP and BGP

i have a doubt there....

as narayan mentioned routes learned via ebgp have a weight of 0,so the weight via redistribution should be less than that,which is not increase the weight for routes learned via ebgp to above 32768(ie above the weight of routes learned via redistribution) .Am i right or my understanding is wrong???

Re: Strange problem with EIGRP and BGP

THe weight needs to be less than 32768 for the routes distributed into BGP. Remember highest weight has higher preference.

Alternate way is to have the weight same as the EBGP route and adjust the local preference to be lower than the BGP route

route-map EIGRPtoBGP permit 10

match ip addess 111

set weight 0

set local preference 90

access-list 111 permit

HTH, rate if it does


New Member

Re: Strange problem with EIGRP and BGP

The way I usually fix this is by sending longer prefixes via the bgp path. I.e. send a /24 on bgp for the same networks that are say /16 on EIGRP.

Another option of course like the group said is weight. there I would use neighbor x.x.x.x weight 50000 and then the real ebgp route will always beat the locally originated route with 32768. The route-map the group listed will work too, just nail the weight on redistribution from EIGRP>BGP with

router bgp 100

redistribute eigrp 1 route-map redis-eigrp-into-bgp

route-map redis-eigrp-into-bgp permit 10

set weight 0

New Member

Re: Strange problem with EIGRP and BGP

Thanks for your great reply.

But why did the route change to the eBGP learned route once I changed the EIGRP admin distance? What you say makes sense especially when I do a sh ip rout and sh ip bgp...

Routing entry for

Known via "bgp 65002", distance 20, metric 0

Tag 1803, type external

Redistributing via eigrp 1

Advertised by eigrp 1 metric 44000 0 255 1 1500

Last update from 12:49:01 ago

Routing Descriptor Blocks:

*, from, 12:49:01 ago

Route metric is 0, traffic share count is 1

AS Hops 2

Route tag 1803

WAN-Router2-#sho ip bgp

BGP routing table entry for, version 315

Paths: (1 available, best #1, table Default-IP-Routing-Table)

Not advertised to any peer

1803 65207 from (

Origin IGP, localpref 100, valid, external, best

But prior to changing the EIGRP admin distance the BGP tables also had the EIGRP learned route with that same weight. I'm still redistributing EIGRP into BGP.

Re: Strange problem with EIGRP and BGP


Weight should come into play only when the router has to choose a path when multiple paths exist for a BGP learned route(s). Between two protocols, as it is in this case, admin distance should be the deciding factor.

I agree with the original poster that EBGP's admin distance should make it the preferred route over the EIGRP learned route. If weight was a factor then increasing EIGRP's admin distance shouldn't have caused the router to use EBGP route replace EIGRP route. It sounds as if changing the admin distance would have caused EIGRP neighbor to drop and reconnect and thus EBGP route replaced it.

I don't have access to lab at this time to test. But, I have a feeling it may have something to do convergence. Since EIGRP probably learned the route much quicker than EBGP and advertised it via BGP it would have considered it as a locally originated route as Narayan alluded to and thus it probably ignored the EBGP route. Any solution may have to be related to how these protocols converge and not weight specific.



Re: Strange problem with EIGRP and BGP

Sundar you are correct.

The behavior is due to the convetrgence factor. EIGRP converges faster and then it gets into the BGP table due to redistribution. Now when BGP receives the route via EBGP it practically has 2 routes for the specific prefix. Here BGP does not consider the Administrative distance as installs the route as per BGP path selection process.

If you do not redistribute the EIGRP routes back into BGP, the BGP table has only one path for a prefix which gets into the BGP table and the router installs it with a AD of 20 after comparing with EIGRP.

If the route or prefix for any reason disappears from the IGP, the EGP route will be immediately injected in the routing table with an AD of 20 if it is eBGP.

Then when the IGP recovers, since the eBGP route is already established in the routing table, IGP will not participate in the BGP path selection. Therefore it will not be selected.

The only way to make it work is 'clear ip bgp *', which basically resets BGP and clears the routing table from all BGP entries.

HTH, rate if it does


New Member

Re: Strange problem with EIGRP and BGP


If I remove the redistribution command and change to network statements, that would eliminate this problem, right?

So let me see if I have the process correct.

1. Router learns route via IGP first.

2. Route is inserted into BGP table via redistribution.

3. Route is learned via eBGP.

4. EIGRP learned route is preferred because of weight.

By clearing the IGP, the eBGP route is used and will continue to be used until the BGP process feels a need to re-learn routes(ie topology change)

That about right?

Re: Strange problem with EIGRP and BGP

Your understanding of the problem is correct.

However, I am not sure if using network statements would resolve your problem because it doesn't address the convergence problem. You may have to look at changing the hello/hold timer for EIGRP to 60/180 to delay and thus slow down EIGRP convergence. Alternatively, you can lower the hello/hold timer for BGP and that mayn't be a viable option if you are peering with an external AS.



New Member

Re: Strange problem with EIGRP and BGP

Yes but by using network statements I can alleviate the problem of the network ever being inserted into the BGP process since I really don't need that route inserted into BGP.

New Member

Re: Strange problem with EIGRP and BGP

Sundar, I have a lab, and here is what I found out... Eigrp is definitely preferred over the EBGP route, just as suspected by Narayan.

I used the to lab this up... as expected bgp thinks its best route is the route it redistributed from eigrp into bgp locally. the ebgp learned route is not used despite lower ad...

I put all the details in the attached txt


Re: Strange problem with EIGRP and BGP


Try clearing the EIGRP neighbor and when the neighbor comes back up I am guessing you mayn't see the EIGRP route preferred any longer.



Re: Strange problem with EIGRP and BGP

Yes friend,

The best way is to use network statements in BGP which alleviates this problem. But this May depend on the number of prefixes you have.

We use the same technique in our network

HTH, rate if it does


New Member

Re: Strange problem with EIGRP and BGP

Sundar, You are correct!

after I cleared the EIGRP neighbor,

BGP is preferred...

fr_hub#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is to network is subnetted, 1 subnets

C is directly connected, Loopback1 is subnetted, 1 subnets

C is directly connected, Serial0/0.201 is subnetted, 1 subnets

C is directly connected, Serial0/0.202 is subnetted, 1 subnets

B [20/0] via, 00:00:04 is subnetted, 1 subnets

C is directly connected, FastEthernet0/0

S* [1/0] via

Re: Strange problem with EIGRP and BGP

Hi Guys,

I just have a question here. Yes, the BGP route will be inserted in the routing table after clearing the EIGRP neighbor so the EIGRP route with the AD of 90 will disappear and the eBGP route with the AD of 20 will be injected. After the EIGRP neighbor comes up, and redistribution happens again, the route will be redistributed again to BGP and it will have a route in the BGP table with a weight of 32768. Will the BGP process reset it's best route automatically to the redistributed route with the weight 32768 as the best route?

Of course if this happens, the EIGRP route will be prefered again because the redistributed route will be a locally injected route with the AD of 200 and the EIGRP route with the AD of 90.

And what if the BGP table does not update automatically? The BGP route will stay in the routing table right? Do I need to issue clear ip bgp x.x.x.x to prefer the EIGRP route?

Sorry for bringing up this topic again. :)


Re: Strange problem with EIGRP and BGP


First of all this isn't a very common setup where a route is being learned via BGP and an IGP (EIGRP) and is mutually redistributed between both protocols. That right there warrants some extra measures to make sure routing works the way it should.

To answer your question the last part of what you said is true i.e when the router starts using EBGP route it wouldn't replace that with EIGRP route because the EIGRP route wouldn't be redistributed into BGP as it would only exist in the EIGRP topology table and not in the routing table. Clearing BGP neighbor will very likely cause the EIGRP route to take over.



Re: Strange problem with EIGRP and BGP

Thank you Sundar for replying to my question. So the redistributed route won't appear in the BGP table unless you clear it. You mentioned that clearing the BGP neighbor will very like cause the EIGRP route to take over. Can I just clear the route in the BGP table for example clear ip bgp to inject the EIGRP redistributed route in the BGP table?


New Member

Re: Strange problem with EIGRP and BGP

The router would prefer any route over a redistributed route rrespective of the administrative distance.The eBGP route that router sees might be a redistributed one.The output of your routingtable will hellp troubleshoot the same.