From owner-ospf@PEACH.EASE.LSOFT.COM Tue Oct 5 15:50:19 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01626 for ; Tue, 5 Oct 2004 15:50:19 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00EA1D96@cherry.ease.lsoft.com>; Tue, 5 Oct 2004 15:50:18 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 38714649 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 5 Oct 2004 15:50:17 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 5 Oct 2004 15:40:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00944; Tue, 5 Oct 2004 15:40:03 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200410051940.PAA00944@ietf.org> Date: Tue, 5 Oct 2004 15:40:03 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-mt-00.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : MT-OSPF: Multi Topology (MT) Routing in OSPF Author(s) : P. Psenak, et al. Filename : draft-ietf-ospf-mt-00.txt Pages : 12 Date : 2004-10-5 This draft describes the extension to OSPF in order to define independent IP topologies called Multi-Topologies (MTs). The MT extension can be used for computing different paths for different classes of service, in-band management network or incongruent topologies for unicast and multicast. M-ISIS describes a similar mechanism for ISIS. This draft also describes an optional extension of Multi-topologies whereby some links might be excluded from the default topology. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-mt-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-mt-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-mt-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-5160512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-mt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-mt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-5160512.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 6 15:51:15 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29150 for ; Wed, 6 Oct 2004 15:51:14 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00EA374F@cherry.ease.lsoft.com>; Wed, 6 Oct 2004 15:51:13 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 38880505 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 6 Oct 2004 15:50:55 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 6 Oct 2004 15:40:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27470; Wed, 6 Oct 2004 15:40:47 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200410061940.PAA27470@ietf.org> Date: Wed, 6 Oct 2004 15:40:47 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-graceful-restart-00.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : OSPFv3 Graceful Restart Author(s) : A. Lindem, P. Pillay-Esnault Filename : draft-ietf-ospf-ospfv3-graceful-restart-00.txt Pages : 11 Date : 2004-10-6 This memo describes the OSPFv3 graceful restart. For OSPFv3, graceful restart is identical to OSPFv2 except for the differences described in this memo. These differences include the format of the grace Link State advertisements (LSA) and other considerations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-graceful-restart-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-6152756.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-graceful-restart-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-6152756.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 7 20:21:02 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17760 for ; Thu, 7 Oct 2004 20:21:01 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00EA5707@cherry.ease.lsoft.com>; Thu, 7 Oct 2004 20:20:57 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39072047 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 7 Oct 2004 20:20:56 -0400 Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 7 Oct 2004 20:20:56 -0400 Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00EA5623@cherry.ease.lsoft.com>; Thu, 7 Oct 2004 20:20:55 -0400 Received: from 131.228.20.22 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 7 Oct 2004 20:20:56 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i980KrF00227 for ; Fri, 8 Oct 2004 03:20:53 +0300 (EET DST) X-Scanned: Fri, 8 Oct 2004 03:17:52 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i980HqrB016152 for ; Fri, 8 Oct 2004 03:17:52 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00REGiQu; Fri, 08 Oct 2004 03:17:40 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9805oY15882 for ; Fri, 8 Oct 2004 03:05:51 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Oct 2004 19:05:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: Receiving Self Originated Network LSA Thread-Index: AcSsypAedW67h2AgQuShL+TVeZmNmA== X-OriginalArrivalTime: 08 Oct 2004 00:05:50.0105 (UTC) FILETIME=[91B38890:01C4ACCA] Message-ID: <8D260779A766FB4A9C1739A476F84FA401F79B34@daebe009.americas.nokia.com> Date: Thu, 7 Oct 2004 19:05:49 -0500 Reply-To: Mailing List Sender: Mailing List From: Mukesh.Gupta@NOKIA.COM Subject: Receiving Self Originated Network LSA Comments: To: OSPF@DISCUSS.MICROSOFT.COM To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi All, Consider this topology.. b () -- R1 =3D=3D=3D=3D=3D R2 -- () a Where R1 and R2 are connected by 2 interfaces a and b and running OSPF on both of them. () is network with more routers. Let say everything is in area backbone. R1 is DR for network a and R2 is DR for network b. Now R2 crashes and comes back up. It establishes=20 adjacency with R1 and generates a network LSA for=20 network b with sequence number 1. Now let say R2=20 receives a self originated network LSA for network b=20 with sequence number 7 on interface a. What should it do ? 1) silently drop the packet because the packet was received on the wrong interface ? The LSA will be flushed or reoriginated when the same LSA will be received on network b. 2) or look up the interface that has the ip address mentioned in the ls id of the LSA and reoriginate the LSA if it is DR on that interface or flush the=20 LSA if it is not. Regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 7 20:34:05 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19060 for ; Thu, 7 Oct 2004 20:34:04 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00EA5641@cherry.ease.lsoft.com>; Thu, 7 Oct 2004 20:34:04 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39073876 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 7 Oct 2004 20:34:03 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 7 Oct 2004 20:34:03 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 1FB08A1FD9C for ; Thu, 7 Oct 2004 17:34:02 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23521-10 for ; Thu, 7 Oct 2004 17:34:01 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.57]) by prattle.redback.com (Postfix) with SMTP id 6D61AA1FD99 for ; Thu, 7 Oct 2004 17:33:59 -0700 (PDT) References: <8D260779A766FB4A9C1739A476F84FA401F79B34@daebe009.americas.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <034e01c4acce$6fb3c7b0$0202a8c0@aceeinspiron> Date: Thu, 7 Oct 2004 20:33:30 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Receiving Self Originated Network LSA To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Mukesh, If I understand your question, R2 should do #2 as long as R1 and R2 are in a state >= EXCHANGE on interface a. If R1 and R2 area in a state < EXCHANGE on interface a R2 will drop the LS Update. Hope this helps, Acee ----- Original Message ----- From: To: Sent: Thursday, October 07, 2004 8:05 PM Subject: Receiving Self Originated Network LSA Hi All, Consider this topology.. b () -- R1 ===== R2 -- () a Where R1 and R2 are connected by 2 interfaces a and b and running OSPF on both of them. () is network with more routers. Let say everything is in area backbone. R1 is DR for network a and R2 is DR for network b. Now R2 crashes and comes back up. It establishes adjacency with R1 and generates a network LSA for network b with sequence number 1. Now let say R2 receives a self originated network LSA for network b with sequence number 7 on interface a. What should it do ? 1) silently drop the packet because the packet was received on the wrong interface ? The LSA will be flushed or reoriginated when the same LSA will be received on network b. 2) or look up the interface that has the ip address mentioned in the ls id of the LSA and reoriginate the LSA if it is DR on that interface or flush the LSA if it is not. Regards Mukesh From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 8 02:00:58 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12127 for ; Fri, 8 Oct 2004 02:00:58 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00EA5DE2@cherry.ease.lsoft.com>; Fri, 8 Oct 2004 2:00:50 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39100510 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 8 Oct 2004 02:00:31 -0400 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 8 Oct 2004 02:00:31 -0400 Received: from smirtoraw2k03 (rtp-vpn2-29.cisco.com [10.82.240.29]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i9860Ru23837 for ; Thu, 7 Oct 2004 23:00:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal Message-ID: <165d01c4acfc$1d721b90$6001a8c0@amer.cisco.com> Date: Fri, 8 Oct 2004 02:00:26 -0400 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: Receiving Self Originated Network LSA To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <034e01c4acce$6fb3c7b0$0202a8c0@aceeinspiron> Precedence: list Content-Transfer-Encoding: 7bit Mukesh, -> ->Hi Mukesh, ->If I understand your question, R2 should do #2 as long ->as R1 and R2 are in a state >= EXCHANGE on interface a. ->If R1 and R2 area in a state < EXCHANGE on interface a ->R2 will drop the LS Update. -> ->Hope this helps, ->Acee ->----- Original Message ----- ->From: ->To: ->Sent: Thursday, October 07, 2004 8:05 PM ->Subject: Receiving Self Originated Network LSA -> -> ->Hi All, -> ->Consider this topology.. -> b ->() -- R1 ===== R2 -- () -> a -> ->Where R1 and R2 are connected by 2 interfaces a and b ->and running OSPF on both of them. () is network with ->more routers. Let say everything is in area backbone. ->R1 is DR for network a and R2 is DR for network b. -> ->Now R2 crashes and comes back up. It establishes ->adjacency with R1 and generates a network LSA for ->network b with sequence number 1. As a side note, R2 can generate network LSA if it is DR however in normal circumstances, R1 will do a NeighborChange event (because R2 adj goes to Init or lower) and R1 elect itself as DR. Therefore R2 cannot become DR when it comes back up... Sina ->Now let say R2 ->receives a self originated network LSA for network b ->with sequence number 7 on interface a. What should ->it do ? -> ->1) silently drop the packet because the packet was -> received on the wrong interface ? The LSA will -> be flushed or reoriginated when the same LSA will -> be received on network b. -> ->2) or look up the interface that has the ip address -> mentioned in the ls id of the LSA and reoriginate -> the LSA if it is DR on that interface or flush the -> LSA if it is not. -> ->Regards ->Mukesh -> From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 8 02:23:49 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26950 for ; Fri, 8 Oct 2004 02:23:49 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00EA5F67@cherry.ease.lsoft.com>; Fri, 8 Oct 2004 2:23:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39101634 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 8 Oct 2004 02:23:47 -0400 Received: from 195.68.44.135 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 8 Oct 2004 02:13:47 -0400 Received: from mailmir.si.fr.atosorigin.com (mailmir.si.fr.atosorigin.com [55.2.7.165]) by mail.si.fr.atosorigin.com (8.13.0/8.13.0) with ESMTP id i986D6T5000320 for ; Fri, 8 Oct 2004 08:13:16 +0200 Received: from aofr03371 ([55.3.96.33]) by mailmir.si.fr.atosorigin.com (8.13.0/8.13.0) with SMTP id i986D95Y005796 for ; Fri, 8 Oct 2004 08:13:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RelayAddrIn-Show: (55.3.96.33) X-RelayAddrIn-Local: Yes X-Scanned-By: MIMEDefang 2.44 Message-ID: <001201c4acfe$2af7f3a0$21600337@aofr03371> Date: Fri, 8 Oct 2004 08:15:11 +0200 Reply-To: Mailing List Sender: Mailing List From: Fabien Verhaeghe Subject: OSPF/Unnumbered To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi, RFC2328 section 12.4.1.1 describing how to encode P2P link into a router LSA required to set the MIB-II interface index in case of unnumbered interface. But there is no mean for other router receiving the LSA to guess if a P2P link is unnumbered or not. This may be a problem when a virtual link path is terminated on such an unnumbered interface. As explained in section 15 this will prevent such virtual link to be up. Indeed on virtual link, the Hello packet are monocasted to the IP address found in the router LSA link that point back to the virtual link. If it is an unnumbered interface the router will eventually send Hello using the MIB-II If index as destination IP address. Isn't it better to encode a valid router IP address instead of the MIB-II index in the router LSA type 1 link when describing unnumbered interface? Do you see any interop problem? Regards, Fabien ==================================================================================================== === This electronic transmission and any files attached to it are strictly confidential and intended solely for the addressee. If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this transmission. If you have received this transmission in error, please notify us by return and delete the same. The views expressed in this electronic transmission do not necessarily reflect those of Atos Origin or any of its subsidiary companies. Although the sender endeavours to maintain a computer virus free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. Thank You. ==================================================================================================== === From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 8 04:49:15 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04444 for ; Fri, 8 Oct 2004 04:49:15 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00EA619C@cherry.ease.lsoft.com>; Fri, 8 Oct 2004 4:49:14 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39108060 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 8 Oct 2004 04:49:13 -0400 Received: from 203.199.93.15 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 8 Oct 2004 04:39:12 -0400 Received: from 192.168.57.15 (a2 [192.168.57.22]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id OAA28166 for "Mailing List"; Fri, 8 Oct 2004 14:10:34 +0530 X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_2004108514911540383426" MIME-Version: 1.0 Message-ID: <200410080840.OAA28166@WS0005.indiatimes.com> Date: Fri, 8 Oct 2004 14:09:01 +0530 Reply-To: Mailing List Sender: Mailing List From: kishoreky Subject: forwrding address in ospfv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --=_MAILER_ATTACH_BOUNDARY1_2004108514911540383426 Content-Type: text/plain; charset=us-ascii Hi, according to rfc 2328 to calculate and external route, router must have the reachability to ASBR (who generates that external lsa) + router should have an INTER AREA or INTRA AREA path to the forwarding address (in case of non zero forwarding address). i feel the same logic is applicable for ospfv3 also. in that case whenever there is a route deletion (Both intra area and Inter area) we need to see all the External lsa in our database and check whether any frowrding address belongs to this route. if so delete the external route. is my understanding correct ? if yes isn't it too costly to check the entire external lsdb database whenever there is a route deletion because most implementation will probably go for incremental route calculation. (Separating the IPv6 prefixes from the router LSA helps in incremental route calculation for intra area route and that could be one of the reason for the separation) Also light on when should we set the forwarding address as Non Zero in OSPFv3 helps. CISCO does not set the forwarding address to non zero even if the nexthop of the redistributed route belongs to OSPFv3 intra area route. (Sorry for discussing about a specific implementation) regards Manish Gupta Indiatimes Email now powered by APIC Advantage. Help! HelpClick on the image to chat with me --=_MAILER_ATTACH_BOUNDARY1_2004108514911540383426 Content-Type: text/html; charset=us-ascii

Hi,

according to rfc 2328 to calculate and external route,

router must have the reachability to ASBR (who generates that external lsa)

+ router should have an INTER AREA or INTRA AREA path to the forwarding

address

(in case of non zero forwarding address).

i feel the same logic is applicable for ospfv3 also.

in that case whenever there is a route deletion (Both intra area and Inter

area) we need to see all the

External lsa in our database and check whether any frowrding address belongs

to this route.

if so delete the external route. is my understanding correct ?

if yes isn't it too costly to check the entire external lsdb database

whenever there is

a route deletion because most implementation will probably go for

incremental route calculation.

(Separating the IPv6 prefixes from the router LSA helps in incremental route

calculation for intra area route and that could be one of the reason for the

separation)

Also light on when should we set the forwarding address as Non Zero in

OSPFv3 helps.

CISCO does not set the forwarding address to non zero even if the nexthop of

the redistributed route belongs to OSPFv3 intra area route. (Sorry for

discussing about a specific implementation)

regards

Manish Gupta


Indiatimes Email now powered by APIC Advantage. Help!
Click on the image to chat with me
--=_MAILER_ATTACH_BOUNDARY1_2004108514911540383426-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 8 04:49:54 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04498 for ; Fri, 8 Oct 2004 04:49:54 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00EA609C@cherry.ease.lsoft.com>; Fri, 8 Oct 2004 4:49:54 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39108374 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 8 Oct 2004 04:49:53 -0400 Received: from 203.199.93.15 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 8 Oct 2004 04:49:52 -0400 Received: from 192.168.57.15 (a2 [192.168.57.22]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id OAA31024 for "Mailing List"; Fri, 8 Oct 2004 14:21:14 +0530 X-URL: http://indiatimes.com Content-Type: multipart/alternative; boundary="=_MAILER_ATTACH_BOUNDARY1_20041085141941233665123" MIME-Version: 1.0 Message-ID: <200410080851.OAA31024@WS0005.indiatimes.com> Date: Fri, 8 Oct 2004 14:19:41 +0530 Reply-To: Mailing List Sender: Mailing List From: kishoreky Subject: Nssa lsa forwarding address To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --=_MAILER_ATTACH_BOUNDARY1_20041085141941233665123 Content-Type: text/plain; charset=us-ascii Hi All, RFC 3101 (NSSA) is a little bit confusing >From Section 2.3 Type7 LSA (Page Number 8) it states that Normally the next hop address of an installed AS external route learned by an NSSA ASBR from an adjacent AS points at one of the adjacent AS's gateway routers. If this address belongs to a network connected to the NSSA ASBR via one of its NSSAs' active interfaces, then the NSSA ASBR copies this next hop address into the forwarding address field of the route's Type-7 LSA that is originated into this NSSA, as is currently done with Type-5 LSAs. (See [OSPF] Section 12.4.4.1.) For an NSSA with no such network the forwarding address field may only be filled with an address from one of the its active interfaces or 0.0.0.0. If the P-bit is set, the forwarding address must be non-zero; otherwise it may be 0.0.0.0. If an NSSA requires the P-bit be set and a non-zero forwarding address is unavailable, then the route's Type-7 LSA is not originated into this NSSA. When a router is forced to pick a forwarding address for a Type-7 LSA, preference should be given first to the router's internal addresses (provided internal addressing is supported). If internal addresses are not available, preference should be given to the router's active OSPF stub network addresses. These choices avoid the possible extra hop that may happen when a transit network's address is used. When the interface whose IP address is the LSA's forwarding address transitions to a Down state (see [OSPF] Section 9.3), the router must select a new forwarding address for the LSA and then re- originate it. If one is not available the LSA should be flushed. Let us consider a situation that the NSSA ASBR (Not an ABR) gets the redistributed route for generating type 7 LSA and It has no global IPv6 Address configured at any interface. - Will it originate Type-7 LSA with P Bit clear and forwarding address set as zero - Will not originate any Type -7 LSA First option seems to be better. Even if the NSSA ASBR originates a Type -7 LSA with P Bit Clear and zero forwarding address in the above situation, I think it will not create any problem as Type 7 LSA with P Bit Clear will not be translated to Type 5 LSA in Type 5 capable areas. So LSA for this static route will be restricted in the NSSA area only. Sorry for the lengthy mail. With Regards, TapabrataIndiatimes Email now powered by APIC Advantage. Help! HelpClick on the image to chat with me --=_MAILER_ATTACH_BOUNDARY1_20041085141941233665123 Content-Type: text/html; charset=us-ascii

Hi All,

RFC 3101 (NSSA) is a little bit confusing

>From Section 2.3 Type7 LSA (Page Number 8) it states that

Normally the next hop address of an installed AS external route

learned by an NSSA ASBR from an adjacent AS points at one of the

adjacent AS's gateway routers. If this address belongs to a network

connected to the NSSA ASBR via one of its NSSAs' active interfaces,

then the NSSA ASBR copies this next hop address into the forwarding

address field of the route's Type-7 LSA that is originated into this

NSSA, as is currently done with Type-5 LSAs. (See [OSPF] Section

12.4.4.1.) For an NSSA with no such network the forwarding address

field may only be filled with an address from one of the its active

interfaces or 0.0.0.0. If the P-bit is set, the forwarding address

must be non-zero; otherwise it may be 0.0.0.0. If an NSSA requires

the P-bit be set and a non-zero forwarding address is unavailable,

then the route's Type-7 LSA is not originated into this NSSA.

When a router is forced to pick a forwarding address for a Type-7

LSA, preference should be given first to the router's internal

addresses (provided internal addressing is supported). If internal

addresses are not available, preference should be given to the

router's active OSPF stub network addresses. These choices avoid the

possible extra hop that may happen when a transit network's address

is used. When the interface whose IP address is the LSA's forwarding

address transitions to a Down state (see [OSPF] Section 9.3), the

router must select a new forwarding address for the LSA and then re-

originate it. If one is not available the LSA should be flushed.

 

Let us consider a situation that the NSSA ASBR (Not an ABR) gets the

redistributed route for generating type 7 LSA and It has no global IPv6

Address configured at any interface.

- Will it originate Type-7 LSA with P Bit clear and forwarding address set

as zero

- Will not originate any Type -7 LSA

First option seems to be better. Even if the NSSA ASBR originates a Type -7

LSA with P Bit Clear and zero forwarding address in the above situation, I

think it will not create any problem as Type 7 LSA with P Bit Clear will not

be translated to Type 5 LSA in Type 5 capable areas. So LSA for this static

route will be restricted in the NSSA area only.

 

Sorry for the lengthy mail.

With Regards,

Tapabrata

Indiatimes Email now powered by APIC Advantage. Help!
Click on the image to chat with me
--=_MAILER_ATTACH_BOUNDARY1_20041085141941233665123-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 8 08:56:05 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20900 for ; Fri, 8 Oct 2004 08:56:05 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00EA665E@cherry.ease.lsoft.com>; Fri, 8 Oct 2004 8:56:03 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39167349 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 8 Oct 2004 08:56:02 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 8 Oct 2004 08:56:02 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 5AB5CBE1A5D for ; Fri, 8 Oct 2004 05:55:59 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22940-03 for ; Fri, 8 Oct 2004 05:55:59 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.57]) by prattle.redback.com (Postfix) with SMTP id 2BCAABE1A5A for ; Fri, 8 Oct 2004 05:55:57 -0700 (PDT) References: <001201c4acfe$2af7f3a0$21600337@aofr03371> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <03a201c4ad36$15379560$0202a8c0@aceeinspiron> Date: Fri, 8 Oct 2004 08:55:26 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF/Unnumbered To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Fabien, While this solution would simplify the virtual link neighbor address selection, I don't think we should change the LSA link format at this time. Many implementations use a heuristic of determining whether the best path link data is a valid IP address and, if not, searching the virtual link endpoint router's backbone router LSA for a routable address. You can look at an example of this in John Moy's GPL ospf implementation (www.ospf.org). Hope this helps, Acee ----- Original Message ----- From: "Fabien Verhaeghe" To: Sent: Friday, October 08, 2004 2:15 AM Subject: OSPF/Unnumbered > Hi, > > RFC2328 section 12.4.1.1 describing how to encode P2P link into a router LSA required to set the > MIB-II > interface index in case of unnumbered interface. > But there is no mean for other router receiving the LSA to guess if a P2P link is unnumbered or not. > > This may be a problem when a virtual link path is terminated on such an unnumbered interface. > As explained in section 15 this will prevent such virtual link to be up. Indeed on virtual link, the > Hello packet > are monocasted to the IP address found in the router LSA link that point back to the virtual link. > If it is > an unnumbered interface the router will eventually send Hello using the MIB-II If index as > destination IP address. > > Isn't it better to encode a valid router IP address instead of the MIB-II index in the router LSA > type 1 link > when describing unnumbered interface? > Do you see any interop problem? > > Regards, > Fabien > > ==================================================================================================== > === > This electronic transmission and any files attached to it are strictly confidential and intended > solely for the addressee. If you are not the intended addressee, you must not disclose, copy or > take any action in reliance of this transmission. If you have received this transmission in error, > please notify us by return and delete the same. The views expressed in this electronic transmission > do not necessarily reflect those of Atos Origin or any of its subsidiary companies. Although the > sender endeavours to maintain a computer virus free network, the sender does not warrant that this > transmission is virus-free and will not be liable for any damages resulting from any virus > transmitted. Thank You. > ==================================================================================================== > === From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 8 09:05:20 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21255 for ; Fri, 8 Oct 2004 09:05:18 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00EA6700@cherry.ease.lsoft.com>; Fri, 8 Oct 2004 9:05:19 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39169012 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 8 Oct 2004 09:05:17 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 8 Oct 2004 09:05:17 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 5CF3FBE1A5B for ; Fri, 8 Oct 2004 06:05:16 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23803-10 for ; Fri, 8 Oct 2004 06:05:15 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.57]) by prattle.redback.com (Postfix) with SMTP id 5DB3ABE1A5A for ; Fri, 8 Oct 2004 06:05:15 -0700 (PDT) References: <200410080840.OAA28166@WS0005.indiatimes.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B7_01C4AD15.DA57EB90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <03ba01c4ad37$61eb65c0$0202a8c0@aceeinspiron> Date: Fri, 8 Oct 2004 09:04:44 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: forwrding address in ospfv3 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_03B7_01C4AD15.DA57EB90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Manish, A couple points: 1. You can be smarter than searching your entire LSA external=20 database everytime there is a change to an OSPFv3 intra or i inter area route.=20 2. In actuality, you won't set the forwarding address for OSPFv3 external LSAs very often. This is due to the fact that most of the time your next-hop address is link-local address. If we ever = re-spin RFC 2740, I'll clarify this.=20 Hope this helps, Acee=20 ----- Original Message -----=20 From: kishoreky=20 To: OSPF@PEACH.EASE.LSOFT.COM=20 Sent: Friday, October 08, 2004 4:39 AM Subject: forwrding address in ospfv3 Hi, according to rfc 2328 to calculate and external route, router must have the reachability to ASBR (who generates that external = lsa) + router should have an INTER AREA or INTRA AREA path to the = forwarding address (in case of non zero forwarding address). i feel the same logic is applicable for ospfv3 also. in that case whenever there is a route deletion (Both intra area and = Inter area) we need to see all the External lsa in our database and check whether any frowrding address = belongs to this route. if so delete the external route. is my understanding correct ? if yes isn't it too costly to check the entire external lsdb database whenever there is a route deletion because most implementation will probably go for incremental route calculation. (Separating the IPv6 prefixes from the router LSA helps in incremental = route calculation for intra area route and that could be one of the reason = for the separation) Also light on when should we set the forwarding address as Non Zero in OSPFv3 helps. CISCO does not set the forwarding address to non zero even if the = nexthop of the redistributed route belongs to OSPFv3 intra area route. (Sorry for discussing about a specific implementation) regards Manish Gupta -------------------------------------------------------------------------= ----- Indiatimes Email now powered by APIC Advantage. Help!=20 Help Click on the image to chat with me ------=_NextPart_000_03B7_01C4AD15.DA57EB90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Manish,
A couple points:
 
  1. You can be smarter than = searching your=20 entire LSA external
      database = everytime there is a change to = an OSPFv3=20 intra or i
      inter=20 area route.
 
  2. In actuality, you won't set = the=20 forwarding address for OSPFv3
      external = LSAs very=20 often. This is due to the fact that most of the
      time = your=20 next-hop address is link-local address. If we ever = re-spin
      RFC = 2740, I'll=20 clarify this.
 
Hope this helps,
Acee
----- Original Message -----
From:=20 kishoreky
Sent: Friday, October 08, 2004 = 4:39=20 AM
Subject: forwrding address in=20 ospfv3

Hi,

according to rfc 2328 to calculate and external route,

router must have the reachability to ASBR (who generates that = external=20 lsa)

+ router should have an INTER AREA or INTRA AREA path to the = forwarding

address

(in case of non zero forwarding address).

i feel the same logic is applicable for ospfv3 also.

in that case whenever there is a route deletion (Both intra area = and=20 Inter

area) we need to see all the

External lsa in our database and check whether any frowrding = address=20 belongs

to this route.

if so delete the external route. is my understanding correct ?

if yes isn't it too costly to check the entire external lsdb = database

whenever there is

a route deletion because most implementation will probably go = for

incremental route calculation.

(Separating the IPv6 prefixes from the router LSA helps in = incremental=20 route

calculation for intra area route and that could be one of the = reason for=20 the

separation)

Also light on when should we set the forwarding address as Non Zero = in

OSPFv3 helps.

CISCO does not set the forwarding address to non zero even if the = nexthop=20 of

the redistributed route belongs to OSPFv3 intra area route. (Sorry = for

discussing about a specific implementation)

regards

Manish Gupta


Indiatimes Email now powered by APIC = Advantage.=20 Help!
Click on=20 the image to chat with me
------=_NextPart_000_03B7_01C4AD15.DA57EB90-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 8 09:07:23 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21349 for ; Fri, 8 Oct 2004 09:07:20 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00EA6721@cherry.ease.lsoft.com>; Fri, 8 Oct 2004 9:07:21 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39169208 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 8 Oct 2004 09:07:20 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 8 Oct 2004 09:07:19 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id BE079BE1A5D for ; Fri, 8 Oct 2004 06:07:18 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24084-09 for ; Fri, 8 Oct 2004 06:07:18 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.57]) by prattle.redback.com (Postfix) with SMTP id 8F2A1BE1A5C for ; Fri, 8 Oct 2004 06:07:17 -0700 (PDT) References: <200410080851.OAA31024@WS0005.indiatimes.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03C0_01C4AD16.2345F6D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <03c301c4ad37$aac28da0$0202a8c0@aceeinspiron> Date: Fri, 8 Oct 2004 09:06:46 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Nssa lsa forwarding address To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_03C0_01C4AD16.2345F6D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tapabrata - agree that the first option is better.=20 ----- Original Message -----=20 From: kishoreky=20 To: OSPF@PEACH.EASE.LSOFT.COM=20 Sent: Friday, October 08, 2004 4:49 AM Subject: Nssa lsa forwarding address Hi All, RFC 3101 (NSSA) is a little bit confusing >From Section 2.3 Type7 LSA (Page Number 8) it states that Normally the next hop address of an installed AS external route learned by an NSSA ASBR from an adjacent AS points at one of the adjacent AS's gateway routers. If this address belongs to a network connected to the NSSA ASBR via one of its NSSAs' active interfaces, then the NSSA ASBR copies this next hop address into the forwarding address field of the route's Type-7 LSA that is originated into this NSSA, as is currently done with Type-5 LSAs. (See [OSPF] Section 12.4.4.1.) For an NSSA with no such network the forwarding address field may only be filled with an address from one of the its active interfaces or 0.0.0.0. If the P-bit is set, the forwarding address must be non-zero; otherwise it may be 0.0.0.0. If an NSSA requires the P-bit be set and a non-zero forwarding address is unavailable, then the route's Type-7 LSA is not originated into this NSSA. When a router is forced to pick a forwarding address for a Type-7 LSA, preference should be given first to the router's internal addresses (provided internal addressing is supported). If internal addresses are not available, preference should be given to the router's active OSPF stub network addresses. These choices avoid the possible extra hop that may happen when a transit network's address is used. When the interface whose IP address is the LSA's forwarding address transitions to a Down state (see [OSPF] Section 9.3), the router must select a new forwarding address for the LSA and then re- originate it. If one is not available the LSA should be flushed. Let us consider a situation that the NSSA ASBR (Not an ABR) gets the redistributed route for generating type 7 LSA and It has no global = IPv6 Address configured at any interface. - Will it originate Type-7 LSA with P Bit clear and forwarding address = set as zero - Will not originate any Type -7 LSA First option seems to be better. Even if the NSSA ASBR originates a = Type -7 LSA with P Bit Clear and zero forwarding address in the above = situation, I think it will not create any problem as Type 7 LSA with P Bit Clear = will not be translated to Type 5 LSA in Type 5 capable areas. So LSA for this = static route will be restricted in the NSSA area only. Sorry for the lengthy mail. With Regards, -------------------------------------------------------------------------= ----- Indiatimes Email now powered by APIC Advantage. Help!=20 Help Click on the image to chat with me ------=_NextPart_000_03C0_01C4AD16.2345F6D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Tapabrata - agree that the first option is better.

----- Original Message -----
From:=20 kishoreky
Sent: Friday, October 08, 2004 = 4:49=20 AM
Subject: Nssa lsa forwarding=20 address


Hi All,

RFC 3101 (NSSA) is a little bit confusing

>From Section 2.3 Type7 LSA (Page Number 8) it states that

Normally the next hop address of an installed AS external route

learned by an NSSA ASBR from an adjacent AS points at one of = the

adjacent AS's gateway routers. If this address belongs to a = network

connected to the NSSA ASBR via one of its NSSAs' active = interfaces,

then the NSSA ASBR copies this next hop address into the = forwarding

address field of the route's Type-7 LSA that is originated into = this

NSSA, as is currently done with Type-5 LSAs. (See [OSPF] = Section

12.4.4.1.) For an NSSA with no such network the forwarding = address

field may only be filled with an address from one of the its = active

interfaces or 0.0.0.0. If the P-bit is set, the forwarding = address

must be non-zero; otherwise it may be 0.0.0.0. If an NSSA = requires

the P-bit be set and a non-zero forwarding address is = unavailable,

then the route's Type-7 LSA is not originated into this NSSA.

When a router is forced to pick a forwarding address for a = Type-7

LSA, preference should be given first to the router's internal

addresses (provided internal addressing is supported). If = internal

addresses are not available, preference should be given to the

router's active OSPF stub network addresses. These choices avoid = the

possible extra hop that may happen when a transit network's = address

is used. When the interface whose IP address is the LSA's = forwarding

address transitions to a Down state (see [OSPF] Section 9.3), = the

router must select a new forwarding address for the LSA and then = re-

originate it. If one is not available the LSA should be = flushed.

 

Let us consider a situation that the NSSA ASBR (Not an ABR) gets = the

redistributed route for generating type 7 LSA and It has no global = IPv6

Address configured at any interface.

- Will it originate Type-7 LSA with P Bit clear and forwarding = address=20 set

as zero

- Will not originate any Type -7 LSA

First option seems to be better. Even if the NSSA ASBR originates a = Type=20 -7

LSA with P Bit Clear and zero forwarding address in the above = situation,=20 I

think it will not create any problem as Type 7 LSA with P Bit Clear = will=20 not

be translated to Type 5 LSA in Type 5 capable areas. So LSA for = this=20 static

route will be restricted in the NSSA area only.

 

Sorry for the lengthy mail.

