On Mon, Jul 03, 2023 at 11:28:44AM +0200, Claudio Jeker wrote:
> Similar to the relayd diff use ibuf_data instead of ibuf->buf.
ok tb
Similar to the relayd diff use ibuf_data instead of ibuf->buf.
--
:wq Claudio
Index: auth.c
===
RCS file: /cvs/src/usr.sbin/ospfd/auth.c,v
retrieving revision 1.21
diff -u -p -r1.21 auth.c
--- auth.c 20 Jun 2023 15:19:55 -0
On Tue, Jun 20, 2023 at 06:29:59PM +0200, Claudio Jeker wrote:
> On Tue, Jun 20, 2023 at 02:47:41PM +0200, Claudio Jeker wrote:
> > This diff updates ospfd to use the new ibuf API.
> >
> > It mainly removes the use of ibuf_seek() and replaces these calls with
> > i
On Tue, Jun 20, 2023 at 02:47:41PM +0200, Claudio Jeker wrote:
> This diff updates ospfd to use the new ibuf API.
>
> It mainly removes the use of ibuf_seek() and replaces these calls with
> ibuf_set().
>
> Regress still passes with this diff in.
Here the same diff for ospf6
On Tue, Jun 20, 2023 at 03:46:23PM +0200, Theo Buehler wrote:
> On Tue, Jun 20, 2023 at 02:47:41PM +0200, Claudio Jeker wrote:
> > This diff updates ospfd to use the new ibuf API.
> >
> > It mainly removes the use of ibuf_seek() and replaces these calls with
> > ibuf_se
On Tue, Jun 20, 2023 at 02:47:41PM +0200, Claudio Jeker wrote:
> This diff updates ospfd to use the new ibuf API.
>
> It mainly removes the use of ibuf_seek() and replaces these calls with
> ibuf_set().
>
> Regress still passes with this diff in.
There's a functi
This diff updates ospfd to use the new ibuf API.
It mainly removes the use of ibuf_seek() and replaces these calls with
ibuf_set().
Regress still passes with this diff in.
--
:wq Claudio
Index: auth.c
===
RCS file: /cvs/src
Remi Locherer(remi.loche...@relo.ch) on 2021.11.03 22:23:44 +0100:
> On Tue, Nov 02, 2021 at 05:27:11PM +, Stuart Henderson wrote:
> > I've recently started seeing a number of flaps with ospfd/ospf6d
> > with invalid seq nums / "seq num mismatch, bad flags" log
On Tue, Nov 02, 2021 at 05:27:11PM +, Stuart Henderson wrote:
> I've recently started seeing a number of flaps with ospfd/ospf6d
> with invalid seq nums / "seq num mismatch, bad flags" logged.
> Not quite sure what's going yet as they must be occurring on
> va
I've recently started seeing a number of flaps with ospfd/ospf6d
with invalid seq nums / "seq num mismatch, bad flags" logged.
Not quite sure what's going yet as they must be occurring on
various local switched segments on one nic and also on ethernet
wan circuits direct to
On 05/06/2021 21:31, Stuart Henderson wrote:
Sometimes I see authentication errors from ospfd, mainly (though
possibly not entirely always) on a 30 minute cycle, e.g. these log entries
2021-06-03T05:30:04.952Z ospfd[31748]: spf_calc: area 0.0.0.0 calculated
2021-06-03T05:51:43.785Z ospfd
Sometimes I see authentication errors from ospfd, mainly (though
possibly not entirely always) on a 30 minute cycle, e.g. these log entries
2021-06-03T05:30:04.952Z ospfd[31748]: spf_calc: area 0.0.0.0 calculated
2021-06-03T05:51:43.785Z ospfd[76044]: auth_validate: decreasing seq num
This is my try at cleaning up commons in ospfd.
I made one big combined diff but will probably split up a few things
into own commits. E.g. the lsupdate.c and lsreq.c ones.
I had to cleanup the control.c code a bit since this was a bit of a mess.
While in bgpd I was able to remove the global
ospfd is our first target for using ROUTE_FLAGFILTER to reduce pressure on the
route socket, so here's the diff we've been running for a couple of weeks now
(minus the fix for RTM_DELETE flags, notably).
ok?
Index: kroute.c
=
Thanks for the comments, some good things to think about.
Out of interest, can anyone think of some good examples of daemons which
call ctl commands, just wanting to review the patterns and approach, and
what is the best, best practice examples today.
On Mon, 18 May 2020, 16:46 Theo de Raadt,
Claudio Jeker wrote:
> Last note, please do not try to directly talk to the daemons always pass
> via the *ctl program. The API used between for example bgpd and bgpctl
> is not public and also not stable. It requires that both tools are in
> sync.
There is an additional reason for doing this.
On Mon, May 18, 2020 at 04:16:05PM +0100, Stuart Henderson wrote:
> On 2020/05/18 15:31, Richard Chivers wrote:
> > Hi,
> >
> > We could do with exposing certain metrics from bgpd, ospfd and pf.
> >
> > I was considering a couple of approaches and really was
On 2020/05/18 15:31, Richard Chivers wrote:
> Hi,
>
> We could do with exposing certain metrics from bgpd, ospfd and pf.
>
> I was considering a couple of approaches and really was just
> interested in what would make most sense in general.
>
> Has anyone else considered
Hi,
We could do with exposing certain metrics from bgpd, ospfd and pf.
I was considering a couple of approaches and really was just
interested in what would make most sense in general.
Has anyone else considered this at all?
Would this be useful to anyone else?
Also just to say I am not
Can someone give this diff for ospf6d a try?
This fixes the same issue that I just committed for ospfd:
revision 1.48
date: 2020/05/06 14:40:54; author: claudio; state: Exp; lines: +5 -5;
commitid: 1nh8JCAv0Kmqd1jV;
Do not use the pointer returned by ibuf_reserve() after calling another
ibuf
On Sat, Mar 28, 2020 at 05:00:11PM +0100, Remi Locherer wrote:
> On Sat, Mar 21, 2020 at 05:25:45PM +0100, Denis Fondras wrote:
> > Biggest chunk is rework of rde_asext_get()/rde_asext_put().
> > Also change get_net_link() and get_rtr_link() to work like ospfd couterpart.
>
>
On Sat, Mar 21, 2020 at 05:25:45PM +0100, Denis Fondras wrote:
> Biggest chunk is rework of rde_asext_get()/rde_asext_put().
> Also change get_net_link() and get_rtr_link() to work like ospfd couterpart.
Reads good to me and I didn't spot any issues running tests with it.
One question
Biggest chunk is rework of rde_asext_get()/rde_asext_put().
Also change get_net_link() and get_rtr_link() to work like ospfd couterpart.
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/rde.c,v
retrieving revision 1.84
diff -u -p
On Thu, Jan 02, 2020 at 05:17:02PM +0100, Denis Fondras wrote:
> Sync with ospfd's hello.c
ok remi@
>
> Index: hello.c
> ===
> RCS file: /cvs/src/usr.sbin/ospf6d/hello.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 hello.c
> ---
On Thu, Jan 02, 2020 at 04:05:45PM +0100, Denis Fondras wrote:
> This is mostly log messages sync.
ok remi@
>
> Index: database.c
> ===
> RCS file: /cvs/src/usr.sbin/ospf6d/database.c,v
> retrieving revision 1.18
> diff -u -p -r1.18
Sync with ospfd's hello.c
Index: hello.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/hello.c,v
retrieving revision 1.21
diff -u -p -r1.21 hello.c
--- hello.c 23 Dec 2019 11:25:41 - 1.21
+++ hello.c 2 Jan 2020 16:11:19 -000
This is mostly log messages sync.
Index: database.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/database.c,v
retrieving revision 1.18
diff -u -p -r1.18 database.c
--- database.c 23 Dec 2019 07:33:49 - 1.18
+++ database.c 2 Jan 2
On 17/11/2019 13:44, Remi Locherer wrote:
> Yes, I'll send a separate diff for that later.
>
> OK for the new diff?
Works for me.
G
> > > > > fib
> > > > > and routing table!) and also test reports with real p2p2 interfaces
> > > > > (gif
> > > > > or gre).
> > > > >
> > > > > Of course OKs are also welcome. ;-)
> > > > >
> > &
ting table!) and also test reports with real p2p2 interfaces (gif
> > > > or gre).
> > > >
> > > > Of course OKs are also welcome. ;-)
> > > >
> > > > Remi
> > >
> > >
> > > Hi,
> > >
> > > From firs
gre).
> > >
> > > Of course OKs are also welcome. ;-)
> > >
> > > Remi
> >
> >
> > Hi,
> >
> > From first test seems to work :)
> >
> > looking forward test it for IPv6 as well
> >
> > thanks
> >
orts with real p2p2 interfaces (gif
> > or gre).
> >
> > Of course OKs are also welcome. ;-)
> >
> > Remi
>
>
> Hi,
>
> From first test seems to work :)
>
> looking forward test it for IPv6 as well
>
> thanks
>
> Giannis
Anyon
Sebastian Benoit wrote:
> > OK. Another option is to use __func__ which is always correct.
>
> Please definatly use __func__. With that ok benno too.
I like __func__ where it makes sense, but often developers consider
"i've shown an obscurely named function that i know" to be a solved
problem,
> > RCS file: /cvs/src/usr.sbin/ospfd/kroute.c,v
> > retrieving revision 1.112
> > diff -u -p -r1.112 kroute.c
> > --- kroute.c28 Dec 2018 19:25:10 - 1.112
> > +++ kroute.c9 Nov 2019 14:11:03 -
> > @@ -1501,7 +1501,7 @@ rtmsg_pr
On Sat, Nov 09, 2019 at 03:27:31PM +0100, Denis Fondras wrote:
> Fix function name in error message.
>
> Index: kroute.c
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/kroute.c,v
> retrieving revision 1.112
> diff -
Fix function name in error message.
Index: kroute.c
===
RCS file: /cvs/src/usr.sbin/ospfd/kroute.c,v
retrieving revision 1.112
diff -u -p -r1.112 kroute.c
--- kroute.c28 Dec 2018 19:25:10 - 1.112
+++ kroute.c9 Nov
On Mon, Nov 04, 2019 at 02:01:57PM +0200, Kapetanakis Giannis wrote:
> On 25/10/2019 13:57, Remi Locherer wrote:
> > Hi tech@,
> >
> > earlier this year I sent a diff that allowed to change an interface
> > from broadcast to point-to-point.
> >
> > https://marc.info/?l=openbsd-tech&m=15613292320370
(check the fib
> and routing table!) and also test reports with real p2p2 interfaces (gif
> or gre).
>
> Of course OKs are also welcome. ;-)
>
> Remi
Hi,
>From first test seems to work :)
looking forward test it for IPv6 as well
thanks
Giannis
>
>
>
> Index:
Newer version after a comment by claudio@.
Currently ospfd logs routing message type code instead of name.
Make it more explicit.
remi@ is OK but wonders if rtm_type_name() will be updated as needed.
What do you think ?
Denis
Index: kroute.c
Currently ospfd logs routing message type code instead of name.
Make it more explicit.
remi@ is OK but wonders if rtm_type_name() will be updated as needed (that's why
I also log the typecode)
What do you think ?
Denis
Index: kro
;-)
Remi
Index: hello.c
===
RCS file: /cvs/src/usr.sbin/ospfd/hello.c,v
retrieving revision 1.24
diff -u -p -r1.24 hello.c
--- hello.c 12 Aug 2019 20:21:58 - 1.24
+++ hello.c 21 Sep 2019 22:06:17 -
@@ -189,14 +189,13 @@ recv_hello(struct iface *iface, struct i
emi
>
>
> Index: hello.c
> ===
> RCS file: /cvs/src/usr.sbin/ospfd/hello.c,v
> retrieving revision 1.23
> diff -u -p -r1.23 hello.c
> --- hello.c 15 Jul 2019 18:26:39 - 1.23
> +++ hello.c 11 Aug 2019 09:36:13
reads ok
Remi Locherer(remi.loche...@relo.ch) on 2019.08.11 11:21:36 +0200:
> When ospfd receives a hello packet it takes the src IP address and updates
> the address in its neighbor struct for the given router id unconditionally.
>
> In the case of broadcast interfaces this is n
I'd like to get a notification when a neighbor changes the src IP address
for hello packets. Either it is a planned change or something bad happens
in the network.
OK?
Remi
Index: hello.c
===
RCS file: /cvs/src/usr.sbin/
When ospfd receives a hello packet it takes the src IP address and updates
the address in its neighbor struct for the given router id unconditionally.
In the case of broadcast interfaces this is not a problem:
find_iface() checks that the src address is from the same subnet as
the receiving
On Mon, Jul 15, 2019 at 07:32:18AM +0200, Remi Locherer wrote:
> Hi,
>
> I'd like to improve ospfd's logging when sending a packet fails.
>
> I got a debug output from a ospfd user which contains "send packet: error
> ...".
> I guess ospfd failed to s
Hi,
I'd like to improve ospfd's logging when sending a packet fails.
I got a debug output from a ospfd user which contains "send packet: error ...".
I guess ospfd failed to send an ls ack. With below diff applied it would be
clear which packet could not be sent and to which
ck route the BSD is announcing.
Thank you for testing!
Can you send me your ospfd.conf, the output from ospfd -dv and the output
from tcpdump showing the ospf traffic?
> On 24/06/2019 01:33, Remi Locherer wrote:
> > Diff below adds to ospfd point to point support for Ethernet interfaces.
Hi,
This does not work for me with IOS.
neighbor is full,
rib is ok
fib does not list the routes to IOS and
routing table is not updated on BSD
On IOS I do have the loopback route the BSD is announcing.
G
On 24/06/2019 01:33, Remi Locherer wrote:
> Diff below adds to ospfd point to po
Works for me no problem. tested to IOS.
On 03.07.19 00:00, Remi Locherer wrote:
ping
On Mon, Jun 24, 2019 at 12:33:16AM +0200, Remi Locherer wrote:
Diff below adds to ospfd point to point support for Ethernet interfaces.
I successfully tested this against Junos and FastIron.
I first made the
ping
On Mon, Jun 24, 2019 at 12:33:16AM +0200, Remi Locherer wrote:
> Diff below adds to ospfd point to point support for Ethernet interfaces.
> I successfully tested this against Junos and FastIron.
>
> I first made the key word in the config "point-to-point". But then I
Diff below adds to ospfd point to point support for Ethernet interfaces.
I successfully tested this against Junos and FastIron.
I first made the key word in the config "point-to-point". But then I
changed to "type p2p". The later would allow for "type nbma" or &
cherer
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi David
>>>>>>>>>
>>>>>>>>> On Mon, Apr 29, 2019 at 11:53:27AM +1000, David Gwynne wrote:
>>>>>>>>>
gt; > >> a number,
> > > > > > > >> but then have to think hard to convert that number to an
> > > > > > > >> address for use
> > > > > > > >> in openbsd. eg, i was given area 700 in one place, which is
> &
it's always bothered me that i config areas on a crisco using a
> > > > > > >> number,
> > > > > > >> but then have to think hard to convert that number to an address
> > > > > > >> for use
> > > > > >
>> but then have to think hard to convert that number to an address
> > > > > >> for use
> > > > > >> in openbsd. eg, i was given area 700 in one place, which is
> > > > > >> 0.0.2.188
> > > > > >> as
On Wed, May 15, 2019 at 11:15:03PM +0200, Remi Locherer wrote:
> Any opinions or comments on this? I think this would be a valuable addition
> to ospfd.
>
I can't see any harm in it.
OK denis@
> >
> > Below diff changes ospfctl to accept the address and number f
t; > >> it's always bothered me that i config areas on a crisco using a
> > > > >> number,
> > > > >> but then have to think hard to convert that number to an address for
> > > > >> use
> > > > >> in openbsd. eg, i
On Wed, May 15, 2019 at 03:52:57PM +0200, Denis Fondras wrote:
> When router-id is unspecified, ospfd will choose the lowest IP address of the
> host. I added an area and an IP lower than the existing ones and on reload
> ospfd asked me to restart and did not activate the new area.
>
When router-id is unspecified, ospfd will choose the lowest IP address of the
host. I added an area and an IP lower than the existing ones and on reload
ospfd asked me to restart and did not activate the new area.
Why would it update the router-id in such a case ?
This diff changes this
o convert that number to an address for
> > > >> use
> > > >> in openbsd. eg, i was given area 700 in one place, which is 0.0.2.188
> > > >> as an address. super annoying.
> > > >>
> > > >> so this changes the
this changes the ospfd parser so it accepts both a number or address.
i also changed it so it prints the number by default, which may be
contentious. the manpage is slightly tweaked too.
thoughts?
why don't just add something like 'convert' to ospfctl? wouldn't it be
easier
SPF Area ID's are typically formatted as IP
addresses).
> so this changes the ospfd parser so it accepts both a number or address.
> i also changed it so it prints the number by default, which may be
> contentious. the manpage is slightly tweaked too.
Please keep it as it is. os
at 11:53:27AM +1000, David Gwynne wrote:
> > >> it's always bothered me that i config areas on a crisco using a number,
> > >> but then have to think hard to convert that number to an address for use
> > >> in openbsd. eg, i was given area 700 in one place, which
config areas on a crisco using a number,
> >> but then have to think hard to convert that number to an address for use
> >> in openbsd. eg, i was given area 700 in one place, which is 0.0.2.188
> >> as an address. super annoying.
> >>
> >> so this chang
mber to an address for use
>> in openbsd. eg, i was given area 700 in one place, which is 0.0.2.188
>> as an address. super annoying.
>>
>> so this changes the ospfd parser so it accepts both a number or address.
>> i also changed it so it prints the number by default, wh
0.0.2.188
> as an address. super annoying.
>
> so this changes the ospfd parser so it accepts both a number or address.
> i also changed it so it prints the number by default, which may be
> contentious. the manpage is slightly tweaked too.
>
> thoughts?
I like it to be
it's always bothered me that i config areas on a crisco using a number,
but then have to think hard to convert that number to an address for use
in openbsd. eg, i was given area 700 in one place, which is 0.0.2.188
as an address. super annoying.
so this changes the ospfd parser so it accepts
e wrote:
> > >> I kept finding I had a lingering /30 route when I turned off one of my
> > >> test boxes. I tracked it down to ospfd sending RTM_ADD for a stub
> > >> network with the non-masked prefix. The RTM_ADD path applies the mask
> > >> inside t
f one of my
> >> test boxes. I tracked it down to ospfd sending RTM_ADD for a stub
> >> network with the non-masked prefix. The RTM_ADD path applies the mask
> >> inside the kernel, so the route got added as expected, but the
> >> RTM_DELETE enforces an exact match,
On 2/04/2019 3:30 pm, Remi Locherer wrote:
> Hi Mitchell
>
> On Sat, Mar 30, 2019 at 04:10:09PM +1000, Mitchell Krome wrote:
>> I kept finding I had a lingering /30 route when I turned off one of my
>> test boxes. I tracked it down to ospfd sending RTM_ADD for a stub
&g
Hi Mitchell
On Sat, Mar 30, 2019 at 04:10:09PM +1000, Mitchell Krome wrote:
> I kept finding I had a lingering /30 route when I turned off one of my
> test boxes. I tracked it down to ospfd sending RTM_ADD for a stub
> network with the non-masked prefix. The RTM_ADD path applies the mask
I kept finding I had a lingering /30 route when I turned off one of my
test boxes. I tracked it down to ospfd sending RTM_ADD for a stub
network with the non-masked prefix. The RTM_ADD path applies the mask
inside the kernel, so the route got added as expected, but the
RTM_DELETE enforces an exact
On Mon, Mar 25 2019, Remi Locherer wrote:
[...]
> This works and it makes sense to me.
>
> The log message is a bit lengthy compared to other log messages produced
> by ospfd. Maybe something like this: "router-id changed: restart required"
Yep, fine with me.
> But
oad because it doesn't make sense
> > sending the config to all the children if we know we're going to abort.
>
> Your patch was mangled (long line wrapped) but the changes looked good.
> Here's an updated version which tweaks punc
p into ospf_reload because it doesn't make sense
> > sending the config to all the children if we know we're going to abort.
>
> Your patch was mangled (long line wrapped) but the changes looked good.
> Here's an updated version which tweaks punctuation and case (to match
> the
d.
>
> I moved the check up into ospf_reload because it doesn't make sense
> sending the config to all the children if we know we're going to abort.
Your patch was mangled (long line wrapped) but the changes looked good.
Here's an updated version which tweaks punctuation and cas
fig
to take effect after changing the router id.
I moved the check up into ospf_reload because it doesn't make sense
sending the config to all the children if we know we're going to abort.
Mitchell
diff --git a/usr.sbin/ospfd/ospfd.c b/usr.sbin/ospfd/ospfd.c
index d01a2fa66..bc2
Sebastian Benoit wrote:
> Mitchell Krome(mitchellkr...@gmail.com) on 2019.03.23 20:27:17 +1000:
> > Was messing around with ospf and got myself into a situation where the
> > router ID's were the same on two boxes because I only did a reload on
> > one of them when I changed the loopback IP's.
>
e. not load the new config at all.
You just add a warning, but who reads the log at that point?
ospf6d cant reload its config at this time, so not a problem there.
/Benno
> Mitchell
>
>
> diff --git a/usr.sbin/ospfd/ospfd.c b/usr.sbin/ospfd/ospfd.c
> index d01a2fa66..db59fc7
uch). Same patch can probably be applied to
ospf6d if people think it's useful.
Mitchell
diff --git a/usr.sbin/ospfd/ospfd.c b/usr.sbin/ospfd/ospfd.c
index d01a2fa66..db59fc718 100644
--- a/usr.sbin/ospfd/ospfd.c
+++ b/usr.sbin/ospfd/ospfd.c
@@ -694,6 +694,10 @@ merge_config(struct ospfd_con
affected route
> might be used by other routers a long time after removing it from the
> config (until the LSA ages out).
>
> Below diff fixes this.
>
> OK?
Makes sense, OK claudio@
> Index: ospfd.c
> =======
> R
(until the LSA ages out).
Below diff fixes this.
OK?
Remi
Index: ospfd.c
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfd.c,v
retrieving revision 1.102
diff -u -p -r1.102 ospfd.c
--- ospfd.c 28 Dec 2018 19:25:10 - 1.102
t kr_state.
> >
> >
> > OK?
> >
> > Remi
> >
> >
> >
> > cvs diff: Diffing .
> > Index: kroute.c
> > ===
> > RCS file: /cvs/src/usr.sbin/ospfd/kroute.c,v
> > retrieving revision 1.111
> > diff -u -p -r1.111 k
kr_dispatch_msg() needs to be reset. Because of that I added fib_prio to
> struct kr_state.
>
>
> OK?
>
> Remi
>
>
>
> cvs diff: Diffing .
> Index: kroute.c
> ===
> RCS file: /cvs/src/usr.sbin/
.
Index: kroute.c
===
RCS file: /cvs/src/usr.sbin/ospfd/kroute.c,v
retrieving revision 1.111
diff -u -p -r1.111 kroute.c
--- kroute.c10 Jul 2018 11:49:04 - 1.111
+++ kroute.c9 Dec 2018 21:39:46 -
@@ -45,6 +45,7 @@ stru
On Sat, Sep 01, 2018 at 10:38:09PM +0200, Sebastian Benoit wrote:
> Remi Locherer(remi.loche...@relo.ch) on 2018.09.01 21:53:21 +0200:
> > Hi,
> >
> > Since slaacd is able to use pledge in the parent process I thought it may
> > be possible for ospfd too.
> >
&
the parent process I thought it may
> > > be possible for ospfd too.
> > >
> > > It works fine until ospfd gets reloaded. At this point it uses setsockopt
> > > to set the priority filter on the routing socket.
> > >
> > > Since I could not f
On Sat, Sep 01, 2018 at 10:38:09PM +0200, Sebastian Benoit wrote:
> Remi Locherer(remi.loche...@relo.ch) on 2018.09.01 21:53:21 +0200:
> > Hi,
> >
> > Since slaacd is able to use pledge in the parent process I thought it may
> > be possible for ospfd too.
> >
&
Remi Locherer(remi.loche...@relo.ch) on 2018.09.01 21:53:21 +0200:
> Hi,
>
> Since slaacd is able to use pledge in the parent process I thought it may
> be possible for ospfd too.
>
> It works fine until ospfd gets reloaded. At this point it uses setsockopt
> to set the p
Hi,
Since slaacd is able to use pledge in the parent process I thought it may
be possible for ospfd too.
It works fine until ospfd gets reloaded. At this point it uses setsockopt
to set the priority filter on the routing socket.
Since I could not find a promise for this I extended wroute. Does
t; > > > the main process.
> > >
> > > New diff below creates the control socket in the main process and passes
> > > it
> > > to the ospf engine later on. The connect check on the control socket now
> > > happens very early.
> > >
ain process.
> > >
> > > New diff below creates the control socket in the main process and passes
> > > it
> > > to the ospf engine later on. The connect check on the control socket now
> > > happens very early.
> > >
n to
> > > pledge (stdio rpath sendfd wroute) and eventually unveil (read ospfd.conf)
> > > the main process.
> >
> > New diff below creates the control socket in the main process and passes it
> > to the ospf engine later on. The connect check on the control soc
gt; On Tue, Aug 21, 2018 at 05:54:18PM +0100, Stuart Henderson wrote:
> > > > > On 2018/08/21 17:16, Remi Locherer wrote:
> > > > > > Hi tech,
> > > > > >
> > > > > > recently we had a short outage in our network. A script st
> > On 2018/08/21 17:16, Remi Locherer wrote:
> > > > > Hi tech,
> > > > >
> > > > > recently we had a short outage in our network. A script started an
> > > > > additional
> > > > > ospfd instance because the -n flag f
> > >
> > > > recently we had a short outage in our network. A script started an
> > > > additional
> > > > ospfd instance because the -n flag for config test was missing.
> > >
> > > This is a problem with bgpd as well, last time I
script started an
> > > additional
> > > ospfd instance because the -n flag for config test was missing.
> >
> > This is a problem with bgpd as well, last time I did this it killed one of
> > the
> > *other* routers on the network (i.e. not just the one where
On Tue, Aug 21, 2018 at 05:54:18PM +0100, Stuart Henderson wrote:
> On 2018/08/21 17:16, Remi Locherer wrote:
> > Hi tech,
> >
> > recently we had a short outage in our network. A script started an
> > additional
> > ospfd instance because the -n flag for config
On Tue, Aug 21, 2018 at 05:16:47PM +0200, Remi Locherer wrote:
> Hi tech,
>
> recently we had a short outage in our network. A script started an additional
> ospfd instance because the -n flag for config test was missing.
>
> What then happend was not nice:
> - The new ospfd
1 - 100 of 242 matches
Mail list logo
