Strange problem with EIGRP and BGP

[bgibson]

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?

[Richard Burts]

Brian

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.

HTH

Rick

[royalblues]

Friend,

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

Narayan

[jpl861]

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

-John

[s.arunkumar]

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 possible...so 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???

[royalblues]

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

Narayan

[jbrunner007]

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

[bgibson]

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 192.168.207.0/24

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 172.20.56.1 12:49:01 ago

Routing Descriptor Blocks:

* 172.20.56.1, from 172.20.56.1, 12:49:01 ago

Route metric is 0, traffic share count is 1

AS Hops 2

Route tag 1803

WAN-Router2-#sho ip bgp 192.168.207.0

BGP routing table entry for 192.168.207.0/24, version 315

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

Not advertised to any peer

1803 65207

172.20.56.1 from 172.20.56.1 (10.247.23.72)

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.

[sundar.palaniappan]

Interesting!!

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.

HTH

Sundar

[royalblues]

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

Narayan

[bgibson]

Interesting.

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?

[sundar.palaniappan]

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.

HTH

Sundar

[bgibson]

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.

[jbrunner007]

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 9.9.9.0/24 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

-Joe

[sundar.palaniappan]

Joe,

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.

HTH

Sundar