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? > 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") :) --