<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
William Herrin wrote:
<blockquote
cite="mid:3c3e3fca0801151216h3206872bx5d9a1b159e08901a@mail.gmail.com"
type="cite">
<pre wrap="">On Jan 15, 2008 12:51 PM, Dave Israel <a class="moz-txt-link-rfc2396E" href="mailto:davei@otd.com"><davei@otd.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> 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.
</pre>
</blockquote>
<pre wrap=""><!---->
Dave,
That's half-true.
</pre>
</blockquote>
[discussion of FIB vs RIB deleted]<br>
<br>
But, as you said yourself:<br>
<blockquote
cite="mid:3c3e3fca0801151216h3206872bx5d9a1b159e08901a@mail.gmail.com"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
Ergo, why I didn't discuss the FIB in my email. If you want to filter
routes, you generally have to filter them at the RIB.<br>
<br>
How you move data from the RIB to the FIB is one of those questions
that keep router engineers up all night. The transfer must be fast,
reliable, and cheap on the CPU. Often, this means keeping logic out of
it. A paradigm is decided upon early, and if it takes ten years to
actually come back to haunt them, they haven't done too badly. Fixing
something that far down in the nuts and bolts isn't easy. (I am not
saying the presence of a revenue-generating hardware fix doesn't
influence the decision not to make a risky change to the software; I'm
just saying there's a lot of grey area to play in.)<br>
<br>
-Dave<br>
</body>
</html>