paul [Sat, 18 Jan 2003 00:12:02 +0000 (00:12 +0000)]
Date: Fri, 20 Dec 2002 17:28:45 +0900
From: Masahiko Endo <endo@suri.co.jp> Reply-To: zebra@zebra.org
To: zebra@zebra.org Cc: kunihiro@zebra.org, yokota@kddlabs.co.jp
Subject: [zebra 16823] [PATCH] Bugfix and new feature in Opaque-LSA
handling.
1.1 When an opaque LSA is being removed from (or added to) the LSDB,
it does not mean a change in network topology. Therefore, SPF
recalculation should not be triggered in that case.
There was an assertion failure problem "assert (rn && rn->info)"
inside the function "ospf_ase_incremental_update()", because
the upper function "ospf_lsa_maxage_walker_remover()" called it
when a type-11 opaque LSA is removed due to MaxAge.
1.2 Type-9 LSA is defined to have "link-local" flooding scope.
In the Database exchange procedure with a new neighbor, a type-9
LSA was added in the database summary of a DD message, even if
the link is different from the one that have bound to.
2. Feature enhancements
2.1 Though a "wildcard" concept to handle type-9/10/11 LSAs altogether
has introduced about a year ago, it was only a symbol definition
and actual handling mechanism was not implemented. Now it works.
paul [Fri, 17 Jan 2003 23:48:42 +0000 (23:48 +0000)]
From endo@suri.co.jp Fri Jan 17 23:36:30 2003
Date: Fri, 20 Dec 2002 17:58:43 +0900
From: Masahiko Endo <endo@suri.co.jp> Reply-To: zebra@zebra.org
To: zebra@zebra.org Cc: kunihiro@zebra.org
Subject: [zebra 16824] [PATCH] nsm_kill_neighbor
[ The following text is in the "ISO-2022-JP" character set. ]
[ Your display is set for the "ISO-8859-1" character set. ]
[ Some characters may be displayed incorrectly. ]
Hi Ishiguro-san,
Here is my problem analysis against the case that the ospfd crashes
when an interface is brought down.
When the ospfd receives a ZEBRA message "ZEBRA_INTERFACE_DOWN" from
zebra daemon, the ospfd performs bunch of ospf-interface cleanup for
the notified zebra-interface.
There are cases that neighbor instance "nbr", which will be removed
afterward, may scheduled in the NSM thread event queue. And when the
NSM event thread is fired, dereference for this already freed "nbr"
pointer causes SIGSEGV.
Please take a look at following timeline of processing sequences.
paul [Fri, 17 Jan 2003 23:47:00 +0000 (23:47 +0000)]
From havanna_moon@gmx.net Fri Jan 17 23:37:49 2003
Date: Sat, 11 Jan 2003 23:26:28 +0100 (CET)
From: Yon Uriarte <havanna_moon@gmx.net>
To: "the list(tm) Zebra" <zebra@zebra.org>
Subject: [zebra 17217] [PATCH] show thread CPU
Hi,
a little patch from the 'stupid preprocessor tricks' collection to record
thread statistics.
Usage: "show thread cpu [r][w][t][e][x]"
Output Fields: self explaining I hope. Type is one of RWTEX for:
Read, Write (fd threads), Timer, Event, Execute.
Overhead vs. vanilla zebra: almost nothing. Vanilla CVS zebra already
collects thread run times.
Caveats: Under linux getrusage has a granularity of 10ms, which is almost
useless in this case. Run ./configure, edit config.h and comment out
"#define HAVE_RUSAGE", this way it will use getimeofday which has a much
better granularity. IMHO this is better, as cooperative threads are
effectively running during all that wall time (dont care if CPU
utilization was 3% or 99% during the time the thread was running (an
effective rusage combined with getimeofday could give that info)).
Maybe someone can give tips for other platforms on API granularity.
TODO: change some of the calls to thread_add_$KIND to
funcname_thread_add_$KIND with a meaningfull funcname, so users will get a
better idea of what's going on.
projects / matthieu / frr.git / log