Mailing List Archive

OSPF point-to-point, Link Data field of Router LSAs
In RFC 2328, section A.4.2, Router-LSAs, it states that for unnumbered
point-to-point connections, the Link Data field should be the interface's
MIB-II [RFC 1213] ifIndex value.

In ospf_lsa.c, function lsa_link_ptop_set, the code reads:

if ((nbr = ospf_nbr_lookup_ptop (oi)))
if (nbr->state == NSM_Full)
{
/* For unnumbered point-to-point networks, the Link Data field
should specify the interface's MIB-II ifIndex value. */
link_info_set (s, nbr->router_id, oi->address->u.prefix4,
LSA_LINK_TYPE_POINTOPOINT, 0, oi->output_cost);
links++;
}

The parameter oi->address->u.prefix4 (passed to link_info_set) seems to be
at variance with the comment immediately preceding, and also with the RFC.

Is there any reason why the code does not read:
link_info_set (s, nbr->router_id, (struct in_addr) oi->ifp->ifindex,
LSA_LINK_TYPE_POINTOPOINT, 0, oi->output_cost);

?

<M>
Re: OSPF point-to-point, Link Data field of Router LSAs [ In reply to ]
I wrote:
>In RFC 2328, section A.4.2, Router-LSAs, it states that for
>unnumbered point-to-point connections, the Link Data field
>should be the interface's MIB-II [RFC 1213] ifIndex value.

We have applied the following patch (as made against the
current CVS revision (1.23) of ospf_lsa.c) in our lab, and
it is giving the results we would expect.

If you feel this is appropriate to merge into the quagga
source tree, then please feel free to do so.

Kind regards,

<M>

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


--- quagga/ospfd/ospf_lsa.c Mon Oct 13 09:06:46 2003
+++ quagga_patched/ospfd/ospf_lsa.c Wed Oct 15 14:07:10 2003
@@ -514,11 +514,16 @@
{
/* For unnumbered point-to-point networks, the Link Data field
should specify the interface's MIB-II ifIndex value. */
- link_info_set (s, nbr->router_id, oi->address->u.prefix4,
- LSA_LINK_TYPE_POINTOPOINT, 0, oi->output_cost);
+ /* link_info_set expects third parameter to be of type
+ struct in_addr, so create a temporary in_addr struct
+ to hold the ifIndex value */
+ struct in_addr tmp_addr;
+ /* Copy ifIndex into tmp_addr (changing byte order if necessary) */
+ tmp_addr.s_addr = htonl(oi->ifp->ifindex);
+ link_info_set (s, nbr->router_id, tmp_addr,
+ LSA_LINK_TYPE_POINTOPOINT, 0, oi->output_cost);
links++;
}
-
if (oi->connected->destination != NULL)
{
/* Option 1:
@@ -642,14 +647,21 @@
if (nbr->state == NSM_Full)

{
- link_info_set (s, nbr->router_id, oi->address->u.prefix4,
- LSA_LINK_TYPE_POINTOPOINT, 0, oi->output_cost);
+ /* For unnumbered point-to-point networks, the Link Data field
+ should specify the interface's MIB-II ifIndex value. */
+ /* link_info_set expects third parameter to be of type
+ struct in_addr, so create a temporary in_addr struct
+ to hold the ifIndex value */
+ struct in_addr tmp_addr;
+ /* Copy ifIndex into tmp_addr (changing byte order if
necessary) */
+ tmp_addr.s_addr = htonl(oi->ifp->ifindex);
+ link_info_set (s, nbr->router_id, tmp_addr,
+ LSA_LINK_TYPE_POINTOPOINT, 0, oi->output_cost);
links++;
if (IS_DEBUG_OSPF (lsa, LSA_GENERATE))
- zlog_info ("PointToMultipoint: set link to %s",
- inet_ntoa(oi->address->u.prefix4));
+ zlog_info ("PointToMultipoint: set link data to %u",
+ oi->ifp->tmp_addr.s_addr);
}
-
return links;
}


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
--
Re: OSPF point-to-point, Link Data field of Router LSAs [ In reply to ]
Oops...

>We have applied the following patch (as made against the
>current CVS revision (1.23) of ospf_lsa.c) in our lab, and
>it is giving the results we would expect.

Except it isn't.

It was working fine for a single router in the middle of the
network. When we rolled it out across the net, updates were
being sent, but routes weren't being installed :-(

Clearly things are a more involved than we first thought...

Moral of story: test the patch properly before sending it!

<M>
Re: OSPF point-to-point, Link Data field of Router LSAs [ In reply to ]
I've been looking into why changing the Link Data field
of the Router LSA of a point-to-point link to the ifIndex
value breaks Quagga's OSPF routing.

There are a number of places in the code where the field
is used. In particular, it looks like the following
occurrences could be causing problems:

[From today's CVS]
ospf_spf.c lines 397-443, in function ospf_nexthop_calculation:

if (l->m[0].type == LSA_LINK_TYPE_POINTOPOINT)
{
/* Check for PtMP, signified by PtP link V->W
with link_data our PtMP interface. */
oi = ospf_if_is_configured (area->ospf, &l->link_data);
if (oi && oi->type == OSPF_IFTYPE_POINTOMULTIPOINT)
{
struct prefix_ipv4 la;
la.prefixlen = oi->address->prefixlen;
/* We link to them on PtMP interface
- find the interface on w */
while ((l2 = ospf_get_next_link (w, v, l2)))
{
la.prefix = l2->link_data;

if (prefix_cmp ((struct prefix *) &la,
oi->address) == 0)
/* link_data is on our PtMP network */
break;
}
}
else
{
{
oi = ospf_if_is_configured (area->ospf,
&(l2->link_data));

This almost certainly is causing a problem -- (a) the ptp
interface might not have an address at all, (b) even if it
does, the link_data field in its Router LSA should not
contain that IP address, it should contain an ifIndex...


if (oi == NULL)
continue;

if (!IPV4_ADDR_SAME (&oi->address->u.prefix4,
&l->link_data))

Even supposing we get this far (which is not likely, given the
problem on line 422...), this line looks like it could also
cause us problems -- the link_data field should not match the
ospf interface *address* it should be its *ifIndex*

continue;

break;
}
}

if (oi && l2)
{
nh = vertex_nexthop_new (v);
nh->oi = oi;
nh->router = l2->link_data;

And, once the previous tests for interface validity have been
corrected, this line is also wrong. The link_data field should
not contain the next hop, so we shouldn't be looking for it
there at all...

ospf_spf_consider_nexthop (w->nexthop, nh);
}
}

Any comments/suggestions/preferences on how to fix this?

<M>
--