Re: OpenOSPFD (6.4) "depend on" feature forces "type 1"

2019-01-15 Thread Remi Locherer
Hi Igor On Thu, Jan 10, 2019 at 11:31:00PM +0100, Sebastian Benoit wrote: > Remi Locherer(remi.loche...@relo.ch) on 2019.01.10 21:18:58 +0100: > > On Fri, Jan 11, 2019 at 12:06:09AM +0700, Igor Podlesny wrote: > > > On Thu, 10 Jan 2019 at 21:11, Remi Locherer wrote: > > > [...] > > > > I can repr

Re: OpenOSPFD (6.4) "depend on" feature forces "type 1"

2019-01-10 Thread Sebastian Benoit
Remi Locherer(remi.loche...@relo.ch) on 2019.01.10 21:18:58 +0100: > On Fri, Jan 11, 2019 at 12:06:09AM +0700, Igor Podlesny wrote: > > On Thu, 10 Jan 2019 at 21:11, Remi Locherer wrote: > > [...] > > > I can reproduce it. Interestingly it only sends out the wrong type when > > > the "depend on" i

Re: OpenOSPFD (6.4) "depend on" feature forces "type 1"

2019-01-10 Thread Remi Locherer
On Fri, Jan 11, 2019 at 12:06:09AM +0700, Igor Podlesny wrote: > On Thu, 10 Jan 2019 at 21:11, Remi Locherer wrote: > [...] > > I can reproduce it. Interestingly it only sends out the wrong type when > > the "depend on" interfac (carp1 in your example) is down or in backup > > state and the config

Re: OpenOSPFD (6.4) "depend on" feature forces "type 1"

2019-01-10 Thread Igor Podlesny
On Thu, 10 Jan 2019 at 21:11, Remi Locherer wrote: [...] > I can reproduce it. Interestingly it only sends out the wrong type when > the "depend on" interfac (carp1 in your example) is down or in backup > state and the configured type is 2. That's an irony for real! -- Type 1 is "heavier" than Ty

Re: OpenOSPFD (6.4) "depend on" feature forces "type 1"

2019-01-10 Thread Remi Locherer
On Thu, Jan 10, 2019 at 03:06:59PM +0700, Igor Podlesny wrote: > On Thu, 10 Jan 2019 at 01:21, Remi Locherer wrote: > [...] > > > > It is not intended. I'll look into it. I can reproduce it. Interestingly it only sends out the wrong type when the "depend on" interfac (carp1 in your example) is do

Re: OpenOSPFD (6.4) "depend on" feature forces "type 1"

2019-01-10 Thread Igor Podlesny
On Thu, 10 Jan 2019 at 01:21, Remi Locherer wrote: [...] > > It is not intended. I'll look into it. I see, thank you. BTW, if-when it's fixed would such a fix be brought within standard syspatch update process or what would it be otherwise? Can you also explain why Type 1 has been chosen as defa

Re: OpenOSPFD (6.4) "depend on" feature forces "type 1"

2019-01-09 Thread Remi Locherer
On Wed, Jan 09, 2019 at 10:47:21PM +0700, Igor Podlesny wrote: > Hi! > > My tests show that OpenOSPFD "depend on" feature forces "type 1" > overriding explicitly specified "type 2". For example this statement > can be used: > > redistribute 0.0.0.0/0 set { type 2 } depend on carp1 > > (or keywor

OpenOSPFD (6.4) "depend on" feature forces "type 1"

2019-01-09 Thread Igor Podlesny
Hi! My tests show that OpenOSPFD "depend on" feature forces "type 1" overriding explicitly specified "type 2". For example this statement can be used: redistribute 0.0.0.0/0 set { type 2 } depend on carp1 (or keyword "default" can be used instead of prefix.) Is it an intended behaviour or it's