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

   Jocke