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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Igor Podlesny-2
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 not?

Is this mail list appropriate for similar topics related to OpenOSPFD
at all or some other mail list should better be used instead?

System information:
* 6.4 GENERIC.MP#3 amd64
* syspatch up to 010_pcbopts installed

--
End of message. Next message?

Reply | Threaded
Open this post in threaded view
|

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

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 keyword "default" can be used instead of prefix.)
>
> Is it an intended behaviour or it's not?

It is not intended. I'll look into it.
 
> Is this mail list appropriate for similar topics related to OpenOSPFD
> at all or some other mail list should better be used instead?

Next time maybe bugs@.

>
> System information:
> * 6.4 GENERIC.MP#3 amd64
> * syspatch up to 010_pcbopts installed
>
> --
> End of message. Next message?
>

Reply | Threaded
Open this post in threaded view
|

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

Igor Podlesny-2
On Thu, 10 Jan 2019 at 01:21, Remi Locherer <[hidden email]> 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 default one at all? For e. g.
  https://www.juniper.net/documentation/en_US/junos/topics/concept/ospf-routing-external-metrics-overview.html
states "By default, OSPF uses the Type 2 external metric."
Bird OSPF also uses Type 2 for default route announcements.

It's interesting hence why OpenOSPFD uses Type 1 instead.

--
End of message. Next message?

Reply | Threaded
Open this post in threaded view
|

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

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 <[hidden email]> 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 down or in backup
state and the configured type is 2.

I don't have much time right now so please don't expect a fast fix.

>
> 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. And I also don't see how it affects existing setups.

>
> Can you also explain why Type 1 has been chosen as default one at all? For e. g.
>   https://www.juniper.net/documentation/en_US/junos/topics/concept/ospf-routing-external-metrics-overview.html
> states "By default, OSPF uses the Type 2 external metric."
> Bird OSPF also uses Type 2 for default route announcements.
>
> It's interesting hence why OpenOSPFD uses Type 1 instead.

I have no clue. But now it is unlikely that the default changes since that
would affect existing setups.

>
> --
> End of message. Next message?
>

Reply | Threaded
Open this post in threaded view
|

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

Igor Podlesny-2
On Thu, 10 Jan 2019 at 21:11, Remi Locherer <[hidden email]> 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") :)

--

Reply | Threaded
Open this post in threaded view
|

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

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 <[hidden email]> 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. ;-)

Reply | Threaded
Open this post in threaded view
|

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

Sebastian Benoit
Remi Locherer([hidden email]) 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 <[hidden email]> 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?

We supply errata (and thus syspatches) for security issues and for problems
that can cause a lot of grief to many people.

depend on is a nice feature, but not critical to the use of ospfd, so this
probably wont get an errata. If you really need the fix, you can apply the
patch to /usr/src/usr.sbin/ospfd yourself (i believe it should apply without
problems), build and install it, until you update to 6.5.

/Benno

> 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. ;-)

Reply | Threaded
Open this post in threaded view
|

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

Remi Locherer
Hi Igor

On Thu, Jan 10, 2019 at 11:31:00PM +0100, Sebastian Benoit wrote:

> Remi Locherer([hidden email]) 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 <[hidden email]> 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?
>
> We supply errata (and thus syspatches) for security issues and for problems
> that can cause a lot of grief to many people.
>
> depend on is a nice feature, but not critical to the use of ospfd, so this
> probably wont get an errata. If you really need the fix, you can apply the
> patch to /usr/src/usr.sbin/ospfd yourself (i believe it should apply without
> problems), build and install it, until you update to 6.5.
>
> /Benno
>
> > 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. ;-)
>

I just committed a fix for ospfd and ospf6d to -current. You can try it with
the next snapshot or wait for the next release.

If you need this functionality now on OpenBSD 6.4 with type2 external LSAs
you can use ifstated to monitor a carp interface, modifying metrics in
ospfd.conf and reloading ospfd.

Thank you for reporting the problem!

Regards,
Remi