Date: Tue, 15 Jan 2008 15:16:04 -0500 From: "William Herrin" <herrin-nanog@dirtside.com> Subject: Re: BGP Filtering
On Jan 15, 2008 12:51 PM, Dave Israel <davei@otd.com> wrote:
I think I understand what you want, and you don't want it. If you receive a route for, say, 204.91.0.0/16, 204.91.0.0/17, and 204.91.128.0/17, you want to drop the /17s and just care about the /16. But a change in topology does not generally result in a complete update of the BGP table. Route changes result in route adds and draws, not a flood event. So if you forgot about the /17s and just kept the /16, and the /16 was subsequently withdrawn, your router would not magically remember that it had /17s to route to as well.
Dave,
That's half-true.
The "routing table" is comprised of two components: the Routing Information Base (RIB) and the Forwarding Information Base (FIB). The RIB sits in slow, cheap memory and contains routes and metrics for every route as announced by every neighbor. The FIB sits in fast, expensive memory and contains the currently "best" route for each destination. The FIB is built by choosing the best routes from the RIB. Packet-forwarding decisions are made by consulting the FIB.
Opportunistically filtering routes from the RIB would have exactly the problem you point out: routing updates are incremental. The knowledge that the /16 has been withdrawn may not accompany the knowledge that the /17s are available.
Opportunistically filtering more-specific routes from the FIB, however, could be very valuable at the edge of the DFZ. If Cisco supported such filtering, those Sup2's could have another few years of life left in them. With 512m ram in a two-transit provider scenario a Sup2 could handle upwards of 1M routes in the RIB. Unfortunately, they can only handle 244k routes in the FIB.
Ben, coming back to your question: I don't think there is a way to make the software filter the routes inserted into the FIB. I don't see a reason why it couldn't be programmed to do that. But the fine folks at Cisco didn't see fit to write that software. Its a pity 'cause it would be very useful.
This leads to one 'obviuous' approach to the matter. a smart BGP 'proxy' that accepts 'full' data from all the peers, manages the RIB and outputs =only= the current 'most desired' subset of routes to the target router. In _that_ router the RIB and FIB are going to be equivalent, This gets the 'hog' part of things off into 'commodity' hardware, and where you can afford to burn CPU cycles implementing 'smarts' to compensate for other people's 'dumbs'. At a quick glance it looks like this would not be terribly difficult to build, using Quagga/Zebra as a base platform.
Hi, That is where I got to last night with my cogitations before I feel asleep. Ben -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Robert Bonomi Sent: 16 January 2008 01:26 To: nanog@merit.edu Subject: Re: BGP Filtering
Date: Tue, 15 Jan 2008 15:16:04 -0500 From: "William Herrin" <herrin-nanog@dirtside.com> Subject: Re: BGP Filtering
On Jan 15, 2008 12:51 PM, Dave Israel <davei@otd.com> wrote:
I think I understand what you want, and you don't want it. If you receive a route for, say, 204.91.0.0/16, 204.91.0.0/17, and 204.91.128.0/17, you want to drop the /17s and just care about the /16. But a change in topology does not generally result in a complete update of the BGP table. Route changes result in route adds and draws, not a flood event. So if you forgot about the /17s and just kept the /16, and the /16 was subsequently withdrawn, your router would not magically remember
that it had /17s to route to as well.
Dave,
That's half-true.
The "routing table" is comprised of two components: the Routing Information Base (RIB) and the Forwarding Information Base (FIB). The RIB sits in slow, cheap memory and contains routes and metrics for every route as announced by every neighbor. The FIB sits in fast, expensive memory and contains the currently "best" route for each destination. The FIB is built by choosing the best routes from the RIB. Packet-forwarding decisions are made by consulting the FIB.
Opportunistically filtering routes from the RIB would have exactly the
problem you point out: routing updates are incremental. The knowledge that the /16 has been withdrawn may not accompany the knowledge that the /17s are available.
Opportunistically filtering more-specific routes from the FIB, however, could be very valuable at the edge of the DFZ. If Cisco supported such filtering, those Sup2's could have another few years of
life left in them. With 512m ram in a two-transit provider scenario a Sup2 could handle upwards of 1M routes in the RIB. Unfortunately, they
can only handle 244k routes in the FIB.
Ben, coming back to your question: I don't think there is a way to make the software filter the routes inserted into the FIB. I don't see
a reason why it couldn't be programmed to do that. But the fine folks at Cisco didn't see fit to write that software. Its a pity 'cause it would be very useful.
This leads to one 'obviuous' approach to the matter. a smart BGP 'proxy' that accepts 'full' data from all the peers, manages the RIB and outputs =only= the current 'most desired' subset of routes to the target router. In _that_ router the RIB and FIB are going to be equivalent, This gets the 'hog' part of things off into 'commodity' hardware, and where you can afford to burn CPU cycles implementing 'smarts' to compensate for other people's 'dumbs'. At a quick glance it looks like this would not be terribly difficult to build, using Quagga/Zebra as a base platform.
participants (2)
-
Ben Butler -
Robert Bonomi