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.
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.
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
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
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???
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
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
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
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.
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.
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
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?
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.
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.
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 220.127.116.11/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
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.
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
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 10.230.13.1 to network 0.0.0.0
18.104.22.168/32 is subnetted, 1 subnets
C 100.100.100.1 is directly connected, Loopback1
22.214.171.124/30 is subnetted, 1 subnets
C 126.96.36.199 is directly connected, Serial0/0.201
188.8.131.52/30 is subnetted, 1 subnets
C 184.108.40.206 is directly connected, Serial0/0.202
220.127.116.11/24 is subnetted, 1 subnets
B 18.104.22.168 [20/0] via 22.214.171.124, 00:00:04
10.0.0.0/24 is subnetted, 1 subnets
C 10.230.13.0 is directly connected, FastEthernet0/0
S* 0.0.0.0/0 [1/0] via 10.230.13.1
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. :)
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.
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 126.96.36.199/24 to inject the EIGRP redistributed route in the BGP table?
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.