[quagga-dev 15133] Re: [PATCH] ospfd: fix - correct neighbor index on changing/p2p/virtual links

2016-04-21 Thread Joakim Tjernlund
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 >  

[quagga-dev 15132] CI Testresult: PASSED (Re: [quagga-dev, 15130] zserv: [pimd] fix - avoid dereferencing a NULL pointer)

2016-04-21 Thread cisystem
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 :

[quagga-dev 15131] CI Testresult: PASSED (Re: [quagga-dev, 15127] ospfd: fix - correct neighbor index on changing/p2p/virtual links)

2016-04-21 Thread cisystem
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 :

[quagga-dev 15130] [PATCH] zserv: [pimd] fix - avoid dereferencing a NULL pointer

2016-04-21 Thread Jafar Al-Gharaibeh
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

[quagga-dev 15129] CI Testresult: PASSED (Re: [quagga-dev, 15122] pimd: Fix hang when doing nexthop lookup from zebra)

2016-04-21 Thread cisystem
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 :

[quagga-dev 15128] Re: [PATCH] ospfd: fix - correct neighbor index on changing/p2p/virtual links

2016-04-21 Thread Jafar Al-Gharaibeh
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

[quagga-dev 15127] [PATCH] ospfd: fix - correct neighbor index on changing/p2p/virtual links

2016-04-21 Thread Jafar Al-Gharaibeh
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"

[quagga-dev 15123] Re: [PATCH] pimd: Fix hang when doing nexthop lookup from zebra

2016-04-21 Thread Jafar Al-Gharaibeh
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:

[quagga-dev 15122] [PATCH] pimd: Fix hang when doing nexthop lookup from zebra

2016-04-21 Thread jonomhart
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.

[quagga-dev 15121] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support

2016-04-21 Thread Paul Jakma
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

[quagga-dev 15120] Re: ospfd crashes after updating to 1.0.20160315

2016-04-21 Thread Jafar Al-Gharaibeh
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

[quagga-dev 15118] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support

2016-04-21 Thread Lou Berger
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:

[quagga-dev 15117] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support

2016-04-21 Thread Paul Jakma
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 --

[quagga-dev 15116] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support

2016-04-21 Thread Paul Jakma
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

[quagga-dev 15115] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support

2016-04-21 Thread David Lamparter
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

[quagga-dev 15114] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support

2016-04-21 Thread Lou Berger
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

[quagga-dev 15112] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support

2016-04-21 Thread Paul Jakma
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

[quagga-dev 15111] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support

2016-04-21 Thread Paul Jakma
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

[quagga-dev 15110] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support

2016-04-21 Thread Paul Jakma
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

[quagga-dev 15108] Re: [PATCH] ospfd: stub-router "allow transit" option and add "Host" option support

2016-04-21 Thread Paul Jakma
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