Ondrej Zajicek <santiago@crfreenet.org> wrote on 2010/04/23 14:09:50:
On Fri, Apr 23, 2010 at 12:38:59PM +0200, Joakim Tjernlund wrote:
But this won't fix multiple ptp I/Fs between the same two routes and I don't think it will work if one end is unnumbered and the other one is not.
Our algorithm (in the git tree) works well for multiple ptp ifaces between the same two routers (because both the SPF and the calc_next_hop() chooses the same (cheapest) ptp link.
Even if all local PtoP I/Fs have the same IP address or no IP address?
Yes, for the version in the git tree.
Or more precisely, it works for links having the same ptp address. (a link with ptp/peer addresses is considered unnumbered).
If there is really no IP address on the link, it will not work, but for several completely different reasons - BIRD core would not accept such route.
What does this comment in calc_next_hop mean? /* * Remaining cases - local neighbours. * There are two problems with this code: * 1) we use IP address from HELLO packet * and not the one from LSA (router or link). * This may break NBMA networks * 2) we use find_neigh_noifa() and does not * take into account associated iface. * This breaks neighbors connected by more links. */
This is an old code, which has some bugs i fixed a two weeks ago:
Oh, I figured I cloned fairly recently. Must have jut missed you change. Anyhow I looked at the new code and it is an improvement but I think there is a flaw: It looks like the ptp code just find ANY interface that has a connection to the remote router, not the I/F that has created that particular RLSA entry. That may lead to asymmetric links, TX one link and RX on another. Not sure what other implications there might be but I believe OSPF was not designed to deal with such scenarios. Jocke