Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Rib failure when aggregating

I have eigrp running between my core switch and my wan router and all my /24 networks in the core are present in the wan router's routing table. Under my bgp config I have individual network statements for each of these /24 networks and then I have a couple aggregate address 172.21.4.0/22 and 172.21.8.0/22 with the summary only keyword. The summarized address appears as a rib failure in the sh ip bgp rib-failure and sh ip bgp peer x.x.x.x advertised-routes output. However, on remote ends the router appears in the routing table of those remote routers. I have a static route pointing to the null interface for each of the summary addresses because I was told you had to have a matching route in your routing table for an aggregate route. I'll be extending this summary address range to 172.21.1.0/20 and was thinking about summarizing eigrp on the uplink interface from my core to the wan router,

int vlan 1

ip summary-address eigrp 100 172.21.1.0 255.255.240.0

Then the only route the wan router would know about for any of the more specific /24s would be known via the summarized /20 route. It was my understanding of BGP that as long as their was an IGP route present, in this case eigrp advertising 172.21.1.0/20, that I could then enter a network 172.21.1.0 mask 255.255.240.0 summary-only under my bgp process without any negative impact. Is this correct and could anyone explain the rib failures I'm getting?

thank you,

Bill

1 ACCEPTED SOLUTION

Accepted Solutions
New Member

Re: Rib failure when aggregating

Right, for the BGP aggregate to make it into the RIB, there can't already exist the same route from another protocol with a better AD. You could accomplish this many ways, based upon your network needs, such as having BGP be the only creator of the summary, or fiddling with your administrative distances.

Correct as to the summary, as long as there is a more specific prefix that is a part of the summary existing in the BGP table, there will be no problem creating the aggregate. So, if you have 172.21.1.0/24, BGP would not have a problem creating a 172.21.0.0/20 aggregate, for example.

3 REPLIES
New Member

Re: Rib failure when aggregating

BGP RIB failures can be caused by a few different problems, but you are definitely encountering it here because there already exists a route in the table with a higher administrative distance than BGP.

Your static routes will be in the table with an AD of 1, so the corresponding BGP summary routes with an AD of 200 will not make it into the RIB, hence the RIB failure. The same would happen with your EIGRP summary routes, which have an AD of 5.

Also, you don't need a static route that matches the summary you are creating, as long as there already exists in the BGP table a subset of that summary address, it should work.

New Member

Re: Rib failure when aggregating

So my summary routes need to have the best AD distance in order to make it into the RIB? How would I make that happen?

In regard to the static route question, do you mean if I have a statement like

network 172.21.1.0 mask 255.255.255.0

under my bgp routing process that I will then be fine with using the summary?

New Member

Re: Rib failure when aggregating

Right, for the BGP aggregate to make it into the RIB, there can't already exist the same route from another protocol with a better AD. You could accomplish this many ways, based upon your network needs, such as having BGP be the only creator of the summary, or fiddling with your administrative distances.

Correct as to the summary, as long as there is a more specific prefix that is a part of the summary existing in the BGP table, there will be no problem creating the aggregate. So, if you have 172.21.1.0/24, BGP would not have a problem creating a 172.21.0.0/20 aggregate, for example.

368
Views
0
Helpful
3
Replies
CreatePlease to create content