[Xorp-users] Questions on OSPF

[kristian at spritelink.net]

On Thu, 13 Sep 2007 14:58:01 -0700, Atanu Ghosh <atanu at icsi.berkeley.edu>
wrote:
>>>>>> "kristian" == kristian  <kristian at spritelink.net> writes:
> 
>     kristian> On Thu, 13 Sep 2007 12:18:42 -0700, Atanu Ghosh
>     kristian> <atanu at icsi.berkeley.edu> wrote:
>     >>>>>>> "kristian" == kristian <kristian at spritelink.net> writes:
>     >>
>     kristian> On Thu, 13 Sep 2007 11:51:32 -0700, Atanu Ghosh
>     kristian> <atanu at icsi.berkeley.edu> wrote:
>     >> >>>>>>> "Kristian" == Kristian Larsson <kristian at spritelink.net>
>     >> >>>>>>> writes:
>     >> >>
>     Kristian> Hansi wrote:
>     >> >> >> Hello All,
>     >> >> >>
>     >> >> >> I'm currently learning how to configure OSPFv2 on two XORP
>     >> >> >> machines just to establish adjacency with one another. In a
>     >> p2p >> >> link type, is it still necessary to explicitly set the
>     >> >> 'neighbor' >> parameter of each machine before adjacency is >>
>     >> established?  >> Furthermore, would it be possible to set the >>
>     >> router-id to its >> loopback address? instead of say.. the ip >>
>     >> address of the >> interface on which ospf will be used?
>     >> >>
>     Kristian> The neighbor command is only useful if you are using a
>     Kristian> medium on which the routers cannot broadcast and thus
>     Kristian> cannot discover each other.  If you're using ethernet
>     Kristian> (which I presume from your NIC names) you do not have to
>     Kristian> use the neighbor statements. I would advice configuring
>     Kristian> the interfaces as link-type p2p as this avoids DR election
>     Kristian> and unnecessary CPU load.
>     >>  >> I am fairly sure that it is necessary to use the neighbour >>
>     >> statements.
>     >>
>     kristian> Are you serious?  I haven't used the XORP code in quite
>     kristian> some time now.. but at least I thought XORP implemented
>     kristian> the OSPF standard. AFAIK, that includes being able to
>     kristian> discover neighbors and turn up adjacencies to them. Is
>     kristian> this not the case?  Observe that he is running an Ethernet
>     kristian> point-to-point link, ie, it is not a non-broadcast medium.
>     kristian> Or are you saying that you can't do link-type p2p without
>     kristian> configuring neighbours ?
> 
>     >>  If the link-type is set to "broadcast" then the neighbours will
>     >> be correctly discovered. If the link-type is set to "p2p"
>     >> (Point-to-point) or "p2m" (Point-to-multipoint) then it is
>     >> necessary to configure the neighbours. It has been argued that it
>     >> should not be necessary to configure the neighbours if the
>     >> routers are connected via a true Point-to-point link, but
>     >> unfortunately even in this case it is necessary to configure the
>     >> neighbour.
> 
>     kristian> Okey, that "kinda" makes sense. I apparently forgot or
>     kristian> missed the conversation on this.  What I want to configure
>     kristian> with link-type p2p is not whether or not the router should
>     kristian> try to broadcast but if it should setup one of those
>     kristian> virtual router thingys, hehe. I'm not very familiar with
>     kristian> the terminology but (as you know) on a broadcast medium
>     kristian> you first have a DR selection and all that and then you're
>     kristian> gonna run your SPF. Since SPF can't handle the concept of
>     kristian> a broadcast medium it creates a "virtual router" to
>     kristian> represent the broadcast medium and connects all routers in
>     kristian> that broadcast domain as adjacencies to the virtual
>     kristian> router.  When I configure 'isis network point-to-point' on
>     kristian> a Cisco router I expect it to not setup one of these
>     kristian> "virtual routers" in it's SPF topology. And this is
>     kristian> different with XORP?
> 
> Setting the link type to "broadcast" or "p2p" will both result in the
> hello packets being broadcast, the distinction is that if the link-type
> is set to "p2p" no DR election will be attempted.

Alright, just as I expected.

> The XORP OSPF behaves
> as specified in the relevant RFCs and interoperates with other OSPF
> implementations, the only difference is in configuration of a "p2p"
> where we require the neighbour to be specified, which as I mentioned
> before should not strictly be necessary.

Okey, not what I expected. Why is it so? Just lack of time to do the actual
implementation (although I don't see how it would actually be more code
than it is today) or has there been a policy decision against it?

  -K