"Juergen Arlt" <[email protected]> wrote on 28/07/2009 15:09:49: > > I don't want to worm up the long discussion that took place in January > (thanks to Joakims hint) but I still read that the option 1 should be > used to advertise the remote router IP as a stub host route - though it > is not required for the protocol to work. I agree however that in the > LSA example of 2328 Router 3 ommited the option 1 as well. > > But the advertisement of the neighbor IP is clearly stated in RFC 1583 > and I would read now the same in 2328. > > Quote "When interface addresses are assigned, they are modelled as stub > links, with each router advertising a stub connection to the other > router's interface address."
Since the P2P I/F has an IP address(as I read it) and I guess an /32 mask I think you can view it as an numbered I/F and use Option 1. It does not matter that the IP address isn't unique I think. I you have many P2P links you get a significantly bigger Router LSA though so I think Acee's suggestion is better. > > The issue however is actually not the tunnel endpoint reachability but > our developers did advertise the network of the unnumbered associated IP > address as stub (which did not even have OSPF configured) along with the > ptp link which led to some weird routing problems. > > Now I am trying to convince them to correct this and want to make sure > it is done correctly. So I proposed to use option 1 - as we know the > tunnel endpoints IP (manual configuration) and remove the incorrect > option 2 implementation. > > Thanks > Juergen > > > > -----Original Message----- > From: Acee Lindem [mailto:[email protected]] > Sent: Dienstag, 28. Juli 2009 14:50 > To: Joakim Tjernlund > Cc: Arlt, Juergen (GERST:476S); [email protected] > Subject: Re: [OSPF] Question about Stub advertisement of a PtP link RFC > 2328 > > Hi Joakim, Juergen, > > That is correct, there is no stub link at all associated with an > unnumbered link. It sounds like you have some requirements to > advertise local endpoints though. If you are truly modeling the > tunnel as an unnumbered P2P interface, then these requirements should > be satisfied by advertising the endpoint interface independently as a > stub link. Many times this is the loopback and the endpoint for many > tunnels. > > Thanks, > Acee > On Jul 28, 2009, at 6:34 AM, Joakim Tjernlund wrote: > > > "Juergen Arlt" <[email protected]> wrote on 28/07/2009 12:22:44: > >> > >> As I need to convince our development team - can you give me some > >> more > >> background on this. They are advertising currently the associated > >> address for the link (that to me is the incorrect approach) which > >> caused > >> some misbehavior in the network. > >> Thanks and regards > >> Juergen > > > > Just find the discussion in the archive. It was quite clear what to > > do. > > Acee Lindem, chair of OSPF WG, clarified this and there was no > > room for other interpretations. If you read the OSPF spec there are > > lots of hints and the previous version of the OSPF spec was very clear > > too. > > > > Jocke > > > >> > >> -----Original Message----- > >> From: Joakim Tjernlund [mailto:[email protected]] > >> Sent: Dienstag, 28. Juli 2009 12:15 > >> To: Arlt, Juergen (GERST:476S) > >> Cc: [email protected] > >> Subject: Re: [OSPF] Question about Stub advertisement of a PtP > >> link RFC > >> 2328 > >> > >>> > >>> I have a very specific problem on an unnumbered point to point link > >> for an > >>> IPsec tunnel. This link is associated to another IP interfaces > >>> address > >> on the > >>> device to borrow an IP (source) address for the packets. The link > >> itself (as > >>> being unnumbered has no IP subnet assigned). > >>> Which option of the following in "12.4.1.1. Describing point-to- > >>> point > >>> interfaces" would apply for the stub area advertisement? > >>> In addition, as long as the state of the > >> interface > >>> is "Point-to-Point" (and regardless of the > >>> neighboring router state), a Type 3 link (stub > >>> network) should be added. There are two forms > >>> that > >>> this stub link can take: > >>> Option 1 > >>> Assuming that the neighboring router's IP > >>> address is known, set the Link ID of the > >>> Type > >> 3 > >>> link to the neighbor's IP address, the Link > >> Data > >>> to the mask 0xffffffff (indicating a host > >>> route), and the cost to the interface's > >>> configured output cost.[15] > >>> Option 2 > >>> If a subnet has been assigned to the > >>> point-to- > >>> point link, set the Link ID of the Type 3 > >>> link > >>> to the subnet's IP address, the Link Data to > >> the > >>> subnet's mask, and the cost to the > >>> interface's > >>> configured output cost.[16] > >>> I would read that option 2 would not apply as the link is unnumbered > >> therefore > >>> no subnet has been assigned to that link (even though an associated > >> address is set). > >>> For my specific PtP case the neighbor address is known as the tunnel > >> endpoint > >>> is manually configured (though not in any local network) therefore I > >> can use > >>> this for the Stub entry. > >>> Is that reading correct? > >> > >> There was a discussion about this some months ago(started by me) > >> on this > >> subject. > >> The short answer is that for unnumbered links you don't send Option 1 > >> nor Option 2. The > >> spec is a bit unclear but that is what the list concluded. > >> > >>> What if we are talking about a virtual link? > >>> Although a virtual link acts like an > >>> unnumbered point-to-point link, it does have an > >>> associated IP > >>> interface address. This address is used as the IP source in > >>> OSPF protocol packets it sends along the virtual link, > >>> and is > >>> set dynamically during the routing table build process. > >>> Is has no known neighbor router IP as it knows only the neighbor > >> routers > >>> router-ID (not IP) and it has no subnet assigned to the virtual link > >> (though > >>> an associated IP). How should the stub advertisement look like - > >>> which > >> of the > >>> options apply? > >>> Regards > >>> Juergen Arlt > >>> ------------------------------------------------- > >>> Juergen Arlt > >>> Nortel GmbH > >>> Senior Network Solutions Engineer > >>> Global Network Technical Support > >>> Mittlerer Pfad 26 > >>> 70499 Stuttgart > >>> Germany > >>> Tel: +49 (711) 1394361 > >>> ESN: 595 4361 > >>> Fax: +49 (711) 1394330 > >>> ------------------------------------------------- > >>> _______________________________________________ > >>> OSPF mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/ospf > >> > >> > >> > > > > _______________________________________________ > > OSPF mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ospf > > > _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