With Regards,
Indiatimes Email now powered by APIC = Advantage.=20 Help!
Click on=20 the image to chat with me
------=_NextPart_000_03C0_01C4AD16.2345F6D0-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 8 09:07:51 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21421 for ; Fri, 8 Oct 2004 09:07:51 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00EA6709@cherry.ease.lsoft.com>; Fri, 8 Oct 2004 9:07:51 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39167489 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 8 Oct 2004 09:07:50 -0400 Received: from 63.113.148.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 8 Oct 2004 08:57:50 -0400 Received: from rs-sc-exc8.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id FAA12484; Fri, 8 Oct 2004 05:57:49 -0700 (PDT) Received: from legolas.rs.riverstonenet.com ([134.141.176.109]) by rs-sc-exc8.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 8 Oct 2004 05:57:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: OSPF Redistributing Direct / Connected routes Thread-Index: AcSs/2Kcs3FGIKHSTOSYwt9tC9K0rwANQW/Q X-OriginalArrivalTime: 08 Oct 2004 12:57:26.0130 (UTC) FILETIME=[5C485520:01C4AD36] Message-ID: <7549C475A1F3CF47ABCA660BF44738B36F57A3@legolas.rs.riverstonenet.com> Date: Fri, 8 Oct 2004 05:57:25 -0700 Reply-To: Mailing List Sender: Mailing List From: "Mollin, Arvind - LiqwidKrystal" Subject: OSPF Redistributing Direct / Connected routes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi, I am having a simple setup like this, R1-I1--------p2p--------I1-R2-I2-------p2p-----I1-R3 OSPF interfaces are R1-I1 and R2-I1. Now I am trying to redistribute connected/direct routes into OSPF in R2. When I do that R2 redistributes the address of R3's I1 interface address, but it is not redistributing R2's I2 interface address. Due to this R1 is not able to ping R2'sI2 interface, but able to ping R3's I1 interface. Is this behaviour a normal one or abnormal one ??. Is there any standards that speaks how OSPF should redistribute connected routes ??. Pls help me out Thanks Arvind =20 From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 8 09:43:48 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23679 for ; Fri, 8 Oct 2004 09:43:48 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00EA6766@cherry.ease.lsoft.com>; Fri, 8 Oct 2004 9:43:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39172119 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 8 Oct 2004 09:43:47 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 8 Oct 2004 09:43:47 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 61F34390511 for ; Fri, 8 Oct 2004 06:43:45 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28722-01 for ; Fri, 8 Oct 2004 06:43:45 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.57]) by prattle.redback.com (Postfix) with SMTP id 392AD39050E for ; Fri, 8 Oct 2004 06:43:44 -0700 (PDT) References: <7549C475A1F3CF47ABCA660BF44738B36F57A3@legolas.rs.riverstonenet.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <03d601c4ad3c$c20c3740$0202a8c0@aceeinspiron> Date: Fri, 8 Oct 2004 09:43:13 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: OSPF Redistributing Direct / Connected routes To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Arvind, For the ping to work, you must have bi-directional routing. The pinger must have a route matching the specified ping target destination. The pingee must have a route to matching the source address the pinger uses in his ICMP echo request packet. Regarding redistribution, it is just one aspect of the network design and it should not be standardized. Hope this helps, Acee ----- Original Message ----- From: "Mollin, Arvind - LiqwidKrystal" To: Sent: Friday, October 08, 2004 8:57 AM Subject: OSPF Redistributing Direct / Connected routes Hi, I am having a simple setup like this, R1-I1--------p2p--------I1-R2-I2-------p2p-----I1-R3 OSPF interfaces are R1-I1 and R2-I1. Now I am trying to redistribute connected/direct routes into OSPF in R2. When I do that R2 redistributes the address of R3's I1 interface address, but it is not redistributing R2's I2 interface address. Due to this R1 is not able to ping R2'sI2 interface, but able to ping R3's I1 interface. Is this behaviour a normal one or abnormal one ??. Is there any standards that speaks how OSPF should redistribute connected routes ??. Pls help me out Thanks Arvind From owner-ospf@PEACH.EASE.LSOFT.COM Tue Oct 12 05:39:37 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03453 for ; Tue, 12 Oct 2004 05:39:36 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00EAB675@cherry.ease.lsoft.com>; Tue, 12 Oct 2004 5:39:33 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39556492 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 12 Oct 2004 05:38:51 -0400 Received: from 203.199.93.15 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 12 Oct 2004 05:38:51 -0400 Received: from 192.168.57.15 (IDENT:demail@a1 [192.168.57.21]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id PAA11804 for "Mailing List"; Tue, 12 Oct 2004 15:09:11 +0530 X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii Message-ID: <200410120939.PAA11804@WS0005.indiatimes.com> Date: Tue, 12 Oct 2004 15:10:31 -0400 Reply-To: Mailing List Sender: Mailing List From: kishoreky Subject: ospf redistribute To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi , i have few doubts regarding ospf redistribution. say i have added a static route with next hop X.X.X.X if ospf want's to redistribute this static route what all ospf should check? does ospf should have a OSPF route (directly connected) to the next hop X.X.X.X to generate Type 5 LSA or it is enough if the route to nexthop can be either INTER AREA or INTRA AREA. i think if the route is direct one, we can set the forwarding address in Type 5 LSA as X.X.X.X but if the route is not the direct one then what should be the forwarding address? X.X.X.X or 0.0.0.0 if it needs to generate the LSA. regards Manish Gupta Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now! From owner-ospf@PEACH.EASE.LSOFT.COM Tue Oct 12 11:40:44 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01957 for ; Tue, 12 Oct 2004 11:40:44 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00EAC008@cherry.ease.lsoft.com>; Tue, 12 Oct 2004 11:40:44 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39625148 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 12 Oct 2004 11:40:42 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 12 Oct 2004 11:40:42 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 9F1C95E7031 for ; Tue, 12 Oct 2004 08:40:29 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08140-08 for ; Tue, 12 Oct 2004 08:40:29 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.20]) by prattle.redback.com (Postfix) with SMTP id 33C035E702B for ; Tue, 12 Oct 2004 08:40:29 -0700 (PDT) References: <200410120939.PAA11804@WS0005.indiatimes.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <003101c4b071$cc4fc770$8129359b@aceeinspiron> Date: Tue, 12 Oct 2004 11:40:27 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: ospf redistribute To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "kishoreky" To: Sent: Tuesday, October 12, 2004 3:10 PM Subject: ospf redistribute > Hi , > > i have few doubts regarding ospf redistribution. > > say i have added a static route with next hop X.X.X.X > > if ospf want's to redistribute this static route what all ospf should check? > > does ospf should have a OSPF route (directly connected) to the next hop > X.X.X.X to generate Type > 5 LSA or > > it is enough if the route to nexthop can be either INTER AREA or INTRA AREA. > > i think if the route is direct one, we can set the forwarding address in > Type > 5 LSA as X.X.X.X > > but if the route is not the direct one then what should be the forwarding > address? X.X.X.X or 0.0.0.0 if it needs to generate the LSA. Hi Manish, Standard OSPF doesn't compute recursive next-hops. Hence, by definition, X.X.X.X is directly connected. One could raise the question of tunneled interfaces but I don't think these should be treated any differently. Another implementation decision is whether or not to advertise a forwarding address for redistributed/imported ECMP routes. In this case, I do not. Hope this helps, Acee > > regards > > Manish Gupta > > > > > > Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com > > Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com > > Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now! From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 13 01:02:53 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20948 for ; Wed, 13 Oct 2004 01:02:53 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00EACE24@cherry.ease.lsoft.com>; Wed, 13 Oct 2004 1:02:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39704200 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 13 Oct 2004 01:02:46 -0400 Received: from 216.82.244.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 13 Oct 2004 01:02:46 -0400 X-VirusChecked: Checked X-Env-Sender: rmalhotra@bankofny.com X-Msg-Ref: server-5.tower-65.messagelabs.com!1097643766!17072403 X-StarScan-Version: 5.2.10; banners=bankofny.com,-,- X-Originating-IP: [160.254.107.25] Received: (qmail 14771 invoked from network); 13 Oct 2004 05:02:46 -0000 Received: from unknown (HELO lgsbrc01.bankofny.com) (160.254.107.25) by server-5.tower-65.messagelabs.com with SMTP; 13 Oct 2004 05:02:46 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Wed, 13 Oct 2004 01:02:50 -0400 Reply-To: Mailing List Sender: Mailing List From: rmalhotra@BANKOFNY.COM Subject: Ravi Malhotra is out of the office. To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list I will be out of the office starting 10/08/2004 and will not return until 10/18/2004. I will respond to your message when I return. Please contact Mike Tang with any urgent issues. Thank You, Ravi Malhotra ________________________________________________________________________ The information in this e-mail, and any attachment therein, is confidential and for use by the addressee only. If you are not the intended recipient, please return the e-mail to the sender and delete it from your computer. Although The Bank of New York attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 13 09:28:42 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25862 for ; Wed, 13 Oct 2004 09:28:42 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00EAD806@cherry.ease.lsoft.com>; Wed, 13 Oct 2004 9:28:34 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39773319 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 13 Oct 2004 09:28:32 -0400 Received: from 203.199.93.15 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 13 Oct 2004 09:28:31 -0400 Received: from 192.168.57.15 (a3 [192.168.57.23]) by WS0005.indiatimes.com (8.9.3/8.9.3) with SMTP id SAA11187 for "Mailing List"; Wed, 13 Oct 2004 18:58:02 +0530 X-URL: http://indiatimes.com Content-Type: text/plain; charset=us-ascii Message-ID: <200410131328.SAA11187@WS0005.indiatimes.com> Date: Wed, 13 Oct 2004 19:02:28 +0530 Reply-To: Mailing List Sender: Mailing List From: kishoreky Subject: Re: ospf redistribute To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi Ace, Thnaks for reply but i have one more doubt :- According to RFC 2328 section 12.4.4.1. Examples of AS-external-LSAs :- when the forwarding address field is non- zero, it should point to a router belonging to another Autonomous System. According to RFC 2328 section 16.4 :- If the forwarding address is non-zero, look up the forwarding address in the routing table.[24] The matching routing table entry must specify an intra-area or inter-area path. + | +---+.....|.BGP |RTA|-----|.....+---+ +---+ |-----|RTX| | +---+ +---+ | |RTB|-----| +---+ | | +---+ | |RTC|-----| +---+ | | + this is the figure number 16 taken from RFC 2328 here RTA, RTB and RTC are ospf routers and RTX is non-ospf router in this situation if the all routers are connected through broadcast network then we can take the forwarding address of RTX interface since it will allow RTB and RTC to not to forward packet for external network through RTA they can directly send to RTX. at the same time ALL ospf routers will have a INTRA AREA or INTER AREA path to the forwarding address so they can compute the External Routes. but my doubt is if these routers are connected through PTOMP network then is it valid to set a forwarding address as RTX interface. i think ospf routers will not have a INTRA AREA or INTER AREA route to the RTX Interface address and so no one will compute the path. should i set the forwarding address zero in this case. but i am not sure whether we can configure a PTOMP network like this. somewhere i read that Point-to-MutiPoint subnets were created solely to interconnect OSPF routers. if this statement is true then does it mean we need to fill forwarding address in AS External LSA only when ospf routers are connected through broadcast network to non ospf router. if the ospf router is connected to non ospf router by ptop network then ther is no need to fill any forwarding address. regards Manish Gupta "Mailing List" wrote: ----- Original Message ----- From: "kishoreky" To: Sent: Tuesday, October 12, 2004 3:10 PM Subject: ospf redistribute > Hi , > > i have few doubts regarding ospf redistribution. > > say i have added a static route with next hop X.X.X.X > > if ospf want's to redistribute this static route what all ospf should check? > > does ospf should have a OSPF route (directly connected) to the next hop > X.X.X.X to generate Type > 5 LSA or > > it is enough if the route to nexthop can be either INTER AREA or INTRA AREA. > > i think if the route is direct one, we can set the forwarding address in > Type > 5 LSA as X.X.X.X > > but if the route is not the direct one then what should be the forwarding > address? X.X.X.X or 0.0.0.0 if it needs to generate the LSA. Hi Manish, Standard OSPF doesn't compute recursive next-hops. Hence, by definition, X.X.X.X is directly connected. One could raise the question of tunneled interfaces but I don't think these should be treated any differently. Another implementation decision is whether or not to advertise a forwarding address for redistributed/imported ECMP routes. In this case, I do not. Hope this helps, Acee > > regards > > Manish Gupta > > > > > > Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com > > Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com > > Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now! Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now! From owner-ospf*ospf-archive**LISTS*-IETF*-ORG@PEACH.EASE.LSOFT.COM Thu Oct 14 00:38:14 2004 Received: from grape.ease.lsoft.com (grape.ease.lsoft.com [209.119.1.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17000 for ; Thu, 14 Oct 2004 00:38:13 -0400 (EDT) Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <5.00506484@grape.ease.lsoft.com>; Thu, 14 Oct 2004 0:38:13 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39863696 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 14 Oct 2004 00:38:13 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 14 Oct 2004 00:38:12 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 1C251B0FC0A for ; Wed, 13 Oct 2004 21:38:12 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18092-07 for ; Wed, 13 Oct 2004 21:38:11 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.63]) by prattle.redback.com (Postfix) with SMTP id 697EDB0FC06 for ; Wed, 13 Oct 2004 21:38:11 -0700 (PDT) References: <200410131328.SAA11187@WS0005.indiatimes.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <003a01c4b1a7$9a2b99e0$c96aacd1@aceeinspiron> Date: Thu, 14 Oct 2004 00:38:07 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: ospf redistribute To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Manish, See inline. ----- Original Message ----- From: "kishoreky" To: Sent: Wednesday, October 13, 2004 9:32 AM Subject: Re: ospf redistribute > Hi Ace, > > Thnaks for reply > > but i have one more doubt :- > > According to RFC 2328 section 12.4.4.1. Examples of AS-external-LSAs :- > when the forwarding address field is non- zero, it should point to a > router belonging to another Autonomous System. > > According to RFC 2328 section 16.4 :- > If the forwarding address is non-zero, look up the > forwarding address in the routing table.[24] The matching > routing table entry must specify an intra-area or inter-area > path. > > > > + > | > +---+.....|.BGP > |RTA|-----|.....+---+ > +---+ |-----|RTX| > | +---+ > +---+ | > |RTB|-----| > +---+ | > | > +---+ | > |RTC|-----| > +---+ | > | > + > > this is the figure number 16 taken from RFC 2328 > here RTA, RTB and RTC are ospf routers and RTX is non-ospf router > > in this situation if the all routers are connected through broadcast network then we can > take the forwarding address of RTX interface since it will allow RTB and RTC to not to > forward packet for external network through RTA they can directly send to RTX. at the same time > ALL ospf routers will have a INTRA AREA or INTER AREA path to the forwarding address so they > can compute the External Routes. > > but my doubt is if these routers are connected through PTOMP network then is it valid to > set a forwarding address as RTX interface. i think ospf routers will not have a INTRA AREA > or INTER AREA route to the RTX Interface address and so no one will compute the path. should > i set the forwarding address zero in this case. > > but i am not sure whether we can configure a PTOMP network like this. > somewhere i read that Point-to-MutiPoint subnets were created solely > to interconnect OSPF routers. if this statement is true > then does it mean we need to fill forwarding address in AS External LSA only when > ospf routers are connected through broadcast network to non ospf router > > if the ospf router is connected to non ospf router by ptop network then ther is no need to > fill any forwarding address. The RFC doesn't go into this level of detail regarding when and when not to advertise a forwarding address. Clearly, it could be beneficial on broadcast and NBMA networks with more than 2 routers. For P2MP networks, the forwarding address could still possibly provide a shorter path if there are multiple OSPF routers that have connectivity to the AS external route's next-hop. > > regards > Manish Gupta > > > > > > > > "Mailing List" wrote: > ----- Original Message ----- > From: "kishoreky" > To: > Sent: Tuesday, October 12, 2004 3:10 PM > Subject: ospf redistribute > > >> Hi , >> >> i have few doubts regarding ospf redistribution. >> >> say i have added a static route with next hop X.X.X.X >> >> if ospf want's to redistribute this static route what all ospf should check? >> >> does ospf should have a OSPF route (directly connected) to the next hop >> X.X.X.X to generate Type >> 5 LSA or >> >> it is enough if the route to nexthop can be either INTER AREA or INTRA AREA. >> >> i think if the route is direct one, we can set the forwarding address in >> Type >> 5 LSA as X.X.X.X >> >> but if the route is not the direct one then what should be the forwarding >> address? X.X.X.X or 0.0.0.0 if it needs to generate the LSA. > > Hi Manish, > Standard OSPF doesn't compute recursive next-hops. Hence, by definition, > X.X.X.X is directly connected. One could raise the question of tunneled > interfaces but I don't think these should be treated any differently. Another > implementation decision is whether or not to advertise a forwarding address > for redistributed/imported ECMP routes. In this case, I do not. > > Hope this helps, > Acee > > >> >> regards >> >> Manish Gupta >> >> >> >> >> >> Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com >> >> Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com >> >> Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now! > Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com > > Buy The Best In BOOKS at http://www.bestsellers.indiatimes.com > > Bid for for Air Tickets @ Re.1 on Air Sahara Flights. Just log on to http://airsahara.indiatimes.com and Bid Now! From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 14 15:06:12 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16297 for ; Thu, 14 Oct 2004 15:06:12 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00EAF98F@cherry.ease.lsoft.com>; Thu, 14 Oct 2004 15:06:12 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39994648 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 14 Oct 2004 15:06:10 -0400 Received: from 206.190.39.207 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 14 Oct 2004 15:06:10 -0400 Received: from [204.154.128.112] by web53104.mail.yahoo.com via HTTP; Thu, 14 Oct 2004 12:06:10 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20041014190610.68340.qmail@web53104.mail.yahoo.com> Date: Thu, 14 Oct 2004 12:06:10 -0700 Reply-To: Mailing List Sender: Mailing List From: John Pecola Subject: RFC 3137 question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, The intent of the stub router advertisement is to advertise a path with a very high cost in the hope that it will not be used for transiting traffic. The same is not done for stub links. Can there be any issues if the cost of stub links is also set to 0xFFFF? Thanks John _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 14 15:24:29 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18470 for ; Thu, 14 Oct 2004 15:24:28 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00EAF91E@cherry.ease.lsoft.com>; Thu, 14 Oct 2004 15:24:29 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39995520 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 14 Oct 2004 15:24:26 -0400 Received: from 63.113.148.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 14 Oct 2004 15:24:26 -0400 Received: from rs-sc-exc8.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id MAA09893; Thu, 14 Oct 2004 12:24:25 -0700 (PDT) Received: from legolas.rs.riverstonenet.com ([134.141.176.109]) by rs-sc-exc8.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 14 Oct 2004 12:24:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B223.5C59E8DC" Thread-Topic: Max number of OSPF neighbors in an area ?? Thread-Index: AcSyIljX+LEjYq+eR/iG0IKPg7LxUg== X-OriginalArrivalTime: 14 Oct 2004 19:24:02.0734 (UTC) FILETIME=[5D03B4E0:01C4B223] Message-ID: <7549C475A1F3CF47ABCA660BF44738B36F58AB@legolas.rs.riverstonenet.com> Date: Thu, 14 Oct 2004 12:24:01 -0700 Reply-To: Mailing List Sender: Mailing List From: "Mollin, Arvind - LiqwidKrystal" Subject: Max number of OSPF neighbors in an area ?? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B223.5C59E8DC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Can anybody suggest me what is the maximum number of OSPF neighbors can be configured in an area? It is very obvious that it depends on the capacity of the routers.=20 But Is there any ideal max limit??=20 =20 TIA Arvind =20 ------_=_NextPart_001_01C4B223.5C59E8DC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

  Can anybody suggest me what is  the = maximum number of OSPF neighbors can be configured in an area? It is very obvious that it = depends on the capacity of the routers.

But Is there any ideal max limit?? =

 

TIA

Arvind

 

------_=_NextPart_001_01C4B223.5C59E8DC-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 14 15:44:47 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21535 for ; Thu, 14 Oct 2004 15:44:47 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00EAF8F3@cherry.ease.lsoft.com>; Thu, 14 Oct 2004 15:44:48 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39998300 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 14 Oct 2004 15:44:46 -0400 Received: from 171.68.227.75 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 14 Oct 2004 15:44:46 -0400 Received: from smirtoraw2k03 (sjc-vpn4-181.cisco.com [10.21.80.181]) by fire.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i9EJigi12887 for ; Thu, 14 Oct 2004 12:44:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal Message-ID: <23e901c4b226$420fa740$6001a8c0@amer.cisco.com> Date: Thu, 14 Oct 2004 15:44:36 -0400 Reply-To: Mailing List Sender: Mailing List From: Sina Mirtorabi Subject: Re: RFC 3137 question To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <20041014190610.68340.qmail@web53104.mail.yahoo.com> Precedence: list Content-Transfer-Encoding: 7bit John, -> ->Hi, -> ->The intent of the stub router advertisement is to ->advertise a path with a very high cost in the hope ->that it will not be used for transiting traffic. The ->same is not done for stub links. Can there be any ->issues if the cost of stub links is also set to ->0xFFFF? Yes you can take a suboptimal path to reach the router's stub link, consider the following example R4 / \ / \ / \ R1--R2--R3 R2 is doing stub router advertisement, say S is the subnet for R2-R3 link. If you advertise R2's stub link with infinity cost, R1 will take the path R1-R4-R3-R2 to reach R2's IP address for subnet S instead of R1-R2 path. Sina -> ->Thanks ->John -> -> -> -> ->_______________________________ ->Do you Yahoo!? ->Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 14 16:06:53 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23727 for ; Thu, 14 Oct 2004 16:06:53 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00EAF8C2@cherry.ease.lsoft.com>; Thu, 14 Oct 2004 16:06:53 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 39999240 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 14 Oct 2004 16:06:51 -0400 Received: from 47.140.192.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 14 Oct 2004 15:56:51 -0400 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9EJuVh11930 for ; Thu, 14 Oct 2004 15:56:32 -0400 (EDT) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id <47BGFNQ0>; Thu, 14 Oct 2004 15:56:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B227.D4D73025" Message-ID: Date: Thu, 14 Oct 2004 15:56:01 -0400 Reply-To: Mailing List Sender: Mailing List From: Andrew Smith Subject: Re: Max number of OSPF neighbors in an area ?? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4B227.D4D73025 Content-Type: text/plain A good rule of thumb is no more than 100 OSPF neighbors in one area. Of course you always need to play towards the weakest router you are including in the area so it may be less than that if you are running alot of low-end routers. The performance of that limit is greatly dependent upon how clean your network is, the type of area used, the number of routes you keep in the LSDB and obviously the amount of processor power of your devices. The good news is the newer, more powerful and more efficient routers coming out now will be able to scale well past 1000 neighbors per router. My advice would be to always play it safe. Design your network with your equipment and the skill of your engineers in mind. Build your design with a threshold of 60 - 70% of maximum in mind to allow for growth and spare some room for crisis mode. That way you won't be disappointed in its performance and you can show some pride when the network survives an outage. Regards, Andy Smith -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mollin, Arvind - LiqwidKrystal Sent: Thursday, October 14, 2004 3:24 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Max number of OSPF neighbors in an area ?? Hi, Can anybody suggest me what is the maximum number of OSPF neighbors can be configured in an area? It is very obvious that it depends on the capacity of the routers. But Is there any ideal max limit?? TIA Arvind ------_=_NextPart_001_01C4B227.D4D73025 Content-Type: text/html Message
A good rule of thumb is no more than 100 OSPF neighbors in one area. Of course you always need to play towards the weakest router you are including in the area so it may be less than that if you are running alot of low-end routers.
 
The performance of that limit is greatly dependent upon how clean your network is, the type of area used, the number of routes you keep in the LSDB and obviously the amount of processor power of your devices.
 
The good news is the newer, more powerful and more efficient routers coming out now will be able to scale well past 1000 neighbors per router.
 
My advice would be to always play it safe. Design your network with your equipment and the skill of your engineers in mind. Build your design with a threshold of 60 - 70% of maximum in mind to allow for growth and spare some room for crisis mode. That way you won't be disappointed in its performance and you can show some pride when the network survives an outage.
 
Regards,
Andy Smith
 
-----Original Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mollin, Arvind - LiqwidKrystal
Sent: Thursday, October 14, 2004 3:24 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Max number of OSPF neighbors in an area ??

Hi,

  Can anybody suggest me what is  the maximum number of OSPF neighbors can be configured in an area? It is very obvious that it depends on the capacity of the routers.

But Is there any ideal max limit??

 

TIA

Arvind

 

------_=_NextPart_001_01C4B227.D4D73025-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 14 16:22:40 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25889 for ; Thu, 14 Oct 2004 16:22:37 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00EAF915@cherry.ease.lsoft.com>; Thu, 14 Oct 2004 16:22:37 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40001305 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 14 Oct 2004 16:22:35 -0400 Received: from 63.113.148.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 14 Oct 2004 16:22:35 -0400 Received: from rs-sc-exc8.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id NAA17369; Thu, 14 Oct 2004 13:22:34 -0700 (PDT) Received: from legolas.rs.riverstonenet.com ([134.141.176.109]) by rs-sc-exc8.rs.riverstonenet.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 14 Oct 2004 13:22:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B22B.7C0F9FAC" Thread-Topic: Max number of OSPF neighbors in an area ?? Thread-Index: AcSyKWLvRjwIOJF1QqyHMIRSx0YnGwAAPQyA X-OriginalArrivalTime: 14 Oct 2004 20:22:11.0605 (UTC) FILETIME=[7C8B2C50:01C4B22B] Message-ID: <7549C475A1F3CF47ABCA660BF44738B36F58AD@legolas.rs.riverstonenet.com> Date: Thu, 14 Oct 2004 13:22:10 -0700 Reply-To: Mailing List Sender: Mailing List From: "Mollin, Arvind - LiqwidKrystal" Subject: Re: Max number of OSPF neighbors in an area ?? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B22B.7C0F9FAC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Smith. =20 ________________________________ From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Andrew Smith Sent: Friday, October 15, 2004 1:26 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Max number of OSPF neighbors in an area ?? =20 A good rule of thumb is no more than 100 OSPF neighbors in one area. Of course you always need to play towards the weakest router you are including in the area so it may be less than that if you are running alot of low-end routers.=20 =20 The performance of that limit is greatly dependent upon how clean your network is, the type of area used, the number of routes you keep in the LSDB and obviously the amount of processor power of your devices. =20 The good news is the newer, more powerful and more efficient routers coming out now will be able to scale well past 1000 neighbors per router. =20 My advice would be to always play it safe. Design your network with your equipment and the skill of your engineers in mind. Build your design with a threshold of 60 - 70% of maximum in mind to allow for growth and spare some room for crisis mode. That way you won't be disappointed in its performance and you can show some pride when the network survives an outage. =20 Regards, Andy Smith =20 -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mollin, Arvind - LiqwidKrystal Sent: Thursday, October 14, 2004 3:24 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Max number of OSPF neighbors in an area ?? Hi, Can anybody suggest me what is the maximum number of OSPF neighbors can be configured in an area? It is very obvious that it depends on the capacity of the routers.=20 But Is there any ideal max limit??=20 =20 TIA Arvind =20 ------_=_NextPart_001_01C4B22B.7C0F9FAC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Thanks = Smith.

 

From: = Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Andrew Smith
Sent: Friday, October 15, = 2004 1:26 AM
To: = OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Max number = of OSPF neighbors in an area ??

 

A good rule of thumb is no more = than 100 OSPF neighbors in one area. Of course you always need to play towards = the weakest router you are including in the area so it may be less than that = if you are running alot of low-end routers.

 

The performance of that limit is = greatly dependent upon how clean your network is, the type of area used, the = number of routes you keep in the LSDB and obviously the amount of processor power = of your devices.

 

The good news is the newer, more = powerful and more efficient routers coming out now will be able to scale well = past 1000 neighbors per router.

 

My advice would be to always play = it safe. Design your network with your equipment and the skill of your engineers = in mind. Build your design with a threshold of 60 - 70% of maximum in mind = to allow for growth and spare some room for crisis mode. That way you won't = be disappointed in its performance and you can show some pride when the = network survives an outage.

 

Regards,

Andy = Smith

 

-----Original = Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mollin, Arvind - LiqwidKrystal
Sent: Thursday, October = 14, 2004 3:24 PM
To: = OSPF@PEACH.EASE.LSOFT.COM
Subject: Max number of = OSPF neighbors in an area ??

Hi,

  Can anybody suggest me what is  the = maximum number of OSPF neighbors can be configured in an area? It is very = obvious that it depends on the capacity of the routers.

But Is there any ideal max limit?? =

 

TIA

Arvind

 

------_=_NextPart_001_01C4B22B.7C0F9FAC-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 15 02:33:48 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27773 for ; Fri, 15 Oct 2004 02:33:48 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00EB0694@cherry.ease.lsoft.com>; Fri, 15 Oct 2004 2:33:47 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40050621 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Oct 2004 02:33:22 -0400 Received: from 156.153.255.237 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 15 Oct 2004 02:23:22 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by palrel12.hp.com (Postfix) with ESMTP id 4E6004022FA for ; Thu, 14 Oct 2004 23:23:20 -0700 (PDT) Received: from india.hp.com (nt23049.india.hp.com [15.42.230.49]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id LAA00123 for ; Fri, 15 Oct 2004 11:53:37 +0530 (IST) X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <416F6D65.1F094209@india.hp.com> Date: Fri, 15 Oct 2004 11:55:41 +0530 Reply-To: Mailing List Sender: Mailing List From: Praveen C Organization: HP ISO Subject: junk checksum and next LSA are not processed properly To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Group, If we have a "update packet with say 3 LSAs", and the 1st LSA in this packet has a checksum error, should the rest of the LSAs in the update packet be attempted to be processed ? Note: The check sum error means, there is change in length field of the first LSA RFC 2328 page 142 section 13 says: " Validate the LSA's LS checksum. If the checksum turns out to be invalid, discard the LSA and get the next one from the Link State Update packet. " In this case we could assume that checking the type of the next LSA could be within a valid LSA type range, and still not have the correct beginning of the 2nd or 3rd LSAs. Is this behavior specified anywhere? Thanks in advance. Regards, Praveen From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 15 06:58:00 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16794 for ; Fri, 15 Oct 2004 06:58:00 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <6.00EB0A53@cherry.ease.lsoft.com>; Fri, 15 Oct 2004 6:58:01 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40098668 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Oct 2004 06:58:00 -0400 Received: from 209.119.0.109 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 15 Oct 2004 06:48:00 -0400 Received: from PEACH.EASE.LSOFT.COM (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <0.00EB0B1D@cherry.ease.lsoft.com>; Fri, 15 Oct 2004 6:47:59 -0400 Message-ID: Date: Fri, 15 Oct 2004 06:48:00 -0400 Reply-To: Mailing List Sender: Mailing List From: "Vijay V. Karthik" Subject: Forwarding Address in AS-External LSA of NBMA network To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, I configured NBMA network in Area 0 with rt2 as DR and rt1 and rt3 as DR- Other as given below. Topology: # ------------------ # |1 1| # +-------+ +-------+ # | DUT | | | # | rtr1 |-------| rtr2 | # +-------+2 | 2+-------+ # | # |2 area 0 # +------+ # | |1 # | rtr3 |-------------- # +------+ # The configuration of the routers is as given below. DUT# ! interface eth1 ip address 1.1.1.1/24 ipv6 address fe80::204:75ff:fef0:4266/64 ip ospf cost 10 ! interface eth2 ip address 2.2.2.1/24 ipv6 address fe80::203:47ff:fe96:409b/64 ip ospf network non-broadcast ip ospf hello-interval 10 ip ospf dead-interval 40 ip ospf priority 0 ! router ospf ospf router-id 10.70.0.112 redistribute static network 1.1.1.0/24 area 1 network 2.2.2.0/24 area 0 neighbor 2.2.2.2 priority 10 rtr2# interface eth1 ip address 1.1.1.2/24 ipv6 address fe80::204:75ff:fef0:427a/64 ipv6 address 5f00:1:2:10::2/64 ip ospf cost 10 ! interface eth2 ip address 2.2.2.2/24 ipv6 address fe80::203:47ff:fe96:43f4/64 ipv6 address 5f00:1:2:50::1/64 ip ospf network non-broadcast ip ospf hello-interval 10 ip ospf dead-interval 40 router ospf ospf router-id 10.70.0.113 network 2.2.2.0/24 area 0 neighbor 2.2.2.1 neighbor 2.2.2.3 ! ! rtr3# interface eth1 ip address 3.3.3.1/24 ipv6 address fe80::202:b3ff:feb3:40fe/64 ipv6 address 5f00:1:2:60::1/64 ip ospf cost 10 ! interface eth2 ip address 2.2.2.3/24 ipv6 address fe80::208:a1ff:fe16:797d/64 ipv6 address 5f00:1:2:20::2/64 ip ospf network non-broadcast ip ospf cost 10 ip ospf hello-interval 10 ip ospf dead-interval 40 ip ospf priority 0 router ospf ospf router-id 10.70.0.114 redistribute static network 2.2.2.0/24 area 0 network 3.3.3.0/24 area 0 neighbor 2.2.2.2 priority 10 ! ip route 100.100.100.0/24 3.3.3.10 ip route 200.200.200.0/24 eth1 ! When I try to look at the AS-External-LSA's generated by rt3 I find that the for the statis route 100.100.100.0 the forwarding address is set to 3.3.3.10 as given below. Looking at AS-External-LSA generated by rtr3 AS External Link States LS age: 651 Options: 0x2 (*|-|-|-|-|-|E|-) LS Type: AS-external-LSA Link State ID: 100.100.100.0 (External Network Number) Advertising Router: 10.70.0.114 LS Seq Number: 80000002 Checksum: 0x4971 Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 3.3.3.10 External Route Tag: 0 LS age: 4 Options: 0x2 (*|-|-|-|-|-|E|-) LS Type: AS-external-LSA Link State ID: 200.200.200.0 (External Network Number) Advertising Router: 10.70.0.114 LS Seq Number: 80000001 Checksum: 0x346d Length: 36 Network Mask: /24 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 I would like to know if the forwarding address will be set as 3.3.3.10 (as configured in rt3 as a static route) or forwarding address should be shown as 0.0.0.0 even if I have configured a static route. What does the RFC have to say about this? Pls revert back Thanks, Vijay From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 15 09:51:24 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00153 for ; Fri, 15 Oct 2004 09:51:24 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00EB0B85@cherry.ease.lsoft.com>; Fri, 15 Oct 2004 9:51:24 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40125205 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Oct 2004 09:51:13 -0400 Received: from 128.2.209.197 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 15 Oct 2004 09:51:13 -0400 Received: from ux10.sp.cs.cmu.edu ([128.2.209.197]) by ux10.sp.cs.cmu.edu id aa04336; 15 Oct 2004 9:50 EDT X-X-Sender: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Fri, 15 Oct 2004 09:50:54 -0400 Reply-To: Mailing List Sender: Mailing List From: Keng Subject: Re: junk checksum and next LSA are not processed properly To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <416F6D65.1F094209@india.hp.com> Precedence: list Praveen, I think the answer is "yes. You should continue to process the other lsas in the packet even when you encounter one or more lsas in the packet that failed the checksum verification. The text you quoted from the rfc tells you exactly what the implementation should be doing. regards, Keng On Fri, 15 Oct 2004, Praveen C wrote: > Hi Group, > > If we have a "update packet with say 3 LSAs", and the 1st LSA in > this packet has a checksum error, should the rest of the LSAs in the > update packet be attempted to be processed ? > > Note: The check sum error means, there is change in length field of > the first LSA > > RFC 2328 page 142 section 13 says: > " Validate the LSA's LS checksum. If the checksum turns out > to be invalid, discard the LSA and get the next one from > the Link State Update packet. " > > In this case we could assume that checking the type of the next LSA > could be within a valid LSA type range, and still not have the correct > beginning of the 2nd or 3rd LSAs. > > > Is this behavior specified anywhere? > > Thanks in advance. > > Regards, > Praveen > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 15 10:57:00 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10571 for ; Fri, 15 Oct 2004 10:57:00 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00EB0DB6@cherry.ease.lsoft.com>; Fri, 15 Oct 2004 10:57:00 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40131617 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Oct 2004 10:56:59 -0400 Received: from 156.153.255.206 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 15 Oct 2004 10:56:59 -0400 Received: from iconsrv6.india.hp.com (iconsrv6.india.hp.com [15.42.227.74]) by atlrel8.hp.com (Postfix) with ESMTP id B5DB577E8 for ; Fri, 15 Oct 2004 10:56:57 -0400 (EDT) Received: from india.hp.com (nt23049.india.hp.com [15.42.230.49]) by iconsrv6.india.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.02) with ESMTP id UAA13382 for ; Fri, 15 Oct 2004 20:27:15 +0530 (IST) X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <416FE5C6.BBE962C0@india.hp.com> Date: Fri, 15 Oct 2004 20:29:18 +0530 Reply-To: Mailing List Sender: Mailing List From: Praveen C Organization: HP ISO Subject: Re: junk checksum and next LSA are not processed properly To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi , Thanks for the quick reply. If the checksum error is because of changes in length field of first LSA, in this case we should not process the LSA using the length field or is there any other alternative ? Thanks, Praveen. Keng wrote: > Praveen, > > I think the answer is "yes. You should continue to process the other lsas > in the packet even when you encounter one or more lsas in the packet that > failed the checksum verification. The text you quoted from the rfc tells > you exactly what the implementation should be doing. > > regards, > Keng > > On Fri, 15 Oct 2004, Praveen C wrote: > > > Hi Group, > > > > If we have a "update packet with say 3 LSAs", and the 1st LSA in > > this packet has a checksum error, should the rest of the LSAs in the > > update packet be attempted to be processed ? > > > > Note: The check sum error means, there is change in length field of > > the first LSA > > > > RFC 2328 page 142 section 13 says: > > " Validate the LSA's LS checksum. If the checksum turns out > > to be invalid, discard the LSA and get the next one from > > the Link State Update packet. " > > > > In this case we could assume that checking the type of the next LSA > > could be within a valid LSA type range, and still not have the correct > > beginning of the 2nd or 3rd LSAs. > > > > > > Is this behavior specified anywhere? > > > > Thanks in advance. > > > > Regards, > > Praveen > > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 15 11:43:10 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14648 for ; Fri, 15 Oct 2004 11:43:09 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00EB0CED@cherry.ease.lsoft.com>; Fri, 15 Oct 2004 11:43:10 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40138294 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Oct 2004 11:43:08 -0400 Received: from 192.91.191.8 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 15 Oct 2004 11:43:08 -0400 Received: by beiderbecke.datcon.co.uk with Internet Mail Service (5.5.2653.19) id <49GN5LHQ>; Fri, 15 Oct 2004 16:42:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <53F74F5A7B94D511841C00B0D0AB16F802870BC9@baker.datcon.co.uk> Date: Fri, 15 Oct 2004 16:42:30 +0100 Reply-To: Mailing List Sender: Mailing List From: Nic Neate Subject: Some comments on draft-ietf-ospf-ospfv3-mib-08.txt Comments: To: "djoyal@nortelnetworks.com" , "vishwas@sinett.com" To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, I have a handful of comments on and suggestions for draft-ietf-ospf-ospfv3-mib-08. Please have a look through and let me know whether you agree or if I'm misunderstanding anything. Interface instance IDs ---------------------- As previously agreed on this list, the ospfv3IfTable should be indexed by both ospfv3IfIndex and ospfv3InstId, and correspondingly the ospfv3NbrTable, ospfv3NbmaNbrTable and ospfv3LinkLsdbTable also need new interface instance index fields. It was also recently noted that the instance ID on virtual interfaces will not always be 0, and therefore needs to be configurable. I therefore suggest we also add an ospfv3VirtIfInstId field to the ospfv3VirtIfTable. Designated Router identification -------------------------------- The ospfv3IfDesignatedRouter and ospfv3IfBackupDesignatedRouter fields have been carried over from the OSPFv2 MIB, with their descriptions updated to note that these refer to Router IDs rather than IP addresses. I think it would be helpful to add further fields providing the Interface IDs of the designated and backup designated routers to the network (say, ospfv3IfDesignatedRouterIfId and ospfv3IfBackupDesignatedRouterIfId). My reasoning is that while in OSPFv2, the DR's IP address (as provided in the MIB) uniquely identified a network, in OSPFv3, both the DR's Router ID and its Interface ID to the link are required. The ospfv3NbmaNbrTable ---------------------- This table is described as follows. -- The OSPFv3 NBMA Neighbor Table describes all configured -- NBMA neighbors and neighbors dynamically discovered by -- lower-level protocols such as Inverse Neighbor Discovery. I thought that Point-to-Multipoint links also require explicit neighbor configuration (or discovery by lower-level protocols) in the same way as NBMA links. If this is the case, I think it would be clearer if the name of the table was changed to something less specific such as ospfv3ConfiguredNbrTable and the comment updated accordingly. Other nits ---------- - There are various references to type-5 and type-7 LSAs thoughout. It would be more consistent with RFC2740 (and clearer) to refer to these as AS-External-LSAs and NSSA-LSAs respectively. - There are two references to site-local IPv6 addresses. I believe these have been retired from IPv6. - In the descriptions of ospfv3IfRtrDeadInterval and ospfv3VirtIfRtrDeadInterval, "it's" should be replaced with "its". - In the descriptions of ospfv3NbrRtrId and ospfv3NbmaNbrRtrId, I'm not clear what "represented as type IpAddress" means (given that these take syntax RouterID). Thanks, Nic From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 15 12:06:30 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16260 for ; Fri, 15 Oct 2004 12:06:29 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00EB0E9C@cherry.ease.lsoft.com>; Fri, 15 Oct 2004 12:06:30 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40139984 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Oct 2004 12:06:28 -0400 Received: from 192.91.191.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 15 Oct 2004 12:06:28 -0400 Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2657.72) id <49HBA8BF>; Fri, 15 Oct 2004 17:06:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <53F74F5A7B94D511841C00B0D0AB16F802870BCC@baker.datcon.co.uk> Date: Fri, 15 Oct 2004 17:05:52 +0100 Reply-To: Mailing List Sender: Mailing List From: Nic Neate Subject: Query regarding draft-ietf-ospf-te-node-addr Comments: To: "rahul@juniper.net" , Juniper - Kireeti Kompella To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, We're implementing the Node Attribute TLV defined in draft-ietf-ospf-te-node-addr-01 as part of OSPFv3-TE (draft-ietf-ospf-ospfv3-traffic-02). I have a query regarding the use of the Node Attribute TLV which I was hoping you would resolve. In draft-ietf-ospf-te-node-addr, it's not clear whether a router is allowed to originate more than one Node Attribute TLV (where each TLV is of course in a different Intra-area-TE-LSA as per RFC3630 section 2.4). Could you please clarify this for us. We believe that it should be allowed (similar to the way a router may originate multiple link TLVs) in order to provide space for a large number of IPv6 addresses. Section A.1 of RFC 2740 states the following. ...IPv6 fragmentation should be avoided whenever possible. Using this reasoning, an attempt should be made to limit the sizes of OSPF packets sent over virtual links to 1280 bytes... A 1280 byte Link State Update packet only allows for 77 IPv6 addresses in an Intra-area-TE-LSA containing a Node Attribute TLV. We want to provide the flexibility to include more than that, which means we need to allow a router to originate multiple Node Attribute TLVs. Many thanks, Nic From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 15 15:51:43 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04161 for ; Fri, 15 Oct 2004 15:51:43 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00EB120A@cherry.ease.lsoft.com>; Fri, 15 Oct 2004 15:51:43 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40165751 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Oct 2004 15:51:41 -0400 Received: from 207.217.121.252 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 15 Oct 2004 15:51:41 -0400 Received: from user-2ivfmsb.dialup.mindspring.com ([165.247.219.139] helo=earthlink.net) by pop-a065d14.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CIY71-0004Vw-00 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 15 Oct 2004 12:51:40 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <41702AB2.A82779CD@earthlink.net> Date: Fri, 15 Oct 2004 12:53:22 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: junk checksum and next LSA are not processed properly To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, Interesting... First, I question that you actually know what the "valid" length of the first LSA is since one or more fields are invalid or the chksum itself is invalid. If the pkt is repeatedly sent that way, the recv'd router would ignore all the LSAs from the sending router and effectively blackhole that router. ** Assuming that you ignore that the chksum is also a validation of length, type, etc fields. If 1 LSA is invalid, the Update pkt needs to be resent anyway. The overhead in processing the pkt with 1 less LSA is minimal. Why would you insert new LSAs into the LSDB that has invalid information? Additionally, instead of running just 1 SPF calc for the valid recieved LSAs, by processing two pkts, if they are new LSAs, we will most likely need to run 2 SPF calcs. This and more, would suggest to at least me that upon chksum failure the pkt should be discarded. The negative effects is that one or more LSAs would have to be transmitted. If these LSAs the rexmit interval should be small enough that it the additional time should be insignificant. Additional issues reside in what to do if you process a fewer number of LSAs than was then stated in the Update pkt? Can you/should you back out the previously inserted LSAs from your LSDB? Mitchell Erblich ------------------- Keng wrote: > > Praveen, > > I think the answer is "yes. You should continue to process the other lsas > in the packet even when you encounter one or more lsas in the packet that > failed the checksum verification. The text you quoted from the rfc tells > you exactly what the implementation should be doing. > > regards, > Keng > > On Fri, 15 Oct 2004, Praveen C wrote: > > > Hi Group, > > > > If we have a "update packet with say 3 LSAs", and the 1st LSA in > > this packet has a checksum error, should the rest of the LSAs in the > > update packet be attempted to be processed ? > > > > Note: The check sum error means, there is change in length field of > > the first LSA > > > > RFC 2328 page 142 section 13 says: > > " Validate the LSA's LS checksum. If the checksum turns out > > to be invalid, discard the LSA and get the next one from > > the Link State Update packet. " > > > > In this case we could assume that checking the type of the next LSA > > could be within a valid LSA type range, and still not have the correct > > beginning of the 2nd or 3rd LSAs. > > > > > > Is this behavior specified anywhere? > > > > Thanks in advance. > > > > Regards, > > Praveen > > From owner-ospf@PEACH.EASE.LSOFT.COM Sat Oct 16 22:10:22 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27115 for ; Sat, 16 Oct 2004 22:10:22 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00EB28E7@cherry.ease.lsoft.com>; Sat, 16 Oct 2004 22:10:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40265712 for OSPF@PEACH.EASE.LSOFT.COM; Sat, 16 Oct 2004 22:10:21 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sat, 16 Oct 2004 22:10:20 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 99E14BF9659 for ; Sat, 16 Oct 2004 19:10:19 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24859-06 for ; Sat, 16 Oct 2004 19:10:19 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.72]) by prattle.redback.com (Postfix) with SMTP id B994FBF9657 for ; Sat, 16 Oct 2004 19:10:18 -0700 (PDT) References: <20041014190610.68340.qmail@web53104.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <005801c4b3ee$6f3e51c0$0202a8c0@aceeinspiron> Date: Sat, 16 Oct 2004 22:10:10 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: RFC 3137 question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "John Pecola" To: Sent: Thursday, October 14, 2004 3:06 PM Subject: RFC 3137 question > Hi, > > The intent of the stub router advertisement is to > advertise a path with a very high cost in the hope > that it will not be used for transiting traffic. The > same is not done for stub links. Can there be any > issues if the cost of stub links is also set to > 0xFFFF? Hi John, If there are true stub networks (i.e., not advertised in any other router's router LSA) then I can't think of any implications. LSInfinity is 0xFFFFFF so the total path cost to reach the stub network shouldn't be influenced by the advertised cost. My question for you is why should it matter? If you know the network is a stub it is just as easy to advertise the real cost. Hope this helps, Acee > > Thanks > John > > > > > _______________________________ > Do you Yahoo!? > Declare Yourself - Register online to vote today! > http://vote.yahoo.com From owner-ospf@PEACH.EASE.LSOFT.COM Sun Oct 17 03:14:52 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29989 for ; Sun, 17 Oct 2004 03:14:52 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00EB2FF3@cherry.ease.lsoft.com>; 17 Oct 2004 3:14:51 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40294656 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 17 Oct 2004 03:14:49 -0400 Received: from 207.217.120.122 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 17 Oct 2004 03:14:49 -0400 Received: from user-2ivfnja.dialup.mindspring.com ([165.247.222.106] helo=earthlink.net) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1CJ5Fg-0000ZA-00 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 17 Oct 2004 00:14:48 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <20041014190610.68340.qmail@web53104.mail.yahoo.com> <005801c4b3ee$6f3e51c0$0202a8c0@aceeinspiron> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <41721BF5.806E8E60@earthlink.net> Date: Sun, 17 Oct 2004 00:15:01 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: RFC 3137 question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, Sorry... my two cents stub router advertisement... it will not be used for transiting traffic where another normal/lower path cost exists.. If a path is advertised and it is the ONLY path available, it still is going to be used, no matter the cost.. Mitchell Erblich --------------------- Acee Lindem wrote: > > ----- Original Message ----- > From: "John Pecola" > To: > Sent: Thursday, October 14, 2004 3:06 PM > Subject: RFC 3137 question > > > Hi, > > > > The intent of the stub router advertisement is to > > advertise a path with a very high cost in the hope > > that it will not be used for transiting traffic. The > > same is not done for stub links. Can there be any > > issues if the cost of stub links is also set to > > 0xFFFF? > > Hi John, > If there are true stub networks (i.e., not advertised in any > other router's router LSA) then I can't think of any implications. > LSInfinity is 0xFFFFFF so the total path cost to reach > the stub network shouldn't be influenced by the advertised > cost. My question for you is why should it matter? If you > know the network is a stub it is just as easy to advertise the > real cost. > > Hope this helps, > Acee > > > > > Thanks > > John > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Declare Yourself - Register online to vote today! > > http://vote.yahoo.com From owner-ospf@PEACH.EASE.LSOFT.COM Sun Oct 17 16:34:00 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22920 for ; Sun, 17 Oct 2004 16:34:00 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00EB384F@cherry.ease.lsoft.com>; 17 Oct 2004 16:34:00 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40373492 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 17 Oct 2004 16:33:58 -0400 Received: from 171.71.176.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 17 Oct 2004 16:33:58 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Oct 2004 13:41:08 -0700 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9HKXtYJ027493 for ; Sun, 17 Oct 2004 13:33:55 -0700 (PDT) Received: from cisco.com (sjc-vpn3-8.cisco.com [10.21.64.8]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id AXT83818; Sun, 17 Oct 2004 13:34:14 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <41702AB2.A82779CD@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4172D751.7020203@cisco.com> Date: Sun, 17 Oct 2004 13:34:25 -0700 Reply-To: Mailing List Sender: Mailing List From: Michael J Barnes Subject: Re: junk checksum and next LSA are not processed properly To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <41702AB2.A82779CD@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit Hi Mitchell, Erblichs wrote: > Group, > > Interesting... > > First, I question that you actually know what > the "valid" length of the first LSA is since > one or more fields are invalid or the chksum > itself is invalid. If the length field turns out to be invalid, then when you try to process the next LSA and you're not looking at the beginning of that LSA packet, then you won't get the correct checksum for it either and will skip it too. You may waste a few cpu cycles this way (as opposed to quitting as soon as one bad LSA is found) but if it turns out that the length field is correct you're a lot better off by processing the rest of the LSAs. > > If the pkt is repeatedly sent that way, > the recv'd router would ignore all the > LSAs from the sending router and effectively > blackhole that router. And this is good? I don't think so. > > ** Assuming that you ignore that the chksum is > also a validation of length, type, etc fields. > > If 1 LSA is invalid, the Update pkt needs to be > resent anyway. The overhead in processing the > pkt with 1 less LSA is minimal. But the LSA is probably invalid in the sender's memory, if it was corrupted on the wire then the checksum for the packet would fail. So unless the sender is checking the checksums before putting the LSAs into the packet, it will continue to send this bad LSA. > Why would you insert new LSAs into the LSDB > that has invalid information? I don't think anyone is suggesting to do this. I would certainly say this would be the wrong thing to do. Regards, Michael > Additionally, instead of running just 1 SPF > calc for the valid recieved LSAs, by processing > two pkts, if they are new LSAs, we will most > likely need to run 2 SPF calcs. > > This and more, would suggest to at least me > that upon chksum failure the pkt should be > discarded. > > The negative effects is that one or more LSAs > would have to be transmitted. If these LSAs > the rexmit interval should be small enough > that it the additional time should be > insignificant. > > Additional issues reside in what to do if > you process a fewer number of LSAs than was > then stated in the Update pkt? Can you/should > you back out the previously inserted LSAs from > your LSDB? > > Mitchell Erblich > ------------------- > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Oct 17 19:07:51 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02896 for ; Sun, 17 Oct 2004 19:07:51 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00EB3AE7@cherry.ease.lsoft.com>; 17 Oct 2004 19:07:52 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40384483 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 17 Oct 2004 19:07:50 -0400 Received: from 207.217.120.74 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 17 Oct 2004 19:07:50 -0400 Received: from user-2ivfmu8.dialup.mindspring.com ([165.247.219.200] helo=earthlink.net) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1CJK7w-00062F-00 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 17 Oct 2004 16:07:49 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <41702AB2.A82779CD@earthlink.net> <4172D751.7020203@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <4172FBA9.F9C12BB5@earthlink.net> Date: Sun, 17 Oct 2004 16:09:29 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: junk checksum and next LSA are not processed properly To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Group, et al, Bottom line.. The reason for doing a chksum validation is to validate the pkts contents. If you are still going to process the pkt regardless of the chksum, then why spend the CPU cycles to check the chksum in the first place? Mitchell Erblich --------------------- Michael J Barnes wrote: > > Hi Mitchell, > > Erblichs wrote: > > Group, > > > > Interesting... > > > > First, I question that you actually know what > > the "valid" length of the first LSA is since > > one or more fields are invalid or the chksum > > itself is invalid. > > If the length field turns out to be invalid, then when you try to process > the next LSA and you're not looking at the beginning of that LSA packet, > then you won't get the correct checksum for it either and will skip it > too. You may waste a few cpu cycles this way (as opposed to quitting as > soon as one bad LSA is found) but if it turns out that the length field is > correct you're a lot better off by processing the rest of the LSAs. > Wow... The Update pkt has a invalid chksum. Their is one chksum for the entire Update pkt. Some fields you could do some minor validation to know if they are out of bounds, however, how do you know what that say the router-id is valid? > > > > If the pkt is repeatedly sent that way, > > the recv'd router would ignore all the > > LSAs from the sending router and effectively > > blackhole that router. > > And this is good? I don't think so. > > > > > ** Assuming that you ignore that the chksum is > > also a validation of length, type, etc fields. > > > > If 1 LSA is invalid, the Update pkt needs to be > > resent anyway. The overhead in processing the > > pkt with 1 less LSA is minimal. > > But the LSA is probably invalid in the sender's memory, if it was > corrupted on the wire then the checksum for the packet would fail. So > unless the sender is checking the checksums before putting the LSAs into > the packet, it will continue to send this bad LSA. The the sender should be removing this LSA from its LSDB/memory when it does a chksum validation. > > > Why would you insert new LSAs into the LSDB > > that has invalid information? > > I don't think anyone is suggesting to do this. I would certainly say this > would be the wrong thing to do. > > Regards, > Michael > > > Additionally, instead of running just 1 SPF > > calc for the valid recieved LSAs, by processing > > two pkts, if they are new LSAs, we will most > > likely need to run 2 SPF calcs. > > > > This and more, would suggest to at least me > > that upon chksum failure the pkt should be > > discarded. > > > > The negative effects is that one or more LSAs > > would have to be transmitted. If these LSAs > > the rexmit interval should be small enough > > that it the additional time should be > > insignificant. > > > > Additional issues reside in what to do if > > you process a fewer number of LSAs than was > > then stated in the Update pkt? Can you/should > > you back out the previously inserted LSAs from > > your LSDB? > > > > Mitchell Erblich > > ------------------- > > From owner-ospf@PEACH.EASE.LSOFT.COM Sun Oct 17 21:17:57 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11135 for ; Sun, 17 Oct 2004 21:17:57 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00EB3C33@cherry.ease.lsoft.com>; 17 Oct 2004 21:17:57 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40393000 for OSPF@PEACH.EASE.LSOFT.COM; Sun, 17 Oct 2004 21:17:53 -0400 Received: from 171.68.10.87 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Sun, 17 Oct 2004 21:17:52 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 17 Oct 2004 18:19:25 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9I1HiYJ025996 for ; Sun, 17 Oct 2004 18:17:44 -0700 (PDT) Received: from cisco.com (sjc-vpn1-727.cisco.com [10.21.98.215]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id AXT92035; Sun, 17 Oct 2004 18:18:10 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <41702AB2.A82779CD@earthlink.net> <4172D751.7020203@cisco.com> <4172FBA9.F9C12BB5@earthlink.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <417319D7.9020401@cisco.com> Date: Sun, 17 Oct 2004 18:18:15 -0700 Reply-To: Mailing List Sender: Mailing List From: Michael J Barnes Subject: Re: junk checksum and next LSA are not processed properly To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4172FBA9.F9C12BB5@earthlink.net> Precedence: list Content-Transfer-Encoding: 7bit > Michael J Barnes wrote: > >>Hi Mitchell, >> >>Erblichs wrote: >> >>>Group, >>> >>> Interesting... >>> >>> First, I question that you actually know what >>> the "valid" length of the first LSA is since >>> one or more fields are invalid or the chksum >>> itself is invalid. >> >>If the length field turns out to be invalid, then when you try to process >>the next LSA and you're not looking at the beginning of that LSA packet, >>then you won't get the correct checksum for it either and will skip it >>too. You may waste a few cpu cycles this way (as opposed to quitting as >>soon as one bad LSA is found) but if it turns out that the length field is >>correct you're a lot better off by processing the rest of the LSAs. >> > Wow... > The Update pkt has a invalid chksum. Their is > one chksum for the entire Update pkt. Some > fields you could do some minor validation to > know if they are out of bounds, however, how do > you know what that say the router-id is valid? No, that's not what I meant. We're talking about the LSAs, not packets. If the packet has a bad checksum then of course you don't use it. I was referring to the LSA's checksum, as was Praveen in his question. Michael From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 18 09:29:15 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15483 for ; Mon, 18 Oct 2004 09:29:14 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00EB4785@cherry.ease.lsoft.com>; Mon, 18 Oct 2004 9:29:13 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40484304 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 18 Oct 2004 09:29:11 -0400 Received: from 209.119.1.83 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 18 Oct 2004 09:18:57 -0400 Received: from PEACH.EASE.LSOFT.COM (lists.state.gov) by wnt.dc.lsoft.com (LSMTP for Windows NT v1.1b) with SMTP id <4.FF833DD6@wnt.dc.lsoft.com>; Mon, 18 Oct 2004 9:18:57 -0400 Message-ID: Date: Mon, 18 Oct 2004 09:18:56 -0400 Reply-To: Mailing List Sender: Mailing List From: Mohit Gurnani Subject: Type 5 LSA Forwarding Address To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Hi, I have the following topology: _ _ _ _ _ | | 1 1 DUT-----RT2 2 | 2 | |2 1 RT3------- DUT# ! interface eth1 ip address 1.1.1.1/24 ! interface eth2 ip address 2.2.2.1/24 ip ospf network non-broadcast ! router ospf ospf router-id 10.70.0.112 ! rtr2# ! interface eth1 ip address 1.1.1.2/24 ! interface eth2 ip address 2.2.2.2/24 ip ospf network non-broadcast ! router ospf ospf router-id 10.70.0.113 network 2.2.2.0/24 area 0 neighbor 2.2.2.1 neighbor 2.2.2.3 ! rtr3# interface eth1 ip address 3.3.3.1/24 ! interface eth2 ip address 2.2.2.3/24 ip ospf network non-broadcast ! router ospf ospf router-id 10.70.0.114 redistribute static network 2.2.2.0/24 area 0 network 3.3.3.0/24 area 0 neighbor 2.2.2.2 priority 10 ! ip route 100.100.100.0/24 3.3.3.10 ip route 200.200.200.0/24 eth1 ! RT3 is generating the following two AS External LSAs: ----------------------------------------------------- LS age: 651 Options: 0x2 (*|-|-|-|-|-|E|-) LS Type: AS-external-LSA Link State ID: 100.100.100.0 Advertising Router: 10.70.0.114 LS Seq Number: 80000002 Checksum: 0x4971 Length: 36 Network Mask: /24 Metric Type: 2 TOS: 0 Metric: 20 Forward Address: 3.3.3.10 External Route Tag: 0 LS age: 4 Options: 0x2 (*|-|-|-|-|-|E|-) LS Type: AS-external-LSA Link State ID: 200.200.200.0 Advertising Router: 10.70.0.114 LS Seq Number: 80000001 Checksum: 0x346d Length: 36 Network Mask: /24 Metric Type: 2 TOS: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 The LSA for the route 100.100.100.0 has forwarding address set to 3.3.3.10. Is this the correct behaviour. Or should the forwarding address be set to default - 0.0.0.0? I couldnt find the rules to set External Routes forwarding address in the RFC. Could someone guide me to that? From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 18 09:29:16 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15490 for ; Mon, 18 Oct 2004 09:29:15 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00EB4830@cherry.ease.lsoft.com>; Mon, 18 Oct 2004 9:29:15 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40485188 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 18 Oct 2004 09:29:13 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 18 Oct 2004 09:29:12 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D246AA4C25D for ; Mon, 18 Oct 2004 06:29:11 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16117-08 for ; Mon, 18 Oct 2004 06:29:11 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.24]) by prattle.redback.com (Postfix) with SMTP id B6E4DA4C25A for ; Mon, 18 Oct 2004 06:29:10 -0700 (PDT) References: <41702AB2.A82779CD@earthlink.net> <4172D751.7020203@cisco.com> <4172FBA9.F9C12BB5@earthlink.net> <417319D7.9020401@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <010601c4b516$738fac00$0202a8c0@aceeinspiron> Date: Mon, 18 Oct 2004 09:29:09 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: junk checksum and next LSA are not processed properly To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit I agree totally with Michael and this is also consistent with RFC 2328. The outcome of the LSA header checksum calculation should not affect processing of subsequent LSAs in the same Link State Update packet. With respect to concerns about a corrupted header length, one should assure that the LSA header length doesn't exceed the bounds of the current Link State Update packet (and this is independent of the LSA header outcome). Thanks, Acee ----- Original Message ----- From: "Michael J Barnes" To: Sent: Sunday, October 17, 2004 9:18 PM Subject: Re: junk checksum and next LSA are not processed properly >> Michael J Barnes wrote: >> >>>Hi Mitchell, >>> >>>Erblichs wrote: >>> >>>>Group, >>>> >>>> Interesting... >>>> >>>> First, I question that you actually know what >>>> the "valid" length of the first LSA is since >>>> one or more fields are invalid or the chksum >>>> itself is invalid. >>> >>>If the length field turns out to be invalid, then when you try to process >>>the next LSA and you're not looking at the beginning of that LSA packet, >>>then you won't get the correct checksum for it either and will skip it >>>too. You may waste a few cpu cycles this way (as opposed to quitting as >>>soon as one bad LSA is found) but if it turns out that the length field is >>>correct you're a lot better off by processing the rest of the LSAs. >>> >> Wow... >> The Update pkt has a invalid chksum. Their is >> one chksum for the entire Update pkt. Some >> fields you could do some minor validation to >> know if they are out of bounds, however, how do >> you know what that say the router-id is valid? > > No, that's not what I meant. We're talking about the LSAs, not packets. If > the packet has a bad checksum then of course you don't use it. I was > referring to the LSA's checksum, as was Praveen in his question. > > Michael From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 18 09:38:55 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16115 for ; Mon, 18 Oct 2004 09:38:54 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00EB4921@cherry.ease.lsoft.com>; Mon, 18 Oct 2004 9:38:54 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40485935 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 18 Oct 2004 09:38:52 -0400 Received: from 47.129.242.56 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 18 Oct 2004 09:38:52 -0400 Received: from zbl6c004.us.nortel.com (zbl6c004.corpeast.baynetworks.com [132.245.205.54]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9IDclT02410; Mon, 18 Oct 2004 09:38:47 -0400 (EDT) Received: by zbl6c004.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Oct 2004 09:38:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B517.CA8E02DA" Message-ID: <6204FDDE129D364D8040A98BCCB290EF0FF6AF1D@zbl6c004.corpeast.baynetworks.com> Date: Mon, 18 Oct 2004 09:38:46 -0400 Reply-To: Mailing List Sender: Mailing List From: Daniel Joyal Subject: Re: Some comments on draft-ietf-ospf-ospfv3-mib-08.txt Comments: To: Nic Neate , "vishwas@sinett.com" To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4B517.CA8E02DA Content-Type: text/plain Nic, Thanks for your comments. See mine below. Regards, -Dan > -----Original Message----- > From: Nic Neate [mailto:Nic.Neate@dataconnection.com] > Sent: Friday, October 15, 2004 11:43 AM > To: 'ospf@peach.ease.lsoft.com'; Joyal, Daniel > [BL60:NP31:EXCH]; 'vishwas@sinett.com' > Subject: Some comments on draft-ietf-ospf-ospfv3-mib-08.txt > > > Hi, > > I have a handful of comments on and suggestions for > draft-ietf-ospf-ospfv3-mib-08. Please have a look through > and let me know whether you agree or if I'm misunderstanding anything. > > Interface instance IDs > ---------------------- > > As previously agreed on this list, the ospfv3IfTable should > be indexed by both ospfv3IfIndex and ospfv3InstId, and > correspondingly the ospfv3NbrTable, ospfv3NbmaNbrTable and > ospfv3LinkLsdbTable also need new interface instance index fields. > I believe that this is still under discussion. > It was also recently noted that the instance ID on virtual > interfaces will not always be 0, and therefore needs to be > configurable. I therefore suggest we also add an > ospfv3VirtIfInstId field to the ospfv3VirtIfTable. OK. > > Designated Router identification > -------------------------------- > > The ospfv3IfDesignatedRouter and > ospfv3IfBackupDesignatedRouter fields have been carried over > from the OSPFv2 MIB, with their descriptions updated to note > that these refer to Router IDs rather than IP addresses. > > I think it would be helpful to add further fields providing > the Interface IDs of the designated and backup designated > routers to the network (say, ospfv3IfDesignatedRouterIfId and > ospfv3IfBackupDesignatedRouterIfId). My reasoning is that > while in OSPFv2, the DR's IP address (as provided in the MIB) > uniquely identified a network, in OSPFv3, both the DR's > Router ID and its Interface ID to the link are required. > The local and remote interface IDs are available in the neighbor table. Do we want to replicate that information here? > The ospfv3NbmaNbrTable > ---------------------- > > This table is described as follows. > > -- The OSPFv3 NBMA Neighbor Table describes all configured > -- NBMA neighbors and neighbors dynamically discovered by > -- lower-level protocols such as Inverse Neighbor Discovery. > > I thought that Point-to-Multipoint links also require > explicit neighbor configuration (or discovery by lower-level > protocols) in the same way as NBMA links. If this is the > case, I think it would be clearer if the name of the table > was changed to something less specific such as > ospfv3ConfiguredNbrTable and the comment updated accordingly. Yes. This table is meant to contain configured neighbors for use on NBMA and P2MP interfaces. The name can be changed if it is confusing. > > Other nits > ---------- > > - There are various references to type-5 and type-7 LSAs > thoughout. It would be more consistent with RFC2740 (and > clearer) to refer to these as AS-External-LSAs and NSSA-LSAs > respectively. OK. > > - There are two references to site-local IPv6 addresses. I > believe these have been retired from IPv6. > OK. > - In the descriptions of ospfv3IfRtrDeadInterval and > ospfv3VirtIfRtrDeadInterval, "it's" should be replaced with "its". > OK. > - In the descriptions of ospfv3NbrRtrId and > ospfv3NbmaNbrRtrId, I'm not clear what "represented as type > IpAddress" means (given that these take syntax RouterID). Per Keith McCloghrie's earlier comments, a new TC for RouterId will be created to replace the ipAddress syntax. The description above will be appropriately modified. > > Thanks, > > Nic > > ------_=_NextPart_001_01C4B517.CA8E02DA Content-Type: text/html RE: Some comments on draft-ietf-ospf-ospfv3-mib-08.txt

Nic,

Thanks for your comments. See mine below.

Regards,
-Dan

> -----Original Message-----
> From: Nic Neate [mailto:Nic.Neate@dataconnection.com]
> Sent: Friday, October 15, 2004 11:43 AM
> To: 'ospf@peach.ease.lsoft.com'; Joyal, Daniel
> [BL60:NP31:EXCH]; 'vishwas@sinett.com'
> Subject: Some comments on draft-ietf-ospf-ospfv3-mib-08.txt
>
>
> Hi,
>
> I have a handful of comments on and suggestions for
> draft-ietf-ospf-ospfv3-mib-08.  Please have a look through
> and let me know whether you agree or if I'm misunderstanding anything.
>
> Interface instance IDs
> ----------------------
>
> As previously agreed on this list, the ospfv3IfTable should
> be indexed by both ospfv3IfIndex and ospfv3InstId, and
> correspondingly the ospfv3NbrTable, ospfv3NbmaNbrTable and
> ospfv3LinkLsdbTable also need new interface instance index fields.
>

I believe that this is still under discussion.

> It was also recently noted that the instance ID on virtual
> interfaces will not always be 0, and therefore needs to be
> configurable.  I therefore suggest we also add an
> ospfv3VirtIfInstId field to the ospfv3VirtIfTable.

OK.

>
> Designated Router identification
> --------------------------------
>
> The ospfv3IfDesignatedRouter and
> ospfv3IfBackupDesignatedRouter fields have been carried over
> from the OSPFv2 MIB, with their descriptions updated to note
> that these refer to Router IDs rather than IP addresses.
>
> I think it would be helpful to add further fields providing
> the Interface IDs of the designated and backup designated
> routers to the network (say, ospfv3IfDesignatedRouterIfId and
> ospfv3IfBackupDesignatedRouterIfId).  My reasoning is that
> while in OSPFv2, the DR's IP address (as provided in the MIB)
> uniquely identified a network, in OSPFv3, both the DR's
> Router ID and its Interface ID to the link are required.
>

The local and remote interface IDs are available in the neighbor
table. Do we want to replicate that information here?

> The ospfv3NbmaNbrTable
> ----------------------
>
> This table is described as follows.
>
>     -- The OSPFv3 NBMA Neighbor Table describes all configured
>     -- NBMA neighbors and neighbors dynamically discovered by
>     -- lower-level protocols such as Inverse Neighbor Discovery.
>
> I thought that Point-to-Multipoint links also require
> explicit neighbor configuration (or discovery by lower-level
> protocols) in the same way as NBMA links.  If this is the
> case, I think it would be clearer if the name of the table
> was changed to something less specific such as
> ospfv3ConfiguredNbrTable and the comment updated accordingly.

Yes. This table is meant to contain configured neighbors for use
on NBMA and P2MP interfaces. The name can be changed if it is
confusing.

>
> Other nits
> ----------
>
>  - There are various references to type-5 and type-7 LSAs
> thoughout.  It would be more consistent with RFC2740 (and
> clearer) to refer to these as AS-External-LSAs and NSSA-LSAs
> respectively.

OK.

>
>  - There are two references to site-local IPv6 addresses.  I
> believe these have been retired from IPv6.
>

OK.
 
>  - In the descriptions of ospfv3IfRtrDeadInterval and
> ospfv3VirtIfRtrDeadInterval, "it's" should be replaced with "its".
>
OK.
 
>  - In the descriptions of ospfv3NbrRtrId and
> ospfv3NbmaNbrRtrId, I'm not clear what "represented as type
> IpAddress" means (given that these take syntax RouterID).

Per Keith McCloghrie's earlier comments, a new TC for RouterId will be
created to replace the ipAddress syntax. The description above will
be appropriately modified.

>
> Thanks,
>
> Nic
>
>

------_=_NextPart_001_01C4B517.CA8E02DA-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 18 12:23:42 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29140 for ; Mon, 18 Oct 2004 12:23:42 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00EB4C5F@cherry.ease.lsoft.com>; Mon, 18 Oct 2004 12:23:39 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40514577 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 18 Oct 2004 12:23:38 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 18 Oct 2004 12:23:38 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 882FA2CEB56 for ; Mon, 18 Oct 2004 09:23:37 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11678-03 for ; Mon, 18 Oct 2004 09:23:31 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.39]) by prattle.redback.com (Postfix) with SMTP id AE7132CEB50 for ; Mon, 18 Oct 2004 09:23:30 -0700 (PDT) References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <015101c4b52e$cdd1d360$0202a8c0@aceeinspiron> Date: Mon, 18 Oct 2004 12:23:28 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Type 5 LSA Forwarding Address To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Mohit, Since the behavior isn't precisely specified in RFC 2328 and this is the second list post with this same topology I'm going to go out on a limb and say either is correct. In your topology, rtr3 could safely suppress the specification of a forwarding address since there are no other OSPF routers on the 3.3.3.0 subnet. However, specifying one doesn't impact forwarding and will save a re-origination if a neighbor becomes adjacent at a different time. Hope this helps, Acee ----- Original Message ----- From: "Mohit Gurnani" To: Sent: Monday, October 18, 2004 9:18 AM Subject: Type 5 LSA Forwarding Address > Hi, > > I have the following topology: > > _ _ _ _ _ > | | > 1 1 > DUT-----RT2 > 2 | 2 > | > |2 1 > RT3------- > > > > DUT# > ! > interface eth1 > ip address 1.1.1.1/24 > ! > interface eth2 > ip address 2.2.2.1/24 > ip ospf network non-broadcast > ! > router ospf > ospf router-id 10.70.0.112 > ! > > rtr2# > ! > interface eth1 > ip address 1.1.1.2/24 > ! > interface eth2 > ip address 2.2.2.2/24 > ip ospf network non-broadcast > ! > router ospf > ospf router-id 10.70.0.113 > network 2.2.2.0/24 area 0 > neighbor 2.2.2.1 > neighbor 2.2.2.3 > ! > > rtr3# > interface eth1 > ip address 3.3.3.1/24 > ! > interface eth2 > ip address 2.2.2.3/24 > ip ospf network non-broadcast > ! > router ospf > ospf router-id 10.70.0.114 > redistribute static > network 2.2.2.0/24 area 0 > network 3.3.3.0/24 area 0 > neighbor 2.2.2.2 priority 10 > ! > ip route 100.100.100.0/24 3.3.3.10 > ip route 200.200.200.0/24 eth1 > ! > > RT3 is generating the following two AS External LSAs: > ----------------------------------------------------- > > LS age: 651 > Options: 0x2 (*|-|-|-|-|-|E|-) > LS Type: AS-external-LSA > Link State ID: 100.100.100.0 > Advertising Router: 10.70.0.114 > LS Seq Number: 80000002 > Checksum: 0x4971 > Length: 36 > Network Mask: /24 > Metric Type: 2 > TOS: 0 > Metric: 20 > Forward Address: 3.3.3.10 > External Route Tag: 0 > > > LS age: 4 > Options: 0x2 (*|-|-|-|-|-|E|-) > LS Type: AS-external-LSA > Link State ID: 200.200.200.0 > Advertising Router: 10.70.0.114 > LS Seq Number: 80000001 > Checksum: 0x346d > Length: 36 > Network Mask: /24 > Metric Type: 2 > TOS: 0 > Metric: 20 > Forward Address: 0.0.0.0 > External Route Tag: 0 > > > The LSA for the route 100.100.100.0 has forwarding address set to 3.3.3.10. > Is this the correct behaviour. Or should the forwarding address be set to > default - 0.0.0.0? > > I couldnt find the rules to set External Routes forwarding address in the > RFC. Could someone guide me to that? From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 18 13:34:21 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04816 for ; Mon, 18 Oct 2004 13:34:21 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00EB4CF4@cherry.ease.lsoft.com>; Mon, 18 Oct 2004 13:34:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40522429 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 18 Oct 2004 13:34:20 -0400 Received: from 67.17.166.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 18 Oct 2004 13:34:20 -0400 Received: from CallSciences (unverified [172.21.6.71]) by ucmmail.com (Rockliffe SMTPRA 5.3.11) with SMTP id ; Mon, 18 Oct 2004 13:34:36 -0400 Content-Type: text/plain; not specified Message-ID: Date: Mon, 18 Oct 2004 13:33:49 -0400 Reply-To: Mailing List Sender: Mailing List From: Sean Andersen Subject: Re: Type 5 LSA Forwarding Address To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Mohit, You are redistributing the static route "ip route 100.100.100.0/24 3.3.3.10" into ospf, so the forwarding address for 100.100.100.0/24, based on that static route, is 3.3.3.10, right? Sean -----Original Message----- From: Mohit Gurnani Sent: Mon, 18 Oct 2004 09:18:56 -0400 To: OSPF@PEACH.EASE.LSOFT.COM Subject: Type 5 LSA Forwarding Address Hi, I have the following topology: _ _ _ _ _ | | 1 1 DUT-----RT2 2 | 2 | |2 1 RT3------- DUT# ! interface eth1 ip address 1.1.1.1/24 ! interface eth2 ip address 2.2.2.1/24 ip ospf network non-broadcast ! router ospf ospf router-id 10.70.0.112 ! rtr2# ! interface eth1 ip address 1.1.1.2/24 ! interface eth2 ip address 2.2.2.2/24 ip ospf network non-broadcast ! router ospf ospf router-id 10.70.0.113 network 2.2.2.0/24 area 0 neighbor 2.2.2.1 neighbor 2.2.2.3 ! rtr3# interface eth1 ip address 3.3.3.1/24 ! interface eth2 ip address 2.2.2.3/24 ip ospf network non-broadcast ! router ospf ospf router-id 10.70.0.114 redistribute static network 2.2.2.0/24 area 0 network 3.3.3.0/24 area 0 neighbor 2.2.2.2 priority 10 ! ip route 100.100.100.0/24 3.3.3.10 ip route 200.200.200.0/24 eth1 ! RT3 is generating the following two AS External LSAs: ----------------------------------------------------- LS age: 651 Options: 0x2 (*|-|-|-|-|-|E|-) LS Type: AS-external-LSA Link State ID: 100.100.100.0 Advertising Router: 10.70.0.114 LS Seq Number: 80000002 Checksum: 0x4971 Length: 36 Network Mask: /24 Metric Type: 2 TOS: 0 Metric: 20 Forward Address: 3.3.3.10 External Route Tag: 0 LS age: 4 Options: 0x2 (*|-|-|-|-|-|E|-) LS Type: AS-external-LSA Link State ID: 200.200.200.0 Advertising Router: 10.70.0.114 LS Seq Number: 80000001 Checksum: 0x346d Length: 36 Network Mask: /24 Metric Type: 2 TOS: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0 The LSA for the route 100.100.100.0 has forwarding address set to 3.3.3.10. Is this the correct behaviour. Or should the forwarding address be set to default - 0.0.0.0? I couldnt find the rules to set External Routes forwarding address in the RFC. Could someone guide me to that? From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 18 14:27:31 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09492 for ; Mon, 18 Oct 2004 14:27:31 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00EB4D33@cherry.ease.lsoft.com>; Mon, 18 Oct 2004 14:27:30 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40533752 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 18 Oct 2004 14:27:27 -0400 Received: from 206.190.39.206 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 18 Oct 2004 14:27:27 -0400 Received: from [204.154.128.112] by web53103.mail.yahoo.com via HTTP; Mon, 18 Oct 2004 11:27:28 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20041018182728.54201.qmail@web53103.mail.yahoo.com> Date: Mon, 18 Oct 2004 11:27:28 -0700 Reply-To: Mailing List Sender: Mailing List From: John Pecola Subject: Re: RFC 3137 question To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <005801c4b3ee$6f3e51c0$0202a8c0@aceeinspiron> Precedence: list Hi Acee, I was thinking of the true stub router scenario and in that case, as you have pointed out, there are no implications if the cost is set to 0xFFFF. But there can be a case, like the one pointed out by Sina in this thread, where it is important to set the stub link cost to its actual value. The rfc doesnt mention this and I coulnt think of it :-) Thanks John --- Acee Lindem wrote: > ----- Original Message ----- > From: "John Pecola" > To: > Sent: Thursday, October 14, 2004 3:06 PM > Subject: RFC 3137 question > > > > Hi, > > > > The intent of the stub router advertisement is to > > advertise a path with a very high cost in the hope > > that it will not be used for transiting traffic. > The > > same is not done for stub links. Can there be any > > issues if the cost of stub links is also set to > > 0xFFFF? > > Hi John, > If there are true stub networks (i.e., not > advertised in any > other router's router LSA) then I can't think of any > implications. > LSInfinity is 0xFFFFFF so the total path cost to > reach > the stub network shouldn't be influenced by the > advertised > cost. My question for you is why should it matter? > If you > know the network is a stub it is just as easy to > advertise the > real cost. > > Hope this helps, > Acee > > > > > > Thanks > > John > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Declare Yourself - Register online to vote today! > > http://vote.yahoo.com > _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 18 14:51:16 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12062 for ; Mon, 18 Oct 2004 14:51:15 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00EB4F6F@cherry.ease.lsoft.com>; Mon, 18 Oct 2004 14:51:14 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40537714 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 18 Oct 2004 14:51:11 -0400 Received: from 207.217.120.54 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 18 Oct 2004 14:51:11 -0400 Received: from user-uinj90h.dialup.mindspring.com ([165.121.164.17] helo=earthlink.net) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1CJcb8-0005f1-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 18 Oct 2004 11:51:10 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <41702AB2.A82779CD@earthlink.net> <4172D751.7020203@cisco.com> <4172FBA9.F9C12BB5@earthlink.net> <417319D7.9020401@cisco.com> <010601c4b516$738fac00$0202a8c0@aceeinspiron> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <41741109.36B6B1C6@earthlink.net> Date: Mon, 18 Oct 2004 11:52:57 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: junk checksum and next LSA are not processed properly To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee and Michael, Yes, same diff. Acee see below. After the 16 bit chksum field is the 16 bit LSA header length field. How do you know that in a series of LSAs within a Update pkt, that if #1 has a corrupted chksum that the corruption is not at the length field? You can do some minor age, type, etc field validations, but how do you validate a LSA header length field? Without knowing the value of that field, how do you know the begining of the next LSA header???? Only, the corrupted LSA, is the last LSA, then you can make this length check. (Yes, you can see if the length or summed LSAs lengths is greater, equal, or less than, to what was specified in the Update pkt length field. But it won't get you anywhere if it was short. You can also check LSAs counts.) IMO, At that point, the most careful thing is to stop processing the LSAs within the update packet. The worst thing that will happen is a resend of the LSAs not acked. Since the overhead is in the processing of the pkt and it will be needed to be resent anyway (we assumed that we had at least 1 bad LSA anyway), making it just a we bit shorter by attempting to process additional LSAs should be insignificant. Their may be minor bandwidth issues with wireless links, but I assume that LSDB consistency would be a much larger concern. So Acee Lindem what do we save/gain when you attempt to process later LSAs after you see that one has been corrupted??????? Or what was the motivation to specify this in the RFC? Mitchell Erblich ---------------- Acee Lindem wrote: > > I agree totally with Michael and this is also consistent with > RFC 2328. The outcome of the LSA header checksum calculation > should not affect processing of subsequent LSAs in the same > Link State Update packet. > > With respect to concerns about a corrupted header length, one > should assure that the LSA header length doesn't exceed the > bounds of the current Link State Update packet (and this > is independent of the LSA header outcome). > > Thanks, > Acee > > ----- Original Message ----- > From: "Michael J Barnes" > To: > Sent: Sunday, October 17, 2004 9:18 PM > Subject: Re: junk checksum and next LSA are not processed properly > > >> Michael J Barnes wrote: > >> > >>>Hi Mitchell, > >>> > >>>Erblichs wrote: > >>> > >>>>Group, > >>>> > >>>> Interesting... > >>>> > >>>> First, I question that you actually know what > >>>> the "valid" length of the first LSA is since > >>>> one or more fields are invalid or the chksum > >>>> itself is invalid. > >>> > >>>If the length field turns out to be invalid, then when you try to process > >>>the next LSA and you're not looking at the beginning of that LSA packet, > >>>then you won't get the correct checksum for it either and will skip it > >>>too. You may waste a few cpu cycles this way (as opposed to quitting as > >>>soon as one bad LSA is found) but if it turns out that the length field is > >>>correct you're a lot better off by processing the rest of the LSAs. > >>> > >> Wow... > >> The Update pkt has a invalid chksum. Their is > >> one chksum for the entire Update pkt. Some > >> fields you could do some minor validation to > >> know if they are out of bounds, however, how do > >> you know what that say the router-id is valid? > > > > No, that's not what I meant. We're talking about the LSAs, not packets. If > > the packet has a bad checksum then of course you don't use it. I was > > referring to the LSA's checksum, as was Praveen in his question. > > > > Michael From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 20 16:03:56 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19731 for ; Wed, 20 Oct 2004 16:03:55 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00EB8B84@cherry.ease.lsoft.com>; Wed, 20 Oct 2004 16:03:55 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40873525 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 20 Oct 2004 16:03:53 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 20 Oct 2004 16:03:53 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id EC8145C5304 for ; Wed, 20 Oct 2004 13:03:52 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23144-04 for ; Wed, 20 Oct 2004 13:03:52 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.14]) by prattle.redback.com (Postfix) with SMTP id C2E935C5303 for ; Wed, 20 Oct 2004 13:03:51 -0700 (PDT) References: <41702AB2.A82779CD@earthlink.net> <4172D751.7020203@cisco.com> <4172FBA9.F9C12BB5@earthlink.net> <417319D7.9020401@cisco.com> <010601c4b516$738fac00$0202a8c0@aceeinspiron> <41741109.36B6B1C6@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <028201c4b6df$e9fa3e30$0202a8c0@aceeinspiron> Date: Wed, 20 Oct 2004 16:03:48 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: junk checksum and next LSA are not processed properly To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hello Mitchell, At a general level one could argue that attempting to process LSAs subsequent to the one with the bad checksum is consistent with Jon Postal's Robustness Principle "be liberal in what you accept from others". Specific OSPF, I think it makes more sense to continue since there are many ways for a checksum error to be introduced and a bad length is only one of them. For example, if there is a software bug in the transfer from the Link State Database to the packet (or the constuction of a self-originated LSA) continuing processsing LSAs could help narrow down which LSA is in error (eventually, it will be the only one on the neighbor's retransmission list). I'm not sure we are going to come to agreement on this. However, RFC 2328 is not going to be amended unless there is a clear majority who believe the current behavior is broken. Thanks, Acee ----- Original Message ----- From: "Erblichs" To: Sent: Monday, October 18, 2004 2:52 PM Subject: Re: junk checksum and next LSA are not processed properly > Acee and Michael, > > Yes, same diff. Acee see below. > > After the 16 bit chksum field is the 16 bit > LSA header length field. > > How do you know that in a series of LSAs > within a Update pkt, that if #1 has a > corrupted chksum that the corruption is > not at the length field? > > You can do some minor age, type, etc > field validations, but how do you validate > a LSA header length field? Without knowing > the value of that field, how do you know the > begining of the next LSA header???? Only, > the corrupted LSA, is the last LSA, then you > can make this length check. > > (Yes, you > can see if the length or summed LSAs lengths is > greater, equal, or less than, to what was > specified in the Update pkt length field. But > it won't get you anywhere if it was short. > You can also check LSAs counts.) > > IMO, At that point, the most careful thing is > to stop processing the LSAs within the > update packet. > > The worst thing that will happen is a resend > of the LSAs not acked. Since the overhead is > in the processing of the pkt and it will > be needed to be resent anyway (we assumed that > we had at least 1 bad LSA anyway), making it just > a we bit shorter by attempting to process additional > LSAs should be insignificant. > > Their may be minor bandwidth issues with > wireless links, but I assume that LSDB > consistency would be a much larger concern. > > So Acee Lindem what do we save/gain when you attempt > to process later LSAs after you see that one has > been corrupted??????? > > Or what was the motivation to specify this in the > RFC? > > Mitchell Erblich > ---------------- > > Acee Lindem wrote: >> >> I agree totally with Michael and this is also consistent with >> RFC 2328. The outcome of the LSA header checksum calculation >> should not affect processing of subsequent LSAs in the same >> Link State Update packet. >> >> With respect to concerns about a corrupted header length, one >> should assure that the LSA header length doesn't exceed the >> bounds of the current Link State Update packet (and this >> is independent of the LSA header outcome). >> >> Thanks, >> Acee >> >> ----- Original Message ----- >> From: "Michael J Barnes" >> To: >> Sent: Sunday, October 17, 2004 9:18 PM >> Subject: Re: junk checksum and next LSA are not processed properly >> >> >> Michael J Barnes wrote: >> >> >> >>>Hi Mitchell, >> >>> >> >>>Erblichs wrote: >> >>> >> >>>>Group, >> >>>> >> >>>> Interesting... >> >>>> >> >>>> First, I question that you actually know what >> >>>> the "valid" length of the first LSA is since >> >>>> one or more fields are invalid or the chksum >> >>>> itself is invalid. >> >>> >> >>>If the length field turns out to be invalid, then when you try to process >> >>>the next LSA and you're not looking at the beginning of that LSA packet, >> >>>then you won't get the correct checksum for it either and will skip it >> >>>too. You may waste a few cpu cycles this way (as opposed to quitting as >> >>>soon as one bad LSA is found) but if it turns out that the length field is >> >>>correct you're a lot better off by processing the rest of the LSAs. >> >>> >> >> Wow... >> >> The Update pkt has a invalid chksum. Their is >> >> one chksum for the entire Update pkt. Some >> >> fields you could do some minor validation to >> >> know if they are out of bounds, however, how do >> >> you know what that say the router-id is valid? >> > >> > No, that's not what I meant. We're talking about the LSAs, not packets. If >> > the packet has a bad checksum then of course you don't use it. I was >> > referring to the LSA's checksum, as was Praveen in his question. >> > >> > Michael From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 20 16:10:32 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20795 for ; Wed, 20 Oct 2004 16:10:31 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00EB8A2A@cherry.ease.lsoft.com>; Wed, 20 Oct 2004 16:10:31 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40874060 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 20 Oct 2004 16:10:29 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 20 Oct 2004 16:10:29 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id C17F25578DB for ; Wed, 20 Oct 2004 13:10:28 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24048-07 for ; Wed, 20 Oct 2004 13:10:28 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.14]) by prattle.redback.com (Postfix) with SMTP id DD3CA5578DA for ; Wed, 20 Oct 2004 13:10:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <02b301c4b6e0$d602e520$0202a8c0@aceeinspiron> Date: Wed, 20 Oct 2004 16:10:24 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: junk checksum and next LSA are not processed properly To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Acee Lindem" To: "Mailing List" Sent: Wednesday, October 20, 2004 4:03 PM Subject: Re: junk checksum and next LSA are not processed properly > Hello Mitchell, > > At a general level one could argue that attempting to process LSAs > subsequent to the one with the bad checksum is consistent with > Jon Postal's Robustness Principle "be liberal in what you accept > from others". > > Specific OSPF, I think it makes more sense to continue since there > are many ways for a checksum error to be introduced and a bad > length is only one of them. For example, if there is a software bug > in the transfer from the Link State Database to the packet (or the > constuction of a self-originated LSA) continuing processsing LSAs > could help narrow down which LSA is in error (eventually, it will be > the only one on the neighbor's retransmission list). And even if the errors are logged with the LSA is identified (as I remembered that I do ;^), reducing the impact of the error by allowing any valid subsequent LSAs to be be flooded and used by other OSPF routers in the OSPF routing domain is a good thing. > > I'm not sure we are going to come to agreement on this. However, > RFC 2328 is not going to be amended unless there is a clear majority > who believe the current behavior is broken. > > Thanks, > Acee > > ----- Original Message ----- > From: "Erblichs" > To: > Sent: Monday, October 18, 2004 2:52 PM > Subject: Re: junk checksum and next LSA are not processed properly > > >> Acee and Michael, >> >> Yes, same diff. Acee see below. >> >> After the 16 bit chksum field is the 16 bit >> LSA header length field. >> >> How do you know that in a series of LSAs >> within a Update pkt, that if #1 has a >> corrupted chksum that the corruption is >> not at the length field? >> >> You can do some minor age, type, etc >> field validations, but how do you validate >> a LSA header length field? Without knowing >> the value of that field, how do you know the >> begining of the next LSA header???? Only, >> the corrupted LSA, is the last LSA, then you >> can make this length check. >> >> (Yes, you >> can see if the length or summed LSAs lengths is >> greater, equal, or less than, to what was >> specified in the Update pkt length field. But >> it won't get you anywhere if it was short. >> You can also check LSAs counts.) >> >> IMO, At that point, the most careful thing is >> to stop processing the LSAs within the >> update packet. >> >> The worst thing that will happen is a resend >> of the LSAs not acked. Since the overhead is >> in the processing of the pkt and it will >> be needed to be resent anyway (we assumed that >> we had at least 1 bad LSA anyway), making it just >> a we bit shorter by attempting to process additional >> LSAs should be insignificant. >> >> Their may be minor bandwidth issues with >> wireless links, but I assume that LSDB >> consistency would be a much larger concern. >> >> So Acee Lindem what do we save/gain when you attempt >> to process later LSAs after you see that one has >> been corrupted??????? >> >> Or what was the motivation to specify this in the >> RFC? >> >> Mitchell Erblich >> ---------------- >> >> Acee Lindem wrote: >>> >>> I agree totally with Michael and this is also consistent with >>> RFC 2328. The outcome of the LSA header checksum calculation >>> should not affect processing of subsequent LSAs in the same >>> Link State Update packet. >>> >>> With respect to concerns about a corrupted header length, one >>> should assure that the LSA header length doesn't exceed the >>> bounds of the current Link State Update packet (and this >>> is independent of the LSA header outcome). >>> >>> Thanks, >>> Acee >>> >>> ----- Original Message ----- >>> From: "Michael J Barnes" >>> To: >>> Sent: Sunday, October 17, 2004 9:18 PM >>> Subject: Re: junk checksum and next LSA are not processed properly >>> >>> >> Michael J Barnes wrote: >>> >> >>> >>>Hi Mitchell, >>> >>> >>> >>>Erblichs wrote: >>> >>> >>> >>>>Group, >>> >>>> >>> >>>> Interesting... >>> >>>> >>> >>>> First, I question that you actually know what >>> >>>> the "valid" length of the first LSA is since >>> >>>> one or more fields are invalid or the chksum >>> >>>> itself is invalid. >>> >>> >>> >>>If the length field turns out to be invalid, then when you try to process >>> >>>the next LSA and you're not looking at the beginning of that LSA packet, >>> >>>then you won't get the correct checksum for it either and will skip it >>> >>>too. You may waste a few cpu cycles this way (as opposed to quitting as >>> >>>soon as one bad LSA is found) but if it turns out that the length field is >>> >>>correct you're a lot better off by processing the rest of the LSAs. >>> >>> >>> >> Wow... >>> >> The Update pkt has a invalid chksum. Their is >>> >> one chksum for the entire Update pkt. Some >>> >> fields you could do some minor validation to >>> >> know if they are out of bounds, however, how do >>> >> you know what that say the router-id is valid? >>> > >>> > No, that's not what I meant. We're talking about the LSAs, not packets. If >>> > the packet has a bad checksum then of course you don't use it. I was >>> > referring to the LSA's checksum, as was Praveen in his question. >>> > >>> > Michael From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 20 16:13:38 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21277 for ; Wed, 20 Oct 2004 16:13:37 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00EB8A3A@cherry.ease.lsoft.com>; Wed, 20 Oct 2004 16:13:37 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40874240 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 20 Oct 2004 16:13:35 -0400 Received: from 171.71.176.70 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 20 Oct 2004 16:13:35 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 20 Oct 2004 13:23:46 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9KKDTk2015244 for ; Wed, 20 Oct 2004 13:13:29 -0700 (PDT) Received: from cisco.com (dhcp-128-107-178-215.cisco.com [128.107.178.215]) by mira-sjc5-f.cisco.com (MOS 3.4.5-GR) with ESMTP id AXX19765; Wed, 20 Oct 2004 13:14:14 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 References: <02b301c4b6e0$d602e520$0202a8c0@aceeinspiron> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4176C70D.4010905@cisco.com> Date: Wed, 20 Oct 2004 13:14:05 -0700 Reply-To: Mailing List Sender: Mailing List From: Michael J Barnes Subject: Re: junk checksum and next LSA are not processed properly To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <02b301c4b6e0$d602e520$0202a8c0@aceeinspiron> Precedence: list Content-Transfer-Encoding: 7bit Right on! ;-) Acee Lindem wrote: > ----- Original Message ----- > From: "Acee Lindem" > To: "Mailing List" > Sent: Wednesday, October 20, 2004 4:03 PM > Subject: Re: junk checksum and next LSA are not processed properly > > >> Hello Mitchell, >> >> At a general level one could argue that attempting to process LSAs >> subsequent to the one with the bad checksum is consistent with >> Jon Postal's Robustness Principle "be liberal in what you accept >> from others". >> >> Specific OSPF, I think it makes more sense to continue since there >> are many ways for a checksum error to be introduced and a bad >> length is only one of them. For example, if there is a software bug >> in the transfer from the Link State Database to the packet (or the >> constuction of a self-originated LSA) continuing processsing LSAs >> could help narrow down which LSA is in error (eventually, it will be >> the only one on the neighbor's retransmission list). > > > And even if the errors are logged with the LSA is identified (as I > remembered > that I do ;^), reducing the impact of the error by allowing any valid > subsequent > LSAs to be be flooded and used by other OSPF routers in the OSPF routing > domain is a good thing. > >> >> I'm not sure we are going to come to agreement on this. However, >> RFC 2328 is not going to be amended unless there is a clear majority >> who believe the current behavior is broken. >> >> Thanks, >> Acee >> >> ----- Original Message ----- >> From: "Erblichs" >> To: >> Sent: Monday, October 18, 2004 2:52 PM >> Subject: Re: junk checksum and next LSA are not processed properly >> >> >>> Acee and Michael, >>> >>> Yes, same diff. Acee see below. >>> >>> After the 16 bit chksum field is the 16 bit >>> LSA header length field. >>> >>> How do you know that in a series of LSAs >>> within a Update pkt, that if #1 has a >>> corrupted chksum that the corruption is >>> not at the length field? >>> >>> You can do some minor age, type, etc >>> field validations, but how do you validate >>> a LSA header length field? Without knowing >>> the value of that field, how do you know the >>> begining of the next LSA header???? Only, >>> the corrupted LSA, is the last LSA, then you >>> can make this length check. >>> >>> (Yes, you >>> can see if the length or summed LSAs lengths is >>> greater, equal, or less than, to what was >>> specified in the Update pkt length field. But >>> it won't get you anywhere if it was short. >>> You can also check LSAs counts.) >>> >>> IMO, At that point, the most careful thing is >>> to stop processing the LSAs within the >>> update packet. >>> >>> The worst thing that will happen is a resend >>> of the LSAs not acked. Since the overhead is >>> in the processing of the pkt and it will >>> be needed to be resent anyway (we assumed that >>> we had at least 1 bad LSA anyway), making it just >>> a we bit shorter by attempting to process additional >>> LSAs should be insignificant. >>> >>> Their may be minor bandwidth issues with >>> wireless links, but I assume that LSDB >>> consistency would be a much larger concern. >>> >>> So Acee Lindem what do we save/gain when you attempt >>> to process later LSAs after you see that one has >>> been corrupted??????? >>> >>> Or what was the motivation to specify this in the >>> RFC? >>> >>> Mitchell Erblich >>> ---------------- >>> >>> Acee Lindem wrote: >>> >>>> >>>> I agree totally with Michael and this is also consistent with >>>> RFC 2328. The outcome of the LSA header checksum calculation >>>> should not affect processing of subsequent LSAs in the same >>>> Link State Update packet. >>>> >>>> With respect to concerns about a corrupted header length, one >>>> should assure that the LSA header length doesn't exceed the >>>> bounds of the current Link State Update packet (and this >>>> is independent of the LSA header outcome). >>>> >>>> Thanks, >>>> Acee >>>> >>>> ----- Original Message ----- >>>> From: "Michael J Barnes" >>>> To: >>>> Sent: Sunday, October 17, 2004 9:18 PM >>>> Subject: Re: junk checksum and next LSA are not processed properly >>>> >>>> >> Michael J Barnes wrote: >>>> >> >>>> >>>Hi Mitchell, >>>> >>> >>>> >>>Erblichs wrote: >>>> >>> >>>> >>>>Group, >>>> >>>> >>>> >>>> Interesting... >>>> >>>> >>>> >>>> First, I question that you actually know what >>>> >>>> the "valid" length of the first LSA is since >>>> >>>> one or more fields are invalid or the chksum >>>> >>>> itself is invalid. >>>> >>> >>>> >>>If the length field turns out to be invalid, then when you try to >>>> process >>>> >>>the next LSA and you're not looking at the beginning of that LSA >>>> packet, >>>> >>>then you won't get the correct checksum for it either and will >>>> skip it >>>> >>>too. You may waste a few cpu cycles this way (as opposed to >>>> quitting as >>>> >>>soon as one bad LSA is found) but if it turns out that the length >>>> field is >>>> >>>correct you're a lot better off by processing the rest of the LSAs. >>>> >>> >>>> >> Wow... >>>> >> The Update pkt has a invalid chksum. Their is >>>> >> one chksum for the entire Update pkt. Some >>>> >> fields you could do some minor validation to >>>> >> know if they are out of bounds, however, how do >>>> >> you know what that say the router-id is valid? >>>> > >>>> > No, that's not what I meant. We're talking about the LSAs, not >>>> packets. If >>>> > the packet has a bad checksum then of course you don't use it. I was >>>> > referring to the LSA's checksum, as was Praveen in his question. >>>> > >>>> > Michael > > From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 20 20:28:35 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25059 for ; Wed, 20 Oct 2004 20:28:35 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00EB9070@cherry.ease.lsoft.com>; Wed, 20 Oct 2004 20:28:35 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40898476 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 20 Oct 2004 20:28:33 -0400 Received: from 207.217.121.183 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 20 Oct 2004 20:28:33 -0400 Received: from user-2ivfj32.dialup.mindspring.com ([165.247.204.98] helo=earthlink.net) by pop-a065c05.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CKQog-00066p-00 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 20 Oct 2004 17:28:31 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <41702AB2.A82779CD@earthlink.net> <4172D751.7020203@cisco.com> <4172FBA9.F9C12BB5@earthlink.net> <417319D7.9020401@cisco.com> <010601c4b516$738fac00$0202a8c0@aceeinspiron> <41741109.36B6B1C6@earthlink.net> <028201c4b6df$e9fa3e30$0202a8c0@aceeinspiron> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <4177030B.50722EA2@earthlink.net> Date: Wed, 20 Oct 2004 17:30:03 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: junk checksum and next LSA are not processed properly To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Acee Lindem, Let me start off that I first attempted to follow the RFC suggested approach without checks for validating the LSA length. In actuality, the length is also transparently validated by the next LSAs chksum computation. And my issue is when a length from a early LSA is bad when a chksum validation fails. First, I see us trying to achieve a Trusted Network environment and not relying on unverifyable information. We do this with: IPvX CRC chks, header chksums, v2 and IPv6 authentication, TCP's ISS, TCP's Syn attack protection, etc) To have made OSPF robust with respect to this type of "rare" event (length and chksum err) and being efficient, probably would probably have required the ability to Request LSAs in a different order, however.. Acee see the bottom of this email section for what I would suggest as a transparent change. Once we accept a LSA for forwarding, it is our responsibility that the the cksum remains valid. Circular buff error msgs pointing to the first LSA with a particular problem would be my first thing to look at than rexmit lists. The msg could be displayed by the sender upon each nbr rexmit and by the recvr's Update processing routine. IMO, LSDBs are incremntally walked to often, LSAs placed on rexmit lists, that trying to see one LSA staying on the list would be fairly difficult. Maybe in small networks it might not be an issue. IFF the length was also an issue with the chksum failure, I don't see that any further LSAs will be processed within the Update. If this occurs and every LSA is walked and noted as a msg, you would not know the offending LSA. Each LSA would still be in the rexmit list. This is NOT robust. However, if only the first LSA within a Update was noted as an error/msg, you know that at least each reported LSA is actually bad with a failed chksum. Seeing the same LSA err msg over and over is easier to see. However to be fair, it probably would still be "acceptable" to chk the next LSA in the Update. However, if that chksum failed and say the LSA type was out of bounds, etc, I would think you would want to get a fresh Update because the length may be an issue. If you actually had a transient problem with just 1 LSA you would see only one msg vs displaying a large number of secondary msgs for the other skipped LSAs. Remember, we are supposely dealing with a rare event. If that nbr chksum "event" was noted and you are concerned that 1 or more LSAs may be valid behind the bad LSA, you could attempt to process them. But the hope was that the bad LSA was a transient event that was corrected with the rexmit. IMO, if a number of LSAs are repeatedly being rexmit'ed, then..... Lastly, I thought I was told that under a chksum failure the during a LSDB walk, the router would reboot. This was discussed when DNA LSAs could be sent in Demand Circuits. This effectly removes the router from the env. Thus, if I were to suggest any changes to the RFC, I would suggest that upon each rexmit from the nbr rexmit queue, the LSA order be shifted by 1 in a circular manner. IMO, this would add a level of robustness by preventing a single LSA with a bad length preventing later LSAs from being accepted. Mitchell Erblich ----------------------------- Acee Lindem wrote: > > Hello Mitchell, > > At a general level one could argue that attempting to process LSAs > subsequent to the one with the bad checksum is consistent with > Jon Postal's Robustness Principle "be liberal in what you accept > from others". > > Specific OSPF, I think it makes more sense to continue since there > are many ways for a checksum error to be introduced and a bad > length is only one of them. For example, if there is a software bug > in the transfer from the Link State Database to the packet (or the > constuction of a self-originated LSA) continuing processsing LSAs > could help narrow down which LSA is in error (eventually, it will be > the only one on the neighbor's retransmission list). > > I'm not sure we are going to come to agreement on this. However, > RFC 2328 is not going to be amended unless there is a clear majority > who believe the current behavior is broken. > > Thanks, > Acee > > ----- Original Message ----- > From: "Erblichs" > To: > Sent: Monday, October 18, 2004 2:52 PM > Subject: Re: junk checksum and next LSA are not processed properly > > > Acee and Michael, > > > > Yes, same diff. Acee see below. > > > > After the 16 bit chksum field is the 16 bit > > LSA header length field. > > > > How do you know that in a series of LSAs > > within a Update pkt, that if #1 has a > > corrupted chksum that the corruption is > > not at the length field? > > > > You can do some minor age, type, etc > > field validations, but how do you validate > > a LSA header length field? Without knowing > > the value of that field, how do you know the > > begining of the next LSA header???? Only, > > the corrupted LSA, is the last LSA, then you > > can make this length check. > > > > (Yes, you > > can see if the length or summed LSAs lengths is > > greater, equal, or less than, to what was > > specified in the Update pkt length field. But > > it won't get you anywhere if it was short. > > You can also check LSAs counts.) > > > > IMO, At that point, the most careful thing is > > to stop processing the LSAs within the > > update packet. > > > > The worst thing that will happen is a resend > > of the LSAs not acked. Since the overhead is > > in the processing of the pkt and it will > > be needed to be resent anyway (we assumed that > > we had at least 1 bad LSA anyway), making it just > > a we bit shorter by attempting to process additional > > LSAs should be insignificant. > > > > Their may be minor bandwidth issues with > > wireless links, but I assume that LSDB > > consistency would be a much larger concern. > > > > So Acee Lindem what do we save/gain when you attempt > > to process later LSAs after you see that one has > > been corrupted??????? > > > > Or what was the motivation to specify this in the > > RFC? > > > > Mitchell Erblich > > ---------------- > > > > Acee Lindem wrote: > >> > >> I agree totally with Michael and this is also consistent with > >> RFC 2328. The outcome of the LSA header checksum calculation > >> should not affect processing of subsequent LSAs in the same > >> Link State Update packet. > >> > >> With respect to concerns about a corrupted header length, one > >> should assure that the LSA header length doesn't exceed the > >> bounds of the current Link State Update packet (and this > >> is independent of the LSA header outcome). > >> > >> Thanks, > >> Acee > >> > >> ----- Original Message ----- > >> From: "Michael J Barnes" > >> To: > >> Sent: Sunday, October 17, 2004 9:18 PM > >> Subject: Re: junk checksum and next LSA are not processed properly > >> > >> >> Michael J Barnes wrote: > >> >> > >> >>>Hi Mitchell, > >> >>> > >> >>>Erblichs wrote: > >> >>> > >> >>>>Group, > >> >>>> > >> >>>> Interesting... > >> >>>> > >> >>>> First, I question that you actually know what > >> >>>> the "valid" length of the first LSA is since > >> >>>> one or more fields are invalid or the chksum > >> >>>> itself is invalid. > >> >>> > >> >>>If the length field turns out to be invalid, then when you try to process > >> >>>the next LSA and you're not looking at the beginning of that LSA packet, > >> >>>then you won't get the correct checksum for it either and will skip it > >> >>>too. You may waste a few cpu cycles this way (as opposed to quitting as > >> >>>soon as one bad LSA is found) but if it turns out that the length field is > >> >>>correct you're a lot better off by processing the rest of the LSAs. > >> >>> > >> >> Wow... > >> >> The Update pkt has a invalid chksum. Their is > >> >> one chksum for the entire Update pkt. Some > >> >> fields you could do some minor validation to > >> >> know if they are out of bounds, however, how do > >> >> you know what that say the router-id is valid? > >> > > >> > No, that's not what I meant. We're talking about the LSAs, not packets. If > >> > the packet has a bad checksum then of course you don't use it. I was > >> > referring to the LSA's checksum, as was Praveen in his question. > >> > > >> > Michael From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 21 07:23:25 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01882 for ; Thu, 21 Oct 2004 07:23:24 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <8.00EB9BCD@cherry.ease.lsoft.com>; Thu, 21 Oct 2004 7:23:21 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 40981074 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 21 Oct 2004 07:23:18 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 21 Oct 2004 07:23:18 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 65D3F2854CA for ; Thu, 21 Oct 2004 04:23:18 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07398-04 for ; Thu, 21 Oct 2004 04:23:17 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.55]) by prattle.redback.com (Postfix) with SMTP id 431A82854C9 for ; Thu, 21 Oct 2004 04:23:17 -0700 (PDT) References: <41702AB2.A82779CD@earthlink.net> <4172D751.7020203@cisco.com> <4172FBA9.F9C12BB5@earthlink.net> <417319D7.9020401@cisco.com> <010601c4b516$738fac00$0202a8c0@aceeinspiron> <41741109.36B6B1C6@earthlink.net> <028201c4b6df$e9fa3e30$0202a8c0@aceeinspiron> <4177030B.50722EA2@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <053301c4b760$59c59180$0202a8c0@aceeinspiron> Date: Wed, 20 Oct 2004 22:38:50 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: junk checksum and next LSA are not processed properly To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Mitchell, I don't think that such an approach is necessary and it seems that the suggested change to the retransmission processing is simply a consequence to modifying the LS update LSA reception to bail out once an LSA with an invalid checksum is encountered. However, you are welcome to submit a draft documenting the problem and suggested solution for review by the WG. Thanks, Acee ----- Original Message ----- From: "Erblichs" To: Sent: Wednesday, October 20, 2004 8:30 PM Subject: Re: junk checksum and next LSA are not processed properly > Acee Lindem, > > Let me start off that I first attempted to > follow the RFC suggested approach without > checks for validating the LSA length. In > actuality, the length is also transparently > validated by the next LSAs chksum computation. > > And my issue is when a length from a early LSA > is bad when a chksum validation fails. > > First, I see us trying to achieve a Trusted > Network environment and not relying on > unverifyable information. We do this with: > IPvX CRC chks, header chksums, > v2 and IPv6 authentication, TCP's ISS, TCP's > Syn attack protection, etc) > To have made OSPF robust with respect to this > type of "rare" event (length and chksum err) > and being efficient, probably would probably have > required the ability to Request LSAs in a different > order, however.. > > Acee see the bottom of this email section > for what I would suggest as a transparent > change. > > Once we accept a LSA for forwarding, it is > our responsibility that the the cksum remains > valid. > > Circular buff error msgs pointing to the first > LSA with a particular problem would be my > first thing to look at than rexmit lists. The > msg could be displayed by the sender upon each > nbr rexmit and by the recvr's Update processing > routine. > > IMO, LSDBs are incremntally walked to often, > LSAs placed on rexmit lists, that trying to > see one LSA staying on the list would be fairly > difficult. Maybe in small networks it might > not be an issue. > > IFF the length was also an issue with the chksum > failure, I don't see that any further LSAs will > be processed within the Update. If this occurs > and every LSA is walked and noted as a msg, you > would not know the offending LSA. Each LSA would > still be in the rexmit list. This is NOT robust. > > However, if only the first LSA within a Update > was noted as an error/msg, you know that at least > each reported LSA is actually bad with a failed > chksum. Seeing the same LSA err msg over and over > is easier to see. > > However to be fair, it probably would still > be "acceptable" to chk the next LSA in the Update. > However, if that chksum failed and say the > LSA type was out of bounds, etc, I would think > you would want to get a fresh Update because the > length may be an issue. If you actually had a > transient problem with just 1 LSA you would see > only one msg vs displaying a large number of > secondary msgs for the other skipped LSAs. > Remember, we are supposely dealing with a rare > event. If that nbr chksum "event" was noted > and you are concerned that 1 or more LSAs may > be valid behind the bad LSA, you could attempt > to process them. But the hope was that the bad > LSA was a transient event that was corrected with > the rexmit. IMO, if a number of LSAs are repeatedly > being rexmit'ed, then..... > > Lastly, I thought I was told that under a chksum > failure the during a LSDB walk, the router would > reboot. This was discussed when DNA LSAs could > be sent in Demand Circuits. > This effectly removes the router from the env. > > Thus, if I were to suggest any changes to the > RFC, I would suggest that upon each rexmit from > the nbr rexmit queue, the LSA order be shifted > by 1 in a circular manner. IMO, this would add > a level of robustness by preventing a single > LSA with a bad length preventing later LSAs > from being accepted. > > Mitchell Erblich > > ----------------------------- > Acee Lindem wrote: >> >> Hello Mitchell, >> >> At a general level one could argue that attempting to process LSAs >> subsequent to the one with the bad checksum is consistent with >> Jon Postal's Robustness Principle "be liberal in what you accept >> from others". >> >> Specific OSPF, I think it makes more sense to continue since there >> are many ways for a checksum error to be introduced and a bad >> length is only one of them. For example, if there is a software bug >> in the transfer from the Link State Database to the packet (or the >> constuction of a self-originated LSA) continuing processsing LSAs >> could help narrow down which LSA is in error (eventually, it will be >> the only one on the neighbor's retransmission list). >> >> I'm not sure we are going to come to agreement on this. However, >> RFC 2328 is not going to be amended unless there is a clear majority >> who believe the current behavior is broken. >> >> Thanks, >> Acee >> >> ----- Original Message ----- >> From: "Erblichs" >> To: >> Sent: Monday, October 18, 2004 2:52 PM >> Subject: Re: junk checksum and next LSA are not processed properly >> >> > Acee and Michael, >> > >> > Yes, same diff. Acee see below. >> > >> > After the 16 bit chksum field is the 16 bit >> > LSA header length field. >> > >> > How do you know that in a series of LSAs >> > within a Update pkt, that if #1 has a >> > corrupted chksum that the corruption is >> > not at the length field? >> > >> > You can do some minor age, type, etc >> > field validations, but how do you validate >> > a LSA header length field? Without knowing >> > the value of that field, how do you know the >> > begining of the next LSA header???? Only, >> > the corrupted LSA, is the last LSA, then you >> > can make this length check. >> > >> > (Yes, you >> > can see if the length or summed LSAs lengths is >> > greater, equal, or less than, to what was >> > specified in the Update pkt length field. But >> > it won't get you anywhere if it was short. >> > You can also check LSAs counts.) >> > >> > IMO, At that point, the most careful thing is >> > to stop processing the LSAs within the >> > update packet. >> > >> > The worst thing that will happen is a resend >> > of the LSAs not acked. Since the overhead is >> > in the processing of the pkt and it will >> > be needed to be resent anyway (we assumed that >> > we had at least 1 bad LSA anyway), making it just >> > a we bit shorter by attempting to process additional >> > LSAs should be insignificant. >> > >> > Their may be minor bandwidth issues with >> > wireless links, but I assume that LSDB >> > consistency would be a much larger concern. >> > >> > So Acee Lindem what do we save/gain when you attempt >> > to process later LSAs after you see that one has >> > been corrupted??????? >> > >> > Or what was the motivation to specify this in the >> > RFC? >> > >> > Mitchell Erblich >> > ---------------- >> > >> > Acee Lindem wrote: >> >> >> >> I agree totally with Michael and this is also consistent with >> >> RFC 2328. The outcome of the LSA header checksum calculation >> >> should not affect processing of subsequent LSAs in the same >> >> Link State Update packet. >> >> >> >> With respect to concerns about a corrupted header length, one >> >> should assure that the LSA header length doesn't exceed the >> >> bounds of the current Link State Update packet (and this >> >> is independent of the LSA header outcome). >> >> >> >> Thanks, >> >> Acee >> >> >> >> ----- Original Message ----- >> >> From: "Michael J Barnes" >> >> To: >> >> Sent: Sunday, October 17, 2004 9:18 PM >> >> Subject: Re: junk checksum and next LSA are not processed properly >> >> >> >> >> Michael J Barnes wrote: >> >> >> >> >> >>>Hi Mitchell, >> >> >>> >> >> >>>Erblichs wrote: >> >> >>> >> >> >>>>Group, >> >> >>>> >> >> >>>> Interesting... >> >> >>>> >> >> >>>> First, I question that you actually know what >> >> >>>> the "valid" length of the first LSA is since >> >> >>>> one or more fields are invalid or the chksum >> >> >>>> itself is invalid. >> >> >>> >> >> >>>If the length field turns out to be invalid, then when you try to process >> >> >>>the next LSA and you're not looking at the beginning of that LSA packet, >> >> >>>then you won't get the correct checksum for it either and will skip it >> >> >>>too. You may waste a few cpu cycles this way (as opposed to quitting as >> >> >>>soon as one bad LSA is found) but if it turns out that the length field is >> >> >>>correct you're a lot better off by processing the rest of the LSAs. >> >> >>> >> >> >> Wow... >> >> >> The Update pkt has a invalid chksum. Their is >> >> >> one chksum for the entire Update pkt. Some >> >> >> fields you could do some minor validation to >> >> >> know if they are out of bounds, however, how do >> >> >> you know what that say the router-id is valid? >> >> > >> >> > No, that's not what I meant. We're talking about the LSAs, not packets. If >> >> > the packet has a bad checksum then of course you don't use it. I was >> >> > referring to the LSA's checksum, as was Praveen in his question. >> >> > >> >> > Michael From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 22 16:21:42 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07678 for ; Fri, 22 Oct 2004 16:21:41 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00EBBD7D@cherry.ease.lsoft.com>; Fri, 22 Oct 2004 16:21:38 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41218383 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 22 Oct 2004 16:21:34 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 22 Oct 2004 16:11:34 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06357; Fri, 22 Oct 2004 16:11:32 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200410222011.QAA06357@ietf.org> Date: Fri, 22 Oct 2004 16:11:32 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-ospfv3-auth-05.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : Authentication/Confidentiality for OSPFv3 Author(s) : M. Gupta, N. Melam Filename : draft-ietf-ospf-ospfv3-auth-05.txt Pages : 13 Date : 2004-10-22 This document describes means/mechanisms to provide authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension Header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-ospfv3-auth-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-22162023.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-ospfv3-auth-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-22162023.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 22 16:22:02 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07743 for ; Fri, 22 Oct 2004 16:22:01 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <20.00EBBD61@cherry.ease.lsoft.com>; Fri, 22 Oct 2004 16:22:01 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41218427 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 22 Oct 2004 16:22:00 -0400 Received: from 132.151.1.176 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 22 Oct 2004 16:12:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06398; Fri, 22 Oct 2004 16:11:59 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200410222011.QAA06398@ietf.org> Date: Fri, 22 Oct 2004 16:11:59 -0400 Reply-To: Mailing List Sender: Mailing List From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ospf-multi-area-adj-03.txt Comments: To: i-d-announce@ietf.org To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Shortest Path First IGP Working Group of the IETF. Title : OSPF Multi-Area Adjacency Author(s) : S. Mirtorabi, et al. Filename : draft-ietf-ospf-multi-area-adj-03.txt Pages : 12 Date : 2004-10-22 This memo documents an extension to OSPF to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra-area path to the corresponding areas sharing the same link. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-multi-area-adj-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ospf-multi-area-adj-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ospf-multi-area-adj-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-22162029.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ospf-multi-area-adj-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ospf-multi-area-adj-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-22162029.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 25 00:42:14 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00329 for ; Mon, 25 Oct 2004 00:42:14 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00EBF28D@cherry.ease.lsoft.com>; Mon, 25 Oct 2004 0:42:15 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41551272 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Oct 2004 00:42:13 -0400 Received: from 63.113.148.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 25 Oct 2004 00:42:13 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id VAA00609; Sun, 24 Oct 2004 21:42:12 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BA4C.FE84FBEB" Thread-Topic: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? Thread-Index: AcS6S/P2NwJDiP8FReitc8SqbZAplw== Message-ID: <7549C475A1F3CF47ABCA660BF44738B36F5A3B@legolas.rs.riverstonenet.com> Date: Sun, 24 Oct 2004 21:42:12 -0700 Reply-To: Mailing List Sender: Mailing List From: "Mollin, Arvind - LiqwidKrystal" Subject: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C4BA4C.FE84FBEB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have two routers connected back to back through a gig link. I have configured 100 VLANs in that single gig link, now each vlan act as virtual interface. I have configured 100 neighbors on each router using these 100 virtual interfaces. All the neighbors are in backbone. See the figure below, =20 ( 100 nbrs )R1 -------------100 vlans ------------------ R2 ( 100 nbrs ) =20 After sometime I could see all nbrs flapping often. What could be the reason for this ?? Is this topology right?, Has anybody tested with this kind of setup ?? =20 Thanks Arvind =20 ------_=_NextPart_001_01C4BA4C.FE84FBEB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

  I have two routers connected back to back = through a gig link. I have configured 100 VLANs in that single gig link, now each vlan = act as virtual interface. I have configured 100 neighbors on each router using = these 100 virtual interfaces. All the neighbors are in backbone. See the = figure below,

 

