Subject: Re: [OSPF] OSPFquestion

From: Vishwas Manral <[email-masked]>
Date: Thu, 18 Jun 2009 12:40:33 -0700

Hi Hitesh,

The problem is in the DB Exchange process. The point is either an LSA
is requested for which is not in the database or an LSA is got which
is also on the sending neighbor link state request list. With BadLSReq
the neigbor state should go to Exstart (which seems to be wrong too in
your implementation).

RFC2328 would be a good read for this. Maybe someone else in the OPSF
list has some other suggestions.

Thanks,
Vishwas
________________________________________
From: Hitesh N. Patel [mailto:[email-masked]]
Sent: Thursday, June 18, 2009 11:47 AM
To: vishwas
Subject: OSPFquestion

Hi Vishwas,

I have been working on OSPF & have observed several documents by you
on OSPF & thought to pose you a question..Can you suggest something to
resolve BadLSReq, our LSA database size is <1000 & have point to point
link between pair of Router, however RT1 shows FULL state while RT2
remains stuck in LOADING state & after 7-8 minutes it shows BadLSReq
message & transitions to LOADING to EXTRART state & then it quickly
converge from LOADING to FULL. Also, sometimes I see OSPF : Drop
Packet messages too frequently.

Is there any reading that you can suggest for this OSPF behaviour?

Thanks,
Hitesh Patel

---

From: Mitchell Erblich <[email-masked]>
Date: Thu, 18 Jun 2009 13:23:59 -0700

First,

	Turn on debuging.

	Tell us whether you are running v2 or v3 OSPF.

	Drop messages are due to buffer overflow or MTU mismatch or
	unknown LSA type or auth failure or capability not understood or
	a DNA (do not age LSA) not supported or LSA max age or LSA
	corruption or ......  etc..

	Hopefully the debug prints out what one nbr specified in its LSDB,
	then what was REQuested, and then the breakdown for the BAD
	REQUEST.

	Either way, the message/LSA should initially be resent when not
	acked.

	I said initially because some routers will retry X number
	of times with a nbr and then give up. So, you may want to
	first take down the interface, turn on debugging, then bring
	back the interface.

	FYI: All draft, experimental, and informational OSPF RFCs
	should be found within the www.ietf.org website.

	Mitchell Erblich
	================

On Jun 18, 2009, at 12:40 PM, Vishwas Manral wrote:

> _______________________________________________
> OSPF mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ospf