[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OSPF] Question about Stub advertisement of a PtP link RFC 2328

Hi Juergen,
I agree that in this situation you should not advertise the subnet of the outgoing link for the IPsec tunnel. If you advertise the tunnel endpoint as per option 1, you are not modeling the link as an unnumbered link. The OSPF specification does not specify how to model the tunnel - this is up to your implementation. 
Acee
On Jul 28, 2009, at 9:09 AM, Juergen Arlt wrote:


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:acee at redback.com]
Sent: Dienstag, 28. Juli 2009 14:50
To: Joakim Tjernlund
Cc: Arlt, Juergen (GERST:476S); ospf at ietf.org
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" <jarlt at nortel.com> 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:joakim.tjernlund at transmode.se]
Sent: Dienstag, 28. Juli 2009 12:15
To: Arlt, Juergen (GERST:476S)
Cc: ospf at ietf.org
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
OSPF at ietf.org
https://www.ietf.org/mailman/listinfo/ospf






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