( 100 nbrs )R1 -------------100 vlans = ------------------ R2 ( 100 nbrs )

 

After sometime I could see all nbrs flapping often. = What could be the reason for this ??

Is this topology right?, Has anybody tested with this = kind of setup ??

 

Thanks

Arvind

 

------_=_NextPart_001_01C4BA4C.FE84FBEB-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 25 01:29:04 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04571 for ; Mon, 25 Oct 2004 01:29:04 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00EBF389@cherry.ease.lsoft.com>; Mon, 25 Oct 2004 1:29:03 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41555228 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Oct 2004 01:29:02 -0400 Received: from 61.144.161.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 25 Oct 2004 01:29:01 -0400 Received: from dell60 (mta1.huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0I64003DBIEIM8@mta1.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Oct 2004 12:42:20 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: multipart/alternative; boundary="Boundary_(ID_FE1qgWWYeWO3K/nLz1nWEQ)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com Message-ID: <002101c4ba4f$adb8f920$cf04120a@in.huawei.com> Date: Mon, 25 Oct 2004 10:31:22 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: Re: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <7549C475A1F3CF47ABCA660BF44738B36F5A3B@legolas.rs.riverstonene t.com> Precedence: list This is a multi-part message in MIME format. --Boundary_(ID_FE1qgWWYeWO3K/nLz1nWEQ) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Verify if the router id of any of the peers are by mistake matching !!! else; could you provide some LSA database info & the config of each router! ~Sujay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mollin, Arvind - LiqwidKrystal Sent: Monday, October 25, 2004 10:12 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? Hi, I have two routers connected back to back through a gig link. I have configured 100 VLANs in that single gig link, now each vlan act as virtual interface. I have configured 100 neighbors on each router using these 100 virtual interfaces. All the neighbors are in backbone. See the figure below, ( 100 nbrs )R1 -------------100 vlans ------------------ R2 ( 100 nbrs ) After sometime I could see all nbrs flapping often. What could be the reason for this ?? Is this topology right?, Has anybody tested with this kind of setup ?? Thanks Arvind --Boundary_(ID_FE1qgWWYeWO3K/nLz1nWEQ) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT Message
Verify if the router id of any of the peers are by mistake matching !!!
else;
could you provide some LSA database info & the config of each router!
 
~Sujay
-----Original Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Mollin, Arvind - LiqwidKrystal
Sent: Monday, October 25, 2004 10:12 AM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ??

Hi,

  I have two routers connected back to back through a gig link. I have configured 100 VLANs in that single gig link, now each vlan act as virtual interface. I have configured 100 neighbors on each router using these 100 virtual interfaces. All the neighbors are in backbone. See the figure below,

 

( 100 nbrs )R1 -------------100 vlans ------------------ R2 ( 100 nbrs )

 

After sometime I could see all nbrs flapping often. What could be the reason for this ??

Is this topology right?, Has anybody tested with this kind of setup ??

 

Thanks

Arvind

 

--Boundary_(ID_FE1qgWWYeWO3K/nLz1nWEQ)-- From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 25 01:29:22 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04595 for ; Mon, 25 Oct 2004 01:29:22 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00EBF35A@cherry.ease.lsoft.com>; Mon, 25 Oct 2004 1:29:21 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41555276 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Oct 2004 01:29:11 -0400 Received: from 61.144.161.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 25 Oct 2004 01:29:08 -0400 Received: from NitinKCL7064 (mta1.huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0I64003APIHUFV@mta1.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Oct 2004 12:44:20 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-MS-TNEF-Correlator: 00000000E4FE19584F3DCD4683963B447AFB40CD24305300 X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Message-ID: <000701c4ba4f$f4842460$ae04120a@in.huawei.com> Date: Mon, 25 Oct 2004 10:33:23 +0530 Reply-To: Mailing List Sender: Mailing List From: Nitin Kakkar Subject: Re: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <7549C475A1F3CF47ABCA660BF44738B36F5A3B@legolas.rs.riverstonene t.com> Precedence: list Content-Transfer-Encoding: 7BIT Most probable reason seems to be that Hello's doesn't come on time and adjacencies are dropped. Some time later hellos come and adjacencies are reestablished. May be you can increase your adjacency dead timer and try again. HTH Nitin -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Mollin, Arvind - LiqwidKrystal Sent: 2004Ae10OA25EO 10:12 To: OSPF@PEACH.EASE.LSOFT.COM Subject: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? Hi, I have two routers connected back to back through a gig link. I have configured 100 VLANs in that single gig link, now each vlan act as virtual interface. I have configured 100 neighbors on each router using these 100 virtual interfaces. All the neighbors are in backbone. See the figure below, ( 100 nbrs )R1 -------------100 vlans ------------------ R2 ( 100 nbrs ) After sometime I could see all nbrs flapping often. What could be the reason for this ?? Is this topology right?, Has anybody tested with this kind of setup ?? Thanks Arvind From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 25 01:34:44 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04903 for ; Mon, 25 Oct 2004 01:34:44 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00EBF299@cherry.ease.lsoft.com>; Mon, 25 Oct 2004 1:34:44 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41556302 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Oct 2004 01:34:42 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 25 Oct 2004 01:34:42 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Thread-Topic: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? Thread-Index: AcS6VH+jrTYXV+zbQAGDD/sx89B5rgAAGGEg Message-ID: Date: Sun, 24 Oct 2004 22:40:19 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Arvind, Instead of increasing the "Router Dead Interval", you could instead use techniques as given in http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-08.txt Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Nitin Kakkar Sent: Monday, October 25, 2004 10:33 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? Most probable reason seems to be that Hello's doesn't come on time and adjacencies are dropped. Some time later hellos come and adjacencies are reestablished. May be you can increase your adjacency dead timer and try again. HTH Nitin -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Mollin, Arvind - LiqwidKrystal Sent: 2004Ae10OA25EO 10:12 To: OSPF@PEACH.EASE.LSOFT.COM Subject: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? Hi, I have two routers connected back to back through a gig link. I have configured 100 VLANs in that single gig link, now each vlan act as virtual interface. I have configured 100 neighbors on each router using these 100 virtual interfaces. All the neighbors are in backbone. See the figure below, ( 100 nbrs )R1 -------------100 vlans ------------------ R2 ( 100 nbrs ) After sometime I could see all nbrs flapping often. What could be the reason for this ?? Is this topology right?, Has anybody tested with this kind of setup ?? Thanks Arvind From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 25 02:22:24 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22362 for ; Mon, 25 Oct 2004 02:22:23 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00EBF3D1@cherry.ease.lsoft.com>; Mon, 25 Oct 2004 2:22:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41558660 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Oct 2004 02:22:21 -0400 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 25 Oct 2004 02:22:21 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i9P6MK991492 for ; Sun, 24 Oct 2004 23:22:20 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i9P6MFe67664 for ; Sun, 24 Oct 2004 23:22:15 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619) References: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.619) Message-ID: <33BC9824-264E-11D9-A663-000D93298656@juniper.net> Date: Mon, 25 Oct 2004 00:22:10 -0600 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: Precedence: list Content-Transfer-Encoding: 7bit This kind of behavior is related to the quality of the implementation. Some implementations can handle 100 neighbors with aplomb. There's no reason this shouldn't be stable, particularly with the large default timer values. But my rants on this subject are well known... On Oct 24, 2004, at 11:40 PM, Vishwas Manral wrote: > Hi Arvind, > > Instead of increasing the "Router Dead Interval", you could instead use > techniques as given in > http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-08.txt > > Thanks, > Vishwas > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > Nitin > Kakkar > Sent: Monday, October 25, 2004 10:33 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: What will happen in this kind of topology with 100 nbrs > and > 2000 ASEs ?? > > Most probable reason seems to be that Hello's doesn't come on time and > adjacencies are dropped. Some time later hellos come and adjacencies > are > reestablished. May be you can increase your adjacency dead timer and > try > again. > HTH > Nitin > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > Mollin, > Arvind - LiqwidKrystal > Sent: 2004Ae10OA25EO 10:12 > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: What will happen in this kind of topology with 100 nbrs and > 2000 > ASEs ?? > > > > Hi, > > I have two routers connected back to back through a gig link. I have > configured 100 VLANs in that single gig link, now each vlan act as > virtual > interface. I have configured 100 neighbors on each router using these > 100 > virtual interfaces. All the neighbors are in backbone. See the figure > below, > > > > ( 100 nbrs )R1 -------------100 vlans ------------------ R2 ( 100 nbrs > ) > > > > After sometime I could see all nbrs flapping often. What could be the > reason > for this ?? > > Is this topology right?, Has anybody tested with this kind of setup ?? > > > > Thanks > > Arvind > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 25 02:45:10 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24153 for ; Mon, 25 Oct 2004 02:45:10 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00EBF458@cherry.ease.lsoft.com>; Mon, 25 Oct 2004 2:45:10 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41559922 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Oct 2004 02:45:08 -0400 Received: from 63.113.148.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 25 Oct 2004 02:45:08 -0400 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id XAA11739; Sun, 24 Oct 2004 23:45:07 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? Thread-Index: AcS6WwAYfzyewFU6SoKa7wYkOCpS4wAAj5gA Message-ID: <7549C475A1F3CF47ABCA660BF44738B36F5A50@legolas.rs.riverstonenet.com> Date: Sun, 24 Oct 2004 23:45:04 -0700 Reply-To: Mailing List Sender: Mailing List From: "Mollin, Arvind - LiqwidKrystal" Subject: Re: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Thanks for one n all. Well this case is something related to congestion as Vishwas have pointed out. Suppose R1 sends a update, ( that is each neighbor will send an update 100 updates altogether) then R2 would send back 99*100 updates to R1, thus R1 is busy in processing them and doesn't send hello's or doesn't process hellos, also sometimes the buffer overflows. These are the reason why ospf flaps. So in this kind of topology the processing will hog the CPU. Well, I have read that some implementations can handle upto 750 neighbors. !! provided congestions are avoided. --Arvind -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Dave Katz Sent: Monday, October 25, 2004 11:52 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? This kind of behavior is related to the quality of the implementation. Some implementations can handle 100 neighbors with aplomb. There's no reason this shouldn't be stable, particularly with the large default timer values. But my rants on this subject are well known... On Oct 24, 2004, at 11:40 PM, Vishwas Manral wrote: > Hi Arvind, > > Instead of increasing the "Router Dead Interval", you could instead use > techniques as given in > http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-08.txt > > Thanks, > Vishwas > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > Nitin > Kakkar > Sent: Monday, October 25, 2004 10:33 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: What will happen in this kind of topology with 100 nbrs > and > 2000 ASEs ?? > > Most probable reason seems to be that Hello's doesn't come on time and > adjacencies are dropped. Some time later hellos come and adjacencies > are > reestablished. May be you can increase your adjacency dead timer and > try > again. > HTH > Nitin > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > Mollin, > Arvind - LiqwidKrystal > Sent: 2004Ae10OA25EO 10:12 > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: What will happen in this kind of topology with 100 nbrs and > 2000 > ASEs ?? > > > > Hi, > > I have two routers connected back to back through a gig link. I have > configured 100 VLANs in that single gig link, now each vlan act as > virtual > interface. I have configured 100 neighbors on each router using these > 100 > virtual interfaces. All the neighbors are in backbone. See the figure > below, > > > > ( 100 nbrs )R1 -------------100 vlans ------------------ R2 ( 100 nbrs > ) > > > > After sometime I could see all nbrs flapping often. What could be the > reason > for this ?? > > Is this topology right?, Has anybody tested with this kind of setup ?? > > > > Thanks > > Arvind > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 25 03:03:40 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24978 for ; Mon, 25 Oct 2004 03:03:40 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00EBF42F@cherry.ease.lsoft.com>; Mon, 25 Oct 2004 3:03:40 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41560231 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Oct 2004 03:03:39 -0400 Received: from 192.11.226.161 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 25 Oct 2004 02:53:39 -0400 Received: from ci1093exch002u.wins.lucent.com (h135-252-12-239.lucent.com [135.252.12.239]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i9P6rain022885 for ; Mon, 25 Oct 2004 01:53:38 -0500 (CDT) Received: by ci1093exch002u.cn.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 25 Oct 2004 14:53:36 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <6999EF22C12CD4119A6800508B65021F07F64496@CI0027EXCH001U> Date: Mon, 25 Oct 2004 14:53:33 +0800 Reply-To: Mailing List Sender: Mailing List From: "Yu, Mu Zhi (Alex)" Subject: Re: What will happen in this kind of topology with 100 nbrs and 2 000 ASEs ?? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Which kind of router in cisco or juniper could support the mechanisms described in draft-ietf-ospf-scalability-08.txt? especially the = "exponential backoff algorithm" and "water mark" mechanisms. #Alex -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of = Mollin, Arvind - LiqwidKrystal Sent: 2004=E5=B9=B410=E6=9C=8825=E6=97=A5 MuZhiPM 02:45 To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: What will happen in this kind of topology with 100 nbrs = and 2000 ASEs ?? Thanks for one n all. Well this case is something related to congestion as Vishwas have pointed out. Suppose R1 sends a update, ( that is each neighbor will send an update 100 updates altogether) then R2 would send back 99*100 updates to R1, thus R1 is busy in processing them and doesn't send hello's or doesn't process hellos, also sometimes the buffer overflows. These are the reason why ospf flaps. So in this kind of topology the processing will hog the CPU. Well, I have read that some implementations can handle upto 750 neighbors. !! provided congestions are avoided. --Arvind -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Dave Katz Sent: Monday, October 25, 2004 11:52 AM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: What will happen in this kind of topology with 100 nbrs = and 2000 ASEs ?? This kind of behavior is related to the quality of the implementation. Some implementations can handle 100 neighbors with aplomb. There's no reason this shouldn't be stable, particularly with the large default timer values. But my rants on this subject are well known... On Oct 24, 2004, at 11:40 PM, Vishwas Manral wrote: > Hi Arvind, > > Instead of increasing the "Router Dead Interval", you could instead use > techniques as given in > = http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-08.txt > > Thanks, > Vishwas > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > Nitin > Kakkar > Sent: Monday, October 25, 2004 10:33 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: What will happen in this kind of topology with 100 nbrs > and > 2000 ASEs ?? > > Most probable reason seems to be that Hello's doesn't come on time = and > adjacencies are dropped. Some time later hellos come and adjacencies > are > reestablished. May be you can increase your adjacency dead timer and > try > again. > HTH > Nitin > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > Mollin, > Arvind - LiqwidKrystal > Sent: 2004Ae10OA25EO 10:12 > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: What will happen in this kind of topology with 100 nbrs and > 2000 > ASEs ?? > > > > Hi, > > I have two routers connected back to back through a gig link. I = have > configured 100 VLANs in that single gig link, now each vlan act as > virtual > interface. I have configured 100 neighbors on each router using these > 100 > virtual interfaces. All the neighbors are in backbone. See the figure > below, > > > > ( 100 nbrs )R1 -------------100 vlans ------------------ R2 ( 100 = nbrs > ) > > > > After sometime I could see all nbrs flapping often. What could be the > reason > for this ?? > > Is this topology right?, Has anybody tested with this kind of setup = ?? > > > > Thanks > > Arvind > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 25 03:16:52 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26014 for ; Mon, 25 Oct 2004 03:16:51 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00EBF4FE@cherry.ease.lsoft.com>; Mon, 25 Oct 2004 3:16:49 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41561833 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Oct 2004 03:16:47 -0400 Received: from 207.17.137.64 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 25 Oct 2004 03:16:47 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id i9P7GkBm064013 for ; Mon, 25 Oct 2004 00:16:46 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i9P7Gke71933 for ; Mon, 25 Oct 2004 00:16:46 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619) References: <6999EF22C12CD4119A6800508B65021F07F64496@CI0027EXCH001U> Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.619) Message-ID: Date: Mon, 25 Oct 2004 01:16:41 -0600 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: What will happen in this kind of topology with 100 nbrs and 2 000 ASEs ?? To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6999EF22C12CD4119A6800508B65021F07F64496@CI0027EXCH001U> Precedence: list Content-Transfer-Encoding: 7bit On Oct 25, 2004, at 12:53 AM, Yu, Mu Zhi (Alex) wrote: > Which kind of router in cisco or juniper could support the mechanisms > described in draft-ietf-ospf-scalability-08.txt? especially the > "exponential > backoff algorithm" and "water mark" mechanisms. I can't comment on the cisco implementation (haven't looked at the code in most of a decade; I assume it has improved in that time.) The Juniper implementation has a number of mechanisms that it uses to improve scalability, some of which resemble some of the schemes in the draft and some of which don't. The details are proprietary. > > #Alex > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > Mollin, > Arvind - LiqwidKrystal > Sent: 2004 $BG/ (B10 $B7n (B25 $BF| (B MuZhiPM 02:45 > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: What will happen in this kind of topology with 100 nbrs > and > 2000 ASEs ?? > > > Thanks for one n all. > Well this case is something related to congestion as Vishwas have > pointed out. Suppose R1 sends a update, ( that is each neighbor will > send an update 100 updates altogether) then R2 would send back 99*100 > updates to R1, thus R1 is busy in processing them and doesn't send > hello's or doesn't process hellos, also sometimes the buffer overflows. > These are the reason why ospf flaps. So in this kind of topology the > processing will hog the CPU. > Well, I have read that some implementations can handle upto 750 > neighbors. !! provided congestions are avoided. > > --Arvind > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Dave > Katz > Sent: Monday, October 25, 2004 11:52 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: What will happen in this kind of topology with 100 nbrs > and > 2000 ASEs ?? > > This kind of behavior is related to the quality of the implementation. > Some implementations can handle 100 neighbors with aplomb. There's no > reason this shouldn't be stable, particularly with the large default > timer values. > > But my rants on this subject are well known... > > > On Oct 24, 2004, at 11:40 PM, Vishwas Manral wrote: > >> Hi Arvind, >> >> Instead of increasing the "Router Dead Interval", you could instead > use >> techniques as given in >> http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-08.txt >> >> Thanks, >> Vishwas >> >> -----Original Message----- >> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of >> Nitin >> Kakkar >> Sent: Monday, October 25, 2004 10:33 AM >> To: OSPF@PEACH.EASE.LSOFT.COM >> Subject: Re: What will happen in this kind of topology with 100 nbrs >> and >> 2000 ASEs ?? >> >> Most probable reason seems to be that Hello's doesn't come on time and >> adjacencies are dropped. Some time later hellos come and adjacencies >> are >> reestablished. May be you can increase your adjacency dead timer and >> try >> again. >> HTH >> Nitin >> -----Original Message----- >> From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of >> Mollin, >> Arvind - LiqwidKrystal >> Sent: 2004Ae10OA25EO 10:12 >> To: OSPF@PEACH.EASE.LSOFT.COM >> Subject: What will happen in this kind of topology with 100 nbrs and >> 2000 >> ASEs ?? >> >> >> >> Hi, >> >> I have two routers connected back to back through a gig link. I have >> configured 100 VLANs in that single gig link, now each vlan act as >> virtual >> interface. I have configured 100 neighbors on each router using these >> 100 >> virtual interfaces. All the neighbors are in backbone. See the figure >> below, >> >> >> >> ( 100 nbrs )R1 -------------100 vlans ------------------ R2 ( 100 nbrs >> ) >> >> >> >> After sometime I could see all nbrs flapping often. What could be the >> reason >> for this ?? >> >> Is this topology right?, Has anybody tested with this kind of setup ?? >> >> >> >> Thanks >> >> Arvind >> >> > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 25 03:19:57 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26162 for ; Mon, 25 Oct 2004 03:19:56 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <10.00EBF567@cherry.ease.lsoft.com>; Mon, 25 Oct 2004 3:19:55 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41562011 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Oct 2004 03:19:53 -0400 Received: from 207.17.137.57 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 25 Oct 2004 03:19:53 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id i9P7Jr991726 for ; Mon, 25 Oct 2004 00:19:53 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.139] (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id i9P7Jle72214 for ; Mon, 25 Oct 2004 00:19:47 -0700 (PDT) (envelope-from dkatz@juniper.net) Mime-Version: 1.0 (Apple Message framework v619) References: <6999EF22C12CD4119A6800508B65021F07F64496@CI0027EXCH001U> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.619) Message-ID: <3DC61E42-2656-11D9-A663-000D93298656@juniper.net> Date: Mon, 25 Oct 2004 01:19:42 -0600 Reply-To: Mailing List Sender: Mailing List From: Dave Katz Subject: Re: What will happen in this kind of topology with 100 nbrs and 2 000 ASEs ?? To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <6999EF22C12CD4119A6800508B65021F07F64496@CI0027EXCH001U> Precedence: list Content-Transfer-Encoding: 7bit On Oct 25, 2004, at 12:45 AM, Mollin, Arvind - LiqwidKrystal wrote: > Thanks for one n all. > Well this case is something related to congestion as Vishwas have > pointed out. Suppose R1 sends a update, ( that is each neighbor will > send an update 100 updates altogether) then R2 would send back 99*100 > updates to R1, thus R1 is busy in processing them and doesn't send > hello's or doesn't process hellos, also sometimes the buffer overflows. > These are the reason why ospf flaps. So in this kind of topology the > processing will hog the CPU. There's no reason that a router should be so busy as to not send or process hellos if it is properly implemented, excepting the case that the arrival rate of Hellos is so high that there is insufficient resources to process them. Otherwise, the worst that should happen is that convergence will slow due to the processing load. > Well, I have read that some implementations can handle upto 750 > neighbors. !! provided congestions are avoided. Yup. From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 25 03:34:03 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26952 for ; Mon, 25 Oct 2004 03:34:02 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <9.00EBF3AD@cherry.ease.lsoft.com>; Mon, 25 Oct 2004 3:34:00 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41562723 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Oct 2004 03:33:57 -0400 Received: from 207.217.121.247 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 25 Oct 2004 03:33:57 -0400 Received: from user-2inja86.dialup.mindspring.com ([165.121.169.6] helo=earthlink.net) by pop-a065c32.pas.sa.earthlink.net with esmtp (Exim 3.33 #1) id 1CLzMa-0003aU-00 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Oct 2004 00:33:56 -0700 X-Sender: "Erblichs" <@smtp.earthlink.net> (Unverified) X-Mailer: Mozilla 4.72 [en]C-gatewaynet (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <7549C475A1F3CF47ABCA660BF44738B36F5A50@legolas.rs.riverstonenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <417CACAA.67BC8638@earthlink.net> Date: Mon, 25 Oct 2004 00:35:06 -0700 Reply-To: Mailing List Sender: Mailing List From: Erblichs Subject: Re: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Arvind and group, The question as to this implimentation is whether the input queue is undergoing tail drop or whether hellos are processed after the adjs are dropped. A simple test that checks the input queue for hellos that would sustain the adjs should identify whether the former or later condition is occuring. Depending on the result of this test, then measures could be implimented that MIGHT scale the implimentation. Mitchell Erblich ---------------- "Mollin, Arvind - LiqwidKrystal" wrote: > > Thanks for one n all. > Well this case is something related to congestion as Vishwas have > pointed out. Suppose R1 sends a update, ( that is each neighbor will > send an update 100 updates altogether) then R2 would send back 99*100 > updates to R1, thus R1 is busy in processing them and doesn't send > hello's or doesn't process hellos, also sometimes the buffer overflows. > These are the reason why ospf flaps. So in this kind of topology the > processing will hog the CPU. > Well, I have read that some implementations can handle upto 750 > neighbors. !! provided congestions are avoided. > > --Arvind > > -----Original Message----- > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Dave > Katz > Sent: Monday, October 25, 2004 11:52 AM > To: OSPF@PEACH.EASE.LSOFT.COM > Subject: Re: What will happen in this kind of topology with 100 nbrs and > 2000 ASEs ?? > > This kind of behavior is related to the quality of the implementation. > Some implementations can handle 100 neighbors with aplomb. There's no > reason this shouldn't be stable, particularly with the large default > timer values. > > But my rants on this subject are well known... > > On Oct 24, 2004, at 11:40 PM, Vishwas Manral wrote: > > > Hi Arvind, > > > > Instead of increasing the "Router Dead Interval", you could instead > use > > techniques as given in > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-scalability-08.txt > > > > Thanks, > > Vishwas > > > > -----Original Message----- > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of > > Nitin > > Kakkar > > Sent: Monday, October 25, 2004 10:33 AM > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: Re: What will happen in this kind of topology with 100 nbrs > > and > > 2000 ASEs ?? > > > > Most probable reason seems to be that Hello's doesn't come on time and > > adjacencies are dropped. Some time later hellos come and adjacencies > > are > > reestablished. May be you can increase your adjacency dead timer and > > try > > again. > > HTH > > Nitin > > -----Original Message----- > > From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of > > Mollin, > > Arvind - LiqwidKrystal > > Sent: 2004Ae10OA25EO 10:12 > > To: OSPF@PEACH.EASE.LSOFT.COM > > Subject: What will happen in this kind of topology with 100 nbrs and > > 2000 > > ASEs ?? > > > > > > > > Hi, > > > > I have two routers connected back to back through a gig link. I have > > configured 100 VLANs in that single gig link, now each vlan act as > > virtual > > interface. I have configured 100 neighbors on each router using these > > 100 > > virtual interfaces. All the neighbors are in backbone. See the figure > > below, > > > > > > > > ( 100 nbrs )R1 -------------100 vlans ------------------ R2 ( 100 nbrs > > ) > > > > > > > > After sometime I could see all nbrs flapping often. What could be the > > reason > > for this ?? > > > > Is this topology right?, Has anybody tested with this kind of setup ?? > > > > > > > > Thanks > > > > Arvind > > > > From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 25 15:16:14 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25291 for ; Mon, 25 Oct 2004 15:16:14 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00EC0089@cherry.ease.lsoft.com>; Mon, 25 Oct 2004 15:16:14 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41674194 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Oct 2004 15:16:12 -0400 Received: from 131.228.20.26 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 25 Oct 2004 15:06:11 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9PJ67t28142 for ; Mon, 25 Oct 2004 22:06:09 +0300 (EET DST) X-Scanned: Mon, 25 Oct 2004 22:03:22 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9PJ3MrZ013047 for ; Mon, 25 Oct 2004 22:03:22 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00VL4kIh; Mon, 25 Oct 2004 22:03:20 EEST Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9PJ3JS22703 for ; Mon, 25 Oct 2004 22:03:19 +0300 (EET DST) Received: from daebe009.NOE.Nokia.com ([10.241.35.109]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Oct 2004 14:01:31 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: I-D ACTION:draft-ietf-ospf-ospfv3-auth-05.txt Thread-Index: AcS4gGp9JM0K8i0qT8CPky7EeFMWewCOgx9AAAKiUfA= X-OriginalArrivalTime: 25 Oct 2004 19:01:31.0154 (UTC) FILETIME=[09F43720:01C4BAC5] Message-ID: <8D260779A766FB4A9C1739A476F84FA4026AB5DD@daebe009.americas.nokia.com> Date: Mon, 25 Oct 2004 14:01:30 -0500 Reply-To: Mailing List Sender: Mailing List From: Mukesh Gupta Subject: Re: I-D ACTION:draft-ietf-ospf-ospfv3-auth-05.txt To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi All, We have addressed the following things in this revision: - Changed rule 3 & 5 to add OSPF with AH/ESP. - Rules for interfaces and virtual links were separated to remove iface = column - Made AES-CBC & HMAC SHA1 a MUST and other non-stream ciphers a SHOULD. - Use of stream ciphers with manual keys is now prevented - Made changing keys a "SHOULD" from "MAY".=20 - Mentioning that the SAs are per-link (as defined in OSPFv3 RFC). = Therefore, all the OSPF instances have to use same SA. - Referring to New version of IPsec drafts or old versions of IPsec RFCs = now - Some paragraphs were rephrased for clarity - ADDed OSPFv2 in References - Moved to the newer boilerplate This draft does NOT address all the comments that we received from IESG and on the list.=20 We will be submitting another revision to address the remaining changes. Please review this version and see if we got things right. Regards Mukesh & Suresh > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org]On Behalf Of ext > Internet-Drafts@ietf.org > Sent: Friday, October 22, 2004 1:12 PM > To: i-d-announce@ietf.org > Cc: ospf@peach.ease.lsoft.com > Subject: I-D ACTION:draft-ietf-ospf-ospfv3-auth-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Open Shortest Path First IGP=20 > Working Group of the IETF. >=20 > Title : Authentication/Confidentiality for OSPFv3 > Author(s) : M. Gupta, N. Melam > Filename : draft-ietf-ospf-ospfv3-auth-05.txt > Pages : 13 > Date : 2004-10-22 > =09 > This document describes means/mechanisms to provide=20 > authentication/confidentiality to OSPFv3 using IPv6 AH/ESP Extension=20 > Header. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-05.txt >=20 > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of the message. =20 > You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-ospf-ospfv3-auth-05.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html=20 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ospf-ospfv3-auth-05.txt". > =09 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant=20 > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 From owner-ospf@PEACH.EASE.LSOFT.COM Mon Oct 25 20:04:34 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21436 for ; Mon, 25 Oct 2004 20:04:34 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00EC0646@cherry.ease.lsoft.com>; Mon, 25 Oct 2004 20:04:22 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41709947 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 25 Oct 2004 20:04:18 -0400 Received: from 67.17.166.10 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 25 Oct 2004 20:04:18 -0400 Received: from CallSciences (unverified [172.21.6.73]) by ucmmail.com (Rockliffe SMTPRA 5.3.11) with SMTP id ; Mon, 25 Oct 2004 20:04:51 -0400 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART_BOUNDARY_CDVIGRFFSF" Message-ID: Date: Mon, 25 Oct 2004 20:04:36 -0400 Reply-To: Mailing List Sender: Mailing List From: Sean Andersen Subject: Re: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list --PART_BOUNDARY_CDVIGRFFSF Content-Type: text/plain; not specified Mollin, I agree with every answer sent so far. But here is one more thing to look at: Have you checked the GIG link to see if it is flapping? I know of some vendors (will not name names here) that still have some issues/compatibiliy on the Gig links and flap up and down constantly. Sean -----Original Message----- From: Mollin, Arvind - LiqwidKrystal Sent: Sun, 24 Oct 2004 21:42:12 -0700 To: OSPF@PEACH.EASE.LSOFT.COM Subject: What will happen in this kind of topology with 100 nbrs and 2000 ASEs ?? Hi, I have two routers connected back to back through a gig link. I have configured 100 VLANs in that single gig link, now each vlan act as virtual interface. I have configured 100 neighbors on each router using these 100 virtual interfaces. All the neighbors are in backbone. See the figure below, ( 100 nbrs )R1 -------------100 vlans ------------------ R2 ( 100 nbrs ) After sometime I could see all nbrs flapping often. What could be the reason for this ?? Is this topology right?, Has anybody tested with this kind of setup ?? Thanks Arvind --PART_BOUNDARY_CDVIGRFFSF Content-Type: text/html; name="200410252018.html" Content-Disposition: filename="200410252018.html" Content-MD5: wNsA/DZN52fRMZ16FrpzsA== Content-Transfer-Encoding: base64 //48AGgAdABtAGwAIAB4AG0AbABuAHMAOgBvAD0AIgB1AHIAbgA6AHMAYwBoAGUAbQBhAHMA LQBtAGkAYwByAG8AcwBvAGYAdAAtAGMAbwBtADoAbwBmAGYAaQBjAGUAOgBvAGYAZgBpAGMA ZQAiACAAeABtAGwAbgBzADoAdwA9ACIAdQByAG4AOgBzAGMAaABlAG0AYQBzAC0AbQBpAGMA cgBvAHMAbwBmAHQALQBjAG8AbQA6AG8AZgBmAGkAYwBlADoAdwBvAHIAZAAiACAAeABtAGwA bgBzAD0AIgBoAHQAdABwADoALwAvAHcAdwB3AC4AdwAzAC4AbwByAGcALwBUAFIALwBSAEUA QwAtAGgAdABtAGwANAAwACIAPgANAAoADQAKADwAaABlAGEAZAA+AA0ACgA8AE0ARQBUAEEA IABIAFQAVABQAC0ARQBRAFUASQBWAD0AIgBDAG8AbgB0AGUAbgB0AC0AVAB5AHAAZQAiACAA QwBPAE4AVABFAE4AVAA9ACIAdABlAHgAdAAvAGgAdABtAGwAOwAgAGMAaABhAHIAcwBlAHQA PQB1AHMALQBhAHMAYwBpAGkAIgA+AA0ACgA8AG0AZQB0AGEAIABuAGEAbQBlAD0ARwBlAG4A ZQByAGEAdABvAHIAIABjAG8AbgB0AGUAbgB0AD0AIgBNAGkAYwByAG8AcwBvAGYAdAAgAFcA bwByAGQAIAAxADEAIAAoAGYAaQBsAHQAZQByAGUAZAAgAG0AZQBkAGkAdQBtACkAIgA+AA0A CgA8AHMAdAB5AGwAZQA+AA0ACgA8ACEALQAtAA0ACgAgAC8AKgAgAFMAdAB5AGwAZQAgAEQA ZQBmAGkAbgBpAHQAaQBvAG4AcwAgACoALwANAAoAIABwAC4ATQBzAG8ATgBvAHIAbQBhAGwA LAAgAGwAaQAuAE0AcwBvAE4AbwByAG0AYQBsACwAIABkAGkAdgAuAE0AcwBvAE4AbwByAG0A YQBsAA0ACgAgACAAIAAgACAAIAAgACAAewBtAGEAcgBnAGkAbgA6ADAAaQBuADsADQAKACAA IAAgACAAIAAgACAAIABtAGEAcgBnAGkAbgAtAGIAbwB0AHQAbwBtADoALgAwADAAMAAxAHAA dAA7AA0ACgAgACAAIAAgACAAIAAgACAAZgBvAG4AdAAtAHMAaQB6AGUAOgAxADIALgAwAHAA dAA7AA0ACgAgACAAIAAgACAAIAAgACAAZgBvAG4AdAAtAGYAYQBtAGkAbAB5ADoAIgBUAGkA bQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAiADsAfQANAAoAaAAxAA0ACgAgACAAIAAgACAA IAAgACAAewBtAGEAcgBnAGkAbgAtAHQAbwBwADoAMQAyAC4AMABwAHQAOwANAAoAIAAgACAA IAAgACAAIAAgAG0AYQByAGcAaQBuAC0AcgBpAGcAaAB0ADoAMABpAG4AOwANAAoAIAAgACAA IAAgACAAIAAgAG0AYQByAGcAaQBuAC0AYgBvAHQAdABvAG0AOgAzAC4AMABwAHQAOwANAAoA IAAgACAAIAAgACAAIAAgAG0AYQByAGcAaQBuAC0AbABlAGYAdAA6AC4AMgA1AGkAbgA7AA0A CgAgACAAIAAgACAAIAAgACAAdABlAHgAdAAtAGkAbgBkAGUAbgB0ADoALQAuADIANQBpAG4A OwANAAoAIAAgACAAIAAgACAAIAAgAHAAYQBnAGUALQBiAHIAZQBhAGsALQBhAGYAdABlAHIA OgBhAHYAbwBpAGQAOwANAAoAIAAgACAAIAAgACAAIAAgAG0AcwBvAC0AbABpAHMAdAA6AGwA MAAgAGwAZQB2AGUAbAAxACAAbABmAG8AMQA7AA0ACgAgACAAIAAgACAAIAAgACAAZgBvAG4A dAAtAHMAaQB6AGUAOgAyADAALgAwAHAAdAA7AA0ACgAgACAAIAAgACAAIAAgACAAZgBvAG4A dAAtAGYAYQBtAGkAbAB5ADoAQQByAGkAYQBsADsAfQANAAoAYQA6AGwAaQBuAGsALAAgAHMA cABhAG4ALgBNAHMAbwBIAHkAcABlAHIAbABpAG4AawANAAoAIAAgACAAIAAgACAAIAAgAHsA YwBvAGwAbwByADoAYgBsAHUAZQA7AA0ACgAgACAAIAAgACAAIAAgACAAdABlAHgAdAAtAGQA ZQBjAG8AcgBhAHQAaQBvAG4AOgB1AG4AZABlAHIAbABpAG4AZQA7AH0ADQAKAGEAOgB2AGkA cwBpAHQAZQBkACwAIABzAHAAYQBuAC4ATQBzAG8ASAB5AHAAZQByAGwAaQBuAGsARgBvAGwA bABvAHcAZQBkAA0ACgAgACAAIAAgACAAIAAgACAAewBjAG8AbABvAHIAOgBwAHUAcgBwAGwA ZQA7AA0ACgAgACAAIAAgACAAIAAgACAAdABlAHgAdAAtAGQAZQBjAG8AcgBhAHQAaQBvAG4A OgB1AG4AZABlAHIAbABpAG4AZQA7AH0ADQAKAHAALgBNAHMAbwBQAGwAYQBpAG4AVABlAHgA dAAsACAAbABpAC4ATQBzAG8AUABsAGEAaQBuAFQAZQB4AHQALAAgAGQAaQB2AC4ATQBzAG8A UABsAGEAaQBuAFQAZQB4AHQADQAKACAAIAAgACAAIAAgACAAIAB7AG0AYQByAGcAaQBuADoA MABpAG4AOwANAAoAIAAgACAAIAAgACAAIAAgAG0AYQByAGcAaQBuAC0AYgBvAHQAdABvAG0A OgAuADAAMAAwADEAcAB0ADsADQAKACAAIAAgACAAIAAgACAAIABmAG8AbgB0AC0AcwBpAHoA ZQA6ADEAMAAuADAAcAB0ADsADQAKACAAIAAgACAAIAAgACAAIABmAG8AbgB0AC0AZgBhAG0A aQBsAHkAOgAiAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAiADsAfQANAAoAcAAuAEYAaQBnAHUA cgBlACwAIABsAGkALgBGAGkAZwB1AHIAZQAsACAAZABpAHYALgBGAGkAZwB1AHIAZQANAAoA IAAgACAAIAAgACAAIAAgAHsAbQBhAHIAZwBpAG4ALQB0AG8AcAA6ADAAaQBuADsADQAKACAA IAAgACAAIAAgACAAIABtAGEAcgBnAGkAbgAtAHIAaQBnAGgAdAA6ADAAaQBuADsADQAKACAA IAAgACAAIAAgACAAIABtAGEAcgBnAGkAbgAtAGIAbwB0AHQAbwBtADoAMABpAG4AOwANAAoA IAAgACAAIAAgACAAIAAgAG0AYQByAGcAaQBuAC0AbABlAGYAdAA6ADIALgAwAGkAbgA7AA0A CgAgACAAIAAgACAAIAAgACAAbQBhAHIAZwBpAG4ALQBiAG8AdAB0AG8AbQA6AC4AMAAwADAA MQBwAHQAOwANAAoAIAAgACAAIAAgACAAIAAgAGYAbwBuAHQALQBzAGkAegBlADoAMQA2AC4A MABwAHQAOwANAAoAIAAgACAAIAAgACAAIAAgAGYAbwBuAHQALQBmAGEAbQBpAGwAeQA6ACIA QwBvAHUAcgBpAGUAcgAgAE4AZQB3ACIAOwB9AA0ACgBzAHAAYQBuAC4ARQBtAGEAaQBsAFMA dAB5AGwAZQAxADkADQAKACAAIAAgACAAIAAgACAAIAB7AG0AcwBvAC0AcwB0AHkAbABlAC0A dAB5AHAAZQA6AHAAZQByAHMAbwBuAGEAbAAtAGMAbwBtAHAAbwBzAGUAOwANAAoAIAAgACAA IAAgACAAIAAgAGYAbwBuAHQALQBmAGEAbQBpAGwAeQA6AEEAcgBpAGEAbAA7AA0ACgAgACAA IAAgACAAIAAgACAAYwBvAGwAbwByADoAdwBpAG4AZABvAHcAdABlAHgAdAA7AH0ADQAKAEAA cABhAGcAZQAgAFMAZQBjAHQAaQBvAG4AMQANAAoAIAAgACAAIAAgACAAIAAgAHsAcwBpAHoA ZQA6ADgALgA1AGkAbgAgADEAMQAuADAAaQBuADsADQAKACAAIAAgACAAIAAgACAAIABtAGEA cgBnAGkAbgA6ADEALgAwAGkAbgAgADEALgAyADUAaQBuACAAMQAuADAAaQBuACAAMQAuADIA NQBpAG4AOwB9AA0ACgBkAGkAdgAuAFMAZQBjAHQAaQBvAG4AMQANAAoAIAAgACAAIAAgACAA IAAgAHsAcABhAGcAZQA6AFMAZQBjAHQAaQBvAG4AMQA7AH0ADQAKACAALwAqACAATABpAHMA dAAgAEQAZQBmAGkAbgBpAHQAaQBvAG4AcwAgACoALwANAAoAIABAAGwAaQBzAHQAIABsADAA DQAKACAAIAAgACAAIAAgACAAIAB7AG0AcwBvAC0AbABpAHMAdAAtAGkAZAA6ADMAOAAzADUA MgA0ADkAOAAxADsADQAKACAAIAAgACAAIAAgACAAIABtAHMAbwAtAGwAaQBzAHQALQB0AGUA bQBwAGwAYQB0AGUALQBpAGQAcwA6AC0AMgAxADQAMwAzADkAOAAxADkAMAA7AH0ADQAKAEAA bABpAHMAdAAgAGwAMAA6AGwAZQB2AGUAbAAxAA0ACgAgACAAIAAgACAAIAAgACAAewBtAHMA bwAtAGwAZQB2AGUAbAAtAHMAdAB5AGwAZQAtAGwAaQBuAGsAOgAiAEgAZQBhAGQAaQBuAGcA IAAxACIAOwANAAoAIAAgACAAIAAgACAAIAAgAG0AcwBvAC0AbABlAHYAZQBsAC0AdABhAGIA LQBzAHQAbwBwADoALgAyADUAaQBuADsADQAKACAAIAAgACAAIAAgACAAIABtAHMAbwAtAGwA ZQB2AGUAbAAtAG4AdQBtAGIAZQByAC0AcABvAHMAaQB0AGkAbwBuADoAbABlAGYAdAA7AA0A CgAgACAAIAAgACAAIAAgACAAbQBhAHIAZwBpAG4ALQBsAGUAZgB0ADoALgAyADUAaQBuADsA DQAKACAAIAAgACAAIAAgACAAIAB0AGUAeAB0AC0AaQBuAGQAZQBuAHQAOgAtAC4AMgA1AGkA bgA7AH0ADQAKAEAAbABpAHMAdAAgAGwAMAA6AGwAZQB2AGUAbAAyAA0ACgAgACAAIAAgACAA IAAgACAAewBtAHMAbwAtAGwAZQB2AGUAbAAtAHQAZQB4AHQAOgAiACUAMQBcAC4AJQAyAFwA LgAiADsADQAKACAAIAAgACAAIAAgACAAIABtAHMAbwAtAGwAZQB2AGUAbAAtAHQAYQBiAC0A cwB0AG8AcAA6AC4ANQA1AGkAbgA7AA0ACgAgACAAIAAgACAAIAAgACAAbQBzAG8ALQBsAGUA dgBlAGwALQBuAHUAbQBiAGUAcgAtAHAAbwBzAGkAdABpAG8AbgA6AGwAZQBmAHQAOwANAAoA IAAgACAAIAAgACAAIAAgAG0AYQByAGcAaQBuAC0AbABlAGYAdAA6AC4ANQA1AGkAbgA7AA0A CgAgACAAIAAgACAAIAAgACAAdABlAHgAdAAtAGkAbgBkAGUAbgB0ADoALQAuADMAaQBuADsA fQANAAoAQABsAGkAcwB0ACAAbAAwADoAbABlAHYAZQBsADMADQAKACAAIAAgACAAIAAgACAA IAB7AG0AcwBvAC0AbABlAHYAZQBsAC0AdABlAHgAdAA6ACIAJQAxAFwALgAlADIAXAAuACUA MwBcAC4AIgA7AA0ACgAgACAAIAAgACAAIAAgACAAbQBzAG8ALQBsAGUAdgBlAGwALQB0AGEA YgAtAHMAdABvAHAAOgAxAC4AMABpAG4AOwANAAoAIAAgACAAIAAgACAAIAAgAG0AcwBvAC0A bABlAHYAZQBsAC0AbgB1AG0AYgBlAHIALQBwAG8AcwBpAHQAaQBvAG4AOgBsAGUAZgB0ADsA DQAKACAAIAAgACAAIAAgACAAIABtAGEAcgBnAGkAbgAtAGwAZQBmAHQAOgAuADgANQBpAG4A OwANAAoAIAAgACAAIAAgACAAIAAgAHQAZQB4AHQALQBpAG4AZABlAG4AdAA6AC0ALgAzADUA aQBuADsAfQANAAoAQABsAGkAcwB0ACAAbAAwADoAbABlAHYAZQBsADQADQAKACAAIAAgACAA IAAgACAAIAB7AG0AcwBvAC0AbABlAHYAZQBsAC0AdABlAHgAdAA6ACIAJQAxAFwALgAlADIA XAAuACUAMwBcAC4AJQA0AFwALgAiADsADQAKACAAIAAgACAAIAAgACAAIABtAHMAbwAtAGwA ZQB2AGUAbAAtAHQAYQBiAC0AcwB0AG8AcAA6ADEALgAyADUAaQBuADsADQAKACAAIAAgACAA IAAgACAAIABtAHMAbwAtAGwAZQB2AGUAbAAtAG4AdQBtAGIAZQByAC0AcABvAHMAaQB0AGkA bwBuADoAbABlAGYAdAA7AA0ACgAgACAAIAAgACAAIAAgACAAbQBhAHIAZwBpAG4ALQBsAGUA ZgB0ADoAMQAuADIAaQBuADsADQAKACAAIAAgACAAIAAgACAAIAB0AGUAeAB0AC0AaQBuAGQA ZQBuAHQAOgAtAC4ANAA1AGkAbgA7AH0ADQAKAEAAbABpAHMAdAAgAGwAMAA6AGwAZQB2AGUA bAA1AA0ACgAgACAAIAAgACAAIAAgACAAewBtAHMAbwAtAGwAZQB2AGUAbAAtAHQAZQB4AHQA OgAiACUAMQBcAC4AJQAyAFwALgAlADMAXAAuACUANABcAC4AJQA1AFwALgAiADsADQAKACAA IAAgACAAIAAgACAAIABtAHMAbwAtAGwAZQB2AGUAbAAtAHQAYQBiAC0AcwB0AG8AcAA6ADEA LgA3ADUAaQBuADsADQAKACAAIAAgACAAIAAgACAAIABtAHMAbwAtAGwAZQB2AGUAbAAtAG4A dQBtAGIAZQByAC0AcABvAHMAaQB0AGkAbwBuADoAbABlAGYAdAA7AA0ACgAgACAAIAAgACAA IAAgACAAbQBhAHIAZwBpAG4ALQBsAGUAZgB0ADoAMQAuADUANQBpAG4AOwANAAoAIAAgACAA IAAgACAAIAAgAHQAZQB4AHQALQBpAG4AZABlAG4AdAA6AC0ALgA1ADUAaQBuADsAfQANAAoA QABsAGkAcwB0ACAAbAAwADoAbABlAHYAZQBsADYADQAKACAAIAAgACAAIAAgACAAIAB7AG0A cwBvAC0AbABlAHYAZQBsAC0AdABlAHgAdAA6ACIAJQAxAFwALgAlADIAXAAuACUAMwBcAC4A JQA0AFwALgAlADUAXAAuACUANgBcAC4AIgA7AA0ACgAgACAAIAAgACAAIAAgACAAbQBzAG8A LQBsAGUAdgBlAGwALQB0AGEAYgAtAHMAdABvAHAAOgAyAC4AMABpAG4AOwANAAoAIAAgACAA IAAgACAAIAAgAG0AcwBvAC0AbABlAHYAZQBsAC0AbgB1AG0AYgBlAHIALQBwAG8AcwBpAHQA aQBvAG4AOgBsAGUAZgB0ADsADQAKACAAIAAgACAAIAAgACAAIABtAGEAcgBnAGkAbgAtAGwA ZQBmAHQAOgAxAC4AOQBpAG4AOwANAAoAIAAgACAAIAAgACAAIAAgAHQAZQB4AHQALQBpAG4A ZABlAG4AdAA6AC0ALgA2ADUAaQBuADsAfQANAAoAQABsAGkAcwB0ACAAbAAwADoAbABlAHYA ZQBsADcADQAKACAAIAAgACAAIAAgACAAIAB7AG0AcwBvAC0AbABlAHYAZQBsAC0AdABlAHgA dAA6ACIAJQAxAFwALgAlADIAXAAuACUAMwBcAC4AJQA0AFwALgAlADUAXAAuACUANgBcAC4A JQA3AFwALgAiADsADQAKACAAIAAgACAAIAAgACAAIABtAHMAbwAtAGwAZQB2AGUAbAAtAHQA YQBiAC0AcwB0AG8AcAA6ADIALgA1AGkAbgA7AA0ACgAgACAAIAAgACAAIAAgACAAbQBzAG8A LQBsAGUAdgBlAGwALQBuAHUAbQBiAGUAcgAtAHAAbwBzAGkAdABpAG8AbgA6AGwAZQBmAHQA OwANAAoAIAAgACAAIAAgACAAIAAgAG0AYQByAGcAaQBuAC0AbABlAGYAdAA6ADIALgAyADUA aQBuADsADQAKACAAIAAgACAAIAAgACAAIAB0AGUAeAB0AC0AaQBuAGQAZQBuAHQAOgAtAC4A NwA1AGkAbgA7AH0ADQAKAEAAbABpAHMAdAAgAGwAMAA6AGwAZQB2AGUAbAA4AA0ACgAgACAA IAAgACAAIAAgACAAewBtAHMAbwAtAGwAZQB2AGUAbAAtAHQAZQB4AHQAOgAiACUAMQBcAC4A JQAyAFwALgAlADMAXAAuACUANABcAC4AJQA1AFwALgAlADYAXAAuACUANwBcAC4AJQA4AFwA LgAiADsADQAKACAAIAAgACAAIAAgACAAIABtAHMAbwAtAGwAZQB2AGUAbAAtAHQAYQBiAC0A cwB0AG8AcAA6ADIALgA3ADUAaQBuADsADQAKACAAIAAgACAAIAAgACAAIABtAHMAbwAtAGwA ZQB2AGUAbAAtAG4AdQBtAGIAZQByAC0AcABvAHMAaQB0AGkAbwBuADoAbABlAGYAdAA7AA0A CgAgACAAIAAgACAAIAAgACAAbQBhAHIAZwBpAG4ALQBsAGUAZgB0ADoAMgAuADYAaQBuADsA DQAKACAAIAAgACAAIAAgACAAIAB0AGUAeAB0AC0AaQBuAGQAZQBuAHQAOgAtAC4AOAA1AGkA bgA7AH0ADQAKAEAAbABpAHMAdAAgAGwAMAA6AGwAZQB2AGUAbAA5AA0ACgAgACAAIAAgACAA IAAgACAAewBtAHMAbwAtAGwAZQB2AGUAbAAtAHQAZQB4AHQAOgAiACUAMQBcAC4AJQAyAFwA LgAlADMAXAAuACUANABcAC4AJQA1AFwALgAlADYAXAAuACUANwBcAC4AJQA4AFwALgAlADkA XAAuACIAOwANAAoAIAAgACAAIAAgACAAIAAgAG0AcwBvAC0AbABlAHYAZQBsAC0AdABhAGIA LQBzAHQAbwBwADoAMwAuADIANQBpAG4AOwANAAoAIAAgACAAIAAgACAAIAAgAG0AcwBvAC0A bABlAHYAZQBsAC0AbgB1AG0AYgBlAHIALQBwAG8AcwBpAHQAaQBvAG4AOgBsAGUAZgB0ADsA DQAKACAAIAAgACAAIAAgACAAIABtAGEAcgBnAGkAbgAtAGwAZQBmAHQAOgAzAC4AMABpAG4A OwANAAoAIAAgACAAIAAgACAAIAAgAHQAZQB4AHQALQBpAG4AZABlAG4AdAA6AC0AMQAuADAA aQBuADsAfQANAAoAbwBsAA0ACgAgACAAIAAgACAAIAAgACAAewBtAGEAcgBnAGkAbgAtAGIA bwB0AHQAbwBtADoAMABpAG4AOwB9AA0ACgB1AGwADQAKACAAIAAgACAAIAAgACAAIAB7AG0A YQByAGcAaQBuAC0AYgBvAHQAdABvAG0AOgAwAGkAbgA7AH0ADQAKAC0ALQA+AA0ACgA8AC8A cwB0AHkAbABlAD4ADQAKAA0ACgA8AC8AaABlAGEAZAA+AA0ACgANAAoAPABiAG8AZAB5ACAA bABhAG4AZwA9AEUATgAtAFUAUwAgAGwAaQBuAGsAPQBiAGwAdQBlACAAdgBsAGkAbgBrAD0A cAB1AHIAcABsAGUAPgANAAoADQAKADwAZABpAHYAIABjAGwAYQBzAHMAPQBTAGUAYwB0AGkA bwBuADEAPgANAAoADQAKADwAcAAgAGMAbABhAHMAcwA9AE0AcwBvAE4AbwByAG0AYQBsAD4A PABmAG8AbgB0ACAAcwBpAHoAZQA9ADIAIABmAGEAYwBlAD0AQQByAGkAYQBsAD4APABzAHAA YQBuACAAcwB0AHkAbABlAD0AJwBmAG8AbgB0AC0AcwBpAHoAZQA6ADEAMAAuADAAcAB0ADsA DQAKAGYAbwBuAHQALQBmAGEAbQBpAGwAeQA6AEEAcgBpAGEAbAAnAD4ASABpACwAPABvADoA cAA+ADwALwBvADoAcAA+ADwALwBzAHAAYQBuAD4APAAvAGYAbwBuAHQAPgA8AC8AcAA+AA0A CgANAAoAPABwACAAYwBsAGEAcwBzAD0ATQBzAG8ATgBvAHIAbQBhAGwAPgA8AGYAbwBuAHQA IABzAGkAegBlAD0AMgAgAGYAYQBjAGUAPQBBAHIAaQBhAGwAPgA8AHMAcABhAG4AIABzAHQA eQBsAGUAPQAnAGYAbwBuAHQALQBzAGkAegBlADoAMQAwAC4AMABwAHQAOwANAAoAZgBvAG4A dAAtAGYAYQBtAGkAbAB5ADoAQQByAGkAYQBsACcAPgAmAG4AYgBzAHAAOwAgAEkAIABoAGEA dgBlACAAdAB3AG8AIAByAG8AdQB0AGUAcgBzACAAYwBvAG4AbgBlAGMAdABlAGQAIABiAGEA YwBrACAAdABvACAAYgBhAGMAawAgAHQAaAByAG8AdQBnAGgAIABhACAAZwBpAGcADQAKAGwA aQBuAGsALgAgAEkAIABoAGEAdgBlACAAYwBvAG4AZgBpAGcAdQByAGUAZAAgADEAMAAwACAA VgBMAEEATgBzACAAaQBuACAAdABoAGEAdAAgAHMAaQBuAGcAbABlACAAZwBpAGcAIABsAGkA bgBrACwAIABuAG8AdwAgAGUAYQBjAGgAIAB2AGwAYQBuACAAYQBjAHQAIABhAHMADQAKAHYA aQByAHQAdQBhAGwAIABpAG4AdABlAHIAZgBhAGMAZQAuACAASQAgAGgAYQB2AGUAIABjAG8A bgBmAGkAZwB1AHIAZQBkACAAMQAwADAAIABuAGUAaQBnAGgAYgBvAHIAcwAgAG8AbgAgAGUA YQBjAGgAIAByAG8AdQB0AGUAcgAgAHUAcwBpAG4AZwAgAHQAaABlAHMAZQANAAoAMQAwADAA IAB2AGkAcgB0AHUAYQBsACAAaQBuAHQAZQByAGYAYQBjAGUAcwAuACAAQQBsAGwAIAB0AGgA ZQAgAG4AZQBpAGcAaABiAG8AcgBzACAAYQByAGUAIABpAG4AIABiAGEAYwBrAGIAbwBuAGUA LgAgAFMAZQBlACAAdABoAGUAIABmAGkAZwB1AHIAZQANAAoAYgBlAGwAbwB3ACwAPABvADoA cAA+ADwALwBvADoAcAA+ADwALwBzAHAAYQBuAD4APAAvAGYAbwBuAHQAPgA8AC8AcAA+AA0A CgANAAoAPABwACAAYwBsAGEAcwBzAD0ATQBzAG8ATgBvAHIAbQBhAGwAPgA8AGYAbwBuAHQA IABzAGkAegBlAD0AMgAgAGYAYQBjAGUAPQBBAHIAaQBhAGwAPgA8AHMAcABhAG4AIABzAHQA eQBsAGUAPQAnAGYAbwBuAHQALQBzAGkAegBlADoAMQAwAC4AMABwAHQAOwANAAoAZgBvAG4A dAAtAGYAYQBtAGkAbAB5ADoAQQByAGkAYQBsACcAPgA8AG8AOgBwAD4AJgBuAGIAcwBwADsA PAAvAG8AOgBwAD4APAAvAHMAcABhAG4APgA8AC8AZgBvAG4AdAA+ADwALwBwAD4ADQAKAA0A CgA8AHAAIABjAGwAYQBzAHMAPQBNAHMAbwBOAG8AcgBtAGEAbAA+ADwAZgBvAG4AdAAgAHMA aQB6AGUAPQAyACAAZgBhAGMAZQA9AEEAcgBpAGEAbAA+ADwAcwBwAGEAbgAgAHMAdAB5AGwA ZQA9ACcAZgBvAG4AdAAtAHMAaQB6AGUAOgAxADAALgAwAHAAdAA7AA0ACgBmAG8AbgB0AC0A ZgBhAG0AaQBsAHkAOgBBAHIAaQBhAGwAJwA+ACgAIAAxADAAMAAgAG4AYgByAHMAIAApAFIA MQAgAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0AMQAwADAAIAB2AGwAYQBuAHMAIAAtAC0A LQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAgAFIAMgANAAoAKAAgADEAMAAwACAA bgBiAHIAcwAgACkAPABvADoAcAA+ADwALwBvADoAcAA+ADwALwBzAHAAYQBuAD4APAAvAGYA bwBuAHQAPgA8AC8AcAA+AA0ACgANAAoAPABwACAAYwBsAGEAcwBzAD0ATQBzAG8ATgBvAHIA bQBhAGwAPgA8AGYAbwBuAHQAIABzAGkAegBlAD0AMgAgAGYAYQBjAGUAPQBBAHIAaQBhAGwA PgA8AHMAcABhAG4AIABzAHQAeQBsAGUAPQAnAGYAbwBuAHQALQBzAGkAegBlADoAMQAwAC4A MABwAHQAOwANAAoAZgBvAG4AdAAtAGYAYQBtAGkAbAB5ADoAQQByAGkAYQBsACcAPgA8AG8A OgBwAD4AJgBuAGIAcwBwADsAPAAvAG8AOgBwAD4APAAvAHMAcABhAG4APgA8AC8AZgBvAG4A dAA+ADwALwBwAD4ADQAKAA0ACgA8AHAAIABjAGwAYQBzAHMAPQBNAHMAbwBOAG8AcgBtAGEA bAA+ADwAZgBvAG4AdAAgAHMAaQB6AGUAPQAyACAAZgBhAGMAZQA9AEEAcgBpAGEAbAA+ADwA cwBwAGEAbgAgAHMAdAB5AGwAZQA9ACcAZgBvAG4AdAAtAHMAaQB6AGUAOgAxADAALgAwAHAA dAA7AA0ACgBmAG8AbgB0AC0AZgBhAG0AaQBsAHkAOgBBAHIAaQBhAGwAJwA+AEEAZgB0AGUA cgAgAHMAbwBtAGUAdABpAG0AZQAgAEkAIABjAG8AdQBsAGQAIABzAGUAZQAgAGEAbABsACAA bgBiAHIAcwAgAGYAbABhAHAAcABpAG4AZwAgAG8AZgB0AGUAbgAuACAAVwBoAGEAdAANAAoA YwBvAHUAbABkACAAYgBlACAAdABoAGUAIAByAGUAYQBzAG8AbgAgAGYAbwByACAAdABoAGkA cwAgAD8APwA8AG8AOgBwAD4APAAvAG8AOgBwAD4APAAvAHMAcABhAG4APgA8AC8AZgBvAG4A dAA+ADwALwBwAD4ADQAKAA0ACgA8AHAAIABjAGwAYQBzAHMAPQBNAHMAbwBOAG8AcgBtAGEA bAA+ADwAZgBvAG4AdAAgAHMAaQB6AGUAPQAyACAAZgBhAGMAZQA9AEEAcgBpAGEAbAA+ADwA cwBwAGEAbgAgAHMAdAB5AGwAZQA9ACcAZgBvAG4AdAAtAHMAaQB6AGUAOgAxADAALgAwAHAA dAA7AA0ACgBmAG8AbgB0AC0AZgBhAG0AaQBsAHkAOgBBAHIAaQBhAGwAJwA+AEkAcwAgAHQA aABpAHMAIAB0AG8AcABvAGwAbwBnAHkAIAByAGkAZwBoAHQAPwAsACAASABhAHMAIABhAG4A eQBiAG8AZAB5ACAAdABlAHMAdABlAGQAIAB3AGkAdABoACAAdABoAGkAcwAgAGsAaQBuAGQA DQAKAG8AZgAgAHMAZQB0AHUAcAAgAD8APwA8AG8AOgBwAD4APAAvAG8AOgBwAD4APAAvAHMA cABhAG4APgA8AC8AZgBvAG4AdAA+ADwALwBwAD4ADQAKAA0ACgA8AHAAIABjAGwAYQBzAHMA PQBNAHMAbwBOAG8AcgBtAGEAbAA+ADwAZgBvAG4AdAAgAHMAaQB6AGUAPQAyACAAZgBhAGMA ZQA9AEEAcgBpAGEAbAA+ADwAcwBwAGEAbgAgAHMAdAB5AGwAZQA9ACcAZgBvAG4AdAAtAHMA aQB6AGUAOgAxADAALgAwAHAAdAA7AA0ACgBmAG8AbgB0AC0AZgBhAG0AaQBsAHkAOgBBAHIA aQBhAGwAJwA+ADwAbwA6AHAAPgAmAG4AYgBzAHAAOwA8AC8AbwA6AHAAPgA8AC8AcwBwAGEA bgA+ADwALwBmAG8AbgB0AD4APAAvAHAAPgANAAoADQAKADwAcAAgAGMAbABhAHMAcwA9AE0A cwBvAE4AbwByAG0AYQBsAD4APABmAG8AbgB0ACAAcwBpAHoAZQA9ADIAIABmAGEAYwBlAD0A QQByAGkAYQBsAD4APABzAHAAYQBuACAAcwB0AHkAbABlAD0AJwBmAG8AbgB0AC0AcwBpAHoA ZQA6ADEAMAAuADAAcAB0ADsADQAKAGYAbwBuAHQALQBmAGEAbQBpAGwAeQA6AEEAcgBpAGEA bAAnAD4AVABoAGEAbgBrAHMAPABvADoAcAA+ADwALwBvADoAcAA+ADwALwBzAHAAYQBuAD4A PAAvAGYAbwBuAHQAPgA8AC8AcAA+AA0ACgANAAoAPABwACAAYwBsAGEAcwBzAD0ATQBzAG8A TgBvAHIAbQBhAGwAPgA8AGYAbwBuAHQAIABzAGkAegBlAD0AMgAgAGYAYQBjAGUAPQBBAHIA aQBhAGwAPgA8AHMAcABhAG4AIABzAHQAeQBsAGUAPQAnAGYAbwBuAHQALQBzAGkAegBlADoA MQAwAC4AMABwAHQAOwANAAoAZgBvAG4AdAAtAGYAYQBtAGkAbAB5ADoAQQByAGkAYQBsACcA PgBBAHIAdgBpAG4AZAA8AG8AOgBwAD4APAAvAG8AOgBwAD4APAAvAHMAcABhAG4APgA8AC8A ZgBvAG4AdAA+ADwALwBwAD4ADQAKAA0ACgA8AHAAIABjAGwAYQBzAHMAPQBNAHMAbwBOAG8A cgBtAGEAbAA+ADwAZgBvAG4AdAAgAHMAaQB6AGUAPQAyACAAZgBhAGMAZQA9AEEAcgBpAGEA bAA+ADwAcwBwAGEAbgAgAHMAdAB5AGwAZQA9ACcAZgBvAG4AdAAtAHMAaQB6AGUAOgAxADAA LgAwAHAAdAA7AA0ACgBmAG8AbgB0AC0AZgBhAG0AaQBsAHkAOgBBAHIAaQBhAGwAJwA+ADwA bwA6AHAAPgAmAG4AYgBzAHAAOwA8AC8AbwA6AHAAPgA8AC8AcwBwAGEAbgA+ADwALwBmAG8A bgB0AD4APAAvAHAAPgANAAoADQAKADwALwBkAGkAdgA+AA0ACgANAAoAPAAvAGIAbwBkAHkA PgANAAoADQAKADwALwBoAHQAbQBsAD4ADQAKAA== --PART_BOUNDARY_CDVIGRFFSF-- From owner-ospf@PEACH.EASE.LSOFT.COM Tue Oct 26 16:57:54 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19967 for ; Tue, 26 Oct 2004 16:57:53 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00EC1F08@cherry.ease.lsoft.com>; Tue, 26 Oct 2004 16:57:52 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41867682 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 26 Oct 2004 16:57:50 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 26 Oct 2004 16:57:50 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B569AB14AE8 for ; Tue, 26 Oct 2004 13:57:44 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04481-09 for ; Tue, 26 Oct 2004 13:57:44 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.13]) by prattle.redback.com (Postfix) with SMTP id 19DDBB14AE9 for ; Tue, 26 Oct 2004 13:57:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <003901c4bb9e$6d80f010$0202a8c0@aceeinspiron> Date: Tue, 26 Oct 2004 16:57:38 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Tentative Agenda for 61st IETF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Any additions? Open Shortest Path First WG (ospf) Monday, November 8th at 1530-1730 ================================= CHAIR(s): Rohit Dube Acee Lindem AGENDA: o Administriva 5 minutes - Mailing list: OSPF@PEACH.EASE.LSOFT.COM Subscription/Removal: http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ospf&A=1 - Scribe? - Blue Sheets o Document Status 10 minutes Acee/Rohit o OSPFv3 MTR 15 minutes draft-mirtorabi-mt-ospfv3-00.txt Abhay Roy/Sina Mirtorabi o OSPF Wireless Design Team Status 20 minutes Tom Henderson o OSPF Wireless Discussion 10-20 minutes Thanks, ------ Acee From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 27 02:56:47 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10543 for ; Wed, 27 Oct 2004 02:56:47 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <21.00EC2AA6@cherry.ease.lsoft.com>; Wed, 27 Oct 2004 2:56:47 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41921214 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 27 Oct 2004 02:56:45 -0400 Received: from 203.197.124.190 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 27 Oct 2004 02:56:44 -0400 Received: from NUTMEG ([192.168.10.140]) by alumnux.com (8.9.3/8.9.3) with SMTP id MAA32375 for ; Wed, 27 Oct 2004 12:19:21 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C4BC20.D06371D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Importance: Normal Message-ID: <000201c4bbf2$b6746e60$8c0aa8c0@NUTMEG> Date: Wed, 27 Oct 2004 12:30:57 +0530 Reply-To: Mailing List Sender: Mailing List From: Joseph Placid Subject: Receiving Self-Orignated Summary 3 LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C4BC20.D06371D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi All, Consider this topology: [Area 0] - - - - R1 - - - - [Area 2] - - - - R2 - - - - [Area 0] When R1 receives a Network LSA from an internal router in Area 2, it summarises it into Area 0. This Summary LSA is seen by R2 since it has an interface in the backbone. Qn 1) Will R2 import this Summary LSA into Area 2? Qn 2) If R1 comes across a self-originated Summary LSA for the same Network in Area2 with a lower cost, what should it do? Regards, Joseph Placid ------=_NextPart_000_0003_01C4BC20.D06371D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 All,
 
Consider this=20 topology:
 
 
[Area 0] - - -=20 - R1 - - - - [Area 2] - - - - R2 - - - - [Area=20 0]
 
 
When = R1 receives a=20 Network LSA from an internal router in Area 2, it summarises it into = Area=20 0.  This Summary LSA is seen by R2 since it has an = interface in=20 the backbone.
 
Qn = 1) Will=20 R2 import this Summary LSA into Area 2? 
Qn = 2) If R1=20 comes across a self-originated Summary LSA for the same Network in Area2 = with a=20 lower cost, what should it do?
 
 
 
