From wwwrun@core3.amsl.com Tue Jun 2 14:37:04 2009 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id DD08C3A6BA2; Tue, 2 Jun 2009 14:37:03 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090602213703.DD08C3A6BA2@core3.amsl.com> Date: Tue, 2 Jun 2009 14:37:03 -0700 (PDT) Cc: ospf@ietf.org Subject: [OSPF] Last Call: draft-ietf-ospf-dynamic-hostname (Dynamic Hostname Exchange Mechanism for OSPF) to Proposed Standard X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 21:37:04 -0000 The IESG has received a request from the Open Shortest Path First IGP WG (ospf) to consider the following document: - 'Dynamic Hostname Exchange Mechanism for OSPF ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-06-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ospf-dynamic-hostname-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17203&rfc_flag=0 From erblichs@earthlink.net Tue Jun 2 16:29:01 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BED53A6897 for ; Tue, 2 Jun 2009 16:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIheawuKaVU7 for ; Tue, 2 Jun 2009 16:28:59 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 841B83A697A for ; Tue, 2 Jun 2009 16:28:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=S24JFhNS+n0uBCBVXqbLta4wrilKQKeJxbUaszs3lvsX0pVOL8UE7W+w1A4TpM8B; h=Received:Message-Id:From:To:Content-Type:Mime-Version:Subject:Date:References:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [74.95.9.18] (helo=[172.21.1.150]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1MBdPg-0006zt-8c for ospf@ietf.org; Tue, 02 Jun 2009 19:29:00 -0400 Message-Id: From: Mitchell Erblich To: ospf@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-132--609833168 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 2 Jun 2009 16:28:59 -0700 References: <18FAF702-3684-4EFD-A191-805617029C15@earthlink.net> X-Mailer: Apple Mail (2.930.3) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec7987bc6527f09a071ab33b546d54c4c8f0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 74.95.9.18 Subject: Re: [OSPF] Last Call: draft-ietf-ospf-dynamic-hostname (Dynamic Hostname Exchange Mechanism for OSPF) to Proposed Standard X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 23:29:01 -0000 --Apple-Mail-132--609833168 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Begin forwarded message: > From: Mitchell Erblich > Date: June 2, 2009 4:06:53 PM PDT > To: ietf@ietf.org > Subject: Re: [OSPF] Last Call: draft-ietf-ospf-dynamic-hostname > (Dynamic Hostname Exchange Mechanism for OSPF) to Proposed Standard > > Group, > > Here are a few stupid/nit questions, > > 1) What do you do with host naming collisions? > > 2) Is a blank "string" blank equal to a "string"? > > 3) Is the hostname case sensitive? > > 4) Since the hostnames are "human readable", would > a backspace within the name make logical sense? > > 5) Don't some system implement x chars per tab, > then how do we show a consistent hostname? > > 6) If bell is included, does the system need to create > a sound each time the name is displayed? > > 7) If the router is localized to a different country, wouldn't > a logical hostname representation be able to support > multi-character and multi-byte foreign languages? > > 8) Underline support? > > Thus, IMO, someone needs to re-write part of this to equal > http(s) URL type representation? or only alphanumeric chars > > And specify some sort of left/right printing justification and > a way to deal with non printable chars.. > > Mitchell Erblich > =================== > > > On Jun 2, 2009, at 2:37 PM, The IESG wrote: > >> The IESG has received a request from the Open Shortest Path First >> IGP WG >> (ospf) to consider the following document: >> >> - 'Dynamic Hostname Exchange Mechanism for OSPF ' >> as a Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to >> the >> ietf@ietf.org mailing lists by 2009-06-16. Exceptionally, >> comments may be sent to iesg@ietf.org instead. In either case, please >> retain the beginning of the Subject line to allow automated sorting. >> >> The file can be obtained via >> http://www.ietf.org/internet-drafts/draft-ietf-ospf-dynamic-hostname-03.txt >> >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17203&rfc_flag=0 >> >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf > --Apple-Mail-132--609833168 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = Mitchell Erblich <erblichs@earthlink.net><= /div>
Date: June 2, 2009 4:06:53 PM = PDT
Subject: = Re: [OSPF] Last Call: draft-ietf-ospf-dynamic-hostname = (Dynamic Hostname Exchange Mechanism for OSPF) to Proposed = Standard
Here are a few stupid/nit = questions,

1) What do you do with host = naming collisions?

2) Is a blank "string" blank = equal to a "string"?

3) Is the hostname case = sensitive?

4) Since the hostnames are "human = readable", would
   a backspace = within the name make logical sense?

5) Don't some system implement x = chars per tab,
   then how do we = show a consistent hostname?

6) If bell is included, does the = system need to create
   a sound each = time the name is displayed?

7) If the router is localized to = a different country, wouldn't
   a logical = hostname representation be able to support
=    multi-character and multi-byte foreign = languages?

8) Underline = support?

= = Thus, IMO, someone needs to re-write part of this to = equal
= = http(s) URL type representation? or only alphanumeric = chars

= = And specify some sort of left/right printing justification = and
= = a way to deal with non printable chars..

Mitchell = Erblich
= = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


On = Jun 2, 2009, at 2:37 PM, The IESG wrote:

The IESG has received a request from the Open Shortest = Path First IGP WG
(ospf) to = consider the following document:

- 'Dynamic = Hostname Exchange Mechanism for OSPF '
 <draft-ietf-ospf-dynamic-hostname-03.txt> as a = Proposed Standard

The IESG plans = to make a decision in the next few weeks, and = solicits
final comments on = this action.  Please send substantive comments to = the
ietf@ietf.org mailing lists by = 2009-06-16. Exceptionally,
comments may be sent to iesg@ietf.org instead. In either case, = please
retain the beginning of = the Subject line to allow automated sorting.

The file can be = obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ospf-dynamic-hos= tname-03.txt


IESG discussion = can be tracked via
https://datatracker.ietf.org/public/= pidtracker.cgi?command=3Dview_id&dTag=3D17203&rfc_flag=3D0
=

_______________________________________________
OSPF mailing = list
OSPF@ietf.org
https://www.ietf.org/m= ailman/listinfo/ospf


= = --Apple-Mail-132--609833168-- From svenkata@google.com Thu Jun 4 12:59:09 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 266E53A702E for ; Thu, 4 Jun 2009 12:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUrq09scdiyv for ; Thu, 4 Jun 2009 12:59:07 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id F1EDE3A697F for ; Thu, 4 Jun 2009 12:59:06 -0700 (PDT) Received: from spaceape24.eur.corp.google.com (spaceape24.eur.corp.google.com [172.28.16.76]) by smtp-out.google.com with ESMTP id n54Jx8i7031497 for ; Thu, 4 Jun 2009 20:59:08 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1244145548; bh=wAysNBpJ7RbWmG0TpnY7c9D9Ic0=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-System-Of-Record; b=J jontXncH+HeVBCBsPSC7XEZQl8F340C3PMIajuWOobIt1cTkOfvd9xZQoYrKY++r47I DZkfXHtccSEnGxeH7w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=TuIQfY4QBl8YZRQJpKNEcPHRulZV7xBv4ScO3a4Nj0etcKG/UaUbHeT3WwXKE7xNT idSTsyN1ym4wCQNA53hjw== Received: from pzk42 (pzk42.prod.google.com [10.243.19.170]) by spaceape24.eur.corp.google.com with ESMTP id n54JweHG024520 for ; Thu, 4 Jun 2009 12:59:06 -0700 Received: by pzk42 with SMTP id 42so983636pzk.21 for ; Thu, 04 Jun 2009 12:59:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.9.9 with SMTP id m9mr947848wfi.41.1244145545936; Thu, 04 Jun 2009 12:59:05 -0700 (PDT) In-Reply-To: References: <18FAF702-3684-4EFD-A191-805617029C15@earthlink.net> Date: Thu, 4 Jun 2009 12:59:05 -0700 Message-ID: From: Subbaiah Venkata To: Mitchell Erblich Content-Type: multipart/alternative; boundary=001636e90a80507e15046b8b35da X-System-Of-Record: true Cc: ospf@ietf.org Subject: Re: [OSPF] Last Call: draft-ietf-ospf-dynamic-hostname (Dynamic Hostname Exchange Mechanism for OSPF) to Proposed Standard X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 19:59:09 -0000 --001636e90a80507e15046b8b35da Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Mitchell, Good questions. Comments inline. Some of which we already covered in the draft. On Tue, Jun 2, 2009 at 4:28 PM, Mitchell Erblich wrote: > > > Begin forwarded message: > > *From: *Mitchell Erblich > *Date: *June 2, 2009 4:06:53 PM PDT > *To: *ietf@ietf.org > *Subject: **Re: [OSPF] Last Call: draft-ietf-ospf-dynamic-hostname > (Dynamic Hostname Exchange Mechanism for OSPF) to Proposed Standard* > > Group, > > Here are a few stupid/nit questions, > > 1) What do you do with host naming collisions? > > Protocols as such doesn't find hostname collisions for the advertising routers. It is beyond the scope of the draft. I suggest user or configuration manager should take care of the collisions. > > 2) Is a blank "string" blank equal to a "string"? > > Yes. > > > 3) Is the hostname case sensitive? > > Yes because the encoding is in ASCII. > > > 4) Since the hostnames are "human readable", would > a backspace within the name make logical sense? > > Anything that is in 7-bit ASCII is supported. Meaning and interpretation of the string is left to user. In the next revision we are adding the following statement to clear ambiguity: This symbolic name can be the FQDN for the router, it can be a subset of the FQDN, or it can be any string operators want to use for the router. The use of FQDN or a subset of it is strongly recommended. The content of this value is a domain name, see [RFC2181]. > > > 5) Don't some system implement x chars per tab, > then how do we show a consistent hostname? > > Interpretation of the tab depends on the display setting. So you are right, you may not get consistent hostname if tabs are used where sender and receiver display settings are different. I would suggest not use tabs. Simple human readable characters like an FQDN are good enough. > > > 6) If bell is included, does the system need to create > a sound each time the name is displayed? > > Same as above. > > 7) If the router is localized to a different country, wouldn't > a logical hostname representation be able to support > multi-character and multi-byte foreign languages? > > This is covered in the draft in section 3.1 The Value field is encoded in 7-bit ASCII. If a user-interface for configuring or displaying this field permits Unicode characters, that user-interface is responsible for applying the ToASCII and/or ToUnicode algorithm as described in [RFC3490] to achieve the correct format for transmission or display. > 8) Underline support? > > Anything that is in 7-bit ASCII is supported. > > > Thus, IMO, someone needs to re-write part of this to equal > http(s) URL type representation? or only alphanumeric chars > > And specify some sort of left/right printing justification and > a way to deal with non printable chars.. > > Meaning and interpretation of the value string is beyond the scope of this draft. It is left to configuration management for flexibility. Anything that is in 7-bit ASCII is supported. Including human readable and unreadable. But we recommend FQDN or subset. Hope this helps, Venkata > > Mitchell Erblich > =================== > > > > On Jun 2, 2009, at 2:37 PM, The IESG wrote: > > The IESG has received a request from the Open Shortest Path First IGP WG > > (ospf) to consider the following document: > > > - 'Dynamic Hostname Exchange Mechanism for OSPF ' > > as a Proposed Standard > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2009-06-16. Exceptionally, > > comments may be sent to iesg@ietf.org instead. In either case, please > > retain the beginning of the Subject line to allow automated sorting. > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-dynamic-hostname-03.txt > > > > IESG discussion can be tracked via > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17203&rfc_flag=0 > > > _______________________________________________ > > OSPF mailing list > > OSPF@ietf.org > > https://www.ietf.org/mailman/listinfo/ospf > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > --001636e90a80507e15046b8b35da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mitchell,

Good questions. Comments inline. Some of which we alrea= dy covered in the draft.


On Tue, Jun = 2, 2009 at 4:28 PM, Mitchell Erblich <erblichs@earthlink.net><= /span> wrote:

Begin forwarded message:

From: Mitc= hell Erblich <erblichs@earthlink.net>
Date: June= 2, 2009 4:06:53 PM PDT
Subject: = <= b>Re: [OSPF] Last Call: draft-ietf-ospf-dynamic-hostname (Dynamic Hostname = Exchange Mechanism for OSPF) to Proposed Standard

Group,<= br>
Here are a few stupid/nit = questions,

1) What do you do with host naming collisions?
Protocols as such doesn= 9;t find hostname collisions for the advertising routers.
It is beyond t= he scope of the draft. I suggest user or=A0 configuration manager should ta= ke care of the collisions.
=A0

2) Is a blank "string&qu= ot; blank equal to a "string"?
Yes.


3) Is the hostname case sensitive?
Yes because the encoding is in ASCII.
<= blockquote type=3D"cite">


4) Since the hostnames are "human readable", would =A0=A0=A0a backspace within the name make logical sense?
Anything that is in 7-bit ASCII = is supported.=A0 Meaning and interpretation of the string is left to user.<= br>In the next revision we are adding the following statement to clear ambi= guity:

=A0=A0 This symboli= c name can be the FQDN for the
=A0=A0 router, it can be a subset of= the FQDN, or it can be any string
=A0=A0 operators want to use for the router.= =A0 The use of FQDN or a subset of
=A0=A0 it is strongly recommended.=A0 The c= ontent of this value is a domain
=A0=A0 name, see = [RFC2181].


5) Don't some system implement x chars per tab, =A0=A0=A0then how do we show a consistent hostname?

Interpretation of the tab de= pends on the display setting. So you are right, you may not get consistent = hostname
if tabs are used where sender and receiver display settings are= different. I would suggest not use tabs.
Simple human readable characters like an FQDN are good enough.


6) If bell is included, does the system need to create
=A0=A0=A0a sound each time the name is displayed?
Same as above.
<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

7) If the router is localized to a different country, wou= ldn't
=A0=A0=A0a logical hostname representation be able t= o support
=A0=A0=A0multi-character and multi-byte foreign languages?

This is covered in the dr= aft in section 3.1

   The V=
alue field is encoded in 7-bit ASCII.  If a user-interface for
   config=
uring or displaying this field permits Unicode characters, that
   user-=
interface is responsible for applying the ToASCII and/or

   ToUnicode algorithm as described in [RFC3490] to achieve the correct
=
   format for transmission or display.
=A0

8) Underline support?=

Anything that is in 7-= bit ASCII is supported.
<= blockquote type=3D"cite">


Thus, IMO, someone needs to re-write part of this to equal
= http(s) URL type representation? or only alphanumeric chars

And specify some sort of left/right printing justification and=
a way to deal with non printable chars..
Meaning and interpretation= of the value string is beyond the scope of this draft.
It is left to co= nfiguration management for flexibility. Anything that is in 7-bit ASCII is = supported.
Including human readable and unreadable. But we recommend FQDN or subset.=A0
Hope this helps,
Venkata

Mitchell Erblich
<= span style=3D"white-space: pre;"> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



On Jun 2, 2009, at 2:= 37 PM, The IESG wrote:

The IESG has receiv= ed a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:

- 'Dynamic Hostnam= e Exchange Mechanism for OSPF '
=A0<draft-ietf-ospf-dynamic-hostname-03.txt> as a Proposed Standard<= br>

The IESG plans to make a decision in the next few weeks, and soli= cits
final comments on this action. =A0Pl= ease send substantive comments to the
ietf@ietf.org m= ailing lists by 2009-06-16. Exceptionally,
comments may be sent to iesg@ietf.org instead. In either= case, please
retain the beginnin= g of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft= -ietf-ospf-dynamic-hostname-03.txt


IESG discussion can be tr= acked via
https://datatracker.ietf.org/public/pidt= racker.cgi?command=3Dview_id&dTag=3D17203&rfc_flag=3D0

_______________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/osp= f



_______= ________________________________________
OSPF mailing list
OSPF@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ospf


--001636e90a80507e15046b8b35da-- From wwwrun@core3.amsl.com Tue Jun 9 09:19:56 2009 Return-Path: X-Original-To: ospf@ietf.org Delivered-To: ospf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 916A93A6A2F; Tue, 9 Jun 2009 09:19:56 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090609161956.916A93A6A2F@core3.amsl.com> Date: Tue, 9 Jun 2009 09:19:56 -0700 (PDT) Cc: ospf mailing list , ospf chair , Internet Architecture Board , RFC Editor Subject: [OSPF] Protocol Action: 'OSPF Link-local Signaling' to Proposed Standard X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 16:19:56 -0000 The IESG has approved the following document: - 'OSPF Link-local Signaling ' as a Proposed Standard This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are Ross Callon and Adrian Farrel. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-lls-08.txt Technical Summary This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. Working Group Summary This draft represents the promotion of RFC 4813 from experimental to proposed standard. It also extends LLS to OSPFv3 which is simpler since authentication is handled via IPsec. Document Quality Passes idnits. No issues. Personnel Dave Ward was the original responsible AD. Ross Callon is the current responsible AD. Acee Lindem is the document shepherd. From vishwas.ietf@gmail.com Thu Jun 18 12:48:25 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A35D3A6A4B for ; Thu, 18 Jun 2009 12:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jofMooGtLCZR for ; Thu, 18 Jun 2009 12:48:24 -0700 (PDT) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id A824D3A67F9 for ; Thu, 18 Jun 2009 12:48:24 -0700 (PDT) Received: by gxk10 with SMTP id 10so2071356gxk.13 for ; Thu, 18 Jun 2009 12:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=FjfXjypsqTSxZ7cL4vA1mXl3BGxHaKAevfyqNF9udgg=; b=XpGajBnwdeI5pxNIEDaJcc6gmS/6TeQgIsIF9pK+AtgjXq+4biKB1B/IjASRhIoYoJ Tga0FkU8sbVA0alUIPCMUdcU7j5D/JWX9G1NOOV19vef9lYC6N8XXItWUwHC74LDA7uo 5d0lxVOqLRU9BlcN8dnfI12/dngvb/JSFev5g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=FwlJOxsCFQOw5q0WU8naiT31z1W9niEKFLcDwwaSPJGDc4wg0IiTsk+rI78v1CJdYc jKODvTiq7oXoyfZCK14PeoA3+ul04OjSZCH67W2Mcm3dmDPzfXEXBstkTo8hPghL1+mN B/7sSC9f0ZXQYJBUhW4XvZYEcrKJK+Lv2bXVM= MIME-Version: 1.0 Received: by 10.151.155.13 with SMTP id h13mr4190736ybo.332.1245354033684; Thu, 18 Jun 2009 12:40:33 -0700 (PDT) Date: Thu, 18 Jun 2009 12:40:33 -0700 Message-ID: <77ead0ec0906181240k6b96eb87v529e1c49191151d3@mail.gmail.com> From: Vishwas Manral To: hiteshonline@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: OSPF List Subject: Re: [OSPF] OSPFquestion X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 19:48:25 -0000 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:hiteshonline@gmail.com] 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 erblichs@earthlink.net Thu Jun 18 13:24:06 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5413A6802 for ; Thu, 18 Jun 2009 13:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SFND-c9vFSZ for ; Thu, 18 Jun 2009 13:24:05 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id E6C513A68BD for ; Thu, 18 Jun 2009 13:23:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=q0qjmbgVqzpv8jBlURHjMIMYMizRfKLf4e1CW3ouHV0VGIggAqHqvss+MqMrdBiT; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.234.127.54] (helo=[10.0.1.3]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1MHO9R-0004rq-AW; Thu, 18 Jun 2009 16:24:01 -0400 Message-Id: From: Mitchell Erblich To: Vishwas Manral In-Reply-To: <77ead0ec0906181240k6b96eb87v529e1c49191151d3@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 18 Jun 2009 13:23:59 -0700 References: <77ead0ec0906181240k6b96eb87v529e1c49191151d3@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec7956395f08da5625abe3c65990a276b344350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.234.127.54 Cc: OSPF List , hiteshonline@gmail.com Subject: Re: [OSPF] OSPFquestion X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 20:24:06 -0000 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: > 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:hiteshonline@gmail.com] > 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 > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf From erblichs@earthlink.net Thu Jun 18 16:30:37 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5EB43A68E7 for ; Thu, 18 Jun 2009 16:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.459 X-Spam-Level: X-Spam-Status: No, score=-1.459 tagged_above=-999 required=5 tests=[AWL=-1.141, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3xdZCAVsVOz for ; Thu, 18 Jun 2009 16:30:36 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id F10043A682B for ; Thu, 18 Jun 2009 16:30:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Pa7XRNH97hyakocjjGZA9fn5UT4xTyzzvJOBxVq2nZJgFZnnlXcy1C40NM2qWhxH; h=Received:Message-Id:From:To:Content-Type:Mime-Version:Subject:Date:References:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.234.127.54] (helo=[10.0.1.3]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1MHR4C-0001C2-5s for ospf@ietf.org; Thu, 18 Jun 2009 19:30:48 -0400 Message-Id: From: Mitchell Erblich To: OSPF List Content-Type: multipart/alternative; boundary=Apple-Mail-187-772674684 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 18 Jun 2009 16:30:46 -0700 References: <41FB5E90-B7AC-4FB5-ABFE-06A394B22FE0@earthlink.net> X-Mailer: Apple Mail (2.930.3) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec7946c16a0adb7ae5d3767ab7476eb439ab350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.234.127.54 Subject: [OSPF] Fwd: OSPFquestion X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 23:30:38 -0000 --Apple-Mail-187-772674684 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Begin forwarded message: > From: Mitchell Erblich > Date: June 18, 2009 4:27:54 PM PDT > To: "Hitesh N. Patel" > Subject: Re: [OSPF] OSPFquestion > > Hi, > > Are you using routers from an established company because > this seems like a fundamental problem? > > If you are looking on a time line and the first bad things are > BadLSReq message on one device & SeqNumberMismatch > on other device. > > then stop... > > Why the Bad Seguence Number? from rfc 2328 > > > > ExStart > If the received packet matches one of the following cases, > then the neighbor state machine should be executed with > the > event NegotiationDone (causing the state to transition to > Exchange), the packet's Options field should be recorded > in > the neighbor structure's Neighbor Options field and the > packet should be accepted as next in sequence and > processed > further (see below). Otherwise, the packet should be > ignored. > > o The initialize(I), more (M) and master(MS) bits are > set, > the contents of the packet are empty, and the > neighbor's > Router ID is larger than the router's own. In this > case > the router is now Slave. Set the master/slave bit to > slave, and set the neighbor data structure's DD > sequence > number to that specified by the master. > > o The initialize(I) and master(MS) bits are off, the > packet's DD sequence number equals the neighbor data > structure's DD sequence number (indicating > acknowledgment) and the neighbor's Router ID is > smaller > than the router's own. In this case the router is > Master. > > Exchange > Duplicate Database Description packets are discarded by > the > master, and cause the slave to retransmit the last > Database > Description packet that it had sent. Otherwise (the packet > is not a duplicate): > > o If the state of the MS-bit is inconsistent with the > master/slave state of the connection, generate the > neighbor event SeqNumberMismatch and stop processing > the > packet. > > o If the initialize(I) bit is set, generate the neighbor > event SeqNumberMismatch and stop processing the > packet. > > Mitchell Erblich > ============================= > > > > On Jun 18, 2009, at 3:27 PM, Hitesh N. Patel wrote: > >> Hi Mitchell, Vishwas, >> >> I have verified MTU & mtu is configured correctly. also, I am >> establishing OSPF v2 point to point neighborship. >> >> I also observed immediately after seeing this message, both the >> device progress from EXCHANGE to EXSTART state, & OSPF converges >> quickly (within 20 seconds) from then on..however it takes about >> 14-15 minutes for device to detect BadLSReq & SeqNumberMismatch >> error, till then both the device remains busy doing LSA EXCHANGE. >> >> I also observed one more thing, that while I was resetting OSPF on >> one device by using clear ip ospf xxx process command, it takes >> above mentioned process to restore FULL Adjacency but if I reset >> OSPF by doing "shut" & "no shut" on interfaces (as OSPF >> neighborship is between point to point network), OSPF convergence >> time is about 20 seconds. >> >> So, after reviewing above fact, it looks to me that, when I do >> "clear ip ospf", OSPF does clear the LSA database however it >> probably mark a delete flag for the LSAs & advertise it to neighbor >> before actually deleting it, so probably when both the devices are >> in EXCHANGE state, they do receive the "about to get deleted" LSA >> details & event of BadLSReq or SeqNumberMismatch error occures when >> neighbor receives actual LSRequest for the deleted LSA. Also, I >> observed that out of 2 device, other than the one of which I am >> executing "clear ip ospf" command is continueously sending LSA >> Update packets. so, I really doubt that doing a "clear ip ospf" >> when LSAs are being received is the right thing..as compared to >> "shut" & "no shut" for verifying OSPF convergence time. Do let me >> know your thoughts on this.. >> >> Thanks so much for sharing this technical issue. >> >> Regards, >> Hitesh >> >> >> >> >> >> On Thu, Jun 18, 2009 at 4:23 PM, Mitchell Erblich > > wrote: >> 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: >> >> 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:hiteshonline@gmail.com] >> 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 >> _______________________________________________ >> OSPF mailing list >> OSPF@ietf.org >> https://www.ietf.org/mailman/listinfo/ospf >> >> > --Apple-Mail-187-772674684 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = Mitchell Erblich <erblichs@earthlink.net><= /div>
Date: June 18, 2009 4:27:54 PM = PDT
To: "Hitesh N. Patel" <hiteshonline@gmail.com><= /div>
Subject: Re: [OSPF] = OSPFquestion

Are you using routers from an = established company because
this seems like a fundamental = problem?

If you are looking on a time line = and the first bad things are 
BadLSReq = message on one device & SeqNumberMismatch 
on other = device.
then = stop...

Why the = Bad Seguence Number? from rfc 2328

=

ExStart
            If the received packet =
matches one of the following cases,
            then the neighbor state machine should be executed with the
            event NegotiationDone (causing the state to transition to
            Exchange), the packet's Options field should be recorded in
            the neighbor structure's Neighbor Options field and the
            packet should be accepted as next in sequence and processed
            further (see below).  Otherwise, the packet should be
            ignored.

            o   The initialize(I), more (M) and master(MS) bits are set,
                the contents of the packet are empty, and the neighbor's
                Router ID is larger than the router's own.  In this case
                the router is now Slave.  Set the master/slave bit to
                slave, and set the neighbor data structure's DD sequence
                number to that specified by the master.

            o   The initialize(I) and master(MS) bits are off, the
                packet's DD sequence number equals the neighbor data
                structure's DD sequence number (indicating
                acknowledgment) and the neighbor's Router ID is smaller
                than the router's own.  In this case the router is
                Master.

        Exchange
            Duplicate Database Description packets are discarded by the
            master, and cause the slave to retransmit the last Database
            Description packet that it had sent. Otherwise (the packet
            is not a duplicate):

            o   If the state of the MS-bit is inconsistent with the
                master/slave state of the connection, generate the
                neighbor event SeqNumberMismatch and stop processing the
                packet.

            o   If the initialize(I) bit is set, generate the neighbor
                event SeqNumberMismatch and stop processing the packet.

Mitchell = Erblich
= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D


<= /div>

On Jun 18, 2009, at 3:27 PM, Hitesh N. Patel = wrote:

Hi Mitchell, Vishwas,
 
I = have verified MTU & mtu is configured correctly. also, I am = establishing OSPF v2 point to point neighborship.

I also = observed  immediately after seeing this message, both the device = progress from EXCHANGE to EXSTART state, & OSPF converges quickly = (within 20 seconds) from then on..however it takes about 14-15 minutes = for device to detect BadLSReq & SeqNumberMismatch error, till then = both the device remains busy doing LSA EXCHANGE.
=
 
I also observed one more thing, that while I was = resetting OSPF on one device by using clear ip ospf xxx process command, = it takes above mentioned process to restore FULL Adjacency but if I = reset OSPF by doing "shut" & "no shut" on interfaces (as OSPF = neighborship is between point to point network), OSPF convergence time = is  about 20 seconds.
 
So, after = reviewing above fact, it looks to me that, when I do "clear ip ospf", = OSPF does clear the LSA database however it probably mark a delete flag = for the LSAs & advertise it to neighbor before actually deleting it, = so probably when both the devices are in EXCHANGE state, they do receive = the "about to get deleted" LSA details & event of BadLSReq or = SeqNumberMismatch error occures when neighbor receives actual LSRequest = for the deleted LSA. Also, I observed that out of 2 device, other than = the one of which I am executing "clear ip ospf" command is continueously = sending LSA Update packets. so, I really doubt that doing a "clear ip = ospf" when LSAs are being received is the right thing..as compared to = "shut" & "no shut" for verifying OSPF convergence time. Do let me = know your thoughts on this..
 
Thanks so much = for sharing this technical issue.
 
=
Regards,
Hitesh
 
=
 
 

 
On Thu, Jun 18, 2009 at 4:23 PM, Mitchell Erblich = <erblichs@earthlink.net> = wrote:
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
       =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D


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

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:hiteshonline@gmail.com]
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
_______________________________________________
= OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf
=



= --Apple-Mail-187-772674684-- From SPaul@ixiacom.com Thu Jun 18 23:10:35 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1334A3A6B0A for ; Thu, 18 Jun 2009 23:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.837 X-Spam-Level: X-Spam-Status: No, score=0.837 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c03xFmC4Qkis for ; Thu, 18 Jun 2009 23:10:23 -0700 (PDT) Received: from ixqw-mail-out.ixiacom.com (ixqw-mail-out.ixiacom.com [66.77.12.12]) by core3.amsl.com (Postfix) with ESMTP id 456AB3A6A92 for ; Thu, 18 Jun 2009 23:10:23 -0700 (PDT) Received: from ixcaexch07.ixiacom.com ([fe80:0000:0000:0000:351c:8718:2.9.179.114]) by ixqw-hc2.ixiacom.com ([10.210.5.16]) with mapi; Thu, 18 Jun 2009 23:10:36 -0700 From: Santanu Paul To: "ospf@ietf.org" Date: Thu, 18 Jun 2009 23:10:32 -0700 Thread-Topic: OSPFquestion Thread-Index: AcnwbNW+98Agj68CQ8+5mcM4lYCOGgALZFKg Message-ID: <716209EC190CA740BA799AC4ACCBFB5D15D008FD35@IXCAEXCH07.ixiacom.com> References: <41FB5E90-B7AC-4FB5-ABFE-06A394B22FE0@earthlink.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_716209EC190CA740BA799AC4ACCBFB5D15D008FD35IXCAEXCH07ixi_" MIME-Version: 1.0 Subject: [OSPF] OSPFquestion X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 06:10:35 -0000 --_000_716209EC190CA740BA799AC4ACCBFB5D15D008FD35IXCAEXCH07ixi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable however RT1 shows FULL state while RT2 remains stuck in LOADING state & aft= er 7-8 minutes it shows BadLSReq message & transitions to LOADING to EXTRAR= T state & then it quickly converge from LOADING to FULL. [Santanu] Assuming, RT1 has around 1000 LSAs and RT2 has none, so it is exp= ected that RT1 will go to FULL state fast, while RT2 will be in loading to = synchronize database, however 7-8 minutes for <1000 LSAs seems too high, yo= u need to do a packet capture to see what is going on. Check in the capture= what LSA headers RT1 sent, and what request RT2 has sent, if any request i= s not corresponding to the LSA headers it has received in DBD RT1 will gene= rate BadLSReq I also observed immediately after seeing this message, both the device pro= gress from EXCHANGE to EXSTART state, & OSPF converges quickly (within 20 s= econds) from then on..however it takes about 14-15 minutes for device to de= tect BadLSReq & SeqNumberMismatch error, till then both the device remains = busy doing LSA EXCHANGE. [Santanu] Could not understand the part "however it takes about 14-15 minut= es for device to detect BadLSReq & SeqNumberMismatch error" could you elabo= rate, is it happening after going to FULL? I also observed one more thing, that while I was resetting OSPF on one devi= ce by using clear ip ospf xxx process command, it takes above mentioned pro= cess to restore FULL Adjacency but if I reset OSPF by doing "shut" & "no sh= ut" on interfaces (as OSPF neighborship is between point to point network),= OSPF convergence time is about 20 seconds. [Santanu] Not sure what router you are using, but generally "clear process"= , clears LSDB but "shut and no-shut" does not, if that is the case "shut no= shut" will converge quickly as you might not see LS requests at all. So, after reviewing above fact, it looks to me that, when I do "clear ip os= pf", OSPF does clear the LSA database however it probably mark a delete fla= g for the LSAs & advertise it to neighbor before actually deleting it, so p= robably when both the devices are in EXCHANGE state, they do receive the "a= bout to get deleted" LSA details & event of BadLSReq or SeqNumberMismatch e= rror occures when neighbor receives actual LSRequest for the deleted LSA. A= lso, I observed that out of 2 device, other than the one of which I am exec= uting "clear ip ospf" command is continueously sending LSA Update packets. = so, I really doubt that doing a "clear ip ospf" when LSAs are being receive= d is the right thing..as compared to "shut" & "no shut" for verifying OSPF = convergence time. Do let me know your thoughts on this.. [Santanu] Verify capturing the packet and router database. Thanks and Regards, Santanu Paul ________________________________ From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Mit= chell Erblich Sent: Friday, June 19, 2009 5:01 AM To: OSPF List Subject: [OSPF] Fwd: OSPFquestion Begin forwarded message: From: Mitchell Erblich > Date: June 18, 2009 4:27:54 PM PDT To: "Hitesh N. Patel" > Subject: Re: [OSPF] OSPFquestion Hi, Are you using routers from an established company because this seems like a fundamental problem? If you are looking on a time line and the first bad things are BadLSReq message on one device & SeqNumberMismatch on other device. then stop... Why the Bad Seguence Number? from rfc 2328 ExStart If the received packet matches one of the following cases, then the neighbor state machine should be executed with the event NegotiationDone (causing the state to transition to Exchange), the packet's Options field should be recorded in the neighbor structure's Neighbor Options field and the packet should be accepted as next in sequence and processed further (see below). Otherwise, the packet should be ignored. o The initialize(I), more (M) and master(MS) bits are set, the contents of the packet are empty, and the neighbor's Router ID is larger than the router's own. In this case the router is now Slave. Set the master/slave bit to slave, and set the neighbor data structure's DD sequence number to that specified by the master. o The initialize(I) and master(MS) bits are off, the packet's DD sequence number equals the neighbor data structure's DD sequence number (indicating acknowledgment) and the neighbor's Router ID is smaller than the router's own. In this case the router is Master. Exchange Duplicate Database Description packets are discarded by the master, and cause the slave to retransmit the last Database Description packet that it had sent. Otherwise (the packet is not a duplicate): o If the state of the MS-bit is inconsistent with the master/slave state of the connection, generate the neighbor event SeqNumberMismatch and stop processing the packet. o If the initialize(I) bit is set, generate the neighbor event SeqNumberMismatch and stop processing the packet. Mitchell Erblich =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D On Jun 18, 2009, at 3:27 PM, Hitesh N. Patel wrote: Hi Mitchell, Vishwas, I have verified MTU & mtu is configured correctly. also, I am establishing = OSPF v2 point to point neighborship. I also observed immediately after seeing this message, both the device pro= gress from EXCHANGE to EXSTART state, & OSPF converges quickly (within 20 s= econds) from then on..however it takes about 14-15 minutes for device to de= tect BadLSReq & SeqNumberMismatch error, till then both the device remains = busy doing LSA EXCHANGE. I also observed one more thing, that while I was resetting OSPF on one devi= ce by using clear ip ospf xxx process command, it takes above mentioned pro= cess to restore FULL Adjacency but if I reset OSPF by doing "shut" & "no sh= ut" on interfaces (as OSPF neighborship is between point to point network),= OSPF convergence time is about 20 seconds. So, after reviewing above fact, it looks to me that, when I do "clear ip os= pf", OSPF does clear the LSA database however it probably mark a delete fla= g for the LSAs & advertise it to neighbor before actually deleting it, so p= robably when both the devices are in EXCHANGE state, they do receive the "a= bout to get deleted" LSA details & event of BadLSReq or SeqNumberMismatch e= rror occures when neighbor receives actual LSRequest for the deleted LSA. A= lso, I observed that out of 2 device, other than the one of which I am exec= uting "clear ip ospf" command is continueously sending LSA Update packets. = so, I really doubt that doing a "clear ip ospf" when LSAs are being receive= d is the right thing..as compared to "shut" & "no shut" for verifying OSPF = convergence time. Do let me know your thoughts on this.. Thanks so much for sharing this technical issue. Regards, Hitesh On Thu, Jun 18, 2009 at 4:23 PM, Mitchell Erblich > wrote: 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 websit= e. Mitchell Erblich =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Jun 18, 2009, at 12:40 PM, Vishwas Manral wrote: 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:hiteshonline@gmail.com] 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 _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf --_000_716209EC190CA740BA799AC4ACCBFB5D15D008FD35IXCAEXCH07ixi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

however RT1 shows FULL state while RT2 remains stuck in LOADING sta= te & after 7-8 minutes it shows BadLSReq message & transitions to LOAD= ING to EXTRART state & then it quickly converge from LOADING to FULL.

 

[Santanu] Assuming, RT1 has around 100= 0 LSAs and RT2 has none, so it is expected that RT1 will go to FULL state fas= t, while RT2 will be in loading to synchronize database, however 7-8 minutes f= or <1000 LSAs seems too high, you need to do a packet capture to see what i= s going on. Check in the capture what LSA headers RT1 sent, and what request = RT2 has sent, if any request is not corresponding to the LSA headers it has received in DBD RT1 will generate BadLSReq

      &n= bsp;    

 

I also observed  immediately after seeing this message, both t= he device progress from EXCHANGE to EXSTART state, & OSPF converges quickl= y (within 20 seconds) from then on..however it takes about 14-15 minutes for device to detect BadLSReq & SeqNumberMismatch error, till then both the device remains busy doing LSA EXCHANGE.<= /p>

 

[Santanu] Could not understand the part “however it takes abo= ut 14-15 minutes for device to detect BadLSReq & SeqNumberMismatch error&#= 8221; could you elaborate, is it happening after going to FULL?=

 

I also observed one more thing, that while I was resetting OSPF on = one device by using clear ip ospf xxx process command, it takes above mentioned process to restore FULL Adjacency but if I reset OSPF by doing "shut&q= uot; & "no shut" on interfaces (as OSPF neighborship is between po= int to point network), OSPF convergence time is  about 20 seconds.

 

[Santanu] Not sure what router you are using, but generally “= clear process”, clears LSDB but “shut and no-shut” does not, if that is the case “shut no shut” will converge quickly as you mi= ght not see LS requests at all.

 

So, after reviewing above fact, it looks to me that, when I do "clear ip ospf", OSPF does clear the LSA database however it prob= ably mark a delete flag for the LSAs & advertise it to neighbor before actua= lly deleting it, so probably when both the devices are in EXCHANGE state, they = do receive the "about to get deleted" LSA details & event of BadLSReq or SeqNumberMismatch error occures when neighbor receives actual LSRequest for the deleted LSA. Also, I observed that out of 2 device, other than the one of which I am executing "clear ip ospf" command is continueously sending LSA Update packets. so, I really doubt that doing a "clear ip ospf" when LSAs are being received is the right thing..= as compared to "shut" & "no shut" for verifying OSPF convergence time. Do let me know your thoughts on this..<= /font>

 

[Santanu] Verify capturing the packet and router database.

 

Thanks and Regards,

Santanu Paul

From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Mitchell Erblich
Sent: Friday, June 19, 2009 = 5:01 AM
To: OSPF List
Subject: [OSPF] Fwd: OSPFque= stion

 

 

 

Begin forwarded message:



From: Mitchell Erblich <erblichs@earthlink.net>

Date: June 18, 2009 4:27:54 PM PDT

To: "Hitesh N. Patel" <hiteshonline@gmail.com>

Subject: Re: [OSPF] OSPFquestion

 

Hi,

 

   = ;         Are you using routers from an established company because

   = ;         this seems like a fundamental problem?

 

   = ;         If you are looking on a time line and the first bad things are 

   = ;         BadL= SReq message on one device & SeqNumberMismatch 

   = ;         on other device.

   = ;        

   = ;         then stop...

 

   = ;         Why the Bad Seguence Number? from rfc 2328

 

   = ;        

 

   = ;         ExStart

   &nb=
sp;        If the received packet matche=
s one of the following cases,
  =
          then the neighbor st=
ate machine should be executed with the
=
  =
          event NegotiationDon=
e (causing the state to transition to
  =
          Exchange), the packe=
t's Options field should be recorded in
=
  =
          the neighbor structu=
re's Neighbor Options field and the
  =
          packet should be acc=
epted as next in sequence and processed
=
  =
          further (see below).=
  Otherwise, the packet should be
<=
font
size=3D2 face=3D"Courier New">  =
          ignored.<=
/span>
 <=
/o:p>
  =
          o   The in=
itialize(I), more (M) and master(MS) bits are set,=

  =
            &nb=
sp; the contents of the packet are empty, and the neighbor's
  =
            &nb=
sp; Router ID is larger than the router's own.  In this case
  =
            &nb=
sp; the router is now Slave.  Set the master/slave bit to
  =
            &nb=
sp; slave, and set the neighbor data structure's DD sequence
   =
;            &n=
bsp;number to that specified by the master.
<= pre> <= /o:p>
  =
          o   The in=
itialize(I) and master(MS) bits are off, the
= 
  =
            &nb=
sp; packet's DD sequence number equals the neighbor data<=
/font>
  =
            &nb=
sp; structure's DD sequence number (indicating
  =
             &n=
bsp;acknowledgment) and the neighbor's Router ID is smaller
  =
            &nb=
sp; than the router's own.  In this case the router is
  =
            &nb=
sp; Master.
 <=
/o:p>
  =
      Exchange
=
  =
          Duplicate Database D=
escription packets are discarded by the
=
  =
          master, and cause th=
e slave to retransmit the last Database
=
  =
          Description packet t=
hat it had sent. Otherwise (the packet
<=
font
size=3D2 face=3D"Courier New">  =
          is not a duplicate):=

 <=
/o:p>
  =
          o   If the=
 state of the MS-bit is inconsistent with the
  =
            &nb=
sp; master/slave state of the connection, generate the
  =
            &nb=
sp; neighbor event SeqNumberMismatch and stop processing the
  =
            &nb=
sp; packet.
 <=
/o:p>
  =
          o   If the=
 initialize(I) bit is set, generate the neighbor
  =
            &nb=
sp; event SeqNumberMismatch and stop processing the packet.



















   =
       Mitchell Erblich













   =
       =3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D













 









 









 









On Jun 18, 2009, at 3:27 PM, Hitesh N. Patel wrote:

















Hi Mitchell, Vishwas,









 









I have verified MTU & mtu is configured correctly. also, I am
establishing OSPF v2 point to point neighborship.<=
/p>










I also observed  immediately after seeing this message, both the devic=
e
progress from EXCHANGE to EXSTART state, & OSPF converges quickly (with=
in
20 seconds) from then on..however it takes about 14-15 minutes for device t=
o
detect BadLSReq & SeqNumberMismatch error, till then both the device
remains busy doing LSA EXCHANGE.









 









I also observed one more thing, that while I was resetting OSPF on =
one
device by using clear ip ospf xxx process command, it takes above mentioned
process to restore FULL Adjacency but if I reset OSPF by doing "shut&q=
uot;
& "no shut" on interfaces (as OSPF neighborship is between po=
int
to point network), OSPF convergence time is  about 20 seconds.









 









So, after reviewing above fact, it looks to me that, when I do
"clear ip ospf", OSPF does clear the LSA database however it prob=
ably
mark a delete flag for the LSAs & advertise it to neighbor before actua=
lly
deleting it, so probably when both the devices are in EXCHANGE state, they =
do
receive the "about to get deleted" LSA details & event of
BadLSReq or SeqNumberMismatch error occures when neighbor receives actual
LSRequest for the deleted LSA. Also, I observed that out of 2 device, other
than the one of which I am executing "clear ip ospf" command is
continueously sending LSA Update packets. so, I really doubt that doing a
"clear ip ospf" when LSAs are being received is the right thing..=
as
compared to "shut" & "no shut" for verifying OSPF
convergence time. Do let me know your thoughts on this..<=
/font>









 









Thanks so much for sharing this technical issue.<=
/font>









 









Regards,









Hitesh









 









 









 











 









On Thu, Jun 18, 2009 at 4:23 PM, Mitchell Erblich <erblichs@earthlink.net> wrote=
:



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 n=
ot
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 ma=
y
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

       =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 













       

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


















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:hiteshonline@gmail.com]

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<=
br>
resolve BadLSReq, our LSA database size is <1000 & have point to poi=
nt

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









_______________________________________________

OSPF mailing list

OSPF@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/ospf






 






 






 

 

