Re: ospfd: depend on interface (new feature)
On 2018-04-20 15:39, Kapetanakis Giannis wrote:
On 20/04/18 16:20, Remi Locherer wrote:
On 2018-04-20 14:46, Kapetanakis Giannis wrote:
While it does the job for local connected/static networks (on the
router),
it doesn't do it for forwarded routes which I learn from remote OSPF
routers.
LSAs from other routers are not changed by the "depend on" feature.
But other
OSPF routers us the metric when they calculate their path.
If this does not answer your question, can you provide a simplified
description
or schema of your network?
Is this normal behavior?
relevant config parts:
stub router no
# redistribute default
redistribute 192.168.1.0/24 set { metric 100 } depend on carp0
area 0.0.0.1 {
interface vlan_int {
metric 1
depend on carp0
}
interface vlan_ext {
metric 1
depend on carp0
}
}
192.168.1.0/24 (which is a local blackhole route) is propagated with
the correct metric,
either 65535 or 100, depended on the carp0 status.
Rest of ospf routes don't change metric on carp0 demotion.
And what about the networks direct connected on vlan_int and vlan_ext?
Above you state it works as you expected for direct connected
networks.
Remi
Thanks for the answer.
I also thought that maybe LSAs are not changed... that's why I've
asked if it's normal.
I was expecting/hoping router links to be changed and thus affecting
LSAs indirectly.
My setup is like this [Cisco_int] <-> [OB1]/[OB2] <-> [Cisco_ext]
I manage Cisco_int and the BSDs. I was monitoring ospf routes on
Cisco_int to see behavior.
vlan_int is also connected on Cisco_int so I didn't expect to see
something different there as it is a connected network.
I tried this because I wanted the primary router/firewall to not take
over after boot, before pfsync is done.
So eventually this would only work on a setup where
internal_network(s) are carp interfaces and external is ospf right?
No, this is supposed to work in your setup.
(I've also seen your updated schema).
Could it be that the routes you're interested in are LSA type 5
(external)
advertised by cisco_ext_1 and _2 and metric type is 2?
If that is the case link metrics are not used for path calculation.
Try to change metric type to 1 on the cisco_ext_X.
On OpenBSD you can use "ospfctl show database external" to see the
metric
type.
Remi
PS: I think this is more a thread for misc@ ;-)
Re: ospfd: depend on interface (new feature)
sorry setup is different: - [OB1]- [Cisco_ext_1] --- [Cisco_int] --| |--- [BGP router] - [OB2]- [Cisco_ext2_ ]--- G
Re: ospfd: depend on interface (new feature)
On 20/04/18 16:20, Remi Locherer wrote:
> On 2018-04-20 14:46, Kapetanakis Giannis wrote:
>> While it does the job for local connected/static networks (on the router),
>> it doesn't do it for forwarded routes which I learn from remote OSPF routers.
>
> LSAs from other routers are not changed by the "depend on" feature. But other
> OSPF routers us the metric when they calculate their path.
>
> If this does not answer your question, can you provide a simplified
> description
> or schema of your network?
>
>> Is this normal behavior?
>>
>> relevant config parts:
>>
>> stub router no
>> # redistribute default
>> redistribute 192.168.1.0/24 set { metric 100 } depend on carp0
>>
>> area 0.0.0.1 {
>> interface vlan_int {
>> metric 1
>> depend on carp0
>> }
>> interface vlan_ext {
>> metric 1
>> depend on carp0
>> }
>> }
>>
>> 192.168.1.0/24 (which is a local blackhole route) is propagated with
>> the correct metric,
>> either 65535 or 100, depended on the carp0 status.
>>
>> Rest of ospf routes don't change metric on carp0 demotion.
>
> And what about the networks direct connected on vlan_int and vlan_ext?
> Above you state it works as you expected for direct connected networks.
>
> Remi
Thanks for the answer.
I also thought that maybe LSAs are not changed... that's why I've asked if it's
normal.
I was expecting/hoping router links to be changed and thus affecting LSAs
indirectly.
My setup is like this [Cisco_int] <-> [OB1]/[OB2] <-> [Cisco_ext]
I manage Cisco_int and the BSDs. I was monitoring ospf routes on Cisco_int to
see behavior.
vlan_int is also connected on Cisco_int so I didn't expect to see something
different there as it is a connected network.
I tried this because I wanted the primary router/firewall to not take over
after boot, before pfsync is done.
So eventually this would only work on a setup where internal_network(s) are
carp interfaces and external is ospf right?
G
Re: ospfd: depend on interface (new feature)
On 2018-04-20 14:46, Kapetanakis Giannis wrote:
On 04/02/18 01:42, Remi Locherer wrote:
Hi
This adds a new feature to ospfd: depend on interface.
A ospfd.conf using it looks like this:
--%<--
redistribute default depend on carp0
area 0.0.0.0 {
interface em2 { depend on carp0 }
[...]
}
--%<--
This router would send out the default route and the em2 network with
default metrics as long as carp0 is master. When carp0 becomes backup
these
routes are advertised with metric 65535.
"depend on" can also be used with other interface types than carp.
This diff was started by benno@ at p2k17 (redistribute and config
parser).
I added the interface part. jca@ contributed several improvements.
Comments, OKs?
Remi
Hi,
I'm trying to evaluate this new feature on my routers (in/out OSPF
only, no carp).
While it does the job for local connected/static networks (on the
router),
it doesn't do it for forwarded routes which I learn from remote OSPF
routers.
LSAs from other routers are not changed by the "depend on" feature. But
other
OSPF routers us the metric when they calculate their path.
If this does not answer your question, can you provide a simplified
description
or schema of your network?
Is this normal behavior?
relevant config parts:
stub router no
# redistribute default
redistribute 192.168.1.0/24 set { metric 100 } depend on carp0
area 0.0.0.1 {
interface vlan_int {
metric 1
depend on carp0
}
interface vlan_ext {
metric 1
depend on carp0
}
}
192.168.1.0/24 (which is a local blackhole route) is propagated with
the correct metric,
either 65535 or 100, depended on the carp0 status.
Rest of ospf routes don't change metric on carp0 demotion.
And what about the networks direct connected on vlan_int and vlan_ext?
Above you state it works as you expected for direct connected networks.
Remi
Re: ospfd: depend on interface (new feature)
On 04/02/18 01:42, Remi Locherer wrote:
> Hi
>
> This adds a new feature to ospfd: depend on interface.
>
> A ospfd.conf using it looks like this:
>
> --%<--
> redistribute default depend on carp0
> area 0.0.0.0 {
> interface em2 { depend on carp0 }
> [...]
> }
> --%<--
>
> This router would send out the default route and the em2 network with
> default metrics as long as carp0 is master. When carp0 becomes backup these
> routes are advertised with metric 65535.
>
> "depend on" can also be used with other interface types than carp.
>
> This diff was started by benno@ at p2k17 (redistribute and config parser).
> I added the interface part. jca@ contributed several improvements.
>
> Comments, OKs?
>
> Remi
Hi,
I'm trying to evaluate this new feature on my routers (in/out OSPF only, no
carp).
While it does the job for local connected/static networks (on the router),
it doesn't do it for forwarded routes which I learn from remote OSPF routers.
Is this normal behavior?
relevant config parts:
stub router no
# redistribute default
redistribute 192.168.1.0/24 set { metric 100 } depend on carp0
area 0.0.0.1 {
interface vlan_int {
metric 1
depend on carp0
}
interface vlan_ext {
metric 1
depend on carp0
}
}
192.168.1.0/24 (which is a local blackhole route) is propagated with the
correct metric,
either 65535 or 100, depended on the carp0 status.
Rest of ospf routes don't change metric on carp0 demotion.
thanks for any info on this,
G
Re: ospfd: depend on interface (new feature)
On 2018/02/04 23:04, Kapetanakis Giannis wrote: > On 04/02/18 17:52, Stuart Henderson wrote: > > On 2018/02/04 02:56, Kapetanakis Giannis wrote: > > > On 04/02/18 01:42, Remi Locherer wrote: > > > > Hi > > > > > > > > This adds a new feature to ospfd: depend on interface. > > > > > > > If I understand this right, someone could use this combined with pfsync, > > > to wait for states full sync before switching routes from backup to > > > master? > > > > > > nice :) > > > > > > G > > > > > > > > I'm not sure pfsync specifically handles that, but as long as you > > make sure the interface is not master at boot (e.g. carpdemote in > > hostname.carpX) and sleep and -carpdemote in rc.local, it will have that > > effect. > > > > Nice thing here is when you combine it with bgpd's demote handling. > > That way you can avoid feeding default to OSPF until BGP sessions are up. > > I'm not talking about "depend on pfsync" > > Since carp waits for pfync demotion counter to become master, > if ospf is waiting for carp (which is waiting for pfsync) then eventually > you have the same effect don't you? > > You can even use an unused carp interface just for depending on it's status. Oh, looking at the code it seems you're right. Seems undocumented though.
Re: ospfd: depend on interface (new feature)
On 04/02/18 17:52, Stuart Henderson wrote: On 2018/02/04 02:56, Kapetanakis Giannis wrote: On 04/02/18 01:42, Remi Locherer wrote: Hi This adds a new feature to ospfd: depend on interface. If I understand this right, someone could use this combined with pfsync, to wait for states full sync before switching routes from backup to master? nice :) G I'm not sure pfsync specifically handles that, but as long as you make sure the interface is not master at boot (e.g. carpdemote in hostname.carpX) and sleep and -carpdemote in rc.local, it will have that effect. Nice thing here is when you combine it with bgpd's demote handling. That way you can avoid feeding default to OSPF until BGP sessions are up. I'm not talking about "depend on pfsync" Since carp waits for pfync demotion counter to become master, if ospf is waiting for carp (which is waiting for pfsync) then eventually you have the same effect don't you? You can even use an unused carp interface just for depending on it's status. G
Re: ospfd: depend on interface (new feature)
On 2018/02/04 02:56, Kapetanakis Giannis wrote:
> On 04/02/18 01:42, Remi Locherer wrote:
> > Hi
> >
> > This adds a new feature to ospfd: depend on interface.
> >
> > A ospfd.conf using it looks like this:
> >
> > --%<--
> > redistribute default depend on carp0
> > area 0.0.0.0 {
> > interface em2 { depend on carp0 }
> > [...]
> > }
> > --%<--
> >
> > This router would send out the default route and the em2 network with
> > default metrics as long as carp0 is master. When carp0 becomes backup these
> > routes are advertised with metric 65535.
> >
> > "depend on" can also be used with other interface types than carp.
> >
> > This diff was started by benno@ at p2k17 (redistribute and config parser).
> > I added the interface part. jca@ contributed several improvements.
> >
> > Comments, OKs?
> >
> > Remi
>
> If I understand this right, someone could use this combined with pfsync,
> to wait for states full sync before switching routes from backup to master?
>
> nice :)
>
> G
>
>
I'm not sure pfsync specifically handles that, but as long as you
make sure the interface is not master at boot (e.g. carpdemote in
hostname.carpX) and sleep and -carpdemote in rc.local, it will have that
effect.
Nice thing here is when you combine it with bgpd's demote handling.
That way you can avoid feeding default to OSPF until BGP sessions are up.
Re: ospfd: depend on interface (new feature)
On Sun, Feb 04, 2018 at 05:19:59AM +0100, Claudio Jeker wrote:
> On Sun, Feb 04, 2018 at 12:42:22AM +0100, Remi Locherer wrote:
> > Hi
> >
> > This adds a new feature to ospfd: depend on interface.
> >
> > A ospfd.conf using it looks like this:
> >
> > --%<--
> > redistribute default depend on carp0
> > area 0.0.0.0 {
> > interface em2 { depend on carp0 }
> > [...]
> > }
> > --%<--
> >
> > This router would send out the default route and the em2 network with
> > default metrics as long as carp0 is master. When carp0 becomes backup these
> > routes are advertised with metric 65535.
> >
> > "depend on" can also be used with other interface types than carp.
> >
> > This diff was started by benno@ at p2k17 (redistribute and config parser).
> > I added the interface part. jca@ contributed several improvements.
> >
> > Comments, OKs?
> >
> > Remi
> > + *metric = (depend_ok) ? r->metric : MAX_METRIC;
> ^ ^
> Please remove the () around depend_ok here. The () are not needed.
> There is many more of these.
updated diff below with () removed around depend_ok.
Index: ospfd.c
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfd.c,v
retrieving revision 1.94
diff -u -p -r1.94 ospfd.c
--- ospfd.c 24 Jan 2017 04:24:25 - 1.94
+++ ospfd.c 4 Feb 2018 11:25:36 -
@@ -29,6 +29,7 @@
#include
#include
+#include
#include
#include
@@ -512,18 +513,30 @@ imsg_compose_event(struct imsgev *iev, u
int
ospf_redistribute(struct kroute *kr, u_int32_t *metric)
{
+ struct in_addr addr;
+ struct kif *kif;
struct redistribute *r;
- u_int8_t is_default = 0;
+ int is_default = 0, depend_ok = 1;
+
+ bzero(, sizeof(addr));
/* only allow 0.0.0.0/0 via REDIST_DEFAULT */
if (kr->prefix.s_addr == INADDR_ANY && kr->prefixlen == 0)
is_default = 1;
SIMPLEQ_FOREACH(r, _conf->redist_list, entry) {
+ if (r->dependon[0] != '\0') {
+ if ((kif = kif_findname(r->dependon, addr, NULL)))
+ depend_ok = ifstate_is_up(kif);
+ else
+ depend_ok = 0;
+ } else
+ depend_ok = 1;
+
switch (r->type & ~REDIST_NO) {
case REDIST_LABEL:
if (kr->rtlabel == r->label) {
- *metric = r->metric;
+ *metric = depend_ok ? r->metric : MAX_METRIC;
return (r->type & REDIST_NO ? 0 : 1);
}
break;
@@ -538,7 +551,7 @@ ospf_redistribute(struct kroute *kr, u_i
if (kr->flags & F_DYNAMIC)
continue;
if (kr->flags & F_STATIC) {
- *metric = r->metric;
+ *metric = depend_ok ? r->metric : MAX_METRIC;
return (r->type & REDIST_NO ? 0 : 1);
}
break;
@@ -548,7 +561,7 @@ ospf_redistribute(struct kroute *kr, u_i
if (kr->flags & F_DYNAMIC)
continue;
if (kr->flags & F_CONNECTED) {
- *metric = r->metric;
+ *metric = depend_ok ? r->metric : MAX_METRIC;
return (r->type & REDIST_NO ? 0 : 1);
}
break;
@@ -559,7 +572,8 @@ ospf_redistribute(struct kroute *kr, u_i
if (r->addr.s_addr == INADDR_ANY &&
r->mask.s_addr == INADDR_ANY) {
if (is_default) {
- *metric = r->metric;
+ *metric = depend_ok ? r->metric :
+ MAX_METRIC;
return (r->type & REDIST_NO ? 0 : 1);
} else
return (0);
@@ -568,13 +582,13 @@ ospf_redistribute(struct kroute *kr, u_i
if ((kr->prefix.s_addr & r->mask.s_addr) ==
(r->addr.s_addr & r->mask.s_addr) &&
kr->prefixlen >= mask2prefi
Re: ospfd: depend on interface (new feature)
Remi Locherer(remi.loche...@relo.ch) on 2018.02.04 00:42:22 +0100:
> Hi
>
> This adds a new feature to ospfd: depend on interface.
>
> A ospfd.conf using it looks like this:
>
> --%<--
> redistribute default depend on carp0
> area 0.0.0.0 {
> interface em2 { depend on carp0 }
> [...]
> }
> --%<--
>
> This router would send out the default route and the em2 network with
> default metrics as long as carp0 is master. When carp0 becomes backup these
> routes are advertised with metric 65535.
>
> "depend on" can also be used with other interface types than carp.
>
> This diff was started by benno@ at p2k17 (redistribute and config parser).
> I added the interface part. jca@ contributed several improvements.
>
> Comments, OKs?
fwiw ok benno@
> Remi
>
>
> Index: ospfd.c
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/ospfd.c,v
> retrieving revision 1.94
> diff -u -p -r1.94 ospfd.c
> --- ospfd.c 24 Jan 2017 04:24:25 - 1.94
> +++ ospfd.c 21 Jan 2018 14:01:42 -
> @@ -29,6 +29,7 @@
>
> #include
> #include
> +#include
>
> #include
> #include
> @@ -512,18 +513,30 @@ imsg_compose_event(struct imsgev *iev, u
> int
> ospf_redistribute(struct kroute *kr, u_int32_t *metric)
> {
> + struct in_addr addr;
> + struct kif *kif;
> struct redistribute *r;
> - u_int8_t is_default = 0;
> + int is_default = 0, depend_ok = 1;
> +
> + bzero(, sizeof(addr));
>
> /* only allow 0.0.0.0/0 via REDIST_DEFAULT */
> if (kr->prefix.s_addr == INADDR_ANY && kr->prefixlen == 0)
> is_default = 1;
>
> SIMPLEQ_FOREACH(r, _conf->redist_list, entry) {
> + if (r->dependon[0] != '\0') {
> + if ((kif = kif_findname(r->dependon, addr, NULL)))
> + depend_ok = ifstate_is_up(kif);
> + else
> + depend_ok = 0;
> + } else
> + depend_ok = 1;
> +
> switch (r->type & ~REDIST_NO) {
> case REDIST_LABEL:
> if (kr->rtlabel == r->label) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric : MAX_METRIC;
> return (r->type & REDIST_NO ? 0 : 1);
> }
> break;
> @@ -538,7 +551,7 @@ ospf_redistribute(struct kroute *kr, u_i
> if (kr->flags & F_DYNAMIC)
> continue;
> if (kr->flags & F_STATIC) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric : MAX_METRIC;
> return (r->type & REDIST_NO ? 0 : 1);
> }
> break;
> @@ -548,7 +561,7 @@ ospf_redistribute(struct kroute *kr, u_i
> if (kr->flags & F_DYNAMIC)
> continue;
> if (kr->flags & F_CONNECTED) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric : MAX_METRIC;
> return (r->type & REDIST_NO ? 0 : 1);
> }
> break;
> @@ -559,7 +572,8 @@ ospf_redistribute(struct kroute *kr, u_i
> if (r->addr.s_addr == INADDR_ANY &&
> r->mask.s_addr == INADDR_ANY) {
> if (is_default) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric :
> + MAX_METRIC;
> return (r->type & REDIST_NO ? 0 : 1);
> } else
> return (0);
> @@ -568,13 +582,13 @@ ospf_redistribute(struct kroute *kr, u_i
> if ((kr->prefix.s_addr & r->mask.s_addr) ==
> (r->addr.s_addr & r->mask.s_addr) &&
> kr->prefixlen >= mask2prefixlen(r->mask.s_addr)) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric : MAX_METRIC;
>
Re: ospfd: depend on interface (new feature)
On Sun, Feb 04, 2018 at 12:42:22AM +0100, Remi Locherer wrote:
> Hi
>
> This adds a new feature to ospfd: depend on interface.
>
> A ospfd.conf using it looks like this:
>
> --%<--
> redistribute default depend on carp0
> area 0.0.0.0 {
> interface em2 { depend on carp0 }
> [...]
> }
> --%<--
>
> This router would send out the default route and the em2 network with
> default metrics as long as carp0 is master. When carp0 becomes backup these
> routes are advertised with metric 65535.
>
> "depend on" can also be used with other interface types than carp.
>
> This diff was started by benno@ at p2k17 (redistribute and config parser).
> I added the interface part. jca@ contributed several improvements.
>
> Comments, OKs?
>
> Remi
>
>
> Index: ospfd.c
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/ospfd.c,v
> retrieving revision 1.94
> diff -u -p -r1.94 ospfd.c
> --- ospfd.c 24 Jan 2017 04:24:25 - 1.94
> +++ ospfd.c 21 Jan 2018 14:01:42 -
> @@ -29,6 +29,7 @@
>
> #include
> #include
> +#include
>
> #include
> #include
> @@ -512,18 +513,30 @@ imsg_compose_event(struct imsgev *iev, u
> int
> ospf_redistribute(struct kroute *kr, u_int32_t *metric)
> {
> + struct in_addr addr;
> + struct kif *kif;
> struct redistribute *r;
> - u_int8_t is_default = 0;
> + int is_default = 0, depend_ok = 1;
> +
> + bzero(, sizeof(addr));
>
> /* only allow 0.0.0.0/0 via REDIST_DEFAULT */
> if (kr->prefix.s_addr == INADDR_ANY && kr->prefixlen == 0)
> is_default = 1;
>
> SIMPLEQ_FOREACH(r, _conf->redist_list, entry) {
> + if (r->dependon[0] != '\0') {
> + if ((kif = kif_findname(r->dependon, addr, NULL)))
> + depend_ok = ifstate_is_up(kif);
> + else
> + depend_ok = 0;
> + } else
> + depend_ok = 1;
> +
> switch (r->type & ~REDIST_NO) {
> case REDIST_LABEL:
> if (kr->rtlabel == r->label) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric : MAX_METRIC;
^ ^
Please remove the () around depend_ok here. The () are not needed.
There is many more of these.
> return (r->type & REDIST_NO ? 0 : 1);
> }
> break;
> @@ -538,7 +551,7 @@ ospf_redistribute(struct kroute *kr, u_i
> if (kr->flags & F_DYNAMIC)
> continue;
> if (kr->flags & F_STATIC) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric : MAX_METRIC;
> return (r->type & REDIST_NO ? 0 : 1);
> }
> break;
> @@ -548,7 +561,7 @@ ospf_redistribute(struct kroute *kr, u_i
> if (kr->flags & F_DYNAMIC)
> continue;
> if (kr->flags & F_CONNECTED) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric : MAX_METRIC;
> return (r->type & REDIST_NO ? 0 : 1);
> }
> break;
> @@ -559,7 +572,8 @@ ospf_redistribute(struct kroute *kr, u_i
> if (r->addr.s_addr == INADDR_ANY &&
> r->mask.s_addr == INADDR_ANY) {
> if (is_default) {
> - *metric = r->metric;
> + *metric = (depend_ok) ? r->metric :
> + MAX_METRIC;
> return (r->type & REDIST_NO ? 0 : 1);
> } else
> return (0);
> @@ -568,13 +582,13 @@ ospf_redistribute(struct kroute *kr, u_i
> if ((kr->prefix.s_addr & r->mask.s_addr) ==
> (r->addr.s_addr & r->mask.s_addr) &&
> kr->prefixlen >= mask2prefixlen(r->mask.s_addr)) {
> -
Re: ospfd: depend on interface (new feature)
On 04/02/18 01:42, Remi Locherer wrote:
Hi
This adds a new feature to ospfd: depend on interface.
A ospfd.conf using it looks like this:
--%<--
redistribute default depend on carp0
area 0.0.0.0 {
interface em2 { depend on carp0 }
[...]
}
--%<--
This router would send out the default route and the em2 network with
default metrics as long as carp0 is master. When carp0 becomes backup these
routes are advertised with metric 65535.
"depend on" can also be used with other interface types than carp.
This diff was started by benno@ at p2k17 (redistribute and config parser).
I added the interface part. jca@ contributed several improvements.
Comments, OKs?
Remi
If I understand this right, someone could use this combined with pfsync,
to wait for states full sync before switching routes from backup to master?
nice :)
G
ospfd: depend on interface (new feature)
Hi
This adds a new feature to ospfd: depend on interface.
A ospfd.conf using it looks like this:
--%<--
redistribute default depend on carp0
area 0.0.0.0 {
interface em2 { depend on carp0 }
[...]
}
--%<--
This router would send out the default route and the em2 network with
default metrics as long as carp0 is master. When carp0 becomes backup these
routes are advertised with metric 65535.
"depend on" can also be used with other interface types than carp.
This diff was started by benno@ at p2k17 (redistribute and config parser).
I added the interface part. jca@ contributed several improvements.
Comments, OKs?
Remi
Index: ospfd.c
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfd.c,v
retrieving revision 1.94
diff -u -p -r1.94 ospfd.c
--- ospfd.c 24 Jan 2017 04:24:25 - 1.94
+++ ospfd.c 21 Jan 2018 14:01:42 -
@@ -29,6 +29,7 @@
#include
#include
+#include
#include
#include
@@ -512,18 +513,30 @@ imsg_compose_event(struct imsgev *iev, u
int
ospf_redistribute(struct kroute *kr, u_int32_t *metric)
{
+ struct in_addr addr;
+ struct kif *kif;
struct redistribute *r;
- u_int8_t is_default = 0;
+ int is_default = 0, depend_ok = 1;
+
+ bzero(, sizeof(addr));
/* only allow 0.0.0.0/0 via REDIST_DEFAULT */
if (kr->prefix.s_addr == INADDR_ANY && kr->prefixlen == 0)
is_default = 1;
SIMPLEQ_FOREACH(r, _conf->redist_list, entry) {
+ if (r->dependon[0] != '\0') {
+ if ((kif = kif_findname(r->dependon, addr, NULL)))
+ depend_ok = ifstate_is_up(kif);
+ else
+ depend_ok = 0;
+ } else
+ depend_ok = 1;
+
switch (r->type & ~REDIST_NO) {
case REDIST_LABEL:
if (kr->rtlabel == r->label) {
- *metric = r->metric;
+ *metric = (depend_ok) ? r->metric : MAX_METRIC;
return (r->type & REDIST_NO ? 0 : 1);
}
break;
@@ -538,7 +551,7 @@ ospf_redistribute(struct kroute *kr, u_i
if (kr->flags & F_DYNAMIC)
continue;
if (kr->flags & F_STATIC) {
- *metric = r->metric;
+ *metric = (depend_ok) ? r->metric : MAX_METRIC;
return (r->type & REDIST_NO ? 0 : 1);
}
break;
@@ -548,7 +561,7 @@ ospf_redistribute(struct kroute *kr, u_i
if (kr->flags & F_DYNAMIC)
continue;
if (kr->flags & F_CONNECTED) {
- *metric = r->metric;
+ *metric = (depend_ok) ? r->metric : MAX_METRIC;
return (r->type & REDIST_NO ? 0 : 1);
}
break;
@@ -559,7 +572,8 @@ ospf_redistribute(struct kroute *kr, u_i
if (r->addr.s_addr == INADDR_ANY &&
r->mask.s_addr == INADDR_ANY) {
if (is_default) {
- *metric = r->metric;
+ *metric = (depend_ok) ? r->metric :
+ MAX_METRIC;
return (r->type & REDIST_NO ? 0 : 1);
} else
return (0);
@@ -568,13 +582,13 @@ ospf_redistribute(struct kroute *kr, u_i
if ((kr->prefix.s_addr & r->mask.s_addr) ==
(r->addr.s_addr & r->mask.s_addr) &&
kr->prefixlen >= mask2prefixlen(r->mask.s_addr)) {
- *metric = r->metric;
+ *metric = (depend_ok) ? r->metric : MAX_METRIC;
return (r->type & REDIST_NO ? 0 : 1);
}
break;
case REDIST_DEFAULT:
if (is_default) {
- *metric = r->metric;
+ *metric = (depend_ok) ? r->metric : MAX_METRIC;
return (r->type & REDIST_NO ? 0 : 1);
}
break;
@@ -841,6 +855,10 @@ merge_interfaces(s