Regards,
Joseph = Placid
------=_NextPart_000_0003_01C4BC20.D06371D0-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 27 03:27:51 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12673 for ; Wed, 27 Oct 2004 03:27:50 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00EC2B48@cherry.ease.lsoft.com>; Wed, 27 Oct 2004 3:27:51 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41922952 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 27 Oct 2004 03:27:34 -0400 Received: from 203.197.138.222 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 27 Oct 2004 03:27:33 -0400 Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by mail1.future.futsoft.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Wed, 27 Oct 2004 12:56:19 +0530 Received: from manishgs (manishgs.future.futsoft.com [10.6.4.94]) by kailash.future.futsoft.com (8.12.8/8.12.8) with SMTP id i9R7RKiM025676 for ; Wed, 27 Oct 2004 12:57:21 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C4BC24.E2CDD000" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Message-ID: <001201c4bbf6$c9159400$5e04060a@future.futsoft.com> Date: Wed, 27 Oct 2004 13:00:07 +0530 Reply-To: Mailing List Sender: Mailing List From: Manish Gupta Subject: Re: Receiving Self-Orignated Summary 3 LSAs To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000201c4bbf2$b6746e60$8c0aa8c0@NUTMEG> Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C4BC24.E2CDD000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Joseph, Please see inline. -----Original Message----- From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Joseph Placid Sent: Wednesday, 27 October 2004 12:31 PM To: OSPF@peach.ease.lsoft.com Subject: Receiving Self-Orignated Summary 3 LSAs Hi All, Consider this topology: [Area 0] - - - - R1 - - - - [Area 2] - - - - R2 - - - - [Area 0] When R1 receives a Network LSA from an internal router in Area 2, it summarises it into Area 0. This Summary LSA is seen by R2 since it has an interface in the backbone. Qn 1) Will R2 import this Summary LSA into Area 2? [Manish Gupta] R2 will not import this summary LSA in Area 2 since it has an INTRA Area route through Area 2 for summary network. Qn 2) If R1 comes across a self-originated Summary LSA for the same Network in Area2 with a lower cost, what should it do? Intra area route will always be preferred over Inter Area Route irrespective of cost. Regards, Joseph Placid *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** ------=_NextPart_000_0013_01C4BC24.E2CDD000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Joseph,
Please=20 see inline.
-----Original Message-----
From: Mailing List=20 [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Joseph=20 Placid
Sent: Wednesday, 27 October 2004 12:31 PM
To:= OSPF@peach.ease.lsoft.com
Subject: Receiving Self-Orignated Su= mmary=20 3 LSAs

Hi=20 All,
 
Conside= r this=20 topology:
 
 
[= Area 0] - -=20 - - R1 - - - - [Area 2] - - - - R2 - - - - [Area=20 0]
 
 
When R1= receives a=20 Network LSA from an internal router in Area 2, it summarises it into Area= 0.  This Summary LSA is seen by R2 since it has an interf= ace in=20 the backbone.
 
Qn 1)&n= bsp;Will=20 R2 import this Summary LSA into Area 2? 
[M= anish=20 Gupta] R2 will not import this summary LSA in Area 2 since it has an= INTRA Area route through Area 2 for summary=20 network.
 
