No subject
Wed Feb 11 23:00:50 2004
Return-Path: xorp-cvs-admin@icir.org
Delivery-Date: Wed, 11 Feb 2004 23:01:32 -0800
Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14])
by tigger.icir.org (8.12.9p1/8.12.8) with ESMTP id i1C71Wmu098117
for <atanu@tigger.icir.org>; Wed, 11 Feb 2004 23:01:32 -0800 (PST)
(envelope-from xorp-cvs-admin@icir.org)
Received: from fruitcake.icsi.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11])
by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i1C71RSi079835;
Wed, 11 Feb 2004 23:01:27 -0800 (PST)
(envelope-from xorp-cvs-admin@icir.org)
Received: from fruitcake.icsi.Berkeley.EDU (localhost [127.0.0.1])
by fruitcake.icsi.Berkeley.EDU (8.12.10/8.12.9) with ESMTP id i1C7117g006562;
Wed, 11 Feb 2004 23:01:01 -0800 (PST)
Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14])
by fruitcake.icsi.Berkeley.EDU (8.12.10/8.12.9) with ESMTP id i1C70o7g006552
for <xorp-cvs@icsi.berkeley.edu>; Wed, 11 Feb 2004 23:00:50 -0800 (PST)
Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68])
by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id i1C70oSi079824
for <xorp-cvs@icir.org>; Wed, 11 Feb 2004 23:00:50 -0800 (PST)
(envelope-from atanu@icir.org)
Received: from xorpc.icir.org (localhost [127.0.0.1])
by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i1C70oAF034554
for <xorp-cvs@icir.org>; Wed, 11 Feb 2004 23:00:50 -0800 (PST)
(envelope-from atanu@xorpc.icir.org)
Received: (from atanu@localhost)
by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i1C70ocg034553;
Wed, 11 Feb 2004 23:00:50 -0800 (PST)
(envelope-from atanu)
From: Atanu Ghosh <atanu@icir.org>
Message-Id: <200402120700.i1C70ocg034553@xorpc.icir.org>
Date: Wed, 11 Feb 2004 23:00:50 ()
To: xorp-cvs@icir.org
Reply-To: atanu@icir.org
Subject: [Xorp-cvs] XORP cvs commit: xorp/bgp/ dump_iterators.cc dump_iterators.hh plumbing.cc plumbing.hh route_table_deletion.hh route_table_dump.cc route_table_dump.hh xorp/bgp/harness/ test_peering2.sh
Sender: xorp-cvs-admin@icir.org
Errors-To: xorp-cvs-admin@icir.org
X-BeenThere: xorp-cvs@icir.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:xorp-cvs-request@icir.org?subject=help>
List-Post: <mailto:xorp-cvs@icir.org>
List-Subscribe: <http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs>,
<mailto:xorp-cvs-request@icir.org?subject=subscribe>
List-Id: Mailing list for XORP CVS commit messages <xorp-cvs.icir.org>
List-Unsubscribe: <http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs>,
<mailto:xorp-cvs-request@icir.org?subject=unsubscribe>
CVSROOT: /usr/local/www/data/cvs
Module name: xorp
Repository: xorp/bgp/harness/
Changes by: atanu@xorpc.icir.org. 04/02/11 23:00:50
Modified files:
xorp/bgp/: dump_iterators.cc dump_iterators.hh plumbing.cc
plumbing.hh route_table_deletion.hh
route_table_dump.cc route_table_dump.hh
xorp/bgp/harness/: test_peering2.sh
Log message:
BGP processes update messages by passing them through a series of
route tables. The route tables are mostly statically plumbed
together. There are however two dynamic tables the "dump table" and
the "deletion table". When a session is established the "dump table"
is responsible for passing all currently winning routes to this new
peer. Once all the routes have been sent to the peer the "dump table"
removes itself from the plumbing. The "deletion table" is used to
remove routes when a session goes down. The "deletion table" also
removes itself when all the routes sent by this peer have been
removed.
There are a number of issues with the interactions between the two
tables. The specific problem we are trying to address is the case of a
"deletion table" existing and hence sending deletes when a new peering
is established. Previously when a new peering was established the
"dump table" would be made aware of all live sessions, but not of any
of the sessions which were down but still sending deletes. If a
session goes down (causing a "deletion table" to be installed) while
another another session is being brought up (by a "dump table"). Then
the "dump table" has to deal specially with the deletes being sent by
the "delete table". The "dump table" has to either supress or pass
through the deletes, but most importantly it has to stay around until
the "deletion table" has finished sending deletes. It is important to
note that any unneccesary deletes that make it to the downstream cache
will cause an XLOG_ASSERT. As deletes must have corresponding state
in the cache.
Previously a new session being brought up while a deletion was in
progress would fail. As the new peer was unaware of the downed peer
any deletes that came from this peer would appear to be from a new
peer. So the "dump table" would pass them through and the cache would
signal an inconsistency by calling XLOG_ASSERT.
The fix is to tell the "dump table" about any "delete tables" that are
running when the "dump table" is instantiated. This fixes all but one
of the regression tests.
_______________________________________________
Xorp-cvs mailing list
Xorp-cvs@icir.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs