ECMP/multipath support

[Ondrej Zajicek]

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.


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

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20101221/69ab33da/attachment-0001.asc>