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." 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
