On Thu, 2016-04-21 at 16:22 -0500, Jafar Al-Gharaibeh wrote:
> ospfd keeps a list of neighbor routers for each configured interface. This
> list is indexed using the neighbor router id in case of point-to-point and
> virtual link types, otherwise the list is indexed using the neighbor's
>
Continous Integration Result: SUCCESSFUL
Congratulations, this patch passed basic tests
Tested-by: NetDEF CI System
This is an EXPERIMENTAL automated CI system.
For questions and feedback, feel free to email
Martin Winter .
Patches applied :
Continous Integration Result: SUCCESSFUL
Congratulations, this patch passed basic tests
Tested-by: NetDEF CI System
This is an EXPERIMENTAL automated CI system.
For questions and feedback, feel free to email
Martin Winter .
Patches applied :
Signed-off-by: Jafar Al-Gharaibeh
---
zebra/zserv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/zebra/zserv.c b/zebra/zserv.c
index 7a75ed4..6fd5ee7 100644
--- a/zebra/zserv.c
+++ b/zebra/zserv.c
@@ -630,7 +630,8 @@ zsend_ipv4_nexthop_lookup_mrib
Continous Integration Result: SUCCESSFUL
Congratulations, this patch passed basic tests
Tested-by: NetDEF CI System
This is an EXPERIMENTAL automated CI system.
For questions and feedback, feel free to email
Martin Winter .
Patches applied :
This patch supersedes patches 1897 and 1898 and provides a better more
general solution to the problem.
--Jafar
On 4/21/2016 4:22 PM, Jafar Al-Gharaibeh wrote:
ospfd keeps a list of neighbor routers for each configured interface. This
list is indexed using the neighbor router id in case
ospfd keeps a list of neighbor routers for each configured interface. This
list is indexed using the neighbor router id in case of point-to-point and
virtual link types, otherwise the list is indexed using the neighbor's
source IP (RFC 2328, page 96). The router adds itself as a "pseudo"
Jon,
We actually ran into this a couple of days and fixed it on our end.
I was waiting for more testing before I submit the same patch.
So, I confirm that this is a big issue, it almost renders pimd useless
because it is going to hang on the first nexthop lookup.
Thank you,
Jafar
Acked-by:
From: Jonathan Hart
I was running in to a bug when pimd would hang in some cases when
it had to do a nexthop lookup from zebra, such as when a PIM JOIN
was received. This issue could be easily reproduced by running
'show ip rib ' from the pimd vty which forces a nexthop lookup.
On Thu, 21 Apr 2016, Lou Berger wrote:
On 4/21/2016 9:00 AM, Lou Berger wrote:
2) how do we get moving on the next release (and the clearing out
http://patchwork.quagga.net/project/quagga/list/)?
I don't know. Donald?
Was anyone to send minutes for the call to the list?
On 4/21/2016 10:19
Hi Sergey,
Do you have the log file for ospfd with various debugging options
enabled?
debug ospfd [packet|ism|nsm|zebra|lsa]
Thanks,
Jafar
On 4/21/2016 10:30 AM, Sergey Popov wrote:
Hi, guys.
After updating Quagga from 0.99.24.1 to 1.0.20160315 i am expirience
constant crashing of
Paul,
What are your thoughts on:
On 4/21/2016 9:00 AM, Lou Berger wrote:
> 2) how do we get moving on the next release (and the clearing out
> http://patchwork.quagga.net/project/quagga/list/)?
also, more below.
On 4/21/2016 10:19 AM, Paul Jakma wrote:
> On Thu, 21 Apr 2016, Lou Berger wrote:
On Thu, 21 Apr 2016, David Lamparter wrote:
My review of your patch argues that updating a Quagga-only setup can
transition through the same path that any mixed setup already is on. The
extra complexity of a special-case pure-Quagga network seems to provide
very little gain at a large cost --
On Thu, 21 Apr 2016, Lou Berger wrote:
If the routing loop issue is serious, then we should take it seriously.
I know we disagree on this -- I personally see loops with standard
routers as a bigger deal as the loop can introduced on a change on the
standard router,
while in the quagga only
On Thu, Apr 21, 2016 at 12:33:50PM +0100, Paul Jakma wrote:
> The previous patch clearly is incomplete, based on the concerns of those
> proposing it and further analysis. Your review of the next patch seems
> to be missing some of the issues, while restating the issue driving this
> that makes
Paul,
see in-line
On 4/21/2016 4:51 AM, Paul Jakma wrote:
> On Wed, 20 Apr 2016, Lou Berger wrote:
>
>> To up level a moment: to me the most important thing is to keep
>> fixes/improvements rolling into the quagga base and not let a single
>> patch block overall progress on improving the code
On Tue, 19 Apr 2016, David Lamparter wrote:
- for a pure Quagga domain, there already is an easy migration path by
configuring 0xfffe instead, as you've pointed out. The
administrative effort of this is no lower or higher (ensuring proper
configuration on all routers) than the new
On Wed, 20 Apr 2016, David Lamparter wrote:
The link-detect comparison keeps coming up, yet there's a major
difference: When I argued for the "slow" link-detect migration, I was
personally aware of 2 installations that would've been broken by the
change, one of them /my own network/.
And
On Wed, 20 Apr 2016, Lou Berger wrote:
To up level a moment: to me the most important thing is to keep
fixes/improvements rolling into the quagga base and not let a single
patch block overall progress on improving the code base. I liked the
idea of proposed branches floated awhile back on
On Thu, 21 Apr 2016, Martin Winter wrote:
This does not seem to be the case. In this case, QUAGGA seems to be different
and causes the issues.
No need to “migrate” a 9-year old bug.
Let’s just fix it.
The concern is routing loops. The "just fix it" approach need not fix that
risk in mixed
20 matches
Mail list logo