cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
636
Views
0
Helpful
7
Replies
Highlighted
Beginner

Strange problem with route selection when using eBGP and EIGRP

I have a mixed WAN environment with both eBGP and EIGRP routes.  The BGP routes should always take precedence, when they exist.  If no BGP routes exist I want the router to fail over to using the EIGRP routes.  So far, this works fine.

The problem is, when the BGP route again becomes available (and the associated entry appears in the "sh ip bgp ... received-routes" output) the router is NOT relinquishing the EIGRP route.  It remains in effect, showing as a "D" route int the route table even though there is a better ("B") route available.

If I bounce EIGRP or the interface associated with it, the EIGRP route disappears and the BGP route reasserts itself, and everything will run correctly until the next time the BGP route disappears due to maintenance, line failure, etc.

Any ideas?

My router is (C2900-UNIVERSALK9-M), Version 15.3(1)T

Here's the associated config

interface Tunnel101

description VPN backup WAN interface

bandwidth 7168

ip address 192.168.75.1 255.255.255.0

no ip redirects

ip mtu 1500

ip flow ingress

ip flow egress

ip nhrp authentication *******

ip nhrp map multicast dynamic

ip nhrp network-id 1001

ip tcp adjust-mss 1460

snmp ifindex persist

tunnel source GigabitEthernet0/1.401

tunnel mode gre multipoint

tunnel key 1001

tunnel protection ipsec profile wbprofile

!

interface GigabitEthernet0/0

bandwidth 20480

ip address 172.17.29.1 255.255.255.252

no ip redirects

no ip unreachables

no ip proxy-arp

ip flow ingress

ip flow egress

duplex full

speed 100

snmp ifindex persist

no cdp enable

service-policy output qos-20meg

router eigrp 101

distribute-list prefix backup-filter out Tunnel101

network 1.1.1.0 0.0.0.3

network 172.17.29.0 0.0.0.3

network 192.168.51.0 0.0.0.63

network 192.168.75.0

network 192.168.96.0

redistribute bgp 65261 metric 2000 1 255 1 1500 route-map ANB-to-WB-map

router bgp 65261

bgp log-neighbor-changes

redistribute connected

redistribute static route-map WB-to-ANB-map

redistribute eigrp 101 metric 1 route-map WB-to-ANB-map

neighbor 172.17.29.2 remote-as 10970

neighbor 172.17.29.2 update-source GigabitEthernet0/0

neighbor 172.17.29.2 version 4

neighbor 172.17.29.2 soft-reconfiguration inbound

neighbor 172.17.29.2 route-map ANB-to-WB-map in

neighbor 172.17.29.2 route-map WB-to-ANB-map out

!

ip bgp-community new-format

route-map WB-to-ANB-map permit 10

match ip address prefix-list WB-to-ANB

!

route-map ANB-to-WB-map permit 10

match ip address prefix-list ANB-to-WB

ip prefix-list backup-filter seq 5 deny 172.17.29.0/24 ge 25

ip prefix-list backup-filter seq 10 deny 192.168.51.0/24 ge 25

ip prefix-list backup-filter seq 15 deny 192.168.52.0/24 ge 25

ip prefix-list backup-filter seq 20 deny 192.168.95.0/24 ge 25

ip prefix-list backup-filter seq 25 permit 0.0.0.0/0 ge 1

ip prefix-list ANB-to-WB description routes permitted from  ANB

ip prefix-list ANB-to-WB seq 5 permit 10.0.0.0/8 ge 9

ip prefix-list ANB-to-WB seq 10 permit 172.31.252.0/24

ip prefix-list ANB-to-WB seq 15 permit 172.31.253.0/24

ip prefix-list ANB-to-WB seq 20 permit 192.168.3.0/24

ip prefix-list ANB-to-WB seq 25 permit 192.168.96.8/32

ip prefix-list ANB-to-WB seq 30 permit 192.168.96.9/32

ip prefix-list ANB-to-WB seq 35 permit 192.168.96.10/32

ip prefix-list ANB-to-WB seq 40 permit 192.168.96.11/32

ip prefix-list ANB-to-WB seq 45 permit 192.168.96.12/32

ip prefix-list ANB-to-WB seq 50 permit 192.168.96.13/32

ip prefix-list ANB-to-WB seq 55 permit 192.168.10.0/24

ip prefix-list ANB-to-WB seq 60 permit 192.168.4.0/24

ip prefix-list ANB-to-WB seq 65 permit 192.168.6.0/24

ip prefix-list ANB-to-WB seq 70 permit 192.168.96.15/32

ip prefix-list ANB-to-WB seq 75 permit 192.168.96.16/32

ip prefix-list ANB-to-WB seq 80 permit 192.168.96.17/32

ip prefix-list ANB-to-WB seq 85 permit 192.168.17.0/24

ip prefix-list ANB-to-WB seq 90 permit 192.168.96.1/32

ip prefix-list ANB-to-WB seq 95 permit 192.168.96.2/32

ip prefix-list ANB-to-WB seq 100 permit 192.168.96.5/32

ip prefix-list ANB-to-WB seq 105 permit 0.0.0.0/0

ip prefix-list ANB-to-WB seq 110 permit 192.168.96.249/32

