ECMP/multipath support

[Joakim Tjernlund]

>
> Ondrej Zajicek <santiago at crfreenet.org> wrote on 2010/12/21 11:42:56:
> >
> > On Tue, Dec 21, 2010 at 09:24:23AM +0100, Joakim Tjernlund wrote:
> > > Ondrej Zajicek <santiago at crfreenet.org> wrote on 2010/12/21 03:24:23:
> > > >
> > > > On Tue, Dec 21, 2010 at 01:22:48AM +0100, Joakim Tjernlund wrote:
> > > > > > For PTP iface, the list contains at most one entry (so the scan is fast
> > > > > > :-) ) and you have to examine it anyways to know neighbor's IP address.
> > > > >
> > > > > Yes, it is a small improvement I guess and you would find the remote
> > > > > IP address, if there is one, by following the ifa ptr.
> > > >
> > > > You cannot get remote IP address just from ifa - you can have ethernet
> > > > network with (e.g.) /24 IP prefix configured as ptp iface (which is OK
> > > > if there is just two routers on that network).
> > >
> > > Oh, so "opposite" in
> > > struct ifa {
> > >   ..
> > >   ip_addr opposite;         /* Opposite end of a point-to-point link */
> > >
> > > does not contain an IP address in this case?
> >
> > Thesa are three different, partially-dependent things:
> >
> > 1) iface that is physically ptp link (like ppp link or some tunnels)
> >
> > 2) iface with some kind of ptp address (real ptp/peer address,
> > or /30, /31 network prefix)
> >
> > 3) iface, which is configured as ptp in OSPF.
> >
> > opposite field is defined for 2), where opposite address can be determined
> > from IP configuration of a device. This field is not changed by protocols.
> > OSPF mostly cares for 3). OSPF guess a default type of the iface from 1)
> > and 2) but it can be, to some degree, overridden.
> >
> > For example, an ethernet iface with a peer address cannot be configured
> > as bcast (it does not have a network prefix), an iface with /30 IP
> > prefix is by default ptp, but can be set to bcast, an iface with (e.g.)
> > /24 IP prefix is by default bcast, but can be set to ptp.
>
> Need to dwell some on this.
>
> >
> >
> > BTW, currently even if an opposite address is known, BIRD OSPF ptp links use
> > multicast for HELLO protocol which would not work on physically ptp links
> > that does not implement multicast. But AFAIK in such cases multicast
> > (and broadcast) is implemented on OS level (just it sends everything
> > to the other side).
>
> Would that be AllSPFRouters? That is what you should use on ptp links(but not
> on ptmp links).

Now I remember, ptp links should always use AllSPFRouters, this a from Quagga
I did some time ago:

Set destination for PtP links to OSPF_ALLSPFROUTERS.
See RFC 2328, chap 8.1 for details:

        "The IP destination address for the packet is selected as
         follows.  On physical point-to-point networks, the IP
         destination is always set to the address AllSPFRouters."

    Without this, it won't be possible to establish adjacencies on
    multiple unnumbered links to the same router.

Not sure were I got that last statement from, perhaps it is Quagga specific.

  Jocke