[36618] in North American Network Operators' Group
Re: gigabit router (was Re: Getting a "portable" /19 or /20)
daemon@ATHENA.MIT.EDU (Brett Frankenberger)
Wed Apr 11 17:58:10 2001
Message-Id: <200104112133.QAA23522@rbfux.rbfnet.com>
To: mdz@csh.rit.edu (Matt Zimmerman)
Date: Wed, 11 Apr 2001 16:33:53 -0500 (CDT)
From: "Brett Frankenberger" <rbf@rbfnet.com>
Cc: nanog@merit.edu
In-Reply-To: <20010411164727.B647@alcor.net> from "Matt Zimmerman" at Apr 11, 2001 04:47:28 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Errors-To: owner-nanog-outgoing@merit.edu
> I think Alex was referring to internal consistency within the router (between
> linecards), not external consistency. For example, if linecard X believes that
> a packet should be forwarded to linecard Y, but linecard Y's forwarding table
> is older than X's, Y could misforward the packet, causing a forwarding loop or
> a dropped packet. Thus, it can be the case that neither the old path nor the
> new path is taken.
>
> Yes, there are ways to approach this problem, but it is a problem that
> central-forwarding systems will not have.
It's a problem that few distributed-forwarding implementations have.
Doing a full destination-IP lookup on the incoming and outgoing
linecard is wasteful. In most implementations, the incoming line card
determines the outgoing interface and neighbor and informs the
destination linecard of that. The destination line card then sends it
out to whomever the source line card specified, without actually
doing a lookup in it's FIB.
Consistency is still a problem, particular the case of line cards being
inconsistent with the central processor for non-transient periods of
time. (As in, they're out of sync, but nothing knows it and no update
is in process, so they are just going to be out of sync forever.)
-- Brett