Qn 2)&n= bsp;If R1=20 comes across a self-originated Summary LSA for the same Network in Area2 = with=20 a lower cost, what should it do?
       &nbs= p;=20 Intra area route will always be preferred over Inter Area Route irrespect= ive=20 of cost.
 
 
 
Regards,
Joseph= Placid


***************************************************************************=
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************=
------=_NextPart_000_0013_01C4BC24.E2CDD000-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 27 03:44:20 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13699 for ; Wed, 27 Oct 2004 03:44:16 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <5.00EC2AB2@cherry.ease.lsoft.com>; Wed, 27 Oct 2004 3:44:15 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41923737 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 27 Oct 2004 03:44:13 -0400 Received: from 203.197.124.190 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 27 Oct 2004 03:44:11 -0400 Received: from NUTMEG ([192.168.10.140]) by alumnux.com (8.9.3/8.9.3) with SMTP id NAA32737 for ; Wed, 27 Oct 2004 13:05:47 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C4BC27.50CAC930" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Importance: Normal Message-ID: <000c01c4bbf9$37128d30$8c0aa8c0@NUTMEG> Date: Wed, 27 Oct 2004 13:17:30 +0530 Reply-To: Mailing List Sender: Mailing List From: Joseph Placid Subject: Re: Receiving Self-Orignated Summary 3 LSAs To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <001201c4bbf6$c9159400$5e04060a@future.futsoft.com> Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C4BC27.50CAC930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks Manish, Qn 2) If R1 comes across a self-originated Summary LSA for the same Network in Area2 with a lower cost, what should it do? >> Intra area route will always be preferred over Inter Area Route irrespective of cost. Would R1: 1) Generate a new summary LSA into the Backbone with the lower cost? 2) Maxage this summary LSA (the one with the lower cost) and generate a new one into the backbone? 3) Simply regenerate the LSA with the right cost into the backbone? 4) Ignore the LSA with the lowercost and Do Nothing. - Joseph Placid -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Manish Gupta Sent: 27 October 2004 01:00 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Receiving Self-Orignated Summary 3 LSAs Hi Joseph, Please see inline. -----Original Message----- From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Joseph Placid Sent: Wednesday, 27 October 2004 12:31 PM To: OSPF@peach.ease.lsoft.com Subject: Receiving Self-Orignated Summary 3 LSAs Hi All, Consider this topology: [Area 0] - - - - R1 - - - - [Area 2] - - - - R2 - - - - [Area 0] When R1 receives a Network LSA from an internal router in Area 2, it summarises it into Area 0. This Summary LSA is seen by R2 since it has an interface in the backbone. Qn 1) Will R2 import this Summary LSA into Area 2? [Manish Gupta] R2 will not import this summary LSA in Area 2 since it has an INTRA Area route through Area 2 for summary network. Qn 2) If R1 comes across a self-originated Summary LSA for the same Network in Area2 with a lower cost, what should it do? Intra area route will always be preferred over Inter Area Route irrespective of cost. Regards, Joseph Placid ************************************************************************** * This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. ************************************************************************** * ------=_NextPart_000_000D_01C4BC27.50CAC930 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks=20 Manish,
 
