Just trying to reproduce this on a very small scenario:
I connected two routers, R1 and R2. I advertised the loopback network via iBGP and via EIGRP on both routers. As you can see in red, EIGRP as expected installed that on the routing table.

Question:Any idea why I did not get the RIB failure in this case? Very curious.

As you can see, the EIGRP

R1#sho run int lo 0
Building configuration...

Current configuration : 67 bytes
!
interface Loopback0
ip address 192.168.1.1 255.255.255.255
end

R1#show ip bgp
BGP table version is 4, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 155.0.1.0/24     0.0.0.0                  0         32768 i                     <== I got no RIB failure even though routes are advertised in both EIGRP and BGP.
* i                 155.0.1.2                0    100      0 i
* i192.168.1.0      155.0.1.2                0    100      0 i
*>                  0.0.0.0                  0         32768 i

R1#show ip route
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
       i - IS-IS, 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 not set

     155.0.0.0/24 is subnetted, 1 subnets
C       155.0.1.0 is directly connected, FastEthernet1/0
     192.168.1.0/32 is subnetted, 2 subnets
C       192.168.1.1 is directly connected, Loopback0
D       192.168.1.2 [90/156160] via 155.0.1.2, 00:07:55, FastEthernet1/0
R1#

R2#show run | b eigrp
router eigrp 100
network 155.0.1.0 0.0.0.255
network 192.168.1.2 0.0.0.0
no auto-summary
no eigrp log-neighbor-changes
!
router bgp 100
bgp log-neighbor-changes
network 155.0.1.0 mask 255.255.255.0
network 192.168.1.0
neighbor 155.0.1.1 remote-as 100
!
ip classless
no ip http server
ip pim bidir-enable
!
logging history size 500
!
line con 0
line aux 0
line vty 0 4
!
!

R2#show ip bgp
BGP table version is 3, local router ID is 192.168.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
* i155.0.1.0/24     155.0.1.1                0    100      0 i
*>                  0.0.0.0                  0         32768 i
* i192.168.1.0      155.0.1.1                0    100      0 i
*>                  0.0.0.0                  0         32768 i
R2#

anyone know what the expected behaviour when aggregating bgp prefixes please ...?

i.e. the originating more specific route is learned via OSPF

I am router running ospf and bgp

I am receiving /23 prefix via OSPF

I add the same /23 using network command under BGP

I add the aggregate-address summ-only cmd to change the /23 to /20

I don't think r> should appear for the summary prefix. One one of my gateways it does, and on another it doesn't. Its odd. Suspect bug or misconfig. Perhaps prefix-list problem...?

Just a note on the original scenario: I think that both routers have 155.4.0.0/24 as a directly connected subnet under their serial interfaces, so one router is sending to the other via BGP a common subnet. This is not something that can be manipulated e.g. by playing with ADs (connected are too powerful and need more violent measures to go away, but in most cases the problem, if one exists, is somewhere else).

In this last case you have 2 loopbacks with /32 masks. You advertise the same /24 using the "network 192.168.1.0" command on both routers. Because you omit the mask and auto-summary is enabled for BGP, route is advertised via iBGP by both routers (no need for exact match anymore, just a subset of the /24 suffices). The routing table output you posted from R1 shows /32's, not a /24 for 192.168.1.0.(Note also that the routing table of R1 shows that the subnet 155.0.1.0/24 is known via connected, and at least part of it has to be known by some other means other than BGP, since it is used in the BGP neighbor statements). If you advertised only a single /32 from each router (the one it has under it's own loopback) via EIGRP and BGP, we would have a better chance to see Edison's suggestion in action.

I attempted to do what Edison suggested; I advertised the routes on BGP only from R1. I still don't see the RIB failure.

Maria, thanks for the observation regarding the loopback /32 bit mask. Very good catch. Now I keep that consistent and advertise it as /32 under EIGRP and BGP. I also made sure BGP is no auto-summary.

If you have time to review this, please let me know why I can't produce a RIB failure.

R1#show run
Building configuration...

