<HTML><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText558 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Wow so I mis understood the quoted email. Kill me why don't ya. </FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Richard A Steenbergen<BR><B>Sent:</B> Tue 8/8/2006 4:12 PM<BR><B>To:</B> Joseph Jackson<BR><B>Cc:</B> Tom Samplonius; foundry-nsp@puck.nether.net<BR><B>Subject:</B> Re: [f-nsp] NetIron MLX Experience..<BR></FONT><BR></DIV>
<DIV><PRE style="WORD-WRAP: break-word">On Tue, Aug 08, 2006 at 03:26:56PM -0700, Joseph Jackson wrote:
>
> Foundry does NOT store the full routing table in the FIB it only stores
> the most specific. The way I understand it, (as explained to me by a
> foundry SE). Is that any changes to the RIB get populated to the FIB
> only if a more specific route is found.
Uh right, thats why it is called a FORWARDING information base. Only the
data that is used for forwarding is installed in the FIB, but the point is
that it is pre-populated with forwarding data for the entire table rather
than a "cache" which is only populated on demand. If there is a less
specific route which changes but it is covered by more specific routes
which do not change, nothing in the forwarding table changes. The same
holds true for routes which are not selected as best path.
The problem with historic non-prepopulated lookup methods is that the
first lookup to a destination which has never been encountered before must
take the "slow path" through the CPU, resulting in non-deterministic
performance, and Very Bad Things (tm) when random destination traffic
(think worms scanning the Internet for new victims) hits your network. By
prepopulating the FIB, get consistent lookup performance to any
destination.
--
Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
</PRE></DIV></BODY></HTML>