|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Erblichs (erblichs
EARTHLINK.NET)Date: Tue Jun 18 2002 - 16:08:35 CDT
My two cents...
It is possible that with database overflow, that some routers
will actually have more LSAs in their database than others.
I am thinking about Opaque LSAs (RFC 2370) allowing opaque
capable routers to contain opaque LSAs.
Assuming that these three LSA types are enough to force a
database overflow, it is concieveable to drop all the adjacencies
with the opaque bit set and to re-establish the adjacency without
having the opaque bit set... It may make sense to keep a
counter of opaque LSAs in the lsdb.. Other LSA counters probably
couldn't hurt either..
Be careful if the adjacency is dropped for less than router
dead interval that the change in the opaque bits are seen. A
cleaner change is drop the adjacency for enough time (greater
than routerdeadinterval) and re-establish the adjacency.
To properly do this, it also concievable to wipe away just
the opaque LSAs, before the opaque bit is set, and to keep
the other ones.. Less time to re-establish the full adjs..
Once all the full adjs are re-established, then run the spf
calculation...
Mitchell Erblich
===================
Hi Amit,
If you note Section 1. in the RFC it clearly states that the value of
ospfExtLsdbLimit should be the same in all routers in
the routing domain. So the ASBR which is actually attempting to put the
external LSA in the domain will be the first one
to overflow, so it will not originate the LSA itself(the situation you
describe will not occur itself).
This RFC is useful, especially cuz we have the entire BGP routing table
acually pumped in into the OSPF domain
inadvertently(which supposedly happens a few times, on the live
networks, a year).
I guess if such a state exists when there are routers which cannot keep
the entire database, the network topology/route
leaking/routers need a change instead.
Thanks,
Vishwas
-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun
YAHOO.COM]
Sent: Tuesday, June 18, 2002 7:35 PM
To: OSPF
DISCUSS.MICROSOFT.COM
Subject: Re: OSPF Retransmission Doubt
Hi Vishwas!
Actually after reading the RFC 1765 only i got this
doubt.Here i feel once the
OSPFEXTLSDBLinit variable is exceeded the router should indicate
other routers that its database is
full and they should not keep on retransmitting the LSA which will
clog the n/w bandwidth.Once the
router comes out of the database overflow state it should indicate
to the other router that now they
should send the LSA.
What do you say about this??
Regards
Amit
"Manral, Vishwas" <VishwasM
NETPLANE.COM> wrote:
Hi Amit,
You may like to look at the RFC1765 - OSPF Database
Overflow.
http://www.ietf.org/rfc/rfc1765.txt This RFC tells a way to
deal with such
overflow when it occurs in OSPF.
Also as the RFC lists as enhancements, if the number of
summary LSA's
increases we could as well flush type3/4 also and originate
default routes
in the domain instead, which could lead to suboptimal
routing or blackholing
however.
However in ur case if a router does not accept and
acknowledge an LSA, it
will be continuously retransmitted as long as the adjacency
is up. If this
is not done, the databases would have no way to come back to
synch as the
adjacency itself would not be broken.
Thanks,
Vishwas
-----Original Message-----
From: Amit Srivastava [mailto:ospfisfun
YAHOO.COM]
Sent: Tuesday, June 18, 2002 5:26 PM
To: OSPF
DISCUSS.MICROSOFT.COM!
Subject: OSPF Retransmission Doubt
Hi All,
I have the doubt which is described below:-
Suppose a router is there whose database is full.Now
it can send and receive hello packets but discards any
new LSA coming to it(as database is full) and hence it
will not ack that LSA.Now my doubt is that RFC 2328
says the the retransmission will continue till the
adjacency is broken.
Does that mean if the database does not have space
for accomodating the new LSA infinite number of
retransmission would result???
Regards
Amit
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]