OSPF performance/SPF calculations

Joakim Tjernlund joakim.tjernlund at transmode.se
Sun Apr 25 18:08:04 CEST 2010


Slowly getting back to SPF again ..

Ondrej Zajicek <santiago at crfreenet.org> wrote on 2010/04/23 16:01:16:
>
> On Fri, Apr 23, 2010 at 03:27:10PM +0200, Joakim Tjernlund wrote:
>
> > 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.
>
> This is not a problem because both SPF and calc_next_hop() chooses the
> cheapest (full) ptp link. They both uses the same (local) metrics.

Our ptp links typically have the same cost between the same two routers so
it is not unlikely that the link will be asymentric I think. However I
don't think that will be a problem anymore as BIRD don't use/support
equal cost multipath, right?

>
> Even if you have asymetric metrics to have one link for one direction
> and the other link for the other direction, the algorithm works,
> because each side uses its metrics for both calculations.
>
> There is one thing when the algorithm might break - if the cheapest full
> ptp link is rejected by link_back() check. But such situation is just
> transitional and would resolve immediately by either breaking the link
> or receiving the new router-LSA from the neighbor.

Right, how about these statements from RFC 2328:
 16.1.1 para 4.  If there is at least one intervening router in the
  current shortest path between the destination and the root, the
  destination simply inherits the set of next hops from the
  parent.

 16.1.1 para 5.
   ...the parent vertex is a network that
 directly connects the calculating router to the destination
 router.  The list of next hops is then determined by
 examining the destination's router-LSA
 For each link in the router-LSA that points back to the
 parent network, the link's Link Data field provides the IP
 address of a next hop router.  The outgoing interface to
 use can then be derived from the next hop IP address (or
 it can be inherited from the parent network).

These talk about inheriting ALL next hops from the parent and I don't
see the BIRD does that. Looks like BIRD just selects one next hop
from its parent?
Assuming it is, does that impose any restricts?


Some other random questions:

One think I always wanted is the possibility to add an host IP address to
all areas, in my case I like to export the routers primary IP address
to all areas so the router can always be reached. Is that possible with
BIRD?

If you pull the cable to an ethernet I/F that is currently in a OSPF
domain, do BIRD delete the whole subnet from the R-LSA or do you
leave a host route with the I/F's IP address in the R-LSA?

 Jocke




More information about the Bird-users mailing list