ip prefix-list WB-to-ANB description routes advertised to ANB

ip prefix-list WB-to-ANB seq 3 deny 192.168.3.252/32

ip prefix-list WB-to-ANB seq 5 permit 192.168.0.0/19 ge 24

ip prefix-list WB-to-ANB seq 10 permit 192.168.192.0/19 ge 24

ip prefix-list WB-to-ANB seq 15 permit 192.168.98.0/24

ip prefix-list WB-to-ANB seq 20 permit 192.168.51.0/26

ip prefix-list WB-to-ANB seq 25 permit 192.168.99.0/24

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

Hi,

I believe Harold is right.

I faced excatly the same problem some time ago.

If you need to keep the prefix redistributed from EIGRP to BGP for some reason (as I did) you can make the eBGP prefix to win by changing BGP attributes.

By default the prefix redistributed from EIGRP to BGP gets the weight=32768 attributes value.

So you can set this value to 0 by the route-map used for redistribution  and increase the local preference, e.g., to be sure it wins.

Or you can set the weight of eBGP prefix to 40000 by another route-map.

Best regards,

Milan

View solution in original post

7 REPLIES 7
Highlighted
Cisco Employee

Hi,

I think the issue is due to the fact that when the primary bgp session goes down, the eigrp route is utilized, which is fine but it is also redistributed in bgp. This causes the route not to be learned via bgp when the session comes backup because the originated bgp route (the one that has been redistributed from eigrp to bgp) is preferred.

You should make sure that the route in question is not redistributed from eigrp to bgp to start with, so that when the bgp session comes back up, the remote bgp routes will be received and redistributed in eigrp.

Regards

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
México móvil: +52 1 55 8312 4915
Cisco México
Paseo de la Reforma 222
Piso 19
Cuauhtémoc, Juárez
Ciudad de México, 06600
México
Highlighted

Hi,

I believe Harold is right.

I faced excatly the same problem some time ago.

If you need to keep the prefix redistributed from EIGRP to BGP for some reason (as I did) you can make the eBGP prefix to win by changing BGP attributes.

By default the prefix redistributed from EIGRP to BGP gets the weight=32768 attributes value.

So you can set this value to 0 by the route-map used for redistribution  and increase the local preference, e.g., to be sure it wins.

Or you can set the weight of eBGP prefix to 40000 by another route-map.

Best regards,

Milan

View solution in original post

Highlighted

Thanks for the replies.  I do need to retain the redistribution, since interface Tunnel101 is the backup path for traffic and the BGP running on Gi0/0 needs to be aware of those routes.

Milan, I did try altering the weight of the eBGP prefix and it did not seem to work... though I did not use the specific value you mentioined. I did not try adjusting the weight or local pref of the redistributed route.  I can try that.

I think you are on the right track, but something you said confuses me.  You stated "By default the prefix redistributed from EIGRP to BGP gets the weight=32768 attributes value.  So you can set this value to 0 by the route-map used for redistribution  and increase the local preference, e.g., to be sure it wins."

I do not want the EIGRP route to win, I want the BGP route to win.  You seem to be saying to lower the weight and/or raise the local preference, which I think would have opposing influences in terms of route selection (?)  I'm not certain how to interpret this.

To be clear, my understanding of the order of route selection looks like this:

1. The route with the highest weight value wins. If there is a tie, then...

2. The route with the highest local pref value wins. If there is still a tie, then...

3. native BGP routes are preferred over redistributed routes.

4. And AS-path length figures in there somewhere down in the list, with shorter paths being preferred over longer ones.  I'm not sure where exactly this falls in the selection order.

Is that correct?

Thanks,

-Mat

Highlighted

Hello Mat,

I totally agree with Milan. I had the same issue some years ago.

You can use

neighbor weight 40000

to solve the issue on eBGP route restore after failure. It makes the eBGP route better then  the locally inejcted route coming from EIGRP that has weight 32768.

Another possible solution as suggested by Harold ( if possible) is to avoid to redistribute the EIGRP route into BGP

Hope to help

Giuseppe

Highlighted

Hi Mat,

you are correct, the sentence should have been

" ... and decrease the local preference, e.g., to be sure it does not win."

In my solution, I was setting the weight to 0 by the redistribution route-map and increasing the eBGP prefix local preference by another route-map, so that's why I made the mistake in the description.

Or you can use the other way of increasng the eBGP prefix weight to beat the 32768 value of the redistributed prefix.

Either the easy way suggested by Giuseppe, or some more complex by using "neighbor ... route-map xxx in"

command and matching the particular prefix(es) to increasse the weight by the xxx route-map.

You mentioned you tried to increase the weight of the eBGP prefix already and it did not work.

Have you issued "clear ip bgp * soft" command or something similar then to refresh the BGP table?

Can you check by "show ip bgp x.x.x.x" command the eBGP prefix has got the correct weight?

Best regards,

Milan

Highlighted

I think you guys are correct.  I am implementing the changes you recommended and I will test them in my next test window (next Tuesday PM.)  I will update again once I know if they worked.

Thanks,

-Mat

Highlighted

Milan, you were correct.  I adjusted the BGP weights per your recommendations and retested yesterday evening.  Worked like a charm.  Thanks!

-Mat