[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 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