Re: How to synchronise 2 spamd instances
On Mon, Apr 22, 2019, 10:43 AM Thuban, wrote: > * Otto Moerbeek le [21-04-2019 12:49:07 +0200]: > > On Sun, Apr 21, 2019 at 09:53:52AM +, Mik J wrote: > > > > > Hello, > > > I read the man but it's not so clear to me > > > https://man.openbsd.org/spamd#SYNCHRONISATION > > > a) I chose unicast synchronisation but I don't know which port should > I open on the firewall ? > > > Is it going to use the spamd-cfg service ? > > > > It will use spamd-sync (udp port 8025) > > Good to know, I was blocking this traffic. It might be interesting to > add a word about this in the manpage, what do you think? > tcpdump -nettti pflog0 That command tells you if anything is being blocked. I normally start there. You would have seen port 8025 being blocked right away > >
crash report
Hi. I am having laptop crashes, but sendbug hangs so am using email directly. Some web page on bug reports, iirc, suggested emailing misc@ first to see if the email is OK, before sending to bugs@.., so I am sending here for feedback. Sendbug (per pstree) appears to hang in usbdevs -v. (Related ps output is below.) Related issues?: I don't know if I have unsupported hardware. I have had overheating problems (separate issue but mentioned in case this all means I need to replace the laptop; the heat issues haven't necessarily been at times I can correlate with these crashes, but somewhat ongoing). I also don't know if this issue relates to the fact that my mouse stops working anywhere from 0 to 10 days after each reboot (which has been the case I'm guessing since I installed a 6.3 snapshot probably about 1/3 of the way from 6.3 to 6.4). Maybe I need a new laptop. But I'm confident that this happens even when the laptop is cool (like, external fans on, laptop idling overnight). Could a crash be caused by having in sysctl.conf "machdep.allowaperture=1" and running X? I'd like to understand the pros/cons of that setting better than I do from reading the manual page. (My sysctl.conf contents are below.) The crash seems to never happen unless I have been running with X for at least 2 days, maybe more. My stock + syspatched 6.4 system dropped into ddb in a console, several hours after the last syspatch and reboot (the last syspatch prior to 2019-3-22), maybe at a moment when I hit "alt-tab" in X (in xfce). (X had frozen before that syspatch a couple of times recently when I hit "alt-tab", but I was able to get to a console then if memory serves. Something like this has happened maybe every several weeks over the last few months, including during times like at night when I am not using this laptop, so I don't know how to reproduce it on demand. Then it did it again several times. I have captured ddb output from a total of 3 of those; the photos of ddb info was captured before I applied the latest syspatch, but it has continued happening since. After I tried to capture the useful output from ddb, I ran "boot sync" to reboot and it just sat there as if frozen, & the laptop's disk activity light was dark. (Then when I forced a hard power cycle it had to do some automatic disk repairs, and the disk activity light was on during that.) In the 2nd set of ddg screen shots (those from the 2nd crash, on the morning of 2019-3-23), I see it reports 3 CPUs. I don't know why 3, because I had 4 before the spectre/meltdown mitigations changed it to 2 (per top activity: 4 shown, 2 seem active). Then on 2019-03-25 after I had stopped using the computer for the day, there were error messages in /var/log/message and when I checked later the computer had completely frozen with a black screen. I was running xfce but no programs outside a terminal (basically the same as in the last set of ddg screen shots' ps output plus the links browser). I read through much of the change log for 6.4->6.5, but am probably unqualified to know if one of the updates addresses this. Again, the crashes where I took photos of ddb output occurred with openbsd stable as of just prior to the March 27 security fix, but have also happened since (sorry I'm so late sending it, due to personal limitations and competing tasks). So far, I think this has only happened while X was running (using xenodm). After sending this, I think I will stop X and see if it happens over the next few days, without it. This has happened both with varying and without any setting in the /etc/malloc.conf symlink. Sorry if that is not a proper report; feedback sought. Thanks *very* much. Links to photos of ddb info from the crashes: http://lukecall.net/temp-crashInfo/1stCrash-imagesOnOnePage.html http://lukecall.net/temp-crashInfo/2ndCrash-imagesOnOnePage.html http://lukecall.net/temp-crashInfo/3rdCrash-imagesOnOnePage.html http://lukecall.net/temp-crashInfo/allImagesLinks.html http://lukecall.net/temp-crashInfo/ Luke Call - - Things I want to tell people: Free personal organizer software, & thoughts on subjects (updated 2019-03-18): http://lukecall.net (Various info dumps follow; each new section starts with a "description".) ps info of usbdevs that wouldn't exit:- USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 93325 0.0 0.0 296 1148 C0 D+12:58PM0:00.02 usbdevs root 80643 0.0 0.0 720 820 C1 Ip12:52PM0:00.00 sh -c usbdevs -v root 84565 0.0 0.0 256 1088 C1 D 12:52PM0:00.01 usbdevs -v root 8493 0.0 0.0 252 1088 C1 D 12:57PM0:00.00 usbdevs -v root 38138 0.0 0.0 720 816 C1 Ip12:57PM0:00.01 sh -c usbdevs -v root 7392 0.0 0.0 724 824 C1 Ip12:57PM0:00.01 sh -c usbdevs -v root 25561 0.0 0.0 252 1084 C1 D 12:57PM0:00.00 usbdevs -v ps auxwwj|grep usbdevs USER PID
Re: eBGP routes are not reannounced
Well it didn't work that's why I asked the question.
>From what I'm used to do with BGP it's not a redistribution it's the same BGP
>table.
Regards
Le lundi 22 avril 2019 à 20:24:49 UTC+2, Denis Fondras
a écrit :
> I don't understand how to use "allow from group"
>
Sorry, I responded too fast. You already receive the prefixes from $spamASN and
you want to redistribute them.
There is no filtering in the (old) versions you use IIRC.
> Yes I use 6.0, 6.1 and 5.8 on these machines. I'm waiting for 6.5 to be
> released and try to migrate them all.
>
> I'm used to configure Cisco devices and there's no filtering. Routes received
> by an eBGP session are reannounced to iBGP peers and next hop self should be
> used in that case.
> If that option is not used, the routes are installed in the BGP table but
> since the next hop is unreachable, they are not installed in the routing
> table.
>
> I expected my iBGP peers (site 3...) to receive the routes (spam) coming from
> the eBGP peer on site 2.
>
> It seemed to me that group was like a peer-group.
> Le lundi 22 avril 2019 à 18:32:26 UTC+2, Tom Smyth
> a écrit :
>
> Hi Mik,
>
> 1) what version of OpenBSD / OpenBGPD are you running...
> 2) if it is >6.4 OpenBSD / OpenBGPD then Claudio et all have
> implemented a new RFC for eBGP (cant remember the number)
>
> TLDR version of the new eBGP RFC is that unfiltered bgp will by
> default, deny any announcements and only announce what is explicitly
> allowed by filters added by the administrator of the BGP router...
>
> Check out Job@ & Claudio@
> *NOG videos on BGPD / OpenBGPD for more details
> (they are on youtube)
>
> I hope this helps
>
> Bon Chance :)
>
>
>
> On Mon, 22 Apr 2019 at 11:17, Mik J wrote:
> >
> > Hello,
> >
> > I'm trying to set up openbgpd.
> >
> > On site 2, I'm peering with us.bgp-spamd.net and eu.bgp-spamd.net
> > sucessfully.
> > The problem is that these routes are not in the bgp table on site 3. The
> > BGP peerings are up.
> > From site 3 I can ping 192.0.2.2/site 2. I sucessfully receive prefixes
> > announced on site 2.
> > I used next hop self on the ibgp session.Does anyone has an idea ?
> >
> > log updates
> > network 192.0.2.2/32network 10.1.1.0/24
> > myAS="65001"
> > site2="192.0.2.2"
> > site3="192.0.2.3"
> > spam_rs1="64.142.121.62" # us.bgp-spamd.net
> > spam_rs2="217.31.80.170" # eu.bgp-spamd.net
> > spamASN="65066"
> >
> > AS $myAS
> > fib-update no
> >
> > group "spam-bgp" {
> > remote-as $spamASN
> > multihop 64
> > announce none # Do not send any route updates
> > neighbor $spam_rs1
> > neighbor $spam_rs2
> > }
> >
> > group "internalnet" {
> > remote-as $myAS
> > multihop 64
> > neighbor $site3
> > local-address $site2
> > set nexthop self
> > tcp md5sig password password1234
> > }
> >
> >
>
>
> --
> Kindest regards,
> Tom Smyth.
>
>
Re: eBGP routes are not reannounced
> I don't understand how to use "allow from group"
>
Sorry, I responded too fast. You already receive the prefixes from $spamASN and
you want to redistribute them.
There is no filtering in the (old) versions you use IIRC.
> Yes I use 6.0, 6.1 and 5.8 on these machines. I'm waiting for 6.5 to be
> released and try to migrate them all.
>
> I'm used to configure Cisco devices and there's no filtering. Routes received
> by an eBGP session are reannounced to iBGP peers and next hop self should be
> used in that case.
> If that option is not used, the routes are installed in the BGP table but
> since the next hop is unreachable, they are not installed in the routing
> table.
>
> I expected my iBGP peers (site 3...) to receive the routes (spam) coming from
> the eBGP peer on site 2.
>
> It seemed to me that group was like a peer-group.
> Le lundi 22 avril 2019 à 18:32:26 UTC+2, Tom Smyth
> a écrit :
>
> Hi Mik,
>
> 1) what version of OpenBSD / OpenBGPD are you running...
> 2) if it is >6.4 OpenBSD / OpenBGPD then Claudio et all have
> implemented a new RFC for eBGP (cant remember the number)
>
> TLDR version of the new eBGP RFC is that unfiltered bgp will by
> default, deny any announcements and only announce what is explicitly
> allowed by filters added by the administrator of the BGP router...
>
> Check out Job@ & Claudio@
> *NOG videos on BGPD / OpenBGPD for more details
> (they are on youtube)
>
> I hope this helps
>
> Bon Chance :)
>
>
>
> On Mon, 22 Apr 2019 at 11:17, Mik J wrote:
> >
> > Hello,
> >
> > I'm trying to set up openbgpd.
> >
> > On site 2, I'm peering with us.bgp-spamd.net and eu.bgp-spamd.net
> > sucessfully.
> > The problem is that these routes are not in the bgp table on site 3. The
> > BGP peerings are up.
> > From site 3 I can ping 192.0.2.2/site 2. I sucessfully receive prefixes
> > announced on site 2.
> > I used next hop self on the ibgp session.Does anyone has an idea ?
> >
> > log updates
> > network 192.0.2.2/32network 10.1.1.0/24
> > myAS="65001"
> > site2="192.0.2.2"
> > site3="192.0.2.3"
> > spam_rs1="64.142.121.62" # us.bgp-spamd.net
> > spam_rs2="217.31.80.170" # eu.bgp-spamd.net
> > spamASN="65066"
> >
> > AS $myAS
> > fib-update no
> >
> > group "spam-bgp" {
> > remote-as $spamASN
> > multihop 64
> > announce none # Do not send any route updates
> > neighbor $spam_rs1
> > neighbor $spam_rs2
> > }
> >
> > group "internalnet" {
> > remote-as $myAS
> > multihop 64
> > neighbor $site3
> > local-address $site2
> > set nexthop self
> > tcp md5sig password password1234
> > }
> >
> >
>
>
> --
> Kindest regards,
> Tom Smyth.
>
>
Re: eBGP routes are not reannounced
Hello Denis, Tom,
Merci/Thank you for your answers.
I don't understand how to use "allow from group"
Yes I use 6.0, 6.1 and 5.8 on these machines. I'm waiting for 6.5 to be
released and try to migrate them all.
I'm used to configure Cisco devices and there's no filtering. Routes received
by an eBGP session are reannounced to iBGP peers and next hop self should be
used in that case.
If that option is not used, the routes are installed in the BGP table but since
the next hop is unreachable, they are not installed in the routing table.
I expected my iBGP peers (site 3...) to receive the routes (spam) coming from
the eBGP peer on site 2.
It seemed to me that group was like a peer-group.
Le lundi 22 avril 2019 à 18:32:26 UTC+2, Tom Smyth
a écrit :
Hi Mik,
1) what version of OpenBSD / OpenBGPD are you running...
2) if it is >6.4 OpenBSD / OpenBGPD then Claudio et all have
implemented a new RFC for eBGP (cant remember the number)
TLDR version of the new eBGP RFC is that unfiltered bgp will by
default, deny any announcements and only announce what is explicitly
allowed by filters added by the administrator of the BGP router...
Check out Job@ & Claudio@
*NOG videos on BGPD / OpenBGPD for more details
(they are on youtube)
I hope this helps
Bon Chance :)
On Mon, 22 Apr 2019 at 11:17, Mik J wrote:
>
> Hello,
>
> I'm trying to set up openbgpd.
>
> On site 2, I'm peering with us.bgp-spamd.net and eu.bgp-spamd.net sucessfully.
> The problem is that these routes are not in the bgp table on site 3. The BGP
> peerings are up.
> From site 3 I can ping 192.0.2.2/site 2. I sucessfully receive prefixes
> announced on site 2.
> I used next hop self on the ibgp session.Does anyone has an idea ?
>
> log updates
> network 192.0.2.2/32network 10.1.1.0/24
> myAS="65001"
> site2="192.0.2.2"
> site3="192.0.2.3"
> spam_rs1="64.142.121.62" # us.bgp-spamd.net
> spam_rs2="217.31.80.170" # eu.bgp-spamd.net
> spamASN="65066"
>
> AS $myAS
> fib-update no
>
> group "spam-bgp" {
> remote-as $spamASN
> multihop 64
> announce none # Do not send any route updates
> neighbor $spam_rs1
> neighbor $spam_rs2
> }
>
> group "internalnet" {
> remote-as $myAS
> multihop 64
> neighbor $site3
> local-address $site2
> set nexthop self
> tcp md5sig password password1234
> }
>
>
--
Kindest regards,
Tom Smyth.
Re: eBGP routes are not reannounced
Hi Mik,
1) what version of OpenBSD / OpenBGPD are you running...
2) if it is >6.4 OpenBSD / OpenBGPD then Claudio et all have
implemented a new RFC for eBGP (cant remember the number)
TLDR version of the new eBGP RFC is that unfiltered bgp will by
default, deny any announcements and only announce what is explicitly
allowed by filters added by the administrator of the BGP router...
Check out Job@ & Claudio@
*NOG videos on BGPD / OpenBGPD for more details
(they are on youtube)
I hope this helps
Bon Chance :)
On Mon, 22 Apr 2019 at 11:17, Mik J wrote:
>
> Hello,
>
> I'm trying to set up openbgpd.
>
> On site 2, I'm peering with us.bgp-spamd.net and eu.bgp-spamd.net sucessfully.
> The problem is that these routes are not in the bgp table on site 3. The BGP
> peerings are up.
> From site 3 I can ping 192.0.2.2/site 2. I sucessfully receive prefixes
> announced on site 2.
> I used next hop self on the ibgp session.Does anyone has an idea ?
>
> log updates
> network 192.0.2.2/32network 10.1.1.0/24
> myAS="65001"
> site2="192.0.2.2"
> site3="192.0.2.3"
> spam_rs1="64.142.121.62"# us.bgp-spamd.net
> spam_rs2="217.31.80.170"# eu.bgp-spamd.net
> spamASN="65066"
>
> AS $myAS
> fib-update no
>
> group "spam-bgp" {
> remote-as $spamASN
> multihop 64
> announce none # Do not send any route updates
> neighbor $spam_rs1
> neighbor $spam_rs2
> }
>
> group "internalnet" {
> remote-as $myAS
> multihop64
> neighbor$site3
> local-address $site2
> setnexthop self
> tcp md5sig password password1234
> }
>
>
--
Kindest regards,
Tom Smyth.
Re: How to synchronise 2 spamd instances
* Otto Moerbeek le [21-04-2019 12:49:07 +0200]: > On Sun, Apr 21, 2019 at 09:53:52AM +, Mik J wrote: > > > Hello, > > I read the man but it's not so clear to me > > https://man.openbsd.org/spamd#SYNCHRONISATION > > a) I chose unicast synchronisation but I don't know which port should I > > open on the firewall ? > > Is it going to use the spamd-cfg service ? > > It will use spamd-sync (udp port 8025) Good to know, I was blocking this traffic. It might be interesting to add a word about this in the manpage, what do you think?
Re: eBGP routes are not reannounced
On Mon, Apr 22, 2019 at 10:07:52AM +, Mik J wrote:
> Hello,
>
> I'm trying to set up openbgpd.
>
> On site 2, I'm peering with us.bgp-spamd.net and eu.bgp-spamd.net sucessfully.
> The problem is that these routes are not in the bgp table on site 3. The BGP
> peerings are up.
> From site 3 I can ping 192.0.2.2/site 2. I sucessfully receive prefixes
> announced on site 2.
> I used next hop self on the ibgp session.Does anyone has an idea ?
>
allow from group "spam-bgp" ?
> log updates
> network 192.0.2.2/32network 10.1.1.0/24
> myAS="65001"
> site2="192.0.2.2"
> site3="192.0.2.3"
> spam_rs1="64.142.121.62" # us.bgp-spamd.net
> spam_rs2="217.31.80.170" # eu.bgp-spamd.net
> spamASN="65066"
>
> AS $myAS
> fib-update no
>
> group "spam-bgp" {
> remote-as $spamASN
> multihop 64
> announce none # Do not send any route updates
> neighbor $spam_rs1
> neighbor $spam_rs2
> }
>
> group "internalnet" {
> remote-as $myAS
> multihop 64
> neighbor $site3
> local-address $site2
> set nexthop self
> tcp md5sig password password1234
> }
>
>
eBGP routes are not reannounced
Hello,
I'm trying to set up openbgpd.
On site 2, I'm peering with us.bgp-spamd.net and eu.bgp-spamd.net sucessfully.
The problem is that these routes are not in the bgp table on site 3. The BGP
peerings are up.
>From site 3 I can ping 192.0.2.2/site 2. I sucessfully receive prefixes
>announced on site 2.
I used next hop self on the ibgp session.Does anyone has an idea ?
log updates
network 192.0.2.2/32network 10.1.1.0/24
myAS="65001"
site2="192.0.2.2"
site3="192.0.2.3"
spam_rs1="64.142.121.62" # us.bgp-spamd.net
spam_rs2="217.31.80.170" # eu.bgp-spamd.net
spamASN="65066"
AS $myAS
fib-update no
group "spam-bgp" {
remote-as $spamASN
multihop 64
announce none # Do not send any route updates
neighbor $spam_rs1
neighbor $spam_rs2
}
group "internalnet" {
remote-as $myAS
multihop 64
neighbor $site3
local-address $site2
set nexthop self
tcp md5sig password password1234
}
Re: How to synchronise 2 spamd instances
Hello Otto, Thank you for your answer. I'm working on it right now. Regards Le dimanche 21 avril 2019 à 12:50:08 UTC+2, Otto Moerbeek a écrit : On Sun, Apr 21, 2019 at 09:53:52AM +, Mik J wrote: > Hello, > I read the man but it's not so clear to me > https://man.openbsd.org/spamd#SYNCHRONISATION > a) I chose unicast synchronisation but I don't know which port should I open > on the firewall ? > Is it going to use the spamd-cfg service ? It will use spamd-sync (udp port 8025) > > b) The synchronisation section mention a key and there's an option -K > regarding that key but in the example the -K option is not used. So it's not > clear. -K is optional. BUt if you use it, all instances syncing should use the same key. > > c) It's not clear which instance is going to contact which. Is there a > master/slave relationship ? What if one IP is WHITELIST on one instance and > BLACKLIST on the other. > Also should I use the -Y option on both instances ? Both are going to try to > start a tcp session ? It's symmetrical. All spamd's send updates to each other. No tcp involved, only udp. Specify A's IP on B and vice-versa. > > d) The message digest is calculated in md5 ? It uses a sha1 hmac message authentication code, so no md5 digest. > > e) Should I specify the -M option on all instance or just on the low priority > MX, which IP adress should I specify the one on that host or the remote MX > > Thank you Never used -M myself, but reading spamd.conf it looks like you only specify an -M IP on the host serving that IP. Note that -M is optional. -Otto