Qn=20 2) If R1 comes across a self-originated Summary LSA for the same = Network in=20 Area2 with a lower cost, what should it do?
       &nbs= p; >> Intra area route will always = be=20 preferred over Inter Area Route irrespective of = cost.
 
Would R1:
 
1)    Generate a new = summary LSA=20 into the Backbone with the lower cost?
2)    Maxage this summary = LSA (the=20 one with the lower cost) and generate a new one into the=20 backbone?
3)    Simply regenerate = the LSA=20 with the right cost into the backbone?
4)    Ignore the LSA with = the=20 lowercost and Do Nothing.
 
 
 
- Joseph = Placid 
 
 
 
 
 
 -----Original Message-----
From: = Mailing List=20 [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Manish=20 Gupta
Sent: 27 October 2004 01:00 PM
To:=20 OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Receiving = Self-Orignated=20 Summary 3 LSAs

Hi=20 Joseph,
Please see inline.
-----Original Message-----
From: Mailing List=20 [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Joseph=20 Placid
Sent: Wednesday, 27 October 2004 12:31 = PM
To:=20 OSPF@peach.ease.lsoft.com
Subject: Receiving = Self-Orignated=20 Summary 3 LSAs

Hi = All,
 
Consider this=20 topology:
 
 
[Area 0] -=20 - - - R1 - - - - [Area 2] - - - - R2 - - - - [Area=20 0]
 
 
When R1 receives=20 a Network LSA from an internal router in Area 2, it summarises it = into Area=20 0.  This Summary LSA is seen by R2 since it has an = interface=20 in the backbone.
 
Qn = 1) Will=20 R2 import this Summary LSA into Area 2? 
[Manish=20 Gupta] R2 will not import this summary LSA in Area 2 since it = has an=20 INTRA Area route through Area 2 for summary=20 network.
 
Qn = 2) If R1=20 comes across a self-originated Summary LSA for the same Network in = Area2=20 with a lower cost, what should it do?
       &nbs= p;=20 Intra area route will always be preferred over Inter Area Route = irrespective=20 of cost.
 
 
 
