| Age | Commit message (Collapse) | Author |
|---|
|
problems with NSSA are resolved, and we can determine whether this had any
point.
|
|
It didnt solve a particular problem of Hasso's, but i'm committing it just
for posterities sakes, so i dont lose it (i'll revert it immediately).
|
|
To: zebra@zebra.org
Subject: [zebra 18648] [PATCH] Selforiginated Type-7 LSA's are not flushed
from lsdb
|
|
Date: 2003-04-10 14:32:31 +0200 (Thu, 10 Apr 2003)
New Revision: 212
Modified:
zebra-ag/trunk/ospfd/ospf_lsa.c
Log:
I've fixed a small opaque lsa bug which got triggered when deleting opaque
lsa of type 11. It used area->ospf->.. when area was null. This was replaced
by a ospf = ospf_lookyp(); ospf->...
|
|
|
|
* Sync to Zebra CVS
* Fix lib/thread.h leak
* Fix small Opaque LSA leak
* Do not configure OSPF interfaces for secondary addresses
* vtysh fixes from Hasso
* Dave Watson's missing ntohs fix
|
|
Subject: [zebra 18573] PATCH ospfd: byte order error in assert statement
I found a bug in the ospfd code tickled this morning by a Type 1
LSA with exactly 62 entries (LSA length of 768, or 0x0300).
A missing ntohs in ospf_lsa.c:ospf_lsa_different() causes an assert
statement to fail, stopping ospfd.
> assert (l1->data->length > OSPF_LSA_HEADER_SIZE);
So, a length of type 768 turns into a length of 3 which is
obviously less than 20.
David
|
|
* sync to latest zebra CVS
* spec file: updated and added define for ospf-api/client
NB: OSPF-API has been broken by the zebra.org changes, which
has added struct ospf * as a new arg to many functions
|
|
|
|
|
|
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.
----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
Changes 2002.12.20
1. Bug fixes
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.
|
|
[zebra 16681] OSPF NSSA Patches
|
|
|
|
|
|
|