--_000_716209EC190CA740BA799AC4ACCBFB5D15D008FD35IXCAEXCH07ixi_-- From hiteshonline@gmail.com Fri Jun 19 08:52:07 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77CA63A6981 for ; Fri, 19 Jun 2009 08:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2s4LTtmep1-U for ; Fri, 19 Jun 2009 08:52:05 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 26F923A659B for ; Fri, 19 Jun 2009 08:52:04 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id d26so427109eyd.31 for ; Fri, 19 Jun 2009 08:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=nXiW7SIFi5SfNy2gPQh5QA0sM8N/d5vu+OKc4wf+xEI=; b=vasYQBU+AbNJCrsxf+jH6cAouMyyCgn6OTx6IhC7gI5y00R1wzah3kqnr+igshvEGc aT5FdSmobD4K7EtYSLX9u7gy3uIwu9F3DFTBEdlm3DdvHLIpWN0Ai8ZA1KRDWo1NCLhO K73uFe4MP8XreLeb5XX6+Jj3AKSizalHpC3m8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CME/Cdj7nhyahr4YPD2loMQpAUV4gwaxgIBHxRXzp9Q8UWV7AQFUq6oq6GRACwdC3T vAFIWcDWcKViGLsWpQmerEVtcm2EtvEL3XXl+e4JWiLXrceMEN+pS9KRZfiuQBASW7Zj tbCiuNTpAlc+WO/QVtxgSqq15UGZdLxr090l8= MIME-Version: 1.0 Received: by 10.210.60.8 with SMTP id i8mr1087510eba.28.1245426735163; Fri, 19 Jun 2009 08:52:15 -0700 (PDT) In-Reply-To: <716209EC190CA740BA799AC4ACCBFB5D15D008FD35@IXCAEXCH07.ixiacom.com> References: <41FB5E90-B7AC-4FB5-ABFE-06A394B22FE0@earthlink.net> <716209EC190CA740BA799AC4ACCBFB5D15D008FD35@IXCAEXCH07.ixiacom.com> Date: Fri, 19 Jun 2009 11:52:15 -0400 Message-ID: <4ac4d38b0906190852g76adbd48v41d335e8f582745e@mail.gmail.com> From: "Hitesh N. Patel" To: Santanu Paul Content-Type: multipart/alternative; boundary=0015174c334e24aa72046cb5820e Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPFquestion X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 15:52:07 -0000 --0015174c334e24aa72046cb5820e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Santanu, Thanks for the reply. Revised LSA database size that I am seeing is about 26K, however observations suggest that convergence time doesn't improve even with small LSA database size. Convergence time is about 18 minutes & if I do packet capture, it does show that RT2 is continueously sending LS Update packets & RT1 keeps sending LS Ack packets, while sometimes I do observe "Receive same LSA" messages. Also= , as you mentioned, "shut" & "no shut" is not clearing a OSPF LSA database. I am wondering if high convergence time has anything to do with LSRefresh time (30 minutes) when Bad LSA gets cleared on either RT1/RT2 & beyond then convergence happen quickly. Thanks, Hitesh On Fri, Jun 19, 2009 at 2:10 AM, Santanu Paul wrote: > 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. > > > > [Santanu] Assuming, RT1 has around 1000 LSAs and RT2 has none, so it is > expected that RT1 will go to FULL state fast, while RT2 will be in loadin= g > to synchronize database, however 7-8 minutes for <1000 LSAs seems too hig= h, > you need to do a packet capture to see what is going on. Check in the > capture what LSA headers RT1 sent, and what request RT2 has sent, if any > request is not corresponding to the LSA headers it has received in DBD RT= 1 > will generate BadLSReq > > > > > > I also observed immediately after seeing this message, both the device > progress from EXCHANGE to EXSTART state, & OSPF converges quickly (within= 20 > seconds) from then on..however it takes about 14-15 minutes for device to > detect BadLSReq & SeqNumberMismatch error, till then both the device rema= ins > busy doing LSA EXCHANGE. > > > > [Santanu] Could not understand the part =93however it takes about 14-15 > minutes for device to detect BadLSReq & SeqNumberMismatch error=94 could = you > elaborate, is it happening after going to FULL? > > > > I also observed one more thing, that while I was resetting OSPF on one > device by using clear ip ospf xxx process command, it takes above mention= ed > process to restore FULL Adjacency but if I reset OSPF by doing "shut" & "= no > shut" on interfaces (as OSPF neighborship is between point to point > network), OSPF convergence time is about 20 seconds. > > > > [Santanu] Not sure what router you are using, but generally =93clear > process=94, clears LSDB but =93shut and no-shut=94 does not, if that is t= he case > =93shut no shut=94 will converge quickly as you might not see LS requests= at > all. > > > > So, after reviewing above fact, it looks to me that, when I do "clear ip > ospf", OSPF does clear the LSA database however it probably mark a delete > flag for the LSAs & advertise it to neighbor before actually deleting it,= so > probably when both the devices are in EXCHANGE state, they do receive the > "about to get deleted" LSA details & event of BadLSReq or SeqNumberMismat= ch > error occures when neighbor receives actual LSRequest for the deleted LSA= . > Also, I observed that out of 2 device, other than the one of which I am > executing "clear ip ospf" command is continueously sending LSA Update > packets. so, I really doubt that doing a "clear ip ospf" when LSAs are be= ing > received is the right thing..as compared to "shut" & "no shut" for verify= ing > OSPF convergence time. Do let me know your thoughts on this.. > > > > [Santanu] Verify capturing the packet and router database. > > > > Thanks and Regards, > > *Santanu Paul* > > ------------------------------ > > *From:* ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] *On Behalf O= f > *Mitchell Erblich > *Sent:* Friday, June 19, 2009 5:01 AM > *To:* OSPF List > *Subject:* [OSPF] Fwd: OSPFquestion > > > > > > > > Begin forwarded message: > > > > *From: *Mitchell Erblich > > *Date: *June 18, 2009 4:27:54 PM PDT > > *To: *"Hitesh N. Patel" > > *Subject: **Re: [OSPF] OSPFquestion* > > > > Hi, > > > > Are you using routers from an established company because > > this seems like a fundamental problem? > > > > If you are looking on a time line and the first bad things > are > > BadLSReq message on one device & SeqNumberMismatch > > on other device. > > > > then stop... > > > > Why the Bad Seguence Number? from rfc 2328 > > > > > > > > ExStart > > If the received packet matches one of the following cases, > > then the neighbor state machine should be executed with the > > event NegotiationDone (causing the state to transition to > > Exchange), the packet's Options field should be recorded in > > the neighbor structure's Neighbor Options field and the > > packet should be accepted as next in sequence and processed > > further (see below). Otherwise, the packet should be > > ignored. > > > > o The initialize(I), more (M) and master(MS) bits are set, > > the contents of the packet are empty, and the neighbor's > > Router ID is larger than the router's own. In this case > > the router is now Slave. Set the master/slave bit to > > slave, and set the neighbor data structure's DD sequence > > number to that specified by the master. > > > > o The initialize(I) and master(MS) bits are off, the > > packet's DD sequence number equals the neighbor data > > structure's DD sequence number (indicating > > acknowledgment) and the neighbor's Router ID is smaller > > than the router's own. In this case the router is > > Master. > > > > Exchange > > Duplicate Database Description packets are discarded by the > > master, and cause the slave to retransmit the last Database > > Description packet that it had sent. Otherwise (the packet > > is not a duplicate): > > > > o If the state of the MS-bit is inconsistent with the > > master/slave state of the connection, generate the > > neighbor event SeqNumberMismatch and stop processing the > > packet. > > > > o If the initialize(I) bit is set, generate the neighbor > > event SeqNumberMismatch and stop processing the packet. > > > > Mitchell Erblich > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > On Jun 18, 2009, at 3:27 PM, Hitesh N. Patel wrote: > > > > Hi Mitchell, Vishwas, > > > > I have verified MTU & mtu is configured correctly. also, I am establishin= g > OSPF v2 point to point neighborship. > > > I also observed immediately after seeing this message, both the device > progress from EXCHANGE to EXSTART state, & OSPF converges quickly (within= 20 > seconds) from then on..however it takes about 14-15 minutes for device to > detect BadLSReq & SeqNumberMismatch error, till then both the device rema= ins > busy doing LSA EXCHANGE. > > > > I also observed one more thing, that while I was resetting OSPF on one > device by using clear ip ospf xxx process command, it takes above mention= ed > process to restore FULL Adjacency but if I reset OSPF by doing "shut" & "= no > shut" on interfaces (as OSPF neighborship is between point to point > network), OSPF convergence time is about 20 seconds. > > > > So, after reviewing above fact, it looks to me that, when I do "clear ip > ospf", OSPF does clear the LSA database however it probably mark a delete > flag for the LSAs & advertise it to neighbor before actually deleting it,= so > probably when both the devices are in EXCHANGE state, they do receive the > "about to get deleted" LSA details & event of BadLSReq or SeqNumberMismat= ch > error occures when neighbor receives actual LSRequest for the deleted LSA= . > Also, I observed that out of 2 device, other than the one of which I am > executing "clear ip ospf" command is continueously sending LSA Update > packets. so, I really doubt that doing a "clear ip ospf" when LSAs are be= ing > received is the right thing..as compared to "shut" & "no shut" for verify= ing > OSPF convergence time. Do let me know your thoughts on this.. > > > > Thanks so much for sharing this technical issue. > > > > Regards, > > Hitesh > > > > > > > > > > > On Thu, Jun 18, 2009 at 4:23 PM, Mitchell Erblich > wrote: > > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > On Jun 18, 2009, at 12:40 PM, Vishwas Manral wrote: > > 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:hiteshonline@gmail.com] > 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 > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > > > > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > --0015174c334e24aa72046cb5820e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Santanu,
=A0
Thanks for the reply.
=A0
Revised LSA database size that I am seeing is about 26K, however obser= vations suggest that convergence time doesn't improve even with small L= SA database size.
Convergence time is about 18 minutes & if I do packet capture, it = does show that RT2 is continueously sending LS Update packets & RT1 kee= ps sending LS Ack packets, while sometimes I do observe "Receive same = LSA" messages. Also, as you mentioned, "shut" & "no= shut" is not clearing a OSPF LSA database.
=A0
I am wondering=A0if high convergence time has anything to do with LSRe= fresh time (30 minutes) when Bad LSA gets cleared on either RT1/RT2 & b= eyond then convergence happen quickly.
Thanks,
Hitesh
=A0
On Fri, Jun 19, 2009 at 2:10 AM, Santanu Paul <SPaul@ixiacom.com<= /a>> wrote:

=A0

[Santanu] Assuming, RT1 has around = 1000 LSAs and RT2 has none, so it is expected that RT1 will go to FULL stat= e fast, while RT2 will be in loading to synchronize database, however 7-8 m= inutes for <1000 LSAs seems too high, you need to do a packet capture to= see what is going on. Check in the capture what LSA headers RT1 sent, and = what request RT2 has sent, if any request is not corresponding to the LSA h= eaders it has received in DBD RT1 will generate BadLSReq

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <= /span>

=A0

=A0

=A0

=A0

Thanks and Regards,=

Sa= ntanu Paul

=

From: ospf-bounces@ietf.or= g [mailto:os= pf-bounces@ietf.org] On Behalf Of = Mitchell Erblich
Sent: Friday, June 19, 2009= 5:01 AM
To: OSPF ListSubject: [OSPF] Fwd: OSPF= question

F= rom: Mitchell Erblich <erblichs@earthlink.net&= gt;

D= ate: June 18, 2009 4:27:54 PM PDT

T= o: "Hitesh N. Patel" <hiteshonline@gmail= .com>

S= ubject: Re: [OSP= F] OSPFquestion

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Are you usin= g routers from an established company because

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 this seems l= ike a fundamental problem?

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 If you are l= ooking on a time line and the first bad things are=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 BadLSReq mes= sage on one device & SeqNumberMismatch=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 on other dev= ice.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 then stop...=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Why the Bad = Seguence Number? from rfc 2328

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ExStart

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 If=
 the received packet matches one of the following cases,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 then the neighbor state machine should b=
e executed with the


=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 event NegotiationDone (causing the state =
to transition to
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Excha=
nge), the packet's Options field should be recorded in

=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the neighbor structure's Neighbor Opt=
ions field and the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0pa=
cket should be accepted as next in sequence and processed

=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 further (see below).=A0 Otherwise, the pa=
cket should be
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ignored=
.


=
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 o=A0=A0 The initia=
lize(I), more (M) and master(MS) bits are set,


=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the contents of the packet ar=
e empty, and the neighbor's
=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 Router ID is larger than the router's own.=A0 In =
this case


=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the router is now Slave.=A0 S=
et the master/slave bit to
=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 slave, and set the neighbor data structure's DD sequ=
ence


=
 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0number to that specified by t=
he master.
=A0


=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 o=A0=A0 The initialize(I) and master(MS) =
bits are off, the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 packet's DD sequence number equals the neighbor data


=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 structure's DD sequence n=
umber (indicating
=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0acknowledgment) and the neighbor's Router ID is smaller


=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 than the router's own.=A0=
 In this case the router is
=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 Master.


=
=A0
=A0=A0=A0=A0=A0=A0=A0 Exchange
=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Duplicate Database Description packets ar=
e discarded by the


=
=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0master, and cause the slave to retransmit=
 the last Database
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 De=
scription packet that it had sent. Otherwise (the packet

=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 is not a duplicate):
<=
pre>=
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 o=A0=A0 If the sta=
te of the MS-bit is inconsistent with the


=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 master/slave state of the con=
nection, generate the
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 neighbor event SeqNumberMismatch and stop processing the


=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 packet.
=
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 o=A0=A0 If the ini=
tialize(I) bit is set, generate the neighbor


=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 event SeqNumberMismatch and s=
top processing the packet.












=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 Mi=
tchell Erblich






=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D






erblichs@earthlink.net> wro=
te:



www.ietf.org website.

=A0 =A0 =A0 =A0Mitchell =
Erblich
=A0 =A0 =A0 =A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =







=


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









hiteshonline@gmail.com]
Sent: Thursday, June 18, 2009 11:47 AM
To: vishwas
Subject: OSPFquest=
ion

Hi Vishwas,

I have been working on OSPF & have observ=
ed 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 poi=
nt
link between pair of Router, however RT1 shows FULL state while RT2remains stuck in LOADING state & after 7-8 minutes it shows BadLSReq<=
br>
message & transitions to LOADING to EXTRART state & then it quickly=

converge from LOADING to FULL. Also, sometimes I see OSPF : Drop
Pac=
ket messages too frequently.

Is there any reading that you can sugge=
st for this OSPF behaviour?


Thanks,
Hitesh Patel


OSPF@ietf.org
https:=
//www.ietf.org/mailman/listinfo/ospf




OSPF@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/ospf


--0015174c334e24aa72046cb5820e-- From dkatz@juniper.net Fri Jun 19 09:22:23 2009 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DE023A699C for ; Fri, 19 Jun 2009 09:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.318 X-Spam-Level: X-Spam-Status: No, score=-4.318 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CndHya3NyUPB for ; Fri, 19 Jun 2009 09:22:20 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 3172E3A69B1 for ; Fri, 19 Jun 2009 09:22:20 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKSju7QuXK6WaJRLjmecNgYXxl5f5vPdHI@postini.com; Fri, 19 Jun 2009 09:22:33 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Fri, 19 Jun 2009 09:19:12 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 09:19:12 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 09:19:11 -0700 Received: from merlot.juniper.net ([172.17.27.10]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 09:19:10 -0700 Received: from dkatz-sslvpn-nc.jnpr.net (dkatz-sslvpn-nc.jnpr.net [172.23.1.63]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id n5JGJ9049876; Fri, 19 Jun 2009 09:19:10 -0700 (PDT) (envelope-from dkatz@juniper.net) Message-ID: <306B2BCB-9B2D-4B99-901C-C05B30A140BD@juniper.net> From: Dave Katz To: "Hitesh N. Patel" In-Reply-To: <4ac4d38b0906190852g76adbd48v41d335e8f582745e@mail.gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail-34-833177016" MIME-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 19 Jun 2009 11:19:09 -0500 References: <41FB5E90-B7AC-4FB5-ABFE-06A394B22FE0@earthlink.net> <716209EC190CA740BA799AC4ACCBFB5D15D008FD35@IXCAEXCH07.ixiacom.com> <4ac4d38b0906190852g76adbd48v41d335e8f582745e@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 19 Jun 2009 16:19:10.0941 (UTC) FILETIME=[ADC128D0:01C9F0F9] Cc: "ospf@ietf.org" Subject: Re: [OSPF] OSPFquestion X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: The Official IETF OSPG WG Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 16:22:23 -0000 --Apple-Mail-34-833177016 Content-Type: text/plain; charset="WINDOWS-1252"; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Please take this off the list and take it up with your vendor. There =20= is a bug here. (If you're the vendor, go back and read the spec carefully...) --Dave On Jun 19, 2009, at 10:52 AM, Hitesh N. Patel wrote: > Hi Santanu, > > Thanks for the reply. > > Revised LSA database size that I am seeing is about 26K, however =20 > observations suggest that convergence time doesn't improve even with =20= > small LSA database size. > Convergence time is about 18 minutes & if I do packet capture, it =20 > does show that RT2 is continueously sending LS Update packets & RT1 =20= > keeps sending LS Ack packets, while sometimes I do observe "Receive =20= > same LSA" messages. Also, as you mentioned, "shut" & "no shut" is =20 > not clearing a OSPF LSA database. > > I am wondering if high convergence time has anything to do with =20 > LSRefresh time (30 minutes) when Bad LSA gets cleared on either RT1/=20= > RT2 & beyond then convergence happen quickly. > Thanks, > Hitesh > > On Fri, Jun 19, 2009 at 2:10 AM, Santanu Paul =20 > wrote: > however RT1 shows FULL state while RT2 remains stuck in LOADING =20 > state & after 7-8 minutes it shows BadLSReq message & transitions to =20= > LOADING to EXTRART state & then it quickly converge from LOADING to =20= > FULL. > > > [Santanu] Assuming, RT1 has around 1000 LSAs and RT2 has none, so it =20= > is expected that RT1 will go to FULL state fast, while RT2 will be =20 > in loading to synchronize database, however 7-8 minutes for <1000 =20 > LSAs seems too high, you need to do a packet capture to see what is =20= > going on. Check in the capture what LSA headers RT1 sent, and what =20 > request RT2 has sent, if any request is not corresponding to the LSA =20= > headers it has received in DBD RT1 will generate BadLSReq > > > > I also observed immediately after seeing this message, both the =20 > device progress from EXCHANGE to EXSTART state, & OSPF converges =20 > quickly (within 20 seconds) from then on..however it takes about =20 > 14-15 minutes for device to detect BadLSReq & SeqNumberMismatch =20 > error, till then both the device remains busy doing LSA EXCHANGE. > > > [Santanu] Could not understand the part =93however it takes about =20 > 14-15 minutes for device to detect BadLSReq & SeqNumberMismatch =20 > error=94 could you elaborate, is it happening after going to FULL? > > > I also observed one more thing, that while I was resetting OSPF on =20 > one device by using clear ip ospf xxx process command, it takes =20 > above mentioned process to restore FULL Adjacency but if I reset =20 > OSPF by doing "shut" & "no shut" on interfaces (as OSPF neighborship =20= > is between point to point network), OSPF convergence time is about =20= > 20 seconds. > > > [Santanu] Not sure what router you are using, but generally =93clear =20= > process=94, clears LSDB but =93shut and no-shut=94 does not, if that = is =20 > the case =93shut no shut=94 will converge quickly as you might not see = =20 > LS requests at all. > > > So, after reviewing above fact, it looks to me that, when I do =20 > "clear ip ospf", OSPF does clear the LSA database however it =20 > probably mark a delete flag for the LSAs & advertise it to neighbor =20= > before actually deleting it, so probably when both the devices are =20 > in EXCHANGE state, they do receive the "about to get deleted" LSA =20 > details & event of BadLSReq or SeqNumberMismatch error occures when =20= > neighbor receives actual LSRequest for the deleted LSA. Also, I =20 > observed that out of 2 device, other than the one of which I am =20 > executing "clear ip ospf" command is continueously sending LSA =20 > Update packets. so, I really doubt that doing a "clear ip ospf" when =20= > LSAs are being received is the right thing..as compared to "shut" & =20= > "no shut" for verifying OSPF convergence time. Do let me know your =20 > thoughts on this.. > > > [Santanu] Verify capturing the packet and router database. > > > Thanks and Regards, > > Santanu Paul > > From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf =20= > Of Mitchell Erblich > Sent: Friday, June 19, 2009 5:01 AM > To: OSPF List > Subject: [OSPF] Fwd: OSPFquestion > > > > > Begin forwarded message: > > > > > From: Mitchell Erblich > > Date: June 18, 2009 4:27:54 PM PDT > > To: "Hitesh N. Patel" > > Subject: Re: [OSPF] OSPFquestion > > > Hi, > > > Are you using routers from an established company because > > this seems like a fundamental problem? > > > If you are looking on a time line and the first bad =20 > things are > > BadLSReq message on one device & SeqNumberMismatch > > on other device. > > > then stop... > > > Why the Bad Seguence Number? from rfc 2328 > > > > > ExStart > > If the received packet matches one of the following cases, > then the neighbor state machine should be executed with =20= > the > event NegotiationDone (causing the state to transition to > Exchange), the packet's Options field should be recorded =20= > in > the neighbor structure's Neighbor Options field and the > packet should be accepted as next in sequence and =20 > processed > further (see below). Otherwise, the packet should be > ignored. > > o The initialize(I), more (M) and master(MS) bits are =20= > set, > the contents of the packet are empty, and the =20 > neighbor's > Router ID is larger than the router's own. In this =20= > case > the router is now Slave. Set the master/slave bit to > slave, and set the neighbor data structure's DD =20 > sequence > number to that specified by the master. > > o The initialize(I) and master(MS) bits are off, the > packet's DD sequence number equals the neighbor data > structure's DD sequence number (indicating > acknowledgment) and the neighbor's Router ID is =20 > smaller > than the router's own. In this case the router is > Master. > > Exchange > Duplicate Database Description packets are discarded by =20= > the > master, and cause the slave to retransmit the last =20 > Database > Description packet that it had sent. Otherwise (the packet > is not a duplicate): > > o If the state of the MS-bit is inconsistent with the > master/slave state of the connection, generate the > neighbor event SeqNumberMismatch and stop processing =20= > the > packet. > > o If the initialize(I) bit is set, generate the neighbor > event SeqNumberMismatch and stop processing the =20 > packet. > > > > Mitchell Erblich > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > > > > > On Jun 18, 2009, at 3:27 PM, Hitesh N. Patel wrote: > > > > > Hi Mitchell, Vishwas, > > > I have verified MTU & mtu is configured correctly. also, I am =20 > establishing OSPF v2 point to point neighborship. > > > I also observed immediately after seeing this message, both the =20 > device progress from EXCHANGE to EXSTART state, & OSPF converges =20 > quickly (within 20 seconds) from then on..however it takes about =20 > 14-15 minutes for device to detect BadLSReq & SeqNumberMismatch =20 > error, till then both the device remains busy doing LSA EXCHANGE. > > > I also observed one more thing, that while I was resetting OSPF on =20 > one device by using clear ip ospf xxx process command, it takes =20 > above mentioned process to restore FULL Adjacency but if I reset =20 > OSPF by doing "shut" & "no shut" on interfaces (as OSPF neighborship =20= > is between point to point network), OSPF convergence time is about =20= > 20 seconds. > > > So, after reviewing above fact, it looks to me that, when I do =20 > "clear ip ospf", OSPF does clear the LSA database however it =20 > probably mark a delete flag for the LSAs & advertise it to neighbor =20= > before actually deleting it, so probably when both the devices are =20 > in EXCHANGE state, they do receive the "about to get deleted" LSA =20 > details & event of BadLSReq or SeqNumberMismatch error occures when =20= > neighbor receives actual LSRequest for the deleted LSA. Also, I =20 > observed that out of 2 device, other than the one of which I am =20 > executing "clear ip ospf" command is continueously sending LSA =20 > Update packets. so, I really doubt that doing a "clear ip ospf" when =20= > LSAs are being received is the right thing..as compared to "shut" & =20= > "no shut" for verifying OSPF convergence time. Do let me know your =20 > thoughts on this.. > > > Thanks so much for sharing this technical issue. > > > Regards, > > Hitesh > > > > > > > > On Thu, Jun 18, 2009 at 4:23 PM, Mitchell Erblich = > wrote: > > 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 =20= > 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 =20= > 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > On Jun 18, 2009, at 12:40 PM, Vishwas Manral wrote: > > 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:hiteshonline@gmail.com] > 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 > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > > > > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf > > > _______________________________________________ > OSPF mailing list > OSPF@ietf.org > https://www.ietf.org/mailman/listinfo/ospf --Apple-Mail-34-833177016 Content-Type: text/html; charset="WINDOWS-1252" Content-Transfer-Encoding: quoted-printable Please take this off the list = and take it up with your vendor.  There is a bug = here.

(If you're the vendor, go back and read the = spec = carefully...)

--Dave

On = Jun 19, 2009, at 10:52 AM, Hitesh N. Patel wrote:

Hi = Santanu,
 
Thanks for the reply.
=
 
Revised LSA database size that I am seeing is = about 26K, however observations suggest that convergence time doesn't = improve even with small LSA database size.
Convergence = time is about 18 minutes & if I do packet capture, it does show that = RT2 is continueously sending LS Update packets & RT1 keeps sending = LS Ack packets, while sometimes I do observe "Receive same LSA" = messages. Also, as you mentioned, "shut" & "no shut" is not clearing = a OSPF LSA database.
 
I am wondering if = high convergence time has anything to do with LSRefresh time (30 = minutes) when Bad LSA gets cleared on either RT1/RT2 & beyond then = convergence happen quickly.
Thanks,
=
Hitesh
 
On Fri, = Jun 19, 2009 at 2:10 AM, Santanu Paul <SPaul@ixiacom.com> = wrote:

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.

 

[Santanu] Assuming, RT1 has around 1000 LSAs and RT2 = has none, so it is expected that RT1 will go to FULL state fast, while = RT2 will be in loading to synchronize database, however 7-8 minutes for = <1000 LSAs seems too high, you need to do a packet capture to see = what is going on. Check in the capture what LSA headers RT1 sent, and = what request RT2 has sent, if any request is not corresponding to the = LSA headers it has received in DBD RT1 will generate = BadLSReq

            =
 

I also observed =  immediately after seeing this message, both the device progress = from EXCHANGE to EXSTART state, & OSPF converges quickly (within 20 = seconds) from then on..however it takes about 14-15 minutes for device = to detect BadLSReq & SeqNumberMismatch error, till then both the = device remains busy doing = LSA EXCHANGE.

 

[Santanu] Could = not understand the part =93however it takes about 14-15 minutes for = device to detect BadLSReq & SeqNumberMismatch error=94 could you = elaborate, is it happening after going to FULL?

 

I also observed one = more thing, that while I was resetting OSPF on one device by using clear = ip ospf xxx process command, it takes above mentioned process to restore = FULL Adjacency but if I reset OSPF by doing "shut" & "no shut" on = interfaces (as OSPF neighborship is between point to point network), = OSPF convergence time is  about 20 = seconds.

 

[Santanu] Not sure = what router you are using, but generally =93clear process=94, clears = LSDB but =93shut and no-shut=94 does not, if that is the case =93shut no = shut=94 will converge quickly as you might not see LS requests at = all.

 

So, after reviewing = above fact, it looks to me that, when I do "clear ip ospf", OSPF does = clear the LSA database however it probably mark a delete flag for the = LSAs & advertise it to neighbor before actually deleting it, so = probably when both the devices are in EXCHANGE state, they do receive = the "about to get deleted" LSA details & event of BadLSReq or = SeqNumberMismatch error occures when neighbor receives actual LSRequest = for the deleted LSA. Also, I observed that out of 2 device, other than = the one of which I am executing "clear ip ospf" command is continueously = sending LSA Update packets. so, I really doubt that doing a "clear ip = ospf" when LSAs are being received is the right thing..as compared to = "shut" & "no shut" for verifying OSPF convergence time. Do let me = know your thoughts on this..

 

[Santanu] Verify = capturing the packet and router database.

 

Thanks and Regards,

Santanu Paul
=
=

From: ospf-bounces@ietf.org [mailto:ospf-bounces@ietf.org] On Behalf Of Mitchell Erblich
= Sent: Friday, June 19, = 2009 5:01 AM
To: OSPF = List
Subject: [OSPF] = Fwd: OSPFquestion

 
 
=
 

Begin forwarded = message:



=

From: Mitchell Erblich <erblichs@earthlink.net>

=

Date: June 18, 2009 4:27:54 PM PDT

=

To: "Hitesh N. Patel" <hiteshonline@gmail.com>

=

Subject: Re: [OSPF] = OSPFquestion

 

Hi,

=
 

            = Are you using routers from an established company = because

            = this seems like a fundamental problem?

=
 

            = If you are looking on a time line and the first bad = things are 

            = BadLSReq message on one device & = SeqNumberMismatch 

            = on other device.

            =
=

            = then stop...

 

            = Why the Bad Seguence Number? from rfc = 2328

 
            =
=
 

            = ExStart

= 
            =
If the received packet matches one of the following =
cases,
            =
then the neighbor state machine should be executed with =
the
            =
event NegotiationDone (causing the state to transition =
to
            =
Exchange), the packet's Options field should be recorded =
in
            =
the neighbor structure's Neighbor Options field and =
the
           =
 packet should be accepted as next in sequence and =
processed
            =
further (see below).  Otherwise, the packet should =
be
            =
ignored.
 
            =
o   The initialize(I), more (M) and master(MS) bits are =
set,
           &n=
bsp;    the contents of the packet are empty, and the =
neighbor's
           &n=
bsp;    Router ID is larger than the router's own.  =
In this case
           &n=
bsp;    the router is now Slave.  Set the =
master/slave bit to
           &n=
bsp;    slave, and set the neighbor data structure's DD =
sequence
 =
            &n=
bsp;  number to that specified by the =
master.
 
= 
            =
o   The initialize(I) and master(MS) bits are off, =
the
           &n=
bsp;    packet's DD sequence number equals the neighbor =
data
           &n=
bsp;    structure's DD sequence number =
(indicating
     =
           acknowle=
dgment) and the neighbor's Router ID is smaller
= 
           &n=
bsp;    than the router's own.  In this case the =
router is
           &n=
bsp;    Master.
 
        =
Exchange
            =
Duplicate Database Description packets are discarded by =
the
        =
    master, and cause the slave to retransmit the =
last Database
            =
Description packet that it had sent. Otherwise (the =
packet
            =
is not a duplicate):
 
            =
o   If the state of the MS-bit is inconsistent with =
the
           &n=
bsp;    master/slave state of the connection, generate =
the
           &n=
bsp;    neighbor event SeqNumberMismatch and stop =
processing the
           &n=
bsp;    packet.
 
            =
o   If the initialize(I) bit is set, generate the =
neighbor
           &n=
bsp;    event SeqNumberMismatch and stop processing the =
packet.



          = Mitchell Erblich

          = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 
 
 
=

On Jun 18, 2009, at 3:27 PM, Hitesh N. Patel = wrote:



=

Hi Mitchell, Vishwas,

=
 

I = have verified MTU & mtu is configured correctly. also, I am = establishing OSPF v2 point to point = neighborship.


I also observed =  immediately after seeing this message, both the device progress = from EXCHANGE to EXSTART state, & OSPF converges quickly (within 20 = seconds) from then on..however it takes about 14-15 minutes for device = to detect BadLSReq & SeqNumberMismatch error, till then both the = device remains busy doing LSA EXCHANGE.

=
 

I = also observed one more thing, that while I was resetting OSPF on one = device by using clear ip ospf xxx process command, it takes above = mentioned process to restore FULL Adjacency but if I reset OSPF by doing = "shut" & "no shut" on interfaces (as OSPF neighborship is between = point to point network), OSPF convergence time is  about 20 = seconds.

 

So, = after reviewing above fact, it looks to me that, when I do "clear ip = ospf", OSPF does clear the LSA database however it probably mark a = delete flag for the LSAs & advertise it to neighbor before actually = deleting it, so probably when both the devices are in EXCHANGE state, = they do receive the "about to get deleted" LSA details & event of = BadLSReq or SeqNumberMismatch error occures when neighbor receives = actual LSRequest for the deleted LSA. Also, I observed that out of 2 = device, other than the one of which I am executing "clear ip ospf" = command is continueously sending LSA Update packets. so, I really doubt = that doing a "clear ip ospf" when LSAs are being received is the right = thing..as compared to "shut" & "no shut" for verifying OSPF = convergence time. Do let me know your thoughts on = this..

 

Thanks so much for sharing this technical = issue.

 

Regards,

Hitesh

 
 
 


 

On Thu, Jun 18, 2009 = at 4:23 PM, Mitchell Erblich <erblichs@earthlink.net> = wrote:

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
       =3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D



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

=

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:hiteshonline@gmail.com]
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

_______________________________________________
OSPF mailing = list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf

 
 
 
 

_____= __________________________________________
OSPF mailing list
OSPF@ietf.org
https://www.ietf.org/mailman/listinfo/ospf


= _______________________________________________
OSPF mailing = list
OSPF@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ospf

= --Apple-Mail-34-833177016--