Regards,
Joseph=20 Placid


********************************************************= *******************
This=20 message is proprietary to Future Software Limited (FSL)
and is = intended=20 solely for the use of the individual to whom it
is addressed. It = may=20 contain privileged or confidential information
and should not be = circulated=20 or used for any purpose other than for
what it is = intended.

If you=20 have received this message in error, please notify the
originator=20 immediately. If you are not the intended recipient,
you are = notified that=20 you are strictly prohibited from using,
copying, altering, or = disclosing=20 the contents of this message.
FSL accepts no responsibility for = loss or=20 damage arising from
the use of the information transmitted by this = email=20 including
damage from=20 = virus.
***************************************************************= ************
------=_NextPart_000_000D_01C4BC27.50CAC930-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 27 05:06:46 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18338 for ; Wed, 27 Oct 2004 05:06:46 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00EC2BE5@cherry.ease.lsoft.com>; Wed, 27 Oct 2004 5:06:47 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41927491 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 27 Oct 2004 05:06:45 -0400 Received: from 61.144.161.40 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 27 Oct 2004 05:06:44 -0400 Received: from dell60 (huawei.com [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0I68000Q6EQ74V@mta0.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Wed, 27 Oct 2004 15:13:20 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.4024 Content-type: multipart/alternative; boundary="Boundary_(ID_gcbHi6PbVhoXNzBd2cWqSA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com Message-ID: <000001c4bbf5$6f97d6a0$cf04120a@in.huawei.com> Date: Wed, 27 Oct 2004 12:50:27 +0530 Reply-To: Mailing List Sender: Mailing List From: sujay Subject: Re: Receiving Self-Orignated Summary 3 LSAs To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000201c4bbf2$b6746e60$8c0aa8c0@NUTMEG> Precedence: list This is a multi-part message in MIME format. --Boundary_(ID_gcbHi6PbVhoXNzBd2cWqSA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi, As it looks like mostly R2 will not add the network route(inter area) for the summary lsa it recvs from R1, because it already has a Intra area route to the same network , so it should not generate the summ lsa for the network back to area 2. Suggest you verify ! Sujay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Joseph Placid Sent: Wednesday, October 27, 2004 12:31 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Receiving Self-Orignated Summary 3 LSAs Hi All, Consider this topology: [Area 0] - - - - R1 - - - - [Area 2] - - - - R2 - - - - [Area 0] When R1 receives a Network LSA from an internal router in Area 2, it summarises it into Area 0. This Summary LSA is seen by R2 since it has an interface in the backbone. Qn 1) Will R2 import this Summary LSA into Area 2? Qn 2) If R1 comes across a self-originated Summary LSA for the same Network in Area2 with a lower cost, what should it do? Regards, Joseph Placid --Boundary_(ID_gcbHi6PbVhoXNzBd2cWqSA) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT Message
Hi,
As it looks like mostly R2 will not add the network route(inter area) for the summary lsa it recvs from R1, because it already has a Intra area route to the same
network , so it should not generate the summ lsa for the network back to area 2.
Suggest you verify !
Sujay
-----Original Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Joseph Placid
Sent: Wednesday, October 27, 2004 12:31 PM
To: OSPF@PEACH.EASE.LSOFT.COM
Subject: Receiving Self-Orignated Summary 3 LSAs

Hi All,
 
Consider this topology:
 
 
[Area 0] - - - - R1 - - - - [Area 2] - - - - R2 - - - - [Area 0]
 
 
When R1 receives a Network LSA from an internal router in Area 2, it summarises it into Area 0.  This Summary LSA is seen by R2 since it has an interface in the backbone.
 
Qn 1) Will R2 import this Summary LSA into Area 2? 
Qn 2) If R1 comes across a self-originated Summary LSA for the same Network in Area2 with a lower cost, what should it do?
 
 
 
Regards,
Joseph Placid
--Boundary_(ID_gcbHi6PbVhoXNzBd2cWqSA)-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 27 05:41:49 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20379 for ; Wed, 27 Oct 2004 05:41:48 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00EC2B2E@cherry.ease.lsoft.com>; Wed, 27 Oct 2004 5:41:44 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 41928896 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 27 Oct 2004 05:41:39 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 27 Oct 2004 05:41:39 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B9E5768A390 for ; Wed, 27 Oct 2004 02:41:37 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12684-03 for ; Wed, 27 Oct 2004 02:41:37 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.13]) by prattle.redback.com (Postfix) with SMTP id 5783368A38E for ; Wed, 27 Oct 2004 02:41:36 -0700 (PDT) References: <000c01c4bbf9$37128d30$8c0aa8c0@NUTMEG> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0348_01C4BBE7.9B616F70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <034b01c4bc09$22e29a20$0202a8c0@aceeinspiron> Date: Wed, 27 Oct 2004 05:41:29 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Receiving Self-Orignated Summary 3 LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0348_01C4BBE7.9B616F70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Joseph,=20 It depends on whether the self-originated LSA is more recent. If is less recent (as defined in section 13.1 of RFC 2328), it will be ignored. If = it is more recent, a new LSA with the correct cost and a larger sequence = number=20 is originated. Note that the LSA interpreted as being equal due to fact = that=20 the differing costs will result in different checksums. Hope this helps, Acee=20 ----- Original Message -----=20 From: Joseph Placid=20 To: OSPF@PEACH.EASE.LSOFT.COM=20 Sent: Wednesday, October 27, 2004 3:47 AM Subject: Re: Receiving Self-Orignated Summary 3 LSAs Thanks Manish, Qn 2) If R1 comes across a self-originated Summary LSA for the same = Network in Area2 with a lower cost, what should it do? >> Intra area route will always be preferred over Inter Area = Route irrespective of cost. Would R1:=20 1) Generate a new summary LSA into the Backbone with the lower = cost? 2) Maxage this summary LSA (the one with the lower cost) and = generate a new one into the backbone? 3) Simply regenerate the LSA with the right cost into the backbone? 4) Ignore the LSA with the lowercost and Do Nothing.=20 - Joseph Placid=20 -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of = Manish Gupta Sent: 27 October 2004 01:00 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Re: Receiving Self-Orignated Summary 3 LSAs Hi Joseph,=20 Please see inline. -----Original Message----- From: Mailing List [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of = Joseph Placid Sent: Wednesday, 27 October 2004 12:31 PM To: OSPF@peach.ease.lsoft.com Subject: Receiving Self-Orignated Summary 3 LSAs Hi All, Consider this topology: [Area 0] - - - - R1 - - - - [Area 2] - - - - R2 - - - - [Area 0] When R1 receives a Network LSA from an internal router in Area 2, = it summarises it into Area 0. This Summary LSA is seen by R2 since it = has an interface in the backbone. Qn 1) Will R2 import this Summary LSA into Area 2?=20 [Manish Gupta] R2 will not import this summary LSA in Area 2 since = it has an INTRA Area route through Area 2 for summary network. Qn 2) If R1 comes across a self-originated Summary LSA for the = same Network in Area2 with a lower cost, what should it do? Intra area route will always be preferred over Inter Area = Route irrespective of cost. Regards, Joseph Placid = *************************************************************************= ** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. = *************************************************************************= ** ------=_NextPart_000_0348_01C4BBE7.9B616F70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Joseph,
 
It depends on whether the = self-originated LSA is=20 more recent. If is less
recent (as defined in section 13.1 of = RFC 2328), it=20 will be ignored. If it is
more recent, a new LSA with the correct = cost and a=20 larger sequence number
is originated. Note that the LSA interpreted as being equal due to fact that =
the differing costs will result in different checksums.
 
Hope this helps,
Acee 
----- Original Message -----
From:=20 Joseph Placid=20
Sent: Wednesday, October 27, = 2004 3:47=20 AM
Subject: Re: Receiving = Self-Orignated=20 Summary 3 LSAs

Thanks Manish,
 
Qn=20 2) If R1 comes across a self-originated Summary LSA for the same = Network=20 in Area2 with a lower cost, what should it do?
       &nbs= p; >> Intra area route will = always be=20 preferred over Inter Area Route irrespective of=20 cost.
 
Would R1: =
 
1)    Generate a new = summary LSA=20 into the Backbone with the lower = cost?
2)    Maxage this = summary LSA=20 (the one with the lower cost) and generate a new one into the=20 backbone?
3)    Simply regenerate = the LSA=20 with the right cost into the = backbone?
4)    Ignore the LSA = with the=20 lowercost and Do Nothing.
 
 
 
- Joseph=20 Placid 
 
 
 
 
 
 -----Original = Message-----
From: Mailing=20 List [mailto:OSPF@PEACH.EASE.LSOFT.COM]On Behalf Of Manish=20 Gupta
Sent: 27 October 2004 01:00 PM
To:=20 OSPF@PEACH.EASE.LSOFT.COM
Subject: Re: Receiving = Self-Orignated=20 Summary 3 LSAs

Hi=20 Joseph,
Please see inline.
-----Original Message-----
From: Mailing List=20 [mailto:OSPF@peach.ease.lsoft.com]On Behalf Of Joseph=20 Placid
Sent: Wednesday, 27 October 2004 12:31 = PM
To:=20 OSPF@peach.ease.lsoft.com
Subject: Receiving = Self-Orignated=20 Summary 3 LSAs

Hi=20 All,
 
Consider this=20 topology:
 
 
[Area 0]=20 - - - - R1 - - - - [Area 2] - - - - R2 - - - - [Area=20 0]
 
 
When R1=20 receives a Network LSA from an internal router in Area 2, it = summarises it=20 into Area 0.  This Summary LSA is seen by R2 since = it has=20 an interface in the backbone.
 
Qn=20 1) Will R2 import this Summary LSA into Area=20 2? 
[Manish Gupta] R2 will not import = this summary=20 LSA in Area 2 since it has an INTRA Area route through Area 2 for = summary=20 network.
 
Qn 2) If=20 R1 comes across a self-originated Summary LSA for the same Network = in=20 Area2 with a lower cost, what should it do?
       &nbs= p;=20 Intra area route will always be preferred over Inter Area Route=20 irrespective of cost.
 
 
 
Regards,
Joseph=20 Placid


********************************************************= *******************
This=20 message is proprietary to Future Software Limited (FSL)
and is = intended=20 solely for the use of the individual to whom it
is addressed. It = may=20 contain privileged or confidential information
and should not be=20 circulated or used for any purpose other than for
what it is=20 intended.

If you have received this message in error, please = notify=20 the
originator immediately. If you are not the intended = recipient,
you=20 are notified that you are strictly prohibited from = using,
copying,=20 altering, or disclosing the contents of this message.
FSL accepts = no=20 responsibility for loss or damage arising from
the use of the = information=20 transmitted by this email including
damage from=20 = virus.
***************************************************************= ************
------=_NextPart_000_0348_01C4BBE7.9B616F70-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 27 21:09:26 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05457 for ; Wed, 27 Oct 2004 21:09:24 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <7.00EC40FF@cherry.ease.lsoft.com>; Wed, 27 Oct 2004 21:09:19 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42070740 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 27 Oct 2004 21:09:18 -0400 Received: from 61.144.161.41 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 27 Oct 2004 20:59:15 -0400 Received: from z00895lab (mta1.huawei.com [172.17.1.60]) by mta1.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0I690015CRHAX9@mta1.huawei.com> for OSPF@PEACH.EASE.LSOFT.COM; Thu, 28 Oct 2004 08:46:23 +0800 (CST) MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: multipart/alternative; boundary="Boundary_(ID_L8XpisoKjRSR1mRPxcuCvQ)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com Message-ID: <000401c4bc89$8a9f1780$e8e9fea9@h3c.huawei3com.com> Date: Thu, 28 Oct 2004 09:00:38 +0800 Reply-To: Mailing List Sender: Mailing List From: Zhao Guang Subject: =?gb2312?B?tPC4tDogUmVjZWl2aW5nIFNlbGYtT3JpZ25hdGVkIFN1bW1hcnkgMyBMU0Fz?= To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <000001c4bbf5$6f97d6a0$cf04120a@in.huawei.com> Precedence: list This is a multi-part message in MIME format. --Boundary_(ID_L8XpisoKjRSR1mRPxcuCvQ) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable =C0=CF=B4=F3=A3=AC=C4=E3=B5=C4=D7=D6=CC=E5=CC=AB=B4=CC=D1=DB=C1=CB=A1=A3 =20 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] = =B4=FA=B1=ED sujay =B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA10=D4=C227=C8=D5 15:20 =CA=D5=BC=FE=C8=CB: OSPF@PEACH.EASE.LSOFT.COM =D6=F7=CC=E2: Re: Receiving Self-Orignated Summary 3 LSAs =20 Hi, As it looks like mostly R2 will not add the network route(inter area) = for the summary lsa it recvs from R1, because it already has a Intra area = route to the same=20 network , so it should not generate the summ lsa for the network back to area 2. Suggest you verify ! Sujay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of = Joseph Placid Sent: Wednesday, October 27, 2004 12:31 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Receiving Self-Orignated Summary 3 LSAs Hi All, =20 Consider this topology: =20 =20 [Area 0] - - - - R1 - - - - [Area 2] - - - - R2 - - - - [Area 0] =20 =20 When R1 receives a Network LSA from an internal router in Area 2, it summarises it into Area 0. This Summary LSA is seen by R2 since it has = an interface in the backbone. =20 Qn 1) Will R2 import this Summary LSA into Area 2?=20 Qn 2) If R1 comes across a self-originated Summary LSA for the same = Network in Area2 with a lower cost, what should it do? =20 =20 =20 Regards, Joseph Placid --Boundary_(ID_L8XpisoKjRSR1mRPxcuCvQ) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: quoted-printable Message

=C0=CF=B4=F3=A3=AC=C4=E3=B5=C4=D7=D6= =CC=E5=CC=AB=B4=CC=D1=DB=C1=CB=A1=A3

 

-----=D3=CA=BC=FE=D4=AD= =BC=FE-----
=B7=A2=BC=FE=C8=CB: = Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] =B4=FA=B1=ED sujay
=B7=A2=CB=CD=CA=B1=BC=E4: = 2004=C4=EA10=D4=C227=C8=D5 15:20
=CA=D5=BC=FE=C8=CB: = OSPF@PEACH.EASE.LSOFT.COM
=D6=F7=CC=E2: Re: = Receiving Self-Orignated Summary 3 LSAs

 

Hi,

As it looks like mostly R2 will not add the network route(inter area) for the summary lsa it recvs from R1, because = it already has a Intra area route to the same

network , so it should not generate the = summ lsa for the network back to area 2.

Suggest you verify = !

Sujay

-----Original Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Joseph Placid
Sent: Wednesday, October 27, 2004 12:31 PM
To: = OSPF@PEACH.EASE.LSOFT.COM
Subject: Receiving = Self-Orignated Summary 3 LSAs

Hi = All,

 

Consider this = topology:

 

 

[Area 0] - - - = - R1 - - - - [Area 2] - - - - R2 - - - - [Area 0]

 

 

When R1 = receives a Network LSA from an internal router in Area 2, it summarises it into = Area 0.  This Summary LSA is seen by R2 since it has an = interface in the backbone.

 

Qn = 1) Will R2 import this Summary LSA into Area 2? 

Qn 2) If = R1 comes across a self-originated Summary LSA for the same Network in Area2 with = a lower cost, what should it do?

 

 

 

Regards,

Joseph = Placid

--Boundary_(ID_L8XpisoKjRSR1mRPxcuCvQ)-- From owner-ospf@PEACH.EASE.LSOFT.COM Wed Oct 27 21:40:46 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07119 for ; Wed, 27 Oct 2004 21:40:46 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <11.00EC401F@cherry.ease.lsoft.com>; Wed, 27 Oct 2004 21:40:46 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42073465 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 27 Oct 2004 21:40:44 -0400 Received: from 219.150.144.124 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 27 Oct 2004 21:30:36 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4BC8D.9C33E9A6" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: reply: Receiving Self-Orignated Summary 3 LSAs Thread-Index: AcS8itpY9Ty/viCxR0+0H+LwW89v2gAAnLjQ Message-ID: <7A7A7A38134E244784EDAC428C538AE9BDF0DD@mail.ndsc.com.cn> Date: Thu, 28 Oct 2004 09:29:47 +0800 Reply-To: Mailing List Sender: Mailing List From: =?gb2312?B?xr3m59e/?= Subject: reply: Receiving Self-Orignated Summary 3 LSAs To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list This is a multi-part message in MIME format. ------_=_NextPart_001_01C4BC8D.9C33E9A6 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi,Jesoph. I can=A1=AFt understand your Qn2,can you detail the topology = further? How can R1 both receive a network LSA and originate one? Best regards, Jacky Ping =20 =20 =20 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Zhao Guang [mailto:zhao_guang@HUAWEI.COM]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA10=D4=C228=C8=D5 9:01 =CA=D5=BC=FE=C8=CB: OSPF@PEACH.EASE.LSOFT.COM =D6=F7=CC=E2: =B4=F0=B8=B4: Receiving Self-Orignated Summary 3 LSAs =20 =C0=CF=B4=F3=A3=AC=C4=E3=B5=C4=D7=D6=CC=E5=CC=AB=B4=CC=D1=DB=C1=CB=A1=A3 =20 -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] = =B4=FA=B1=ED sujay =B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA10=D4=C227=C8=D5 15:20 =CA=D5=BC=FE=C8=CB: OSPF@PEACH.EASE.LSOFT.COM =D6=F7=CC=E2: Re: Receiving Self-Orignated Summary 3 LSAs =20 Hi, As it looks like mostly R2 will not add the network route(inter area) = for the summary lsa it recvs from R1, because it already has a Intra = area route to the same=20 network , so it should not generate the summ lsa for the network back to = area 2. Suggest you verify ! Sujay -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of = Joseph Placid Sent: Wednesday, October 27, 2004 12:31 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Receiving Self-Orignated Summary 3 LSAs Hi All, =20 Consider this topology: =20 =20 [Area 0] - - - - R1 - - - - [Area 2] - - - - R2 - - - - [Area 0] =20 =20 When R1 receives a Network LSA from an internal router in Area 2, it = summarises it into Area 0. This Summary LSA is seen by R2 since it has = an interface in the backbone. =20 Qn 1) Will R2 import this Summary LSA into Area 2?=20 Qn 2) If R1 comes across a self-originated Summary LSA for the same = Network in Area2 with a lower cost, what should it do? =20 =20 =20 Regards, Joseph Placid ------_=_NextPart_001_01C4BC8D.9C33E9A6 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable Message

Hi,Jesoph.=

 &nbs= p;  I can=A1=AFt understand your Qn2,can you detail the = topology further?

 &nbs= p;  How can R1 both receive a network LSA and originate one?

 &nbs= p;  Best regards,

 &nbs= p;  Jacky Ping

 

 

 

-----=D3=CA=BC=FE=D4=AD= =BC=FE-----
=B7=A2=BC=FE=C8=CB: Zhao = Guang [mailto:zhao_guang@HUAWEI.COM]
=B7=A2=CB=CD=CA=B1=BC=E4: = 2004=C4=EA10=D4=C228=C8=D5 9:01
=CA=D5=BC=FE=C8=CB: = OSPF@PEACH.EASE.LSOFT.COM
=D6=F7=CC=E2: = =B4=F0=B8=B4: Receiving Self-Orignated Summary 3 LSAs

 

=C0=CF=B4=F3= =A3=AC=C4=E3=B5=C4=D7=D6=CC=E5=CC=AB=B4=CC=D1=DB=C1=CB=A1=A3

 

-----=D3=CA=BC=FE=D4=AD= =BC=FE-----
=B7=A2=BC=FE=C8=CB: = Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] =B4=FA=B1=ED sujay
=B7=A2=CB=CD=CA=B1=BC=E4: = 2004=C4=EA10=D4=C227=C8=D5 15:20
=CA=D5=BC=FE=C8=CB: = OSPF@PEACH.EASE.LSOFT.COM
=D6=F7=CC=E2: Re: = Receiving Self-Orignated Summary 3 LSAs

 

Hi,

As it looks like mostly R2 will not add the network route(inter area) for the summary lsa it recvs from R1, because = it already has a Intra area route to the same

network , so it should not generate the = summ lsa for the network back to area 2.

Suggest you verify = !

Sujay

-----Original Message-----
From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Joseph Placid
Sent: Wednesday, October 27, 2004 12:31 PM
To: = OSPF@PEACH.EASE.LSOFT.COM
Subject: Receiving = Self-Orignated Summary 3 LSAs

Hi = All,

 

Consider this = topology:

 

 

[Area 0] - - - = - R1 - - - - [Area 2] - - - - R2 - - - - [Area 0]

 

 