Current configuration : 911 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname R1
!
!
ip subnet-zero
!
!
!
!
!
!
interface Loopback0
ip address 192.168.1.1 255.255.255.255
!
interface FastEthernet0/0
no ip address
shutdown
duplex half
!
interface FastEthernet1/0
description R2
ip address 155.0.1.1 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/1
no ip address
shutdown
duplex auto
speed auto
!
!
!
router eigrp 100
network 155.0.1.0 0.0.0.255
network 192.168.1.1 0.0.0.0
no auto-summary
no eigrp log-neighbor-changes
!
router bgp 100
no synchronization
bgp log-neighbor-changes
network 155.0.1.0 mask 255.255.255.0
network 192.168.1.1 mask 255.255.255.255
neighbor 155.0.1.2 remote-as 100
no auto-summary
!
ip classless
no ip http server
ip pim bidir-enable
!
logging history size 500
!
line con 0
line aux 0
line vty 0 4
!
!
end

R1#show ip bgp
BGP table version is 11, local router ID is 192.168.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 155.0.1.0/24     0.0.0.0                  0         32768 i
*> 192.168.1.1/32   0.0.0.0                  0         32768 i
R1#show ip route
(omitted)
       P - periodic downloaded static route

Gateway of last resort is not set

     155.0.0.0/24 is subnetted, 1 subnets
C       155.0.1.0 is directly connected, FastEthernet1/0
     192.168.1.0/32 is subnetted, 2 subnets
C       192.168.1.1 is directly connected, Loopback0
D       192.168.1.2 [90/156160] via 155.0.1.2, 00:15:13, FastEthernet1/0
R1#

R2#show run
Building configuration...

Current configuration : 831 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname R2
!
!
ip subnet-zero
!
!
!
!
!
!
interface Loopback0
ip address 192.168.1.2 255.255.255.255
!
interface FastEthernet0/0
no ip address
shutdown
duplex half
!
interface FastEthernet1/0
description R1
ip address 155.0.1.2 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/1
no ip address
shutdown
duplex auto
speed auto
!
!
!
router eigrp 100
network 155.0.1.0 0.0.0.255
network 192.168.1.2 0.0.0.0
no auto-summary
no eigrp log-neighbor-changes
!

!- I am advertising networks into BGP only on R1.
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 155.0.1.1 remote-as 100
no auto-summary
!
ip classless
no ip http server
ip pim bidir-enable
!
logging history size 500
!
line con 0
line aux 0
line vty 0 4
!
!
end

R2#show ip bgp
BGP table version is 13, local router ID is 192.168.1.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*>i155.0.1.0/24     155.0.1.1                0    100      0 i
*>i192.168.1.1/32   155.0.1.1                0    100      0 i
R2#show ip route
(omitted)

Gateway of last resort is not set

     155.0.0.0/24 is subnetted, 1 subnets
C       155.0.1.0 is directly connected, FastEthernet1/0
     192.168.1.0/32 is subnetted, 2 subnets
D       192.168.1.1 [90/156160] via 155.0.1.1, 00:11:45, FastEthernet1/0
C       192.168.1.2 is directly connected, Loopback0
R2#

The circumstances that rib failures occur are not very well documented, and to be honest I never had the pleasure of exploring them in a production network. A good link that explains them is this:

http://blog.ioshints.info/2007/12/what-is-bgp-rib-failure.html

As you can see, the exact behavior depends on the IOS version you are running, so may I ask if the routers you use now to reproduce the original scenario are the same ones as used initially and what IOS version they are running?

No, the IOS version is different.

If we can't reproduce the problem that is totally fine. I am sure I will find several more rib failures to analyze in the months ahead.

Marlon

Your question asking how you can eliminate the Rib failures implies that you regard them as a problem that should be "solved". Assuming that there is good reason to advertise the same prefixes by EIGRP and by BGP then the Rib failure is really more of an informational event (BGP is reporting that the route that it learned is not inserted into the routing table because an equivalent EIGRP route is present and is preferable) than it is a problem.

If you change the environment and the prefix is advertised by BGP or by EIGRP (but not by both) then the Rib failure goes away.

HTH

Rick

Hi Rick,

I agree with you that this "failure" doesn't necessarily indicate a problem. I used in a previous post of mine in this thread the phrase "the problem, if one exists, is somewhere else", to say this, but maybe I was not very clear. However, I also had in mind a previous thread that Marlon had opened, in which the BGP route and the IGP route seemed to have some disagreement about the correct path through the network towards the destination. So, it doesn't matter which protocol installs the route, as long as it is a correct (or preferred) one that ultimately leads to the destination.

Kind Regards,

Maria