For posterity, below email explains reasoning behind a pending
commit.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
"Boy, life takes a long time to live."
-- Steven Wright
---------- Forwarded message ----------
Date: Sat, 30 Aug 2003 12:07:14 +0200
From: Thomas Giger TGC <thomas.giger@tgc.de>
To: "'paul@jackma.org'" <paul@jackma.org>
Cc: "'mrenzmann@otaku42.de'" <mrenzmann@otaku42.de>
Subject: Offlist Quagga/OSPF patch suggestion (sorry)
Dear Paul,
[redacted]
Up to last week, we've been running zebra 0.91a OSPF. This version had its
problems and most (or all we know) are gone in quagga 0.96.2 OSPF. Very
good! However, area virtual links which have been working in 0.91 break in
0.96.2 (probably in zebra 0.93a too, AFAICT from the code).
After investigating the code, the reason seems to be the following:
(1) When a HELLO packet is sent along a VL, the destination address is
picked at random - and this is probably OK anyway. ospf_vl_set_params() (in
ospf_interface.c) states:
break; /* We take the first interface. */
while looking up the VL peer's address.
(2) However, when the HELLO packet is received at the VL peer, it is passed
into ospf_associate_packet_vl() (in ospf_packet.c) which has code like this
if ((rcv_oi = oi) == NULL)
{
if ((rcv_oi = ospf_if_lookup_by_local_addr (ospf, ifp,
iph->ip_dst)) == NULL)
return NULL;
}
Now, because oi == NULL (it could only be non-NULL if the source is on a
connected network, which is usually not the case for VLs), the packet is
inspected by ospf_if_lookup_by_local_addr() which, if the 'ifp' parameter is
set, will verify the packet destination address matches the address of the
receiving interface ifp.
This is "overkill": VL packets - depending on the network topology - do not
come in on the interface they are being sent to (if the target address is
picked at random in (1)).
The simple fix would be to replace
ospf_if_lookup_by_local_addr (ospf, ifp, iph->ip_dst)
with
ospf_if_lookup_by_local_addr (ospf, NULL, iph->ip_dst)
to accept VL Hellos on any interface as long as the destination address
matches at least one of the known OSPF interfaces.
If replaced by NULL, ifp will become obsolete in ospf_associate_packet_vl()
and can be removed from the parameter list. As this changes a function's
signature and because I don't know whether my proposal violates the OSPF
RFC, I would like to ask you to evaluate my suggestion.
Kind regards,
--
true global communications GmbH
Thomas Giger
[redacted]
commit.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
"Boy, life takes a long time to live."
-- Steven Wright
---------- Forwarded message ----------
Date: Sat, 30 Aug 2003 12:07:14 +0200
From: Thomas Giger TGC <thomas.giger@tgc.de>
To: "'paul@jackma.org'" <paul@jackma.org>
Cc: "'mrenzmann@otaku42.de'" <mrenzmann@otaku42.de>
Subject: Offlist Quagga/OSPF patch suggestion (sorry)
Dear Paul,
[redacted]
Up to last week, we've been running zebra 0.91a OSPF. This version had its
problems and most (or all we know) are gone in quagga 0.96.2 OSPF. Very
good! However, area virtual links which have been working in 0.91 break in
0.96.2 (probably in zebra 0.93a too, AFAICT from the code).
After investigating the code, the reason seems to be the following:
(1) When a HELLO packet is sent along a VL, the destination address is
picked at random - and this is probably OK anyway. ospf_vl_set_params() (in
ospf_interface.c) states:
break; /* We take the first interface. */
while looking up the VL peer's address.
(2) However, when the HELLO packet is received at the VL peer, it is passed
into ospf_associate_packet_vl() (in ospf_packet.c) which has code like this
if ((rcv_oi = oi) == NULL)
{
if ((rcv_oi = ospf_if_lookup_by_local_addr (ospf, ifp,
iph->ip_dst)) == NULL)
return NULL;
}
Now, because oi == NULL (it could only be non-NULL if the source is on a
connected network, which is usually not the case for VLs), the packet is
inspected by ospf_if_lookup_by_local_addr() which, if the 'ifp' parameter is
set, will verify the packet destination address matches the address of the
receiving interface ifp.
This is "overkill": VL packets - depending on the network topology - do not
come in on the interface they are being sent to (if the target address is
picked at random in (1)).
The simple fix would be to replace
ospf_if_lookup_by_local_addr (ospf, ifp, iph->ip_dst)
with
ospf_if_lookup_by_local_addr (ospf, NULL, iph->ip_dst)
to accept VL Hellos on any interface as long as the destination address
matches at least one of the known OSPF interfaces.
If replaced by NULL, ifp will become obsolete in ospf_associate_packet_vl()
and can be removed from the parameter list. As this changes a function's
signature and because I don't know whether my proposal violates the OSPF
RFC, I would like to ask you to evaluate my suggestion.
Kind regards,
--
true global communications GmbH
Thomas Giger
[redacted]