When R1 = receives a Network LSA from an internal router in Area 2, it summarises it into = Area 0.  This Summary LSA is seen by R2 since it has an = interface in the backbone.

 

Qn = 1) Will R2 import this Summary LSA into Area 2? 

Qn 2) If = R1 comes across a self-originated Summary LSA for the same Network in Area2 with = a lower cost, what should it do?

 

 

 

Regards,

Joseph = Placid

=00 ------_=_NextPart_001_01C4BC8D.9C33E9A6-- From owner-ospf@PEACH.EASE.LSOFT.COM Thu Oct 28 15:56:55 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28912 for ; Thu, 28 Oct 2004 15:56:54 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <13.00EC54A8@cherry.ease.lsoft.com>; Thu, 28 Oct 2004 15:56:50 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42209656 for OSPF@PEACH.EASE.LSOFT.COM; Thu, 28 Oct 2004 15:56:43 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Thu, 28 Oct 2004 15:56:42 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 3D0A447ECAE for ; Thu, 28 Oct 2004 12:56:41 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20985-06 for ; Thu, 28 Oct 2004 12:56:41 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.33]) by prattle.redback.com (Postfix) with SMTP id AABE047ECA9 for ; Thu, 28 Oct 2004 12:56:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <04ce01c4bd28$35353f00$0202a8c0@aceeinspiron> Date: Thu, 28 Oct 2004 15:56:25 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Tentative Agenda for 61st IETF To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit One more item: o RFC 2740 Re-spin 10 minutes Acee I've been keeping a list of errata and things that are ambiguous. I'd also add additional text for OSPFv3 NSSA processing. As many of you know, the OSPFv2 specification has been updated a number of times. I'm in the process of converting the text to xml (my preference for a maintainable source). ----- Original Message ----- From: "Acee Lindem" To: "OSPF Discussion List" Sent: Tuesday, October 26, 2004 4:57 PM Subject: Tentative Agenda for 61st IETF > Any additions? > > Open Shortest Path First WG (ospf) > > Monday, November 8th at 1530-1730 > ================================= > > CHAIR(s): Rohit Dube > Acee Lindem > > AGENDA: > > o Administriva 5 minutes > > - Mailing list: OSPF@PEACH.EASE.LSOFT.COM > Subscription/Removal: http://peach.ease.lsoft.com/scripts/wa.exe?SUBED1=ospf&A=1 > > - Scribe? > > - Blue Sheets > > o Document Status 10 minutes > Acee/Rohit > > o OSPFv3 MTR 15 minutes > draft-mirtorabi-mt-ospfv3-00.txt > Abhay Roy/Sina Mirtorabi > > o OSPF Wireless Design Team Status 20 minutes > Tom Henderson > > o OSPF Wireless Discussion 10-20 minutes > > Thanks, > ------ > Acee > From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 29 06:16:59 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14512 for ; Fri, 29 Oct 2004 06:16:59 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00EC6588@cherry.ease.lsoft.com>; Fri, 29 Oct 2004 6:16:56 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42289627 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 29 Oct 2004 06:16:55 -0400 Received: from 192.91.191.4 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 29 Oct 2004 06:16:51 -0400 Received: by goodman.datcon.co.uk with Internet Mail Service (5.5.2657.72) id <49HBHLC9>; Fri, 29 Oct 2004 11:16:41 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <53F74F5A7B94D511841C00B0D0AB16F802870BEE@baker.datcon.co.uk> Date: Fri, 29 Oct 2004 11:16:20 +0100 Reply-To: Mailing List Sender: Mailing List From: Nic Neate Subject: Some comments on RFC2740 Comments: To: "acee@redback.com" To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Acee and all, We've recently been implementing RFC2740, and seeing as you've just put a re-spin of it on the agenda for Washington, I thought this might be a good time for a few comments. Please let me know what you think, and if I've misunderstood anything. Unrecognized LSAs in Database Description packets ------------------------------------------------- RFC2740 section 3.2.2 states that processing received Database Description packets is unchanged from RFC2328 section 10.6. RFC2328 section 10.6 states that if a Database Description is received that contains an unrecognized LSA type, the adjacency is torn down: For each LSA listed, the LSA's LS type is checked for validity. If the LS type is unknown (e.g., not one of the LS types 1-5 defined by this specification), or if this is an AS- external-LSA (LS type = 5) and the neighbor is associated with a stub area, generate the neighbor event SeqNumberMismatch and stop processing the packet. This does not fit with the OSPFv3 procedures for processing unrecognized LSAs according to the U-, S1- and S2-bits in their LS type. I think the rules for which LSA types to accept in Database Descriptions should be the same as those for Link State Updates (section 3.5.1 of RFC2740). Note that there may be a backwards compatibility issue here. An implementation behaving as I've described will fail database exchange with a strict implementation of the current RFC2740. However, in reality I expect that all good implementations already allow unrecognized LSAs in Database Description packets, which is clearly in the spirit of RFC2740. Receiving Link State Update packets ----------------------------------- RFC2740 section 3.5.1 states that an LSA received in a Link State Update should be discarded if - the LS type us unknown, and - the area has been configured as a stub area, and - either the LSA's flooding scope is set to "AS flooding scope" or the U-bit of the LS type is set to 1 (flood even when unrecognized) This is intended to generalize the IPv4 behavior, where AS-external-LSAs are not flooded into/throughout stub areas. However, a strict adherence to those rules will cause you not to discard an AS-external-LSA in a stub area, because the LS type is recognized. I suggest that the rule is reworded along the following lines. Discard the LSA and get the next one from the Link State Update packet if - the area has been configured as a stub area, and - the LSA has AS flooding scope, and - either the LS type is recognized or the U-bit of the LS type is set to 1 (flood even if unrecognized). NSSAs, the R-bit and the V6-bit ------------------------------- It has already been noted several times on this list that the RFC isn't entirely clear in these areas. I think it would be well worth a re-spin of the RFC to create a permanent record of the clarifications proposed. Thanks, Nic From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 29 07:10:42 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17769 for ; Fri, 29 Oct 2004 07:10:41 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <17.00EC678A@cherry.ease.lsoft.com>; Fri, 29 Oct 2004 7:10:41 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42320565 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 29 Oct 2004 07:10:35 -0400 Received: from 63.197.255.158 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 29 Oct 2004 07:10:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: Some comments on RFC2740 Thread-Index: AcS9oVtAcGZyD7IRS+Gu0I/mqPyH2QABzCFQ Message-ID: Date: Fri, 29 Oct 2004 04:16:19 -0700 Reply-To: Mailing List Sender: Mailing List From: Vishwas Manral Subject: Re: Some comments on RFC2740 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: quoted-printable Hi Acee, One that comes to my mind is "Link-local unicast addresses are assigned from the IPv6 address range FF80/10" should be "FE80/10". Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Nic Neate Sent: Friday, October 29, 2004 3:46 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Some comments on RFC2740 Acee and all, We've recently been implementing RFC2740, and seeing as you've just put a re-spin of it on the agenda for Washington, I thought this might be a good time for a few comments. Please let me know what you think, and if I've misunderstood anything. Unrecognized LSAs in Database Description packets ------------------------------------------------- RFC2740 section 3.2.2 states that processing received Database Description packets is unchanged from RFC2328 section 10.6. RFC2328 section 10.6 states that if a Database Description is received that contains an unrecognized LSA type, the adjacency is torn down: For each LSA listed, the LSA's LS type is checked for validity. If the LS type is unknown (e.g., not one of the LS types 1-5 defined by this specification), or if this is an AS- external-LSA (LS type =3D 5) and the neighbor is associated with = a stub area, generate the neighbor event SeqNumberMismatch and stop processing the packet. This does not fit with the OSPFv3 procedures for processing unrecognized LSAs according to the U-, S1- and S2-bits in their LS type. I think the rules for which LSA types to accept in Database Descriptions should be the same as those for Link State Updates (section 3.5.1 of RFC2740). Note that there may be a backwards compatibility issue here. An implementation behaving as I've described will fail database exchange with a strict implementation of the current RFC2740. However, in reality I expect that all good implementations already allow unrecognized LSAs in Database Description packets, which is clearly in the spirit of RFC2740. Receiving Link State Update packets ----------------------------------- RFC2740 section 3.5.1 states that an LSA received in a Link State Update should be discarded if - the LS type us unknown, and - the area has been configured as a stub area, and - either the LSA's flooding scope is set to "AS flooding scope" or the U-bit of the LS type is set to 1 (flood even when unrecognized) This is intended to generalize the IPv4 behavior, where AS-external-LSAs are not flooded into/throughout stub areas. However, a strict adherence to those rules will cause you not to discard an AS-external-LSA in a stub area, because the LS type is recognized. I suggest that the rule is reworded along the following lines. Discard the LSA and get the next one from the Link State Update packet if - the area has been configured as a stub area, and - the LSA has AS flooding scope, and - either the LS type is recognized or the U-bit of the LS type is set to 1 (flood even if unrecognized). NSSAs, the R-bit and the V6-bit ------------------------------- It has already been noted several times on this list that the RFC isn't entirely clear in these areas. I think it would be well worth a re-spin of the RFC to create a permanent record of the clarifications proposed. Thanks, Nic From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 29 07:55:26 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21214 for ; Fri, 29 Oct 2004 07:55:24 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00EC66ED@cherry.ease.lsoft.com>; Fri, 29 Oct 2004 7:55:16 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42324363 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 29 Oct 2004 07:55:14 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 29 Oct 2004 07:55:14 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A86573284D1 for ; Fri, 29 Oct 2004 04:55:12 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08236-03 for ; Fri, 29 Oct 2004 04:55:12 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.27]) by prattle.redback.com (Postfix) with SMTP id 7AAE83284CF for ; Fri, 29 Oct 2004 04:55:11 -0700 (PDT) References: <53F74F5A7B94D511841C00B0D0AB16F802870BEE@baker.datcon.co.uk> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <001801c4bdae$2131fda0$0202a8c0@aceeinspiron> Date: Fri, 29 Oct 2004 07:55:03 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Some comments on RFC2740 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Nic, I agree with all 3 of your suggested clarifications. I think I only had the one regarding the options bits on my list previously. If you find any others, please send them to the list. Thanks, Acee ----- Original Message ----- From: "Nic Neate" To: Sent: Friday, October 29, 2004 6:16 AM Subject: Some comments on RFC2740 > Acee and all, > > We've recently been implementing RFC2740, and seeing as you've just put a > re-spin of it on the agenda for Washington, I thought this might be a good > time for a few comments. Please let me know what you think, and if I've > misunderstood anything. > > Unrecognized LSAs in Database Description packets > ------------------------------------------------- > > RFC2740 section 3.2.2 states that processing received Database Description > packets is unchanged from RFC2328 section 10.6. > > RFC2328 section 10.6 states that if a Database Description is received that > contains an unrecognized LSA type, the adjacency is torn down: > > For each LSA listed, the LSA's LS type is checked for > validity. If the LS type is unknown (e.g., not one of the LS > types 1-5 defined by this specification), or if this is an AS- > external-LSA (LS type = 5) and the neighbor is associated with a > stub area, generate the neighbor event SeqNumberMismatch and > stop processing the packet. > > This does not fit with the OSPFv3 procedures for processing unrecognized > LSAs according to the U-, S1- and S2-bits in their LS type. I think the > rules for which LSA types to accept in Database Descriptions should be the > same as those for Link State Updates (section 3.5.1 of RFC2740). > > Note that there may be a backwards compatibility issue here. An > implementation behaving as I've described will fail database exchange with a > strict implementation of the current RFC2740. However, in reality I expect > that all good implementations already allow unrecognized LSAs in Database > Description packets, which is clearly in the spirit of RFC2740. > > Receiving Link State Update packets > ----------------------------------- > > RFC2740 section 3.5.1 states that an LSA received in a Link State Update > should be discarded if > - the LS type us unknown, and > - the area has been configured as a stub area, and > - either the LSA's flooding scope is set to "AS flooding scope" or the > U-bit of the LS type is set to 1 (flood even when unrecognized) > > This is intended to generalize the IPv4 behavior, where AS-external-LSAs are > not flooded into/throughout stub areas. However, a strict adherence to > those rules will cause you not to discard an AS-external-LSA in a stub area, > because the LS type is recognized. I suggest that the rule is reworded > along the following lines. > > Discard the LSA and get the next one from the Link State > Update packet if > - the area has been configured as a stub area, and > - the LSA has AS flooding scope, and > - either the LS type is recognized or the U-bit of the LS > type is set to 1 (flood even if unrecognized). > > NSSAs, the R-bit and the V6-bit > ------------------------------- > > It has already been noted several times on this list that the RFC isn't > entirely clear in these areas. I think it would be well worth a re-spin of > the RFC to create a permanent record of the clarifications proposed. > > Thanks, > > Nic From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 29 08:01:09 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21416 for ; Fri, 29 Oct 2004 08:01:09 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <12.00EC6738@cherry.ease.lsoft.com>; Fri, 29 Oct 2004 8:01:09 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42325067 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 29 Oct 2004 08:01:04 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 29 Oct 2004 08:01:04 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 7E01165DA22 for ; Fri, 29 Oct 2004 05:01:03 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09124-01 for ; Fri, 29 Oct 2004 05:01:03 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.27]) by prattle.redback.com (Postfix) with SMTP id 9C45E65DA21 for ; Fri, 29 Oct 2004 05:01:02 -0700 (PDT) References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <003601c4bdae$f27b69f0$0202a8c0@aceeinspiron> Date: Fri, 29 Oct 2004 08:00:55 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: Some comments on RFC2740 To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Vishwas, This one was brought up long enough ago that I didn't have it in my list (I think I sent a write to the RFC editor for rfc-errata but I see it never got added to the errata for RFC 2740). Thanks, Acee ----- Original Message ----- From: "Vishwas Manral" To: Sent: Friday, October 29, 2004 7:16 AM Subject: Re: Some comments on RFC2740 Hi Acee, One that comes to my mind is "Link-local unicast addresses are assigned from the IPv6 address range FF80/10" should be "FE80/10". Thanks, Vishwas -----Original Message----- From: Mailing List [mailto:OSPF@PEACH.EASE.LSOFT.COM] On Behalf Of Nic Neate Sent: Friday, October 29, 2004 3:46 PM To: OSPF@PEACH.EASE.LSOFT.COM Subject: Some comments on RFC2740 Acee and all, We've recently been implementing RFC2740, and seeing as you've just put a re-spin of it on the agenda for Washington, I thought this might be a good time for a few comments. Please let me know what you think, and if I've misunderstood anything. Unrecognized LSAs in Database Description packets ------------------------------------------------- RFC2740 section 3.2.2 states that processing received Database Description packets is unchanged from RFC2328 section 10.6. RFC2328 section 10.6 states that if a Database Description is received that contains an unrecognized LSA type, the adjacency is torn down: For each LSA listed, the LSA's LS type is checked for validity. If the LS type is unknown (e.g., not one of the LS types 1-5 defined by this specification), or if this is an AS- external-LSA (LS type = 5) and the neighbor is associated with a stub area, generate the neighbor event SeqNumberMismatch and stop processing the packet. This does not fit with the OSPFv3 procedures for processing unrecognized LSAs according to the U-, S1- and S2-bits in their LS type. I think the rules for which LSA types to accept in Database Descriptions should be the same as those for Link State Updates (section 3.5.1 of RFC2740). Note that there may be a backwards compatibility issue here. An implementation behaving as I've described will fail database exchange with a strict implementation of the current RFC2740. However, in reality I expect that all good implementations already allow unrecognized LSAs in Database Description packets, which is clearly in the spirit of RFC2740. Receiving Link State Update packets ----------------------------------- RFC2740 section 3.5.1 states that an LSA received in a Link State Update should be discarded if - the LS type us unknown, and - the area has been configured as a stub area, and - either the LSA's flooding scope is set to "AS flooding scope" or the U-bit of the LS type is set to 1 (flood even when unrecognized) This is intended to generalize the IPv4 behavior, where AS-external-LSAs are not flooded into/throughout stub areas. However, a strict adherence to those rules will cause you not to discard an AS-external-LSA in a stub area, because the LS type is recognized. I suggest that the rule is reworded along the following lines. Discard the LSA and get the next one from the Link State Update packet if - the area has been configured as a stub area, and - the LSA has AS flooding scope, and - either the LS type is recognized or the U-bit of the LS type is set to 1 (flood even if unrecognized). NSSAs, the R-bit and the V6-bit ------------------------------- It has already been noted several times on this list that the RFC isn't entirely clear in these areas. I think it would be well worth a re-spin of the RFC to create a permanent record of the clarifications proposed. Thanks, Nic From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 29 13:53:39 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19392 for ; Fri, 29 Oct 2004 13:53:38 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00EC6E6C@cherry.ease.lsoft.com>; Fri, 29 Oct 2004 13:53:35 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42360197 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 29 Oct 2004 13:53:33 -0400 Received: from 158.130.12.194 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 29 Oct 2004 13:43:33 -0400 Received: from ee.upenn.edu (mx.ipsumnetworks.com [209.218.185.34]) (authenticated bits=0) by lion.seas.upenn.edu (8.12.10/8.12.10) with ESMTP id i9THhV6C027388 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 29 Oct 2004 13:43:32 -0400 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <4182813B.3060603@ee.upenn.edu> Date: Fri, 29 Oct 2004 13:43:23 -0400 Reply-To: Mailing List Sender: Mailing List From: Roch Guerin Organization: University of Pennsylvania Subject: NSSA question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Sorry to bug with a potentially irrelevant question, but I searched the mailing list archive and could not find an answer to my question. We have developed software that emulates network-wide routing decisions in an OSPF network based on the LSAs received in each area, i.e., by reproducing the routing table computations that would be performed at each router, and that forces us to precisely account for all the possible corner cases that one might encounter in various topologies. In that context, I had a question regarding step (6)(e) of the routing table calculation for Type 7 external routes, as it is described in section 2.5 of RFC 3101. Basically, I wanted to know if step (6)(e) was carried out in parallel or as a follow-up to the other earlier steps of (6), i.e., steps (6)(a) to (6)(d). The latter steps are present in the regular (non-NSSA) OSPF processing for external routes as specified in RFC 2328, and step (6)(e) is a new one that is specific to NSSA and I want to make sure I am interpreting it correctly. Specifically, assume an NSSA that is connected to the backbone area through two ABRs, ABR1 and ABR2, where ABR2 is also an ASBR. Consider now an external route reachable though ABR2 in its capacity as an ASBR, and for which ABR2 specifies a non-zero forwarding address pointing to a subnet inside the NSSA. ABR2 would advertise a T7 with a non-zero forwarding address and the P-bit clear in the NSSA (it already advertises itself a T5 in the rest of the network) and a T5 with the same non-zero forwarding address in the rest of the network. ABR1 therefore has two functionally equivalent LSAs, a T7 and a T5, for that route. Assuming that RFC 1583 compatibility is disabled, when reaching step (6)(c), ABR1 would prefer the intra-area (through the NSSA) path to ABR2. However, if I consider step (6)(e), unless I assume that it is performed *after* step (6)(c), it says that ABR1 should prefer the backbone path to ABR2 (the T7 from ABR2 does not have its P-bit set, and so the T5 should be preferred). My current understanding is that step (6)(e) is indeed performed *after* step (6)(c) so that in the above example, ABR1 would select the path through the NSSA to ABR2, but I wanted to confirm that this was indeed correct. Assuming it is the correct understanding, could someone give an example of when step (6)(e) is actually used? Thanks in advance. Roch From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 29 14:38:29 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22527 for ; Fri, 29 Oct 2004 14:38:29 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <15.00EC6F75@cherry.ease.lsoft.com>; Fri, 29 Oct 2004 14:38:28 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42365871 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 29 Oct 2004 14:38:23 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 29 Oct 2004 14:38:22 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B099343E8F8 for ; Fri, 29 Oct 2004 11:38:09 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11113-08 for ; Fri, 29 Oct 2004 11:38:09 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.35]) by prattle.redback.com (Postfix) with SMTP id 7A06E43E8FB for ; Fri, 29 Oct 2004 11:38:08 -0700 (PDT) References: <4182813B.3060603@ee.upenn.edu> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <00c901c4bde6$6b66bf40$0202a8c0@aceeinspiron> Date: Fri, 29 Oct 2004 14:38:00 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: NSSA question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Roch, Long time no see - see inline. ----- Original Message ----- From: "Roch Guerin" To: Sent: Friday, October 29, 2004 1:43 PM Subject: NSSA question > Sorry to bug with a potentially irrelevant question, but I searched the > mailing list archive and could not find an answer to my question. > > We have developed software that emulates network-wide routing decisions > in an OSPF network based on the LSAs received in each area, i.e., by > reproducing the routing table computations that would be performed at > each router, and that forces us to precisely account for all the > possible corner cases that one might encounter in various topologies. Please post a pointer to the list when you are ready to make this work public (assuming it is being done under the auspices of the University of Pennslyvania). > > In that context, I had a question regarding step (6)(e) of the routing > table calculation for Type 7 external routes, as it is described in > section 2.5 of RFC 3101. Basically, I wanted to know if step (6)(e) was > carried out in parallel or as a follow-up to the other earlier steps of > (6), i.e., steps (6)(a) to (6)(d). The latter steps are present in the > regular (non-NSSA) OSPF processing for external routes as specified in > RFC 2328, and step (6)(e) is a new one that is specific to NSSA and I > want to make sure I am interpreting it correctly. The precedence rules are meant to be performed in order. > > Specifically, assume an NSSA that is connected to the backbone area > through two ABRs, ABR1 and ABR2, where ABR2 is also an ASBR. Consider > now an external route reachable though ABR2 in its capacity as an ASBR, > and for which ABR2 specifies a non-zero forwarding address pointing to a > subnet inside the NSSA. ABR2 would advertise a T7 with a non-zero > forwarding address and the P-bit clear in the NSSA (it already > advertises itself a T5 in the rest of the network) and a T5 with the > same non-zero forwarding address in the rest of the network. > > ABR1 therefore has two functionally equivalent LSAs, a T7 and a T5, for > that route. Assuming that RFC 1583 compatibility is disabled, when > reaching step (6)(c), ABR1 would prefer the intra-area (through the > NSSA) path to ABR2. However, if I consider step (6)(e), unless I assume > that it is performed *after* step (6)(c), it says that ABR1 should > prefer the backbone path to ABR2 (the T7 from ABR2 does not have its > P-bit set, and so the T5 should be preferred). > > My current understanding is that step (6)(e) is indeed performed *after* > step (6)(c) so that in the above example, ABR1 would select the path > through the NSSA to ABR2, but I wanted to confirm that this was indeed > correct. That is my interpretation as well. > Assuming it is the correct understanding, could someone give > an example of when step (6)(e) is actually used? Only when different ASBRs are advertising the same external prefix and other route attributes are equal. Admittedly, it seems that it would hard for (6)(e)(2) to ever come into play. You'd need to have two ASBRs: one in an NSSA and one in a regular non-backbone area advertising the same prefix and the one in the NSSA would need to disable the setting of the P via policy (my implementation allows this via the route map used for redistribution). Am I missing anything? It's been a long week... Good Luck, Acee > > Thanks in advance. > > Roch From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 29 14:39:34 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22608 for ; Fri, 29 Oct 2004 14:39:31 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <1.00EC6F4B@cherry.ease.lsoft.com>; Fri, 29 Oct 2004 14:39:29 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42367751 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 29 Oct 2004 14:39:24 -0400 Received: from 158.130.12.194 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 29 Oct 2004 14:39:22 -0400 Received: from ee.upenn.edu (M367PC1.CIS.upenn.edu [158.130.12.199]) (authenticated bits=0) by lion.seas.upenn.edu (8.12.10/8.12.10) with ESMTP id i9TIdL6C029302 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 29 Oct 2004 14:39:21 -0400 User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <4182813B.3060603@ee.upenn.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41828E25.7080805@ee.upenn.edu> Date: Fri, 29 Oct 2004 14:38:29 -0400 Reply-To: Mailing List Sender: Mailing List From: Roch Guerin Subject: Re: NSSA question To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <4182813B.3060603@ee.upenn.edu> Precedence: list Content-Transfer-Encoding: 7bit Another related question, but that this time results in a potentially inconsistent behavior between RFC 3101 and RFC 2328 involves a similar configuration as the one described below, namely, two ABRs, ABR1 and ABR2, where ABR2 is also an ASBR, but now in addition to the backbone, the two ABRs also share connectivity to two other non-backone areas, and two make things easier, lets assume that both those other areas are NSSAs. Because ABR2 is an ASBR that advertises itself its T5's in the rest of the network, it sends T7's in both NSSAs with the P-bit clear. But now because the P-bit is clear, it seems that ABR2 is NOT required to set the forwarding address to a non-zero value (see p.9 of RFC 3101, i.e., "If the P-bit is set, the forwarding address must be non-zero; otherwise it may be 0.0.0.0." If that happens, then step (6)(e) is never invoked. This would result in the two paths between ABR1 and ABR2 being kept, obviously assuming that they are equal cost. This is inconsistent with the pruning based on area ID that is specified in RFC 2328. Should I therefore assume that RFC 3101 mandates that ABR2 always set the forwarding address to a non-zero value if it is advertising a route using both T7 and T5 LSAs? I could not find language in RFC 3101 that stated this requirement explicitly. Thanks in advance, Roch > Sorry to bug with a potentially irrelevant question, but I searched > the mailing list archive and could not find an answer to my question. > > We have developed software that emulates network-wide routing > decisions in an OSPF network based on the LSAs received in each area, > i.e., by reproducing the routing table computations that would be > performed at each router, and that forces us to precisely account for > all the possible corner cases that one might encounter in various > topologies. > In that context, I had a question regarding step (6)(e) of the routing > table calculation for Type 7 external routes, as it is described in > section 2.5 of RFC 3101. Basically, I wanted to know if step (6)(e) > was carried out in parallel or as a follow-up to the other earlier > steps of (6), i.e., steps (6)(a) to (6)(d). The latter steps are > present in the regular (non-NSSA) OSPF processing for external routes > as specified in RFC 2328, and step (6)(e) is a new one that is > specific to NSSA and I want to make sure I am interpreting it correctly. > > Specifically, assume an NSSA that is connected to the backbone area > through two ABRs, ABR1 and ABR2, where ABR2 is also an ASBR. Consider > now an external route reachable though ABR2 in its capacity as an > ASBR, and for which ABR2 specifies a non-zero forwarding address > pointing to a subnet inside the NSSA. ABR2 would advertise a T7 with > a non-zero forwarding address and the P-bit clear in the NSSA (it > already advertises itself a T5 in the rest of the network) and a T5 > with the same non-zero forwarding address in the rest of the network. > ABR1 therefore has two functionally equivalent LSAs, a T7 and a T5, > for that route. Assuming that RFC 1583 compatibility is disabled, > when reaching step (6)(c), ABR1 would prefer the intra-area (through > the NSSA) path to ABR2. However, if I consider step (6)(e), unless I > assume that it is performed *after* step (6)(c), it says that ABR1 > should prefer the backbone path to ABR2 (the T7 from ABR2 does not > have its P-bit set, and so the T5 should be preferred). > > My current understanding is that step (6)(e) is indeed performed > *after* step (6)(c) so that in the above example, ABR1 would select > the path through the NSSA to ABR2, but I wanted to confirm that this > was indeed correct. Assuming it is the correct understanding, could > someone give an example of when step (6)(e) is actually used? > > Thanks in advance. > > Roch From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 29 15:08:46 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25190 for ; Fri, 29 Oct 2004 15:08:46 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <23.00EC6F90@cherry.ease.lsoft.com>; Fri, 29 Oct 2004 15:08:33 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42371164 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 29 Oct 2004 15:08:32 -0400 Received: from 155.53.12.9 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 29 Oct 2004 15:08:32 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 453B966E846 for ; Fri, 29 Oct 2004 12:08:31 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17926-03 for ; Fri, 29 Oct 2004 12:08:30 -0700 (PDT) Received: from aceeinspiron (unknown [172.31.253.35]) by prattle.redback.com (Postfix) with SMTP id 4B95166E842 for ; Fri, 29 Oct 2004 12:08:30 -0700 (PDT) References: <4182813B.3060603@ee.upenn.edu> <41828E25.7080805@ee.upenn.edu> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Virus-Scanned: by amavisd-new at redback.com Message-ID: <00dc01c4bdea$a942c9e0$0202a8c0@aceeinspiron> Date: Fri, 29 Oct 2004 15:08:22 -0400 Reply-To: Mailing List Sender: Mailing List From: Acee Lindem Subject: Re: NSSA question To: OSPF@PEACH.EASE.LSOFT.COM Precedence: list Content-Transfer-Encoding: 7bit Hi Roch, ----- Original Message ----- From: "Roch Guerin" To: Sent: Friday, October 29, 2004 2:38 PM Subject: Re: NSSA question > Another related question, but that this time results in a potentially > inconsistent behavior between RFC 3101 and RFC 2328 involves a similar > configuration as the one described below, namely, two ABRs, ABR1 and > ABR2, where ABR2 is also an ASBR, but now in addition to the backbone, > the two ABRs also share connectivity to two other non-backone areas, and > two make things easier, lets assume that both those other areas are NSSAs. > > Because ABR2 is an ASBR that advertises itself its T5's in the rest of > the network, it sends T7's in both NSSAs with the P-bit clear. But now > because the P-bit is clear, it seems that ABR2 is NOT required to set > the forwarding address to a non-zero value (see p.9 of RFC 3101, i.e., > > "If the P-bit is set, the forwarding address must be non-zero; otherwise it may be 0.0.0.0." > > > If that happens, then step (6)(e) is never invoked. This would result > in the two paths between ABR1 and ABR2 being kept, obviously assuming > that they are equal cost. This is inconsistent with the pruning based > on area ID that is specified in RFC 2328. > > Should I therefore assume that RFC 3101 mandates that ABR2 always set > the forwarding address to a non-zero value if it is advertising a route > using both T7 and T5 LSAs? I could not find language in RFC 3101 that > stated this requirement explicitly. I think the assumption from RFC 3101 doesn't take this case into account. Since a Type-7 LSA only has area-wide flooding scope, when its forwarding address is set to 0.0.0.0, its ASBR's routing table entry must be chosen from the originating NSSA. Here no pruning is necessary since this entry always contains non- backbone intra-area paths. I must admit that in one implemenation that I worked on I added a knob to allow ECMP routes for AS externals to be calculated through multiple areas. > > Thanks in advance, > > Roch > >> Sorry to bug with a potentially irrelevant question, but I searched >> the mailing list archive and could not find an answer to my question. >> >> We have developed software that emulates network-wide routing >> decisions in an OSPF network based on the LSAs received in each area, >> i.e., by reproducing the routing table computations that would be >> performed at each router, and that forces us to precisely account for >> all the possible corner cases that one might encounter in various >> topologies. >> In that context, I had a question regarding step (6)(e) of the routing >> table calculation for Type 7 external routes, as it is described in >> section 2.5 of RFC 3101. Basically, I wanted to know if step (6)(e) >> was carried out in parallel or as a follow-up to the other earlier >> steps of (6), i.e., steps (6)(a) to (6)(d). The latter steps are >> present in the regular (non-NSSA) OSPF processing for external routes >> as specified in RFC 2328, and step (6)(e) is a new one that is >> specific to NSSA and I want to make sure I am interpreting it correctly. >> >> Specifically, assume an NSSA that is connected to the backbone area >> through two ABRs, ABR1 and ABR2, where ABR2 is also an ASBR. Consider >> now an external route reachable though ABR2 in its capacity as an >> ASBR, and for which ABR2 specifies a non-zero forwarding address >> pointing to a subnet inside the NSSA. ABR2 would advertise a T7 with >> a non-zero forwarding address and the P-bit clear in the NSSA (it >> already advertises itself a T5 in the rest of the network) and a T5 >> with the same non-zero forwarding address in the rest of the network. >> ABR1 therefore has two functionally equivalent LSAs, a T7 and a T5, >> for that route. Assuming that RFC 1583 compatibility is disabled, >> when reaching step (6)(c), ABR1 would prefer the intra-area (through >> the NSSA) path to ABR2. However, if I consider step (6)(e), unless I >> assume that it is performed *after* step (6)(c), it says that ABR1 >> should prefer the backbone path to ABR2 (the T7 from ABR2 does not >> have its P-bit set, and so the T5 should be preferred). >> >> My current understanding is that step (6)(e) is indeed performed >> *after* step (6)(c) so that in the above example, ABR1 would select >> the path through the NSSA to ABR2, but I wanted to confirm that this >> was indeed correct. Assuming it is the correct understanding, could >> someone give an example of when step (6)(e) is actually used? >> >> Thanks in advance. >> >> Roch From owner-ospf@PEACH.EASE.LSOFT.COM Fri Oct 29 15:19:12 2004 Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26970 for ; Fri, 29 Oct 2004 15:19:11 -0400 (EDT) Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <16.00EC6FC6@cherry.ease.lsoft.com>; Fri, 29 Oct 2004 15:19:12 -0400 Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 42371851 for OSPF@PEACH.EASE.LSOFT.COM; Fri, 29 Oct 2004 15:19:11 -0400 Received: from 158.130.12.194 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Fri, 29 Oct 2004 15:19:11 -0400 Received: from ee.upenn.edu (M367PC1.CIS.upenn.edu [158.130.12.199]) (authenticated bits=0) by lion.seas.upenn.edu (8.12.10/8.12.10) with ESMTP id i9TJJA6C032593 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 29 Oct 2004 15:19:10 -0400 User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <4182813B.3060603@ee.upenn.edu> <41828E25.7080805@ee.upenn.edu> <00dc01c4bdea$a942c9e0$0202a8c0@aceeinspiron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <41829779.6030600@ee.upenn.edu> Date: Fri, 29 Oct 2004 15:18:17 -0400 Reply-To: Mailing List Sender: Mailing List From: Roch Guerin Subject: Re: NSSA question To: OSPF@PEACH.EASE.LSOFT.COM In-Reply-To: <00dc01c4bdea$a942c9e0$0202a8c0@aceeinspiron> Precedence: list Content-Transfer-Encoding: 7bit Acee, Thanks. This is a bit of a corner case and it may not happen that often but it indeed seemed that RFC 3101 had left this case open to interpretation and therefore to different implementations. We'll be testing a couple of different implementations to see how they behave for this particular configuration and I'll report what we find, but I'd be interested in any data on how other implementations handle it. Thanks, Roch > Hi Roch, > > ----- Original Message ----- > From: "Roch Guerin" > To: > Sent: Friday, October 29, 2004 2:38 PM > Subject: Re: NSSA question > > >> Another related question, but that this time results in a potentially >> inconsistent behavior between RFC 3101 and RFC 2328 involves a similar >> configuration as the one described below, namely, two ABRs, ABR1 and >> ABR2, where ABR2 is also an ASBR, but now in addition to the backbone, >> the two ABRs also share connectivity to two other non-backone areas, and >> two make things easier, lets assume that both those other areas are >> NSSAs. >> >> Because ABR2 is an ASBR that advertises itself its T5's in the rest of >> the network, it sends T7's in both NSSAs with the P-bit clear. But now >> because the P-bit is clear, it seems that ABR2 is NOT required to set >> the forwarding address to a non-zero value (see p.9 of RFC 3101, i.e., >> >> "If the P-bit is set, the forwarding address must be non-zero; >> otherwise it may be 0.0.0.0." >> >> >> If that happens, then step (6)(e) is never invoked. This would result >> in the two paths between ABR1 and ABR2 being kept, obviously assuming >> that they are equal cost. This is inconsistent with the pruning based >> on area ID that is specified in RFC 2328. >> >> Should I therefore assume that RFC 3101 mandates that ABR2 always set >> the forwarding address to a non-zero value if it is advertising a route >> using both T7 and T5 LSAs? I could not find language in RFC 3101 that >> stated this requirement explicitly. > > > I think the assumption from RFC 3101 doesn't take this case into account. > > Since a Type-7 LSA only has area-wide flooding scope, when its > forwarding address is set to 0.0.0.0, its ASBR's routing table > entry must be chosen from the originating NSSA. Here no > pruning is necessary since this entry always contains non- > backbone intra-area paths. > > I must admit that in one implemenation that I worked on I added a knob to > allow ECMP routes for AS externals to be calculated through multiple > areas. > >