Re: MOSPF can't determine the receiving interface exactly - In John Moy's book OSPF Anatomy of a Routing Protocol
Yasuhiro Ohara <yasu@SFC.WIDE.AD.JP> Tue, 10 June 2003 23:29 UTC
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 TAA22805 for <ospf-archive@LISTS.IETF.ORG>; Tue, 10 Jun 2003 19:29:10 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <3.00A0B31C@cherry.ease.lsoft.com>; Tue, 10 Jun 2003 19:29:11 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 45216078 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 10 Jun 2003 19:29:10 -0400
Received: from 203.178.143.91 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 10 Jun 2003 19:29:09 -0400
Received: from localhost (localhost [127.0.0.1]) by plant.sfc.wide.ad.jp (Postfix) with ESMTP id 6196D3741; Wed, 11 Jun 2003 08:29:07 +0900 (JST)
References: <20030605124150.51373.qmail@web9504.mail.yahoo.com>
X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20030611.082906.09627731.yasu@sfc.wide.ad.jp>
Date: Wed, 11 Jun 2003 08:29:06 +0900
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Yasuhiro Ohara <yasu@SFC.WIDE.AD.JP>
Subject: Re: MOSPF can't determine the receiving interface exactly - In John Moy's book OSPF Anatomy of a Routing Protocol
Comments: To: ijpotts_lists@YAHOO.CO.UK
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <20030605124150.51373.qmail@web9504.mail.yahoo.com>
Precedence: list
Content-Transfer-Encoding: 7bit
Hi, I try to explain. Even in your example, actually you don't determine the receiving half of the point-to-point link. You can only know the receiving interface of the other router by *guessing*, and you can guess only because they don't have any other links to the same router. Let's suppose your example have two point-to-point links between Router 1 and Router 2 as it will be easier to understand. (The book also mentions that configuration, "when multiple point-to-point links connect the router to the neighbor" in the same section) The Router-LSAs in the database will be like below. Router 1 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 144.141.252.254 (Link Data) Router Interface address: 144.128.254.138 Number of TOS metrics: 0 TOS 0 Metrics: 1000 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 144.141.252.254 (Link Data) Router Interface address: 10.1.1.1 (or whatever) Number of TOS metrics: 0 TOS 0 Metrics: 10000 (or whatever) Router 2 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 144.141.89.2 (Link Data) Router Interface address: 144.128.254.137 Number of TOS metrics: 0 TOS 0 Metrics: 1000 Link connected to: another Router (point-to-point) (Link ID) Neighboring Router ID: 144.141.89.2 (Link Data) Router Interface address: 192.168.0.1 (or whatever) Number of TOS metrics: 0 TOS 0 Metrics: 10000 (or whatever) Then, can you illustrate the network configuration, specifically which interface of Router 1 is connected to the interface which is described as Link-Description #1 in the Router 2's Router-LSA ? Why ? Note that point-to-point link can be configured not to share the IP-subnet. So Router 1's interface having address 144.128.254.138 may not necessarily be connected to the Router 2's interface having address 144.128.254.137. For the multicast forwarding of direction from Router 1 to Router 2, both router can calculate that Router 1 should send the datagrams on the interface #1 (having address 144.128.254.138), because it has lower cost. But neither router can determine which interface the Router 2 will receive that datagram on. This problem is resolved in OSPFv3 as each single Link Description in Router-LSA describes both sending and receiving halves (by describing both side of IfIndex). OSPFv2's Link Description only describes sending half and the *Router-ID* of receiving router. It doesn't describe receiving half (interface) of receiving router. Hope this helps. regards, yasu From: Ian Potts <ijpotts_lists@YAHOO.CO.UK> Subject: MOSPF can't determine the receiving interface exactly - In John Moy's book OSPF Anatomy of a Routing Protocol Date: Thu, 5 Jun 2003 13:41:50 +0100 > Hello, > > In John Moy's excellent book, Anatomy of an Internet > Routing Protocol, on page 195 (section 10.3.1 The > Multicast Forwarding Cache), it states that a router > does the RPF check in MOSPF on the router's ID, and > not on the incoming interface, since MOSPF can't > determine the receiving interface exactly, since there > is insufficient information in the OSPF lsdb to match > the sending and receiving halves. > > Can someone please explain this to me since I am > confused. Looking at the router LSAs given below, > can't the router first work out the router-id, then > consult the routing table to find the interface? > > Many Thanks > Ian > > Router 1 > > Link connected to: another Router (point-to-point) > (Link ID) Neighboring Router ID: 144.141.252.254 > (Link Data) Router Interface address: 144.128.254.138 > Number of TOS metrics: 0 > TOS 0 Metrics: 1000 > > Link connected to: a Stub Network > (Link ID) Network/subnet number: 144.128.254.136 > (Link Data) Network Mask: 255.255.255.248 > Number of TOS metrics: 0 > TOS 0 Metrics: 1000 > > Router 2 > > Link connected to: another Router (point-to-point) > (Link ID) Neighboring Router ID: 144.141.89.2 > (Link Data) Router Interface address: 144.128.254.137 > Number of TOS metrics: 0 > TOS 0 Metrics: 1000 > > Link connected to: a Stub Network > (Link ID) Network/subnet number: 144.128.254.136 > (Link Data) Network Mask: 255.255.255.248 > Number of TOS metrics: 0 > TOS 0 Metrics: 1000 > > > > > __________________________________________________ > Yahoo! Plus - For a better Internet experience > http://uk.promotions.yahoo.com/yplus/yoffer.html
- MOSPF can't determine the receiving interface exa… Ian Potts
- Re: MOSPF can't determine the receiving interface… Yasuhiro Ohara