eigrp, bgp, distance

[MARCELO MATURO]

I have a router that is receiving a prefix via redistributed eigrp and bgp. It installs the first in its routing table. The administrative distance are by default.

I don't know that is happening.

Thanks.

Marcelo

[Peter Paluch]

Marcelo,

You have not explained in sufficient detail what is the problem you are trying to solve.

Nevertheless, at least some hints: if a route is redistributed into EIGRP and received by your router from another EIGRP neighbor, it is considered external and its administrative distance will be 170. If the route is advertised using the BGP then it depends on whether the network has been received from an internal or an external BGP peer. For internal BGP peers, the administrative distance is 200, on the other hand, for external BGP peers (from other autonomous systems), the administrative distance will be only 20.

Does that explain what is happening in your routing table?

Best regards,

Peter

[MARCELO MATURO]

The bgp is an external peer. This is the configuration:

router eigrp 300

redistribute bgp 65200 metric 20880 100 255 1 1500

network 10.40.4.0 0.0.0.255

network 10.40.6.0 0.0.0.255

distribute-list 21 out GigabitEthernet0/1

distribute-list 20 in GigabitEthernet0/1

distribute-list 23 in GigabitEthernet0/3

no auto-summary

no eigrp log-neighbor-changes

!

router bgp 65200

no synchronization

bgp log-neighbor-changes

network 10.40.4.0 mask 255.255.255.0

redistribute static

redistribute eigrp 300

neighbor 172.16.255.13 remote-as 10888

neighbor 172.16.255.13 ebgp-multihop 2

neighbor 172.16.255.13 allowas-in

neighbor 172.16.255.13 soft-reconfiguration inbound

neighbor 172.16.255.13 prefix-list in in

neighbor 172.16.255.13 prefix-list out out

neighbor 172.16.255.13 route-ap sec_bgp out

no auto-summary

[Peter Paluch]

Hello Marcelo,

Let's go over a few questions and comments.

1.) What is exactly the problem you are trying to solve? Do you have a network that is present in your table from a particular routing protocol and you expect that is should be present there by a different routing protocol? Please, explain in detail what you see on your router that you consider to be incorrect. Include the related show outputs to demonstrate it.

2.) You have soft-reconfiguration inbound configured for the neighbor 172.16.255.13. This is an obsolete workaround and is very memory-inefficient. All recent BGP implementations support the Route Refresh capability as per RFC 2918 that is activated automatically if both peers support it. If the command

show ip bgp nei 172.16.255.13 | i refresh

shows the following output:

Route refresh: advertised and received(old & new)

then you may safely remove the soft-reconfiguration command for that peer.

Best regards,

Peter

[MARCELO MATURO]

Thanks Peter for your recomendation. The problem is that I need that the network will be present in my router from bgp ( it is the main link) and not by the eigrp ( it is from the secundary link: another bgp redistributed from other location).

This is the show commands:

sh ip route 74.5.124.2

Routing entry for 74.5.124.2/32

Known via "eigrp 300", distance 170, metric 2585856

Tag 10888, type external

Redistributing via eigrp 500, bgp 65200

Advertised by bgp 65200

Last update from 10.40.6.1 on GigabitEthernet0/3, 02:35:39 ago

Routing Descriptor Blocks:

* 10.40.6.1, from 10.40.6.1, 02:35:39 ago, via GigabitEthernet0/3

Route metric is 2585856, traffic share count is 1

Total delay is 1010 microseconds, minimum bandwidth is 1000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 1/255, Hops 1

Route tag 10888

And the route is received by bgp:

sh ip bgp neighbors 172.16.255.13 received-routes | i 74.5.124.2

* 74.5.124.2/32 172.16.255.13 0 10888 10888 i

And then why the router prefer eirp redistributed to bgp?

Thanks.

Marcelo

[Peter Paluch]

Marcelo,

It seems that for some reason the router does not consider the route 74.5.124.2/32 via BGP neighbor as valid. There can be more causes for this but in any case, have a look into this output:

show ip bgp 74.5.124.2 255.255.255.255

Look for any clues that might force the router to believe that this route is unusable for some reason. You can also paste the output of that command here - it will be very helpful.

Best regards,

Peter

[MARCELO MATURO]

This is the show for another addres in the same situation:

sh ip route 75.2.64.5

Routing entry for 75.2.64.5/32

Known via "eigrp 500", distance 170, metric 2585856

Tag 10888, type external

Redistributing via eigrp 500, bgp 65200

Advertised by bgp 65200

Last update from 10.40.6.1 on GigabitEthernet0/3, 1d03h ago

Routing Descriptor Blocks:

* 10.40.6.1, from 10.40.6.1, 1d03h ago, via GigabitEthernet0/3

Route metric is 2585856, traffic share count is 1

Total delay is 1010 microseconds, minimum bandwidth is 1000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 118/255, Hops 1

Route tag 10888

---------------------------------------------------------------------------------

sh ip bgp 75.2.64.5 255.255.255.255

BGP routing table entry for 75.2.64.5/32, version 234499

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

Not advertised to any peer

10888 10888, (received & used)

172.16.255.13 from 172.16.255.13 (200.26.76.83)

Origin IGP, localpref 100, valid, external

Local

10.40.6.1 from 0.0.0.0 (77.252.1.10)

Origin incomplete, metric 2585856, localpref 100, weight 32768, valid, so

[Peter Paluch · Accepted solution]

Hello Marcelo,

Well, now it's clear.

Have a look at this document describing the BGP Best Path selection algorithm:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml

Specifically, have a look at the step 3: Prefer the path that was locally originated via a network or aggregate BGP subcommand or through redistribution from an IGP.

In your case, you have a network in your routing table that comes from EIGRP. This network is subsequently redistributed into BGP database. Now, the BGP goes over entries in its database and for each prefix, it tries to locate the best path. As the locally originated (injected) entries are preferred to entries coming from other BGP peers, the BGP considers these entries to be the best, and does not replace the routing table contents with the prefix information from external BGP peers. That is why the path to those prefixes through the BGP peer is not installed into your routing table because according to the BGP best path selection algorithm, it is currently not considered as the best path.

The question is whether you need to redistribute these networks from EIGRP back into BGP. If not then you should simply filter them out in the redistribution command using a suitable prefix-list or a route-map. In such case, the BGP will not consider these networks as locally injected, and will instead consider the best path to be the path through the BGP neighbor which will subsequently have a better administrative distance than the EIGRP.

Are you sure you need to redistribute those networks into BGP?

Best regards,

Peter

[kschleppenbach · Accepted solution]

Thanks Peter, Great explanation! I was investigating this exact same issue when I came across this post. I had seen the issue years back also and thought I resolved it by adjusting the admin distance on one or the other protocols but it doesn't sound like that will work here.

[MARCELO MATURO]

Thank´s Peter. Very complete answer. I decided to not redistributing eigrp. I created statics routes a redistributed this ones.

Marcelo