[quagga-dev 4511] should ospf be able to run on multiple connected addresses on a single interface?

In http://bugzilla.quagga.net/show_bug.cgi?id=316 we have a problem
where the ospfd was ignoring a connected address if a router-id
was not set statically in the config file.  When there's a router-id
in the config file, then each connected address gets processed
as it arrives from zebra.  And if there are multiple connected addresses
on an interface that match the 'network' statement, an ospf_interface
is created for each.

But if there's no static router-id, then nothing happens until
ospfd receives a router-id from zebra (which seems to happen after
all the interfaces and addresses are added).  At that point,
it calls ospfd.c:ospf_network_run(), and it seems that ospf_network_run
will not create more than a single ospf_interface for each interface
(because there's a 'break' statement that bails out of the loop).
It turns out that deleting the 'break' statement (as in the attached
patch) gets the behavior to match the case where the router-id
was statically configured.

So this leads to the question: does the 'break' statement belong there?
I guess this boils down to: does it ever make sense to run OSPF
more than once on the same interface?

Basically, I think we need either to delete the 'break' statement
from ospf_network_run, or patch somewhere else to prevent the
2nd ospf_interface from being created on the interface in the
case where the router-id was statically configured.  But one way
or another, I think there's a bug: the behavior should be consistent
regardless of whether the router-id was statically set in the config
file.

[quagga-dev 4512] Re: should ospf be able to run on multiple connected addresses on a single interface?

On Fri, 1 Dec 2006, Andrew J. Schorr wrote:

> So this leads to the question: does the 'break' statement belong 
> there?

I think not, no.

> I guess this boils down to: does it ever make sense to run OSPF 
> more than once on the same interface?

Yes, once per distinct logical subnet.

('included' logical subnets probably aren't quite sane, though, they 
might work..).

> Basically, I think we need either to delete the 'break' statement
> from ospf_network_run

Looks like it.

> or another, I think there's a bug: the behavior should be 
> consistent regardless of whether the router-id was statically set 
> in the config file.

ACK.

> Thoughts on which behavior is correct?  Is it legit/useful to have 
> more than one ospf_interface on a single network interface?

Definitely.

[quagga-dev 4513] Re: should ospf be able to run on multiple connected addresses on a single interface?

"Andrew J. Schorr" <aschorr <at> telemetry-investments.com> writes:

> But if there's no static router-id, then nothing happens until
> ospfd receives a router-id from zebra (which seems to happen after
> all the interfaces and addresses are added).  At that point,
> it calls ospfd.c:ospf_network_run(), and it seems that ospf_network_run
> will not create more than a single ospf_interface for each interface
> (because there's a 'break' statement that bails out of the loop).
> It turns out that deleting the 'break' statement (as in the attached
> patch) gets the behavior to match the case where the router-id
> was statically configured.

It's clearly broken for the behavior to be different in these cases.

> Thoughts on which behavior is correct?  Is it legit/useful to have more
> than one ospf_interface on a single network interface?

It's a fair question, and poring over the OSPF spec is probably in
order.  But it seems no less reasonable as running multiple prefixes
on an Ethernet.

--

-- 
    Greg Troxel <gdt <at> ir.bbn.com>

[quagga-dev 4514] Re: should ospf be able to run on multiple connected addresses on a single interface?

On Wed, Dec 06, 2006 at 08:21:00AM -0500, Greg Troxel wrote:
> "Andrew J. Schorr" <aschorr <at> telemetry-investments.com> writes:
> 
> > But if there's no static router-id, then nothing happens until
> > ospfd receives a router-id from zebra (which seems to happen after
> > all the interfaces and addresses are added).  At that point,
> > it calls ospfd.c:ospf_network_run(), and it seems that ospf_network_run
> > will not create more than a single ospf_interface for each interface
> > (because there's a 'break' statement that bails out of the loop).
> > It turns out that deleting the 'break' statement (as in the attached
> > patch) gets the behavior to match the case where the router-id
> > was statically configured.
> 
> It's clearly broken for the behavior to be different in these cases.

Agreed.

> > Thoughts on which behavior is correct?  Is it legit/useful to have more
> > than one ospf_interface on a single network interface?
> 
> It's a fair question, and poring over the OSPF spec is probably in
> order.  But it seems no less reasonable as running multiple prefixes
> on an Ethernet.

I think we agree that if people are going to run multiple prefixes on
the same interface, ospfd should be able to support that.  So I committed
the patch to remove the errant 'break' statement, and everything should
now be consistent.

Regards,

[quagga-dev 4515] Bug in BGP Confederation implementation

Hello,

we have been expieriencing severe oscillation in a Quagga/BGP 
confederation network which I believe is caused by a bug in BGP 
confederation protocol implementation. Prefixes that originate from 
within the confederation sub-ASes (e.g. static bgp entries with network 
command) should not be passed to zebra as FIB routes. Passing them as 
such, breaks reliable bgp scanning since BGP-originated nexthops have 
higher priority than IGP-originated nexthops in nexthop scanning and get 
selected although they may be unreachable.

Regards,
Vassilis

[quagga-dev 4516] Re: missing rib_queue_add in static_install_ipv4()

Applied.

Thanks Piotr,
--

-- 
Paul Jakma	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
The biggest problem with communication is the illusion that it has occurred.

[quagga-dev 4517] Re: isisd patch

Applied.

Though, please try to supply an appropriate change to <dir>/ChangeLog 
when submitting patches, and try seperate patches into smaller, 
specific patches.

Thanks!

regards,
--

-- 
Paul Jakma	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
I thought YOU silenced the guard!

[quagga-dev 4518] RFC2385 going into Linux kernel

Rick Payne's RFC2385 patches are heading into the Linux kernel after all:

  http://www.mail-archive.com/netdev <at> vger.kernel.org/msg26365.html

Does this mean md5qd is unneeded, or should it be kept around for kernels 
prior to 2.6.20?

Chris

[quagga-dev 4519] Re: RFC2385 going into Linux kernel

--On 8 December 2006 02:57:12 +0000 Chris Caputo <ccaputo <at> alt.net> 
wrote:

> Rick Payne's RFC2385 patches are heading into the Linux kernel after
> all:
>
>   http://www.mail-archive.com/netdev <at> vger.kernel.org/msg26365.html

That's good news for those that have to interoperate in the real world. 
Glad someone has seen sense at last.

The patch has been tidied up quite a bit by the looks of things, 
something that I've not had time to do in recent years.

Rick

[quagga-dev 4520] multipath treatment for netlink_route_change(), netlink_routing_table()

Hi

My patch adds multipath treatment to netlink_route_change(), and
netlink_routing_table(). Multipath routes inserted by for example from 
os level by ip r a , would be seen by quagga with all route params
correct. In old behavior when multipath kernel route was inserted  , quagga
have seen only correct destination , interface and gateway was broken or 
incorrect.

There is some changes in code that makes this patch litle dirty (paul
please review it ), 

     zebra/zebra_rib.c - exported function nexthop_ipv4_ifindex_add()

     zebra/rt_netlink.c - added include "memory.h", - I need access to 
                          XCALLOC, to allocate struct rib.

It partially solves #264 .

/pch

--

-- 
Dyslexia bug unpatched since 1977 ...
exploit has been leaked to the underground.

diff --git a/zebra/ChangeLog b/zebra/ChangeLog
index 3ea4f57..5b4e0a9 100644
--- a/zebra/ChangeLog
+++ b/zebra/ChangeLog