On Fri, Jan 11, 2019 at 12:06:09AM +0700, Igor Podlesny wrote: > On Thu, 10 Jan 2019 at 21:11, Remi Locherer <remi.loche...@relo.ch> 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 Type 2; so it means then > when it shouldn't be announcing "heavy" default due it's BACKUP it > actually is announcing > it as "heavy" (preferred) one. > > > I don't have much time right now so please don't expect a fast fix. > > Understood. > > > > 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? > > > > I don't think this is worth a syspatch. It is not a vulnerability or > > stability issue. > > The second part of my question was exactly about how this fix would be > supplied then if > not with syspatch? OpenOSPFD seems to be part of the OS, and I thought that > syspatch is the appropriate mechanism for that hence. What else if not > syspatch? >
A fix will go to -current which will then become the next release. > > And I also don't see how it affects existing setups. > > Well, setting Type 2 is a sign of interaction with different routing > software since most of it > use Type 2 by default. Then: > > * if config isn't mixed it runs on Type 1 and fix won't affect it in a way; > * if it's mixed and doesn't use "depend on" it won't be broken as well. > > But only if it's mixed and uses "depend on" it would be affected (read > "fixed") :) Yes. But this feature is relatively new so I don't expect thousands of networks using it. ;-)
