Re: Relayd with TLS and non-TLS backends - bug

[Henry Bonath]

This specific Backend in my test lab is an IIS machine, but in
production I have OpenBSD/HAProxy in front of IIS, Apache, Tomcat,
etc.
I'm not doing anything fancy either... although the certificate in the
lab is signed by an internal CA.

Here's the relevant output from openssl s_client: The cert verifies
perfectly fine.
openssl s_client -connect 192.168.42.61:443
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-SHA384
Session-ID: C0138246D3973B3106A378C0DB503D4BCDE02C6461AB073949027C90CDCF
Session-ID-ctx:
Master-Key:
AACBE3A3E34406F9371B4E85D4DC82C177C641C94806562053C000FE0E019D2E1456702F69DECFB6D11C4B4A12A0D555
Start Time: 1593970747
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
---

and Netcat:
nc -zv 192.168.42.61 443
Connection to 192.168.42.61 443 port [tcp/https] succeeded!

On Fri, Jul 3, 2020 at 9:40 PM Daniel Jakots  wrote:
>
> On Fri, 3 Jul 2020 19:14:17 -0400, Henry Bonath 
> wrote:
>
> > Daniel,
> >
> > Thanks for taking the time to test this out.
> > I just reloaded a test machine from scratch with -current and
> > installed the HAProxy 2.0.15-4f39279 package.
> > I loaded a very basic config file, and am also seeing the same exact
> > issue on this one as well.
> > Very strange that you are not -
> > Would you mind sharing any additional details of your config file?
> > Is there anything special about the certificate you have on the
> > backend server?
> >
> > I would love to understand what is going on here and what the
> > difference is with my experience.
>
> What is your backend running? Can you connect from the haproxy host with
> nc(1) and/or openssl(1)?
>
> I try to do my stuff as vanilla as possible so it's an RSA key signed
> by LE.

Re: Relayd with TLS and non-TLS backends - bug

[Henry Bonath]

Daniel,

Thanks for taking the time to test this out.
I just reloaded a test machine from scratch with -current and
installed the HAProxy 2.0.15-4f39279 package.
I loaded a very basic config file, and am also seeing the same exact
issue on this one as well.
Very strange that you are not -
Would you mind sharing any additional details of your config file?
Is there anything special about the certificate you have on the backend server?

I would love to understand what is going on here and what the
difference is with my experience.

On Thu, Jul 2, 2020 at 4:38 PM Daniel Jakots  wrote:
>
> On Thu, 2 Jul 2020 14:00:48 -0400, Henry Bonath 
> wrote:
>
> > Note the missing Client Hello on the 6.7 machine as it jumps to
> > Application Data straight away.
> > Configuration files for HAProxy are identical on both systems.
> >
> > I'm currently spinning up a machine on -CURRENT just to see if there
> > is any difference,
> > as there is a newer version of HAProxy in packages under Snapshots.
> >
> > I was initially going to try to reach out to the package maintainer
> > for HAProxy but if this is happening in Relayd, then this "feels
> > like" a de-facto bug. I wonder if NGINX would exhibit the same
> > behavior.
> >
> > Has anyone else experienced such behavior with Load-Balancing TLS
> > Backends since upgrading to 6.7?
>
> I don't use TLS for my backend (the only backend I use nowadays is on
> localhost) so I can't speak for 6.7 (I only use -current, and when
> -current was 6.7, I didn't test that).
>
> I just tested my -current haproxy using another -current host of mine
> running nginx as a backend with TLS and it worked fine.
>
> backend https
>option forwardfor
>server web1 ln.chown.me:443 check ssl verify none
>
> and also with "verify required ca-file /etc/ssl/cert.pem"
>
>
> Maybe some libressl fix happened on -current was not deemed critical
> enough to be backported to 6.7?
>
> Cheers,
> Daniel

Re: Relayd with TLS and non-TLS backends - bug

[Henry Bonath]

I would like to chime in here and confirm that I am seeing very
similar behavior with HAProxy on OpenBSD 6.7,
I was preparing to create my own post on this issue until I saw your thread.
I too believe this is a bug.

I also get the same "Empty reply" response you get via Curl:

> GET / HTTP/1.1
> Host: haproxy.example.com
> User-Agent: curl/7.58.0
> Accept: */*
>
* TLSv1.2 (IN), TLS alert, Client hello (1):
* Empty reply from server
curl: (52) Empty reply from server

For years I have run several OpenBSD Machines with CARP Interfaces and
the HAProxy Load Balancer frontending various services.
I have always used the HAProxy version that is installed via pkg_add,
and for years this has worked out beautifully.

I have upgraded about 8 of the systems from 6.6 to 6.7 and *all* have
exhibited similar behavior when using a TLS backend.
If I switch to a non-TLS backend, it works perfectly, but this of
course breaks the end-to-end encryption that my organization requires.

I have done one further and have taken packet captures to analyze the
traffic pattern in order to try to decipher what is actually
happening,
Below is a summary of the TCP Flow:

OpenBSD 6.6 - haproxy-1.9.15:
-
OpenBSD -> Backend:443 - SYN
Backend:443 -> OpenBSD - SYN/ACK
OpenBSD -> Backend:443 - ACK
OpenBSD -> Backend:443 - TLSv1.2 Client Hello
Backend:443 -> OpenBSD - ACK
Backend:443 -> OpenBSD - ACK
OpenBSD -> Backend:443 - TLSv1.2 Server Hello
OpenBSD -> Backend:443 - ACK
OpenBSD -> Backend:443 - TLSv1.2 Client Key Exhange
<-the rest of the successful session->

OpenBSD 6.7 - haproxy-2.0.14:
-
OpenBSD -> Backend:443 - SYN
Backend:443 -> OpenBSD - SYN/ACK
OpenBSD -> Backend:443 - ACK
OpenBSD -> Backend:443 - TLSv1.2 Application Data
Backend:443 -> OpenBSD - RST/ACK

Note the missing Client Hello on the 6.7 machine as it jumps to
Application Data straight away.
Configuration files for HAProxy are identical on both systems.

I'm currently spinning up a machine on -CURRENT just to see if there
is any difference,
as there is a newer version of HAProxy in packages under Snapshots.

I was initially going to try to reach out to the package maintainer for HAProxy
but if this is happening in Relayd, then this "feels like" a de-facto bug.
I wonder if NGINX would exhibit the same behavior.

Has anyone else experienced such behavior with Load-Balancing TLS
Backends since upgrading to 6.7?


On Thu, Jun 11, 2020 at 4:27 PM Toyam Cox  wrote:
>
> Hello Misc,
>
> Full config at end of email.
>
> I've discussed the below in #openbsd on freenode, and was told to come
> here. At present, I have a setup where I need multiple unrelated
> servers under a single IP address. I used relayd to do https
> interception, read the Host header, and make decisions.
>
> The very relevant part of my config is this:
>
> forward to  port 80
> forward with tls to  port 443
>
> The order here does not matter (unlike most relayd configs, I know,
> but I've tested in my configuration and it works).
>
> When I have "with tls" on that second line, I see error lines like:
> relay web, session 3 (1 active), 0, [redacted] -> 10.0.0.102:80, TLS
> handshake error: handshake failed: error:14FFF3E7:SSL
> routines:(UNKNOWN)SSL_internal:unknown failure occurred, GET:
> Undefined error: 0
>
> and, unhelpfully, relayd responds with no response. There is no
> return. Or, as curl puts it: curl: (52) Empty reply from server
>
> When I remove "with tls" then I successfully reach the http backend,
> but since the https backend requires ssl, that connection no longer
> works. So it seems that 'with tls" affects all "forward" clauses, not
> just the one to which it's attached.
>
> I believe this to be a bug.
>
> cat >/etc/relayd.conf < table  { "10.0.0.101" }
> table  { "10.0.0.102" }
> # obviously obfuscated some values
>
> interval 5
> timeout 1000
>
> log connection
>
> http protocol web {
> return error
>
> match header set "X-Client-IP" value "$REMOTE_ADDR:$REMOTE_PORT"
> match header set "X-Forwarded-For" value "$REMOTE_ADDR"
> match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
>
> http websockets
> pass request quick header "Host" value "myhost.example.com" path
> "/Client/*" forward to 
> pass request quick header "Host" value "otherhost.example.com" forward
> to 
>
> block
> }
>
> relay web {
> listen on 10.0.0.100 port 443 tls
> protocol web
>
> forward to  port 80 check http "/webservice.asmx" code 405
> forward with tls to  port 443 check https
> "/Client/SupportedBrowsers.html" host "myhost.example.com" code 200
> }
> EOF
>

Re: Thinking of changing DNS Service provider, looking for recommendations

[Henry Bonath]

I've used Hurricane Electric's free DNS service for years now along with
their Tunnelbroker since my ISP still does not support IPv6 yet.
They also support dynamic updates which works with "ddclient" from the
OpenBSD package repo.
https://dns.he.net/


On Thu, Jan 2, 2020 at 8:25 AM Jay Hart  wrote:

> Hey all, and Happy New Years!!!
>
> I am currently using DYN.COM for DNS service. A few months back they
> changed there payment
> methodology and I am now considering finding another solution. DYN charges
> me $5 US monthly so its
> not a huge financial burden. That said, if I could find a free service
> provider, all the better.
>
> My only real requirement is they must be able to support OpenBSD based
> system.  Currently using
> DDclient. It works fine, has been for years.
>
> This would be for a residential connection.
>
> Guess what I'm really looking for, from the list, is a OpenBSD friendly
> provider, and a brief
> write up on how you are connected.  I've looked over a few sites but
> nothing stood out as being
> OpenBSD friendly.
>
> Thanks in Advance,
>
> Jay
>
>

Re: OpenBSD BFD support

[Henry Bonath]

While I cannot comment to the BFD support in OpenBSD, I can say that I have
seen
Peter Hessler around here, so hopefully he sees this and can answer your
question.

BFD would be a very nice addition to see, considering the maturity level we
are getting
to with BGPD and MPLS support.

On Wed, Nov 6, 2019 at 4:42 AM Vasco Matos  wrote:

> Hi,
>
>
> I see that a white paper was written in order to have BFD (Bidirectional
> Forwarding Detection) implemented on OpenBSD.
> However after reading the paper and try to implement it it just doesn't
> work.
> I already tried to reach the white paper writer (Peter Hessler) without
> success. Does anyone know if this is an ongoing project?
> From the Changelog "https://www.openbsd.org/plusXX.html;
>  page the only thing I can see is a
> mention on the 6.5 version but it points to a blank page
> (Reconnected bfd(4)  to the build after
> updating for sounlock() api change.)
>
> 
>
> Thanks
>
>

Re: bgplg ping/traceroute failed

[Henry Bonath]

Claudio,

Thank you - that's what I was missing.
I made the change to the fstab in order to test per Theo's recommendation
on the mount point options,
However I was not able to get it to work until I changed the owner to root.

It also sounds like Theo is recommending a separate partition, which I will
definitely do since this thing will be public-facing.

Again, I appreciate you guys taking the time to explain this to me!
-Henry

On Thu, Oct 3, 2019 at 2:56 PM Claudio Jeker 
wrote:

> On Thu, Oct 03, 2019 at 02:07:58PM -0400, Henry Bonath wrote:
> > Hello Misc,
> >
> > I had thought that I had configured the looking glass correctly per the
> man
> > page,
> > I have everything else working correctly, with custom header and footer
> > with CSS and all works great.
> > Whenever I attempt to ping/traceroute from the webpage, it simlpy
> reports:
> > "failed."
> >
> > Here is what permissions look like: (set to 4555, per the man page)
> > # ls -l /var/www/bin
> > total 3584
> > -r-xr-xr-x  1 root  bin  336016 Apr 13 16:35 bgpctl
> > -r-sr-xr-x  2 www   bin  366536 Apr 13 16:35 ping
> > -r-sr-xr-x  2 www   bin  366536 Apr 13 16:35 ping6
> > -r-sr-xr-x  2 www   bin  325320 Apr 13 16:35 traceroute
> > -r-sr-xr-x  2 www   bin  325320 Apr 13 16:35 traceroute6
>
> The ping* and traceroute* binaries need to be setuid root not setuid www.
> The root privs are needed to open the raw socket after that privs are
> dropped. Also check the mail from Theo about nosuid mount option on /var
>
> > OpenBSD version is 6.5 amd64.
> >
> > Is there anything I am missing that I would need to do in order to make
> > this work?
> > Thanks in advance!
> > -Henry
>
> --
> :wq Claudio
>

Re: bgplg ping/traceroute failed

[Henry Bonath]

Thanks Theo, that thought had briefly crossed my mind, and it looks like
you are correct!

/dev/sd0e on /var type ffs (local, nodev, nosuid)

I appreciate your quick response!
-Henry


On Thu, Oct 3, 2019 at 2:10 PM Theo de Raadt  wrote:

> Henry Bonath  wrote:
>
> > Hello Misc,
> >
> > I had thought that I had configured the looking glass correctly per the
> man
> > page,
> > I have everything else working correctly, with custom header and footer
> > with CSS and all works great.
> > Whenever I attempt to ping/traceroute from the webpage, it simlpy
> reports:
> > "failed."
> >
> > Here is what permissions look like: (set to 4555, per the man page)
> > # ls -l /var/www/bin
> > total 3584
> > -r-xr-xr-x  1 root  bin  336016 Apr 13 16:35 bgpctl
> > -r-sr-xr-x  2 www   bin  366536 Apr 13 16:35 ping
> > -r-sr-xr-x  2 www   bin  366536 Apr 13 16:35 ping6
> > -r-sr-xr-x  2 www   bin  325320 Apr 13 16:35 traceroute
> > -r-sr-xr-x  2 www   bin  325320 Apr 13 16:35 traceroute6
> >
> > OpenBSD version is 6.5 amd64.
> >
> > Is there anything I am missing that I would need to do in order to make
> > this work?
>
> Those setuid binaries require a filesystem which is mounted correctly.
>
> Cannot have the options "noexec, nosuid"
>
> btw, those setuid binaries are heavily priv-drop.  But to avoid having
> the entire filesystem outside of this dir open, you could consider
> making just this directory it's own mini filesystem, it's just an
> extra bit of containment.
>

bgplg ping/traceroute failed

[Henry Bonath]

Hello Misc,

I had thought that I had configured the looking glass correctly per the man
page,
I have everything else working correctly, with custom header and footer
with CSS and all works great.
Whenever I attempt to ping/traceroute from the webpage, it simlpy reports:
"failed."

Here is what permissions look like: (set to 4555, per the man page)
# ls -l /var/www/bin
total 3584
-r-xr-xr-x  1 root  bin  336016 Apr 13 16:35 bgpctl
-r-sr-xr-x  2 www   bin  366536 Apr 13 16:35 ping
-r-sr-xr-x  2 www   bin  366536 Apr 13 16:35 ping6
-r-sr-xr-x  2 www   bin  325320 Apr 13 16:35 traceroute
-r-sr-xr-x  2 www   bin  325320 Apr 13 16:35 traceroute6

OpenBSD version is 6.5 amd64.

Is there anything I am missing that I would need to do in order to make
this work?
Thanks in advance!
-Henry

Re: ospf point to point network

[Henry Bonath]

I merely was giving an example of what *could* be done - not
necessarily of what *should* be done ;-)

On Sun, Jun 23, 2019 at 12:40 PM Stuart Henderson  wrote:
>
> On 2019-06-22, Henry Bonath  wrote:
> > What about GRE(4) with a Cisco router on the other end?
> >
> > /etc/hostname.gre123:
> > 1.1.1.1 1.1.1.2 netmask 255.255.255.252 up
> > tunnel   IP.OF.OB.SD   IP.OF.I.OS
> >
> > Cisco IOS:
> > !
> > interface Tunnel123
> >  ip address 1.1.1.2 255.255.255.252
> >  tunnel source GigabitEthernet0/0/1
> >  tunnel destination IP.OF.OB.SD
> >  tunnel mode gre
> > !
>
> That's likely to work, at the expense of reduced MTU. But is it really
> worth it? The main problem with ethernet interfaces and ospfd was a bug
> with DR elections but that has been fixed for a while now.
>
>

Re: ospf point to point network

[Henry Bonath]

What about GRE(4) with a Cisco router on the other end?

/etc/hostname.gre123:
1.1.1.1 1.1.1.2 netmask 255.255.255.252 up
tunnel   IP.OF.OB.SD   IP.OF.I.OS

Cisco IOS:
!
interface Tunnel123
 ip address 1.1.1.2 255.255.255.252
 tunnel source GigabitEthernet0/0/1
 tunnel destination IP.OF.OB.SD
 tunnel mode gre
!

On Fri, Jun 21, 2019 at 3:37 PM Kapetanakis Giannis
 wrote:
>
> On 21/06/2019 20:30, Stuart Henderson wrote:
> > On 2019-06-21, Kapetanakis Giannis  wrote:
> >> Hi,
> >>
> >> Can I get an update if point to point network support has been added in 
> >> ospfd?
> >>
> >> Thanks
> >>
> >> G
> >>
> >>
> >>
> >> On 19/12/2014 12:54, Kapetanakis Giannis wrote:
> >>> On 18/12/14 22:38, Stuart Henderson wrote:
>  On 2014-12-17, Kapetanakis Giannis  wrote:
> > Hi,
> >
> > I'd like to ask if point-to-point support has been added in ospfd.
> >
> > I've read this
> > http://marc.info/?l=openbsd-misc=136580208222751=2
> >
> > but I cant seem to find relevant entries in the source tree so probably
> > is still out?
> >
> > regards,
> >
> > Giannis
> >
> >
>  No, diff didn't work so it wasn't added.
> 
> >>> Thanks for the update.
> >>>
> >>> G
> >>>
> >>
> > Nothing changed in that respect. (For the benefit of the archives and
> > readers unfamiliar with the situation, point to point works fine on
> > a point-to-point interface, this is about ospfd pretending that an
> > ethernet interface is "point to point").
> >
> > That is likely something that would be added to release notes if
> > it was added.
> >
> >
>
> Thanks for the reply Stuart.
>
> Is there any "hack" I can do with all those pseudo-interfaces available
> in OB to full ospfd and do p2p?
>
> For instance ifconfig(8) has ptp options for bridge.
>
> A fellow reader of misc@ proposed gif(4), but my other end is a cisco
> router.
>
> best,
>
> G
>

MPLS mpe0 Throughput

[Henry Bonath]

Hello,
I have recently (within the past few months) turned up an MPLS PE on a
1Gbps link in a L3VPN configuration with BGP and RDomains.
I'm seeing some strange throughput numbers that I am seeking to get
some help understanding.

Now I am currently running OpenBSD 6.4 on the particular PE, and I
realize that 6.5 has several MPLS updates and fixes, I have a
maintenance window scheduled in a couple weeks where I'll be upgrading
this particular system.

Here's what I am seeing, with iperf:
on flows that ingress the MPE interface I see around 750-900Mbps @~20k pps.
for flows that egress the MPE interface, I see around 200Mbps @ ~2k pps.

I realize that things like "throughput" are highly variable, but as I
troubleshoot this - I am looking better understanding how and what is
at play within OpenBSD itself, be it CPU limitations, etc. as I
haven't ruled out the rest of the infrastructure at this point.

Thanks for any insight you can provide.

Re: Modern browser for OpenBSD powerpc

[Henry Bonath]

Here's my build info for 6.5 PowerPC:

pkg list:
autoconf--%2.13
dbus-glib--
g++--%4.9
gcc--%4.9
gmake--
python--%2.7
py-pip--
yasm--
unzip--
zip--

And my .mozconfig:
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.

export CC="egcc -O3 -mcpu=7450 -mtune=7450 -maltivec -mabi=altivec
-falign-loops=16 -falign-functions=16 -falign-labels=16
-falign-jumps=16"
export CXX="eg++ -fpermissive -O3 -mcpu=7450 -mtune=7450 -maltivec
-mabi=altivec -falign-loops=16 -falign-functions=16 -falign-labels=16
-falign-jumps=16"

mk_add_options MOZ_OBJDIR=/usr/local/src/afbuild/
mk_add_options MOZ_MAKE_FLAGS="-s -j2"

ac_add_options --disable-crashreporter
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-updater
ac_add_options --enable-mozril-geoloc
ac_add_options --disable-webrtc
ac_add_options --disable-safe-browsing
ac_add_options --disable-parental-controls
ac_add_options --enable-release
ac_add_options --disable-necko-wifi
ac_add_options --disable-eme
ac_add_options --disable-gamepad
ac_add_options --enable-dbus
ac_add_options --disable-gio
ac_add_options --disable-pulseaudio
ac_add_options --enable-strip
ac_add_options --enable-install-strip
ac_add_options --enable-application=browser
ac_add_options --with-branding=browser/branding/arcticfox
ac_add_options --enable-optimize="-O2"

After about 11 hours, the build failed, I *think* it was my machine as
I got the error about Virtual memory exhausted..
(I attempted on a Powerbook G4 w/512MB of RAM)
I have some XServe G5's around here somewhere, I might load one of
those up to see if I can get it to build on that.

615:35.21 Unified_cpp_gfx_layers3.o
626:10.04 Unified_cpp_gfx_layers4.o
660:32.77 Unified_cpp_gfx_layers5.o
672:05.93 Unified_cpp_layout_base2.o
689:29.56 virtual memory exhausted: Cannot allocate memory
689:32.64
689:32.79 In the directory  /usr/local/src/afbuild/layout/base
689:32.83 The following command failed to execute properly:
689:32.89 eg++ -fpermissive -O3 -mcpu=7450 -mtune=7450 -maltivec
-mabi=altivec -falign-loops=16 -falign-functions=16 -falign-labels=16
-falign-jumps=16 -o Unified_cpp_layout_base1.o -c
-I../../dist/stl_wrappers -I../../dist/system_wrappers -include
/usr/src/Arctic-Fox/config/gcc_hidden.h -DOS_POSIX=1 -DOS_BSD=1
-DOS_OPENBSD=1 -DSTATIC_EXPORTABLE_JS_API -DMOZILLA_INTERNAL_API
-DIMPL_LIBXUL -DMOZ_GLUE_IN_PROGRAM -DAB_CD=en-US -DNO_NSPR_10_SUPPORT
-I/usr/src/Arctic-Fox/layout/base -I.
-I/usr/local/src/afbuild/ipc/ipdl/_ipdlheaders
-I/usr/src/Arctic-Fox/ipc/chromium/src -I/usr/src/Arctic-Fox/ipc/glue
-I/usr/src/Arctic-Fox/layout/base/../forms
-I/usr/src/Arctic-Fox/layout/base/../generic
-I/usr/src/Arctic-Fox/layout/base/../mathml
-I/usr/src/Arctic-Fox/layout/base/../printing
-I/usr/src/Arctic-Fox/layout/base/../style
-I/usr/src/Arctic-Fox/layout/base/../svg
-I/usr/src/Arctic-Fox/layout/base/../tables
-I/usr/src/Arctic-Fox/layout/base/../xul
-I/usr/src/Arctic-Fox/layout/base/../xul/tree/
-I/usr/src/Arctic-Fox/docshell/base -I/usr/src/Arctic-Fox/dom/base
-I/usr/src/Arctic-Fox/dom/html -I/usr/src/Arctic-Fox/dom/svg
-I/usr/src/Arctic-Fox/dom/xbl -I/usr/src/Arctic-Fox/view
-I../../dist/include -I/usr/local/src/afbuild/dist/include/nspr
-I/usr/local/src/afbuild/dist/include/nss -fPIC -I/usr/X11R6/include
-DMOZILLA_CLIENT -include ../../mozilla-config.h -MD -MP -MF
.deps/Unified_cpp_layout_base1.o.pp -I/usr/X11R6/include -Wall
-Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings
-Wno-invalid-offsetof -Wcast-align -fno-exceptions
-fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections
-fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG
-DTRIMMED -g -O2 -fomit-frame-pointer
-I/usr/local/src/afbuild/dist/include/cairo -I/usr/X11R6/include
/usr/local/src/afbuild/layout/base/Unified_cpp_layout_base1.cpp
689:33.53 gmake[5]: *** [/usr/src/Arctic-Fox/config/rules.mk:937:
Unified_cpp_layout_base1.o] Error 1
689:34.56 gmake[4]: *** [/usr/src/Arctic-Fox/config/recurse.mk:74:
layout/base/target] Error 2
689:34.91 gmake[4]: *** Waiting for unfinished jobs
690:26.32 In file included from
/usr/local/src/afbuild/gfx/layers/Unified_cpp_gfx_layers5.cpp:74:0:
690:26.38 /usr/src/Arctic-Fox/gfx/layers/opengl/CompositorOGL.cpp: In
member function 'virtual bool
mozilla::layers::CompositorOGL::Initialize()':
690:27.25 Warning: -Wunused-variable in
/usr/src/Arctic-Fox/gfx/layers/opengl/CompositorOGL.cpp: unused
variable 'force'
690:27.31 /usr/src/Arctic-Fox/gfx/layers/opengl/CompositorOGL.cpp:209:8:
warning: unused variable 'force' [-Wunused-variable]
690:27.31bool force = gfxPrefs::LayersAccelerationForceEnabled();
690:27.33 ^
701:40.90 libgfx_layers.a.desc
701:43.20 gmake[3]: *** [/usr/src/Arctic-Fox/config/recurse.mk:37:
compile] Error 2
701:43.35 gmake[2]: *** [/usr/src/Arctic-Fox/config/rules.mk:541:
default] Error 2

Re: NSD & Unbound refusing to bind to IPv6 when anycast flag set ?

[Henry Bonath]

To chime in here, how I have always implemented Anycast DNS
is by creating additional Loopback adapters in the OS, and then
using BGP or OSPF to distribute said Loopback IPs into a routing
table.

Each DNS server participating in Anycast would have the same
IPv4 and IPv6 address configured on that loopback adapter.

e.g:
/etc/hostname.lo1:
inet 192.0.2.53/32
inet6 2001:db8:dead:beef::53/128

/etc/ospfd.conf and /etc/ospf6d.conf:
router-id 192.0.2.53
fib-update no
stub router yes

auth-type crypt
auth-md 1 "mysecretkey"
auth-md-keyid 1

area 0.0.0.0 {
interface em0
interface lo1 {
passive
}
}


Aside from that, I also believe that if you are going by the old RFCs
The "0" address is reserved as the anycast, so you would have to use
2001:db8:dead:beef::/128 in that case.

On Fri, May 17, 2019 at 8:21 AM Stuart Henderson  wrote:
>
> On 2019/05/16 23:37, Rachel Roch wrote:
> >
> >
> > > RFC3513 says this:
> > >
> > >  o An anycast address must not be used as the source address of
> > >  an IPv6 packet.
> > >
> > >  o An anycast address must not be assigned to an IPv6 host, that
> > >  is, it may be assigned to an IPv6 router only.
> > >
> > > And to help ensure this, the kernel denies binding to an address marked
> > > with the anycast flag (see netinet6/in6_pcb.c).
> > >
> > > This was obsoleted by RFC4291, including this change:
> > >
> > >  o The restrictions on using IPv6 anycast addresses were removed because
> > >  there is now sufficient experience with the use of anycast addresses,
> > >  the issues are not specific to IPv6, and the GROW working group is
> > >  working in this area.
> > >
> > > So I think this restriction can now be removed, at least with this
> > > change, but more might be needed
> > >
> >
> > Certainly in my case the current OpenBSD situation represents a bit too 
> > much "nanny knows best".
>
> No, it represents "following the (old) RFCs".
>
> > My use-case is anycast DNS with NSD and Unbound.
> >
> > Both NSD and unbound provide config parameters that allow distinguishing 
> > between listen address and source address.
> >
> > But then again, is there any real reason to use the anycast flag ?  To make 
> > NSD and unbound work I reconfigured to remove the anycast flag from IPv6 
> > addresses and nothing seems broken ?
> >
>
> If you are doing a typical "internet anycast services" setup with some
> routing protocol announcing the anycasted address then I don't see a use
> for the flag, AFAICT it was mostly in conjunction with using an anycast
> address for a local router, it feels like the usual IPv6 overengineering
> to me..
>

Re: 6.5 PowerPC Packages

[Henry Bonath]

Awesome! Thank you for the status update.

On Sun, May 12, 2019 at 6:33 PM Christian Weisgerber  wrote:
>
> On 2019-05-09, Christian Weisgerber  wrote:
>
> > The build has been running for 25 days so far, across two machines,
> > and the packages will be uploaded once they are finished.
>
> I just signed the packages.  They'll become available in a day or so.
>
> --
> Christian "naddy" Weisgerber  na...@mips.inka.de
>

Re: 6.5 PowerPC Packages

[Henry Bonath]

Only if said trailer is Delorean-shaped.

On Thu, May 9, 2019 at 3:43 PM Edgar Pettijohn  wrote:
>
>
> On May 9, 2019 10:41 AM, danieljb...@icloud.com wrote:
> >
> > On Thu, May 09, 2019 at 08:55:40AM -0600, Theo de Raadt wrote:
> > > The real reason is because we're low on current for the flux capacitor,
> > > after shifting time for the early 6.5 release.  Not all the machines
> > > were able to fit into back seat of the Delorian.
> > >
> >
> > Come on Theo, everybody knows that you can't run a flux capacitor
> > without 1.21 gigawatts. Great Scott
> >
>
> Perhaps we can get a trailer to pull behind the delorian so we can fit all of 
> the machines.
>

Re: 6.5 PowerPC Packages

[Henry Bonath]

That's good to know, thank you for sharing how the process works.
My initial question was more of a curiosity than anything else.
It's 100% understandable that these things take time, especially on
older hardware.
The early release of 6.5 was a nice surprise for sure! Thanks again!

On Thu, May 9, 2019 at 10:53 AM Christian Weisgerber  wrote:
>
> On 2019-05-09, Henry Bonath  wrote:
>
> > I'm not sure how many folks out there are PowerPC users, but I was
> > just curious if anyone had an idea on if or when we might see those
> > out in the mirrors.
>
> The build has been running for 25 days so far, across two machines,
> and the packages will be uploaded once they are finished.
>
> There are two ways to go about this: We can delay the release until
> all architectures have finished building, or we can start releasing
> once the fast & popular archs are ready and the others will catch
> up eventually.
>
> --
> Christian "naddy" Weisgerber  na...@mips.inka.de
>

Re: 6.5 PowerPC Packages

[Henry Bonath]

I figured that was the case, I suppose I was a little afraid that they
weren't coming!

On Thu, May 9, 2019 at 9:35 AM Tom Smyth  wrote:
>
> Hi Henry,
>
> it takes a while to build all the packages on PowerPC ...  IIRC
> so it will take a while AFAIK
>
> Thanks
>
> On Thu, 9 May 2019 at 14:34, Henry Bonath  wrote:
> >
> > I'm not sure how many folks out there are PowerPC users, but I was
> > just curious if anyone had an idea on if or when we might see those
> > out in the mirrors.
> >
> > I also suppose in the same vein, I could be learning how to pull the
> > ports tree and build what I need that way :-)
> >
> > Thanks!
> >
>
>
> --
> Kindest regards,
> Tom Smyth.

6.5 PowerPC Packages

[Henry Bonath]

I'm not sure how many folks out there are PowerPC users, but I was
just curious if anyone had an idea on if or when we might see those
out in the mirrors.

I also suppose in the same vein, I could be learning how to pull the
ports tree and build what I need that way :-)

Thanks!

Re: When will be created a great desktop experience for OpenBSD?

[Henry Bonath]

I'll respond directly here as I recognize you from another mailing
list we both are on :-)

This is *my* desktop of choice on OpenBSD:
https://sourceforge.net/p/cdesktopenv/wiki/OpenBSDBuild/

Why mess with something less tried or true?

On Tue, May 7, 2019 at 8:19 AM Christopher Turkel
 wrote:
>
> This is a webpage I used to install Xfce.
> https://sohcahtoa.org.uk/openbsd.html
>
> On Tue, May 7, 2019 at 6:22 AM John Long  wrote:
>
> > On Tue, 7 May 2019 08:47:18 +0200
> > Denis Fondras  wrote:
> >
> > > > user-friendly and easy-to-use
> > > >
> > >
> > > Sounds like the exact description of current OpenBSD...
> >
> > +100
> >
> > This is exactly why I like and use it.
> >
> >

Re: Controlling OSPFD based on HAProxy state

[Henry Bonath]

Thanks! I can give that a try, I haven't done much with Relayd yet at
this point -
I know that it can do some of what HAProxy is doing for me. (Maybe all of what
HAProxy is doing?) I just need to take the time to figure it out :-)



On Wed, Apr 24, 2019 at 7:53 PM David Gwynne  wrote:
>
> I've used relayd to insert routes to a service based on a health check, and 
> then had ospfd advertise those routes.  That might be good enough for you.
>
> On Fri., 19 Apr. 2019, 00:40 Henry Bonath,  wrote:
>>
>> Does anyone suggest any clever way of controlling OSPFD based on the
>> status of an HAProxy process?
>>
>> I like to use OSPFD to advertise /32 loopback IPs which HAProxy binds
>> to for anycasted highly-available Reverse Proxy/Load Balancer
>> services.
>>
>> This works great if the whole box goes down, as OSPF would no longer
>> be advertising from that site, but if the HAProxy process fails for
>> some reason, then it just goes down as the IP will stay in the OSPF
>> table.
>>
>> I know there are tools like monit or supervisord which may help with
>> this, but I wanted to see if anyone here may have any ideas on how to
>> achieve this that I may be overlooking.
>>
>> Thanks!
>> -Henry
>>

Controlling OSPFD based on HAProxy state

[Henry Bonath]

Does anyone suggest any clever way of controlling OSPFD based on the
status of an HAProxy process?

I like to use OSPFD to advertise /32 loopback IPs which HAProxy binds
to for anycasted highly-available Reverse Proxy/Load Balancer
services.

This works great if the whole box goes down, as OSPF would no longer
be advertising from that site, but if the HAProxy process fails for
some reason, then it just goes down as the IP will stay in the OSPF
table.

I know there are tools like monit or supervisord which may help with
this, but I wanted to see if anyone here may have any ideas on how to
achieve this that I may be overlooking.

Thanks!
-Henry

Re: Reflected IBGP VPNv4 Routes overstaying their welcome

[Henry Bonath]

Thanks Claudio, I was hoping you would see this.

I know that you guys fixed some other MPLS bugs as I was affected by
the LDP/ARP issue as well.
I have one PE running -current that I confirmed was no longer getting
the LDP drops/crashes
but I have not tested this against it as I just discovered it.

I'll spin up some test machines and report back what I find out.

-Henry

On Tue, Apr 9, 2019 at 5:48 AM Claudio Jeker  wrote:
>
> On Mon, Apr 08, 2019 at 05:08:32PM -0400, Henry Bonath wrote:
> > Hello, I am seeing some BGP VPNv4 routes staying populated in
> > the RIB of route-reflector clients even after dropping the originating 
> > neighbor.
> >
> > I'm on OpenBSD 6.4, running MPLS L3VPN.
> >
> > I have 2 IBGP route-reflectors, both OpenBSD 6.4.
> > I run OSPF to distribute Loopbacks into an Area (100)
> > We run Cisco devices for our Provider Edge installed on site at
> > Customer Premise.
> > All MPLS PE devices neighbor with both route reflectors.
> >
> > My bgpd.conf from the route reflectors:
> > ===
> > ASN="64670"
> >
> > # global configuration
> > AS $ASN
> > router-id 172.16.16.212
> > nexthop qualify via default
> >
> > group "IBGP" {
> > remote-as $ASN
> > announce IPv4 vpn
> > route-reflector 172.16.16.212
> > local-address 172.16.16.212
> > neighbor 100.92.64.0/18 {
> > }
> >
> > }
> >
> > # IBGP: allow all updates to and from our IBGP neighbors
> > allow from any
> > allow to any
> > ===
> >
> > bgpd.conf from an OpenBSD PE:
> > ===
> > ASN="64670"
> >
> > # global configuration
> > AS $ASN
> > router-id 100.92.127.121
> >
> > rdomain 2 {
> > rd 64670:37
> > import-target rt 64670:37
> > export-target rt 64670:37
> > # advertise summary of tenant Subnet:
> > network 172.29.21.0/24
> >
> > # Redistribute from OSPF (Priority 32)
> > network inet priority 32
> > depend on mpe1
> > }
> >
> > group "IBGP" {
> > remote-as $ASN
> > announce IPv4 vpn
> > set rtlabel FROM_BGP
> > local-address 100.92.127.121
> > neighbor 172.16.16.211 {
> > descr "bgp-rr-01"
> > }
> > neighbor 172.16.16.212 {
> > descr "bgp-rr-02"
> > }
> >
> > }
> >
> > # IBGP: allow all updates to and from our IBGP neighbors
> > allow from ibgp
> > allow to ibgp
> >
> > ===
> >
> > The problem comes if I shutdown one of my Premise equipment PE
> > devices, or an OpenBSD PE,
> > on the other OpenBSD PEs that remain up, they still show the routes
> > that were advertised by the
> > now shutdown device.
> >
> > If I log into a route reflector and run a "bgpctl show rib" those
> > routes are no longer there as i expected,
> > though they persist at the OpenBSD reflector clients.
> >
> > Example output after shutting down the 100.92.127.21 Cisco PE observed
> > from the OpenBSD PE
> > that is listening to 64670:37 rt/rd:
> >
> > flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
> >S = Stale, E = Error
> > origin validation state: N = not-found, V = valid, ! = invalid
> > origin: i = IGP, e = EGP, ? = Incomplete
> >
> > flags ovs destination  gateway  lpref   med aspath origin
> > I*> N rd 64670:37 192.168.11.0/24 100.92.127.21  100 2 ?
> > I*  N rd 64670:37 192.168.11.0/24 100.92.127.21  100 2 ?
> > I*> N rd 64670:37 192.168.15.0/24 100.92.127.21  100 2 ?
> > I*  N rd 64670:37 192.168.15.0/24 100.92.127.21  100 2 ?
> > I*> N rd 64670:37 192.168.20.0/24 100.92.127.21  100 3 ?
> > I*  N rd 64670:37 192.168.20.0/24 100.92.127.21  100 3 ?
> > I*> N rd 64670:37 192.168.100.0/24 100.92.127.21  100 2 ?
> > I*  N rd 64670:37 192.168.100.0/24 100.92.127.21  100 2 ?
> > I*> N rd 64670:37 192.168.110.0/24 100.92.127.21  100 3 ?
> > I*  N rd 64670:37 192.168.110.0/24 100.92.127.21  100 3 ?
> > I*> N rd 64670:37 192.168.150.0/24 100.92.127.21  100 2 ?
> > I*  N rd 64670:37 192.168.150.0/24 100.92.127.21  100 2 ?
> > I*> N rd 64670:37 192.168.200.0/24 100.92.127.21  100 2 ?
> > I*  N rd 64670:37 192.168.200.0/24 100.92.127.21  100 2 ?
> >
> > Shouldn't those routes disappear once the 100.92.127.21 router is shutdown?
> >
> > Thanks for any help you all  have to offer!
>
> Are you able to test this with -current? There were some fixes and changes
> done for MPLS VPN support. I have the feeling that this may be already
> fixed. Also I would desiable gracefull restart on the RR with 'announce
> restart no' for the template.
>
> --
> :wq Claudio
>

Re: Reflected IBGP VPNv4 Routes overstaying their welcome

[Henry Bonath]

So in today's case, I went into the Cisco BGP process and did a "neighbor
x.x.x.x shutdown"
>From there the OpenBSD route-reflector removed the routes from those
neighbors from the rib.
The other OpenBSD route-reflector clients however kept those routes around.

This was first noticed on Friday, when I changed peering interfaces on
PE-CE, which re-ran LDP against the OSPF routes,
but those routes never made it back to my PE in the Datacenter, and the
Customer's network was down while
I troubleshooted. I think I need to do some more testing and data gathering
and perhaps send a bug report
if my configs look good there. I would just think that if the PE withdrew
the route from the route-reflector, that
the reflector clients would remove the routes as well...

On Mon, Apr 8, 2019 at 5:29 PM Tom Smyth 
wrote:

> Hi Henry,
>
> How long are you leaving the sessions down for  on the PE router ?
> are you leaving the sessions down past the hold time value on the neigbour
> of the router that you are shutting down.
> are you doing a graceful shutdown?
> or are you simply rebooting the neigbour
> if im not mistaken  I dont think the neighbour would withdraw the
> routes until the
> hold time has expired ...
> im subject to correction on this one... but it is the behaviour I have
> empirically observed
> on the bgp routers that i manage
> I hope this helps
> Tom Smyth
>
>
>
>
>
> On Mon, 8 Apr 2019 at 22:11, Henry Bonath  wrote:
> >
> > Hello, I am seeing some BGP VPNv4 routes staying populated in
> > the RIB of route-reflector clients even after dropping the originating
> neighbor.
> >
> > I'm on OpenBSD 6.4, running MPLS L3VPN.
> >
> > I have 2 IBGP route-reflectors, both OpenBSD 6.4.
> > I run OSPF to distribute Loopbacks into an Area (100)
> > We run Cisco devices for our Provider Edge installed on site at
> > Customer Premise.
> > All MPLS PE devices neighbor with both route reflectors.
> >
> > My bgpd.conf from the route reflectors:
> > ===
> > ASN="64670"
> >
> > # global configuration
> > AS $ASN
> > router-id 172.16.16.212
> > nexthop qualify via default
> >
> > group "IBGP" {
> > remote-as $ASN
> > announce IPv4 vpn
> > route-reflector 172.16.16.212
> > local-address 172.16.16.212
> > neighbor 100.92.64.0/18 {
> > }
> >
> > }
> >
> > # IBGP: allow all updates to and from our IBGP neighbors
> > allow from any
> > allow to any
> > ===
> >
> > bgpd.conf from an OpenBSD PE:
> > ===
> > ASN="64670"
> >
> > # global configuration
> > AS $ASN
> > router-id 100.92.127.121
> >
> > rdomain 2 {
> > rd 64670:37
> > import-target rt 64670:37
> > export-target rt 64670:37
> > # advertise summary of tenant Subnet:
> > network 172.29.21.0/24
> >
> > # Redistribute from OSPF (Priority 32)
> > network inet priority 32
> > depend on mpe1
> > }
> >
> > group "IBGP" {
> > remote-as $ASN
> > announce IPv4 vpn
> > set rtlabel FROM_BGP
> > local-address 100.92.127.121
> > neighbor 172.16.16.211 {
> > descr "bgp-rr-01"
> > }
> > neighbor 172.16.16.212 {
> > descr "bgp-rr-02"
> > }
> >
> > }
> >
> > # IBGP: allow all updates to and from our IBGP neighbors
> > allow from ibgp
> > allow to ibgp
> >
> > ===
> >
> > The problem comes if I shutdown one of my Premise equipment PE
> > devices, or an OpenBSD PE,
> > on the other OpenBSD PEs that remain up, they still show the routes
> > that were advertised by the
> > now shutdown device.
> >
> > If I log into a route reflector and run a "bgpctl show rib" those
> > routes are no longer there as i expected,
> > though they persist at the OpenBSD reflector clients.
> >
> > Example output after shutting down the 100.92.127.21 Cisco PE observed
> > from the OpenBSD PE
> > that is listening to 64670:37 rt/rd:
> >
> > flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
> >S = Stale, E = Error
> > origin validation state: N = not-found, V = valid, ! = invalid
> > origin: i = IGP, e

Reflected IBGP VPNv4 Routes overstaying their welcome

[Henry Bonath]

Hello, I am seeing some BGP VPNv4 routes staying populated in
the RIB of route-reflector clients even after dropping the originating neighbor.

I'm on OpenBSD 6.4, running MPLS L3VPN.

I have 2 IBGP route-reflectors, both OpenBSD 6.4.
I run OSPF to distribute Loopbacks into an Area (100)
We run Cisco devices for our Provider Edge installed on site at
Customer Premise.
All MPLS PE devices neighbor with both route reflectors.

My bgpd.conf from the route reflectors:
===
ASN="64670"

# global configuration
AS $ASN
router-id 172.16.16.212
nexthop qualify via default

group "IBGP" {
remote-as $ASN
announce IPv4 vpn
route-reflector 172.16.16.212
local-address 172.16.16.212
neighbor 100.92.64.0/18 {
}

}

# IBGP: allow all updates to and from our IBGP neighbors
allow from any
allow to any
===

bgpd.conf from an OpenBSD PE:
===
ASN="64670"

# global configuration
AS $ASN
router-id 100.92.127.121

rdomain 2 {
rd 64670:37
import-target rt 64670:37
export-target rt 64670:37
# advertise summary of tenant Subnet:
network 172.29.21.0/24

# Redistribute from OSPF (Priority 32)
network inet priority 32
depend on mpe1
}

group "IBGP" {
remote-as $ASN
announce IPv4 vpn
set rtlabel FROM_BGP
local-address 100.92.127.121
neighbor 172.16.16.211 {
descr "bgp-rr-01"
}
neighbor 172.16.16.212 {
descr "bgp-rr-02"
}

}

# IBGP: allow all updates to and from our IBGP neighbors
allow from ibgp
allow to ibgp

===

The problem comes if I shutdown one of my Premise equipment PE
devices, or an OpenBSD PE,
on the other OpenBSD PEs that remain up, they still show the routes
that were advertised by the
now shutdown device.

If I log into a route reflector and run a "bgpctl show rib" those
routes are no longer there as i expected,
though they persist at the OpenBSD reflector clients.

Example output after shutting down the 100.92.127.21 Cisco PE observed
from the OpenBSD PE
that is listening to 64670:37 rt/rd:

flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
   S = Stale, E = Error
origin validation state: N = not-found, V = valid, ! = invalid
origin: i = IGP, e = EGP, ? = Incomplete

flags ovs destination  gateway  lpref   med aspath origin
I*> N rd 64670:37 192.168.11.0/24 100.92.127.21  100 2 ?
I*  N rd 64670:37 192.168.11.0/24 100.92.127.21  100 2 ?
I*> N rd 64670:37 192.168.15.0/24 100.92.127.21  100 2 ?
I*  N rd 64670:37 192.168.15.0/24 100.92.127.21  100 2 ?
I*> N rd 64670:37 192.168.20.0/24 100.92.127.21  100 3 ?
I*  N rd 64670:37 192.168.20.0/24 100.92.127.21  100 3 ?
I*> N rd 64670:37 192.168.100.0/24 100.92.127.21  100 2 ?
I*  N rd 64670:37 192.168.100.0/24 100.92.127.21  100 2 ?
I*> N rd 64670:37 192.168.110.0/24 100.92.127.21  100 3 ?
I*  N rd 64670:37 192.168.110.0/24 100.92.127.21  100 3 ?
I*> N rd 64670:37 192.168.150.0/24 100.92.127.21  100 2 ?
I*  N rd 64670:37 192.168.150.0/24 100.92.127.21  100 2 ?
I*> N rd 64670:37 192.168.200.0/24 100.92.127.21  100 2 ?
I*  N rd 64670:37 192.168.200.0/24 100.92.127.21  100 2 ?

Shouldn't those routes disappear once the 100.92.127.21 router is shutdown?

Thanks for any help you all  have to offer!
-Henry

Re: ARP issues when using ldpd and MPLS pseudowires

[Henry Bonath]

I just wanted to circle back to this, I have had some test machines running
for the past week, and they have kept their LDP neighbors up the entire
time.
The only ones still with issues are the un-patched 6.4 systems, which I
will upgrade once 6.5 is released.

Thanks Adrian and Thanks DLG!
I love this community!

On Tue, Apr 2, 2019 at 12:24 AM Adrian Close 
wrote:

> Hi Henry,
>
> Le 02/04/2019 13:39, Henry Bonath a écrit :
> > It looks like a patch may have been produced, but I do not know how to
> test
> > it. I'm not sure if I can pull down just a small part of the
> > OpenBSD source, or if the entire OS should be built. (Although I'd love
> to
> > learn how to do this)
> Yup, there was a patch.  It's been in the -current snapshots for a while
> now (thanks dlg@), so you can just pull the latest ISO or whatever from
> snapshots/ and install that to test.  Probably not a bad idea, as I'm
> not 100% sure my problem was the same as yours.
>
> I tested the patch by installing a fresh system from the then-current
> snapshot (without the patch), downloading src.tar.gz and sys.tar.gz from
> 6.4, untarring under /usr/src & /usr/src/sys, using CVS to update that
> source to -current, applying the patch and then building the kernel
> ('bsd').  (There may be better ways, but that's how I did it.)
>
> Then, copy the resulting 'bsd' file to / (keep a copy of the existing
> one!) and reboot.  Simple enough...
>
> It was just a kernel patch so I didn't bother rebuilding the entire
> userland, although that's advisable if you're planning on more extensive
> testing.
>
> Have a look at https://www.openbsd.org/faq/faq5.html for some hints and
> feel free to ping me if you get stuck.
>
> Adrian
>
>

Re: Add current rtable to PS1

[Henry Bonath]

Pierre - thanks again, this is hugely helpful!

I just wanted to add to this for everyone here, plus for (perhaps my own)
future Google search reference:

In order to get KSH to evaluate the "id -R" each time I had to use single
quotes.
When using double-quotes id -R is evaluated only once, and then PS1 is set
to 0 by default and stays that way. PS1=(rtable 0)...
The single quotes preserves the literal $(id -R) and so it's being
evaluated every single time the prompt is displayed.
So in my .profile I have:

export PS1='(rtable $(id -R)) [\u@\h]:\w\\$ '

Then if I switch rdomains using: "doas /sbin/route -T42 exec /bin/ksh"
My prompt looks like:
(rtable 42) [henry@openbsd]:~$

And for a bonus, here's a little script I put together that I use to easily
switch between routing domains:
https://gitlab.com/hbonath/openbsd-routing-context

It simply runs a new elevated shell in the specified rtable

e.g.: doas routing-table 42
would run a root shell in rtable 42.


-Henry

On Tue, Apr 2, 2019 at 5:07 PM Pierre Emeriaud 
wrote:

> Le mar. 2 avr. 2019 à 23:00, Henry Bonath  a écrit :
> >
> > Hello,
> > Does anyone have any suggestions as to how to add the current rtable to
> the
> > $PS1 prompt?
> >
> > I tend to flip back and forth between routing domains and tend to lose
> track
> > of which rdomain I am currently using.
> >
> > I've been attempting an approach by trying to run 'ps -aux -o rtable'
> > and using some grep/cut-fu but I am not happy with the results.
> >
> > Perhaps there is something simpler that I am missing?
>
> Yes, `id -R` "Display the routing table of the current process":
>
> PS1="[\u@$\h:\w](rdomain$(id -R))\$ "
>

Re: Add current rtable to PS1

[Henry Bonath]

Pierre, you have my thanks as well!!

On Tue, Apr 2, 2019 at 6:00 PM Tom Smyth 
wrote:

> Pierre, Henry
>  thanks for that  I have wanted this on my systems for a while
> Cheers for asking and answering  this one
>
>
> On Tue, 2 Apr 2019 at 22:21, Pierre Emeriaud
>  wrote:
> >
> > Le mar. 2 avr. 2019 à 23:00, Henry Bonath  a
> écrit :
> > >
> > > Hello,
> > > Does anyone have any suggestions as to how to add the current rtable
> to the
> > > $PS1 prompt?
> > >
> > > I tend to flip back and forth between routing domains and tend to lose
> track
> > > of which rdomain I am currently using.
> > >
> > > I've been attempting an approach by trying to run 'ps -aux -o rtable'
> > > and using some grep/cut-fu but I am not happy with the results.
> > >
> > > Perhaps there is something simpler that I am missing?
> >
> > Yes, `id -R` "Display the routing table of the current process":
> >
> > PS1="[\u@$\h:\w](rdomain$(id -R))\$ "
> >
>
>
> --
> Kindest regards,
> Tom Smyth
>
> The information contained in this E-mail is intended only for the
> confidential use of the named recipient. If the reader of this message
> is not the intended recipient or the person responsible for
> delivering it to the recipient, you are hereby notified that you have
> received this communication in error and that any review,
> dissemination or copying of this communication is strictly prohibited.
> If you have received this in error, please notify the sender
> immediately by telephone at the number above and erase the message
> You are requested to carry out your own virus check before
> opening any attachment.
>

Add current rtable to PS1

[Henry Bonath]

Hello,
Does anyone have any suggestions as to how to add the current rtable to the
$PS1 prompt?

I tend to flip back and forth between routing domains and tend to lose track
of which rdomain I am currently using.

I've been attempting an approach by trying to run 'ps -aux -o rtable'
and using some grep/cut-fu but I am not happy with the results.

Perhaps there is something simpler that I am missing?

Thanks!
-Henry

Re: ARP issues when using ldpd and MPLS pseudowires

[Henry Bonath]

Thanks for the follow-up Adrian, I will build one out and give it a test
here tomorrow.


On Mon, Apr 1, 2019 at 10:42 PM Adrian Close 
wrote:

> Hi guys,
>
> Le 02/04/2019 13:18, Lee Nelson a écrit :
> > This sounds very similar to the problem I mentioned over the last couple
> of
> > days in an email with the subject "Trouble forwarding between mpw's in
> > bridge (6.4)".
> Sorry, I posted a follow-up to my message in tech@ but not misc@.  I
> ended up finally logging an actual bug, which dlg@ picked up, and he put
> a fix in -current that fixed my problem completely.
>
> Try a current snapshot and see if that helps?
>
> Adrian
>

Re: ARP issues when using ldpd and MPLS pseudowires

[Henry Bonath]

Lee, I just read your post about 5 minutes before you sent this. I agree
that I think this is all related.
I'm not running Pseudowires in my environment, only L3VPN but we're all
talking MPLS here.

I came across this thread from the dev mailing list posted by (who I can
assume is) the Adrian Close that started this thread:
http://openbsd-archive.7691.n7.nabble.com/ARP-issues-when-using-ldpd-8-and-mpw-4-td360853.html

It looks like a patch may have been produced, but I do not know how to test
it. I'm not sure if I can pull down just a small part of the
OpenBSD source, or if the entire OS should be built. (Although I'd love to
learn how to do this)

If I'm reading this right, the issue is in if_ethersubr.c and the issue is
with running LDP, when ARP'ing for a neighbor,
ARP "who has" requests go out for the Address of the LDP ID of the neighbor
router, not the directly broadcast-adjacent Address.
In my case, I run Loopbacks advertised into OSPF and use those for LDP and
BGP. ARP requests go out for those Loopback
IP addresses which are not broadcast-adjacent, causing my ARP entries to go
expired/incomplete. (ARP should know that these
addresses are not in my subnet mask and therefore should not be sending
ARPs for those addresses!)

If someone could help me get this patch built, I'd gladly reach back to the
Developer to see if we could get this rolled into a syspatch
or maybe into 6.5 which is right around the corner I'm assuming.  I have
not tested MPLS on 6.5 as of yet.

On Mon, Apr 1, 2019 at 10:18 PM Lee Nelson  wrote:

> This sounds very similar to the problem I mentioned over the last couple
> of days in an email with the subject "Trouble forwarding between mpw's in
> bridge (6.4)".
>
> Our environments are very different, but I think the underlying problem
> may be the same. In short, arp inside of a bridge works as it should except
> between mpw's (pseudowires). An arp broadcast entering the bridge on one
> mpw exits the bridge properly on physical interfaces, but does not get
> properly encapsulated onto the other mpw. The problem probably affects all
> broadcast traffic, but so far arp is the only broadcast traffic I have
> dealt with. Like you, I have to statically configure entries in the arp
> tables. This hack does not scale.
>
> On Mon, Apr 1, 2019, 18:36 Henry Bonath  wrote:
>
>> Tom, Adrian, et al -
>>
>> I have posted before about this issue a few weeks ago - apparently this
>> affects more than just
>> Virtualbox or VMWare, I am experiencing this *EXACT* thing on Hyper-V as
>> well.
>> I have not tried this on metal.
>>
>> My network looks like this:
>>
>> (Customer VMs)<--->(Hyper-V OpenBSD 6.4 PE)<--->(CISCO ASR P)<--->(CISCO
>> ME3750 PE)<--->(CE)
>> They Layer-2 between the Hyper-V and Cisco ASR is a Cisco Nexus 5672.
>> I am using L3VPN instead of Pseudowire.
>>
>> Some of the ARP entries will time out and when they do, LDP will crash.
>> (ldp engine terminated; signal 10)
>> 100.92.64.37 (incomplete) hvn0 expired
>> < ARP timed out
>> 100.92.64.68 00:b7:71:93:32:95hvn0 6m8s  <
>> ARP about to time out
>>
>> ARP Timing out makes no sense as these devices are all running OSPF with
>> each other,
>> granted OSPF is running Multicast to 224.0.0.5 I would think that would be
>> enough to keep ARP up.
>>
>> In my environment I use Salt to manage my systems, and my PE formula has
>> static ARP entries
>> that get added, but that's not really a fix but a workaround.
>>
>> 100.92.64.37 (incomplete) hvn0 expired
>> <--- ARP still missing for this guy
>> 100.92.64.68 00:b7:71:93:32:95hvn0 expired
>> <--- ARP timed out while writing this
>>
>> # ping 100.92.64.68
>> PING 100.92.64.68 (100.92.64.68): 56 data bytes
>> ping: sendmsg: Host is down
>> ping: wrote 100.92.64.68 64 chars, ret=-1
>> ping: sendmsg: Host is down
>>
>> Other ARP Entries stay up, the ones that do not run LDP, and oddly enough-
>> other OpenBSD systems.
>> It seems like this only happens to OpenBSD LDP against Cisco IOS/IOS-XE
>> (in
>> my environment, anyway)
>>
>> -Henry
>>
>>
>> On Wed, Mar 13, 2019 at 7:28 PM Tom Smyth 
>> wrote:
>>
>> > Adrian,
>> > sorry I only saw this now ...   when trying to go through old unread
>> mails
>> >
>> > I would be very wary of vmware virtual networking  and Layer 2
>> Forwarding
>> > I loved vmware before I discovered the ridiculous short comings in
>> > their virtual ne

Re: ARP issues when using ldpd and MPLS pseudowires

[Henry Bonath]

Tom, Adrian, et al -

I have posted before about this issue a few weeks ago - apparently this
affects more than just
Virtualbox or VMWare, I am experiencing this *EXACT* thing on Hyper-V as
well.
I have not tried this on metal.

My network looks like this:

(Customer VMs)<--->(Hyper-V OpenBSD 6.4 PE)<--->(CISCO ASR P)<--->(CISCO
ME3750 PE)<--->(CE)
They Layer-2 between the Hyper-V and Cisco ASR is a Cisco Nexus 5672.
I am using L3VPN instead of Pseudowire.

Some of the ARP entries will time out and when they do, LDP will crash.
(ldp engine terminated; signal 10)
100.92.64.37 (incomplete) hvn0 expired
< ARP timed out
100.92.64.68 00:b7:71:93:32:95hvn0 6m8s  <
ARP about to time out

ARP Timing out makes no sense as these devices are all running OSPF with
each other,
granted OSPF is running Multicast to 224.0.0.5 I would think that would be
enough to keep ARP up.

In my environment I use Salt to manage my systems, and my PE formula has
static ARP entries
that get added, but that's not really a fix but a workaround.

100.92.64.37 (incomplete) hvn0 expired
<--- ARP still missing for this guy
100.92.64.68 00:b7:71:93:32:95hvn0 expired
<--- ARP timed out while writing this

# ping 100.92.64.68
PING 100.92.64.68 (100.92.64.68): 56 data bytes
ping: sendmsg: Host is down
ping: wrote 100.92.64.68 64 chars, ret=-1
ping: sendmsg: Host is down

Other ARP Entries stay up, the ones that do not run LDP, and oddly enough-
other OpenBSD systems.
It seems like this only happens to OpenBSD LDP against Cisco IOS/IOS-XE (in
my environment, anyway)

-Henry


On Wed, Mar 13, 2019 at 7:28 PM Tom Smyth 
wrote:

> Adrian,
> sorry I only saw this now ...   when trying to go through old unread mails
>
> I would be very wary of vmware virtual networking  and Layer 2 Forwarding
> I loved vmware before I discovered the ridiculous short comings in
> their virtual networks
>
>  Vmware Virtual Switches  vmxnet
> they are not switches or bridges...   :(  they (vmware) over optimised
> and the virtual switches forward  too and from vms by default based on
> macs learned
> via each attached machines vmx config file.
> the workaround is promiscuous mode for the virtual switch... (turns
> your virtual switch into
> a crappy hub)
>  but this copies packets (frames) that are destined
> for 1 machine virtual machine attached to the virtual switch, so if
> you have high traffic volumes
> and alot of machines attached to the virtual lan ...  your perf is
> going to suck ...
> also you need to allow forged transmits on the virtual switch (macs
> that dont match the vmx machine
> mac configuration  (which all bridged packets from behind your openbsd
> guest will appear as ...
>
> if you are desperate to use vmware .. .check out the labs...  they had
> an "improved"
> virtual switch with mac learning capabilities ... (only down side is
> that  particular virtual switch
> has no mac ageing on the  switch your virtual switch FIB wont flush
> without rebooting the host
>
> apparently vmware have a switch that has proper mac learning  from
> virtual machines that
> are bridging , but this requires the  super duper awesome license (the
> enterprise + or something like that,
>
> If you still need to use vmware on a lesser license perhaps a
> multiport card + sriov and avoid their poor virtual switches
>
> basically you  will have a lot of hassle with that,
>
> I hope this helps ... 352 days later :/
>
> Tom Smyth
> PS
> Einstein once said " you should make things as simple as possible but
> no simpler" it would appear vmware
> did not heed this advice...  and you dont have to be a genius to work
> that out ... :)   (because I did :) )
>
> On Fri, 16 Mar 2018 at 04:55, Adrian Close 
> wrote:
> >
> > Hi,
> >
> > I'm looking at doing some MPLS/VPLS stuff with OpenBSD, in particular
> > using 'mpw' pseudowires.  I've created a test network comprising two
> > "PE" and two "P" hosts, to transport Ethernet traffic between service
> > ports on the PE hosts across the MPLS network, based on an example I
> > found online.  I'm using a 6.3 snapshot from March 11th.
> >
> >[firewall] = [em0][mpw0][PE1][em1] - [em0][P1][em1] - [em1][P2][em0]
> > - [em1][PE2][mpw0][em0] = [host]
> >
> > PE1 em0 and mpw0 are in a bridge, PE1 em1 is MPLS, P1 em0/1 are MPLS etc.
> >
> > This is all working great, except for short outages which turn out to
> > coincide with the ARP cache expiry time for the P router's IP address on
> > the PE host.
> >
> > When the ARP entry times out (or is manually deleted), the PE host
> > doesn't ARP for the P router IP, but instead sends ARP who-has queries
> > for other, definitely non-local things, such as the IP address for the
> > other PE host's router-id.  After a minute or so it finally ARPs for the
> > P router IP and things work again.
> >
> > This only happens when "ldpd" is running (and I think only when the
> > 

Re: LDPD Crashing

[Henry Bonath]

Thank you for the information on debugging, although I am not sure
that I will know what to do with the output once I get them.
I'm also not positive that the program is actually "crashing" either.

Here is what is going on network-wise which I think may be
contributing to the problem.

I can align the crash with an entry to one LDP neighbor disappearing
from the ARP table:
Host Ethernet AddressNetif ExpireFlags
100.92.64.68 00:b7:71:03:32:95hvn0 17m46s

When that expire counter hits Zero, I am not able to ping the
neighbor, and then my
LDP session drops and the process quits with code 10.
I ran a packet capture of this and I didn't get an ARP request going
out once I hit Zero for some time, and after it was too late and LDP
had already stopped.

I have verified the TCAM in each switch in between and both my hvn0
interface MAC as well as the ASR920 MAC are listed with the correct
ports.
So I don't believe that this is the underlying network causing the issue.

I've just configured a Static, permanent ARP entry so we'll see what
happens with that, but thats more of a workaround instead of a fix.
I may also configure a new VM on -current just to see if that makes
any difference.



On Sun, Mar 3, 2019 at 6:02 AM Stuart Henderson  wrote:
>
> On 2019-03-03, Henry Bonath  wrote:
> > To elaborate, after enabling ldpd with - I have observed the
> > following in the log output:
> >
> > Mar  3 00:58:37 mpls-gw ldpd[77048]: nbr_fsm: event SESSION CLOSE
> > resulted in action CLOSE SESSION and changing state for lsr-id
> > 100.92.64.68 from OPERATIONAL to PRESENT
> > Mar  3 00:58:37 mpls-gw ldpd[77048]: session_close: closing session
> > with lsr-id 100.92.64.68
> > Mar  3 00:58:37 mpls-gw ldpd[9902]: label decision engine exiting
> > Mar  3 00:58:37 mpls-gw ldpd[54245]: kernel routing table decoupled
> > Mar  3 00:58:37 mpls-gw ldpd[54245]: waiting for children to terminate
> > Mar  3 00:58:37 mpls-gw ldpd[54245]: ldp engine terminated; signal 10
> > Mar  3 00:58:37 mpls-gw ldpd[54245]: terminating
>
> A backtrace (preferably from a copy of ldpd built with debug symbols)
> would likely be helpful.
>
> If you don't already have the source tree checked out you can fetch
> just ldpd:
>
> $ cvs -d anon...@anoncvs.openbsd.org:/cvs get -P -r OPENBSD_6_4 
> src/usr.sbin/ldpd
> $ cd src/usr.sbin/ldpd
> $ make obj && make clean && make DEBUG=-g
>
> Enable coredumps for priv-dropped processes, as shown in sysctl(8):
>
> # mkdir -m 700 /var/crash/ldpd
> # sysctl kern.nosuidcoredump=3
>
> Then:
>
> # obj/ldpd -vd
> 
> # ls /var/crash/ldpd
> 12345.core
> # gdb obj/ldpd /var/crash/ldpd/12345.core
> (gdb) bt full
>
>

Re: LDPD Crashing

[Henry Bonath]

To elaborate, after enabling ldpd with - I have observed the
following in the log output:

Mar  3 00:58:37 mpls-gw ldpd[77048]: nbr_fsm: event SESSION CLOSE
resulted in action CLOSE SESSION and changing state for lsr-id
100.92.64.68 from OPERATIONAL to PRESENT
Mar  3 00:58:37 mpls-gw ldpd[77048]: session_close: closing session
with lsr-id 100.92.64.68
Mar  3 00:58:37 mpls-gw ldpd[9902]: label decision engine exiting
Mar  3 00:58:37 mpls-gw ldpd[54245]: kernel routing table decoupled
Mar  3 00:58:37 mpls-gw ldpd[54245]: waiting for children to terminate
Mar  3 00:58:37 mpls-gw ldpd[54245]: ldp engine terminated; signal 10
Mar  3 00:58:37 mpls-gw ldpd[54245]: terminating

On Sun, Mar 3, 2019 at 12:32 AM Henry Bonath  wrote:
>
> Hello, I am still working through some issues with trying to use
> OpenBSD as a Virtual MPLS PE in a multi-tenant hosted IaaS
> environment.
>
> I am running OpenBSD 6.4 in a Hyper-V environment.
>
> I recently started seeing one of my LDP adjacencies flapping, so I
> replace that particular P device with a Cisco ASR 920. So currently,
> my OpenBSD machine is OSPF and LDP Neighbors with the ASR 920, which
> connects to a provider circuit, and then terminates to a Cisco router
> at the customer premise running as a PE with a VRF connecting to the
> CE.
>
> Now, I am getting a crash in LDP happening after about 15 minutes:
> ldp engine terminated; signal 10 shows up in /var/log/messages
>
> here's my ldpd.conf:
> =
> router-id 100.92.127.120
>
> address-family ipv4 {
> interface hvn0
> }
> =
>
> Thanks in advance!

LDPD Crashing

[Henry Bonath]

Hello, I am still working through some issues with trying to use
OpenBSD as a Virtual MPLS PE in a multi-tenant hosted IaaS
environment.

I am running OpenBSD 6.4 in a Hyper-V environment.

I recently started seeing one of my LDP adjacencies flapping, so I
replace that particular P device with a Cisco ASR 920. So currently,
my OpenBSD machine is OSPF and LDP Neighbors with the ASR 920, which
connects to a provider circuit, and then terminates to a Cisco router
at the customer premise running as a PE with a VRF connecting to the
CE.

Now, I am getting a crash in LDP happening after about 15 minutes:
ldp engine terminated; signal 10 shows up in /var/log/messages

here's my ldpd.conf:
=
router-id 100.92.127.120

address-family ipv4 {
interface hvn0
}
=

Thanks in advance!

Re: Keeping track of MAC addresses

[Henry Bonath]

Not sure if this is what you are looking for, but I like Netdisco for this.
It uses SNMP to query network routers, switches, and access points,
and dumps out their TCAM as well as ARP tables into a Database in
order to preserve a history of not only what MAC Address was mapped to
what IP Address, but also what switchport or Access Point it was
attached to.

It uses an external PostgreSQL Database, and is written in Perl.
As far as I know, it is not available in any Packaged form for
OpenBSD, but I assume is probably manually installable.

It's great for tracking down if a device drops off the network, and
being able to track down where it last was plugged in.

On Wed, Feb 20, 2019 at 12:42 PM  wrote:
>
> > I would like to keep tabs on the MAC/IP addresses in my secure net.
> > I do know how to do this, but keeping track of ethernet MAC addresses
> > seems
> > quite cumbersome in OpenBSD, not that it is more convenient in any
> > other
> > general purpose operating system but many interfaces for ex. routers
> > make it
> > easy to manage, especially MAC filtering.
> >
> > At the moment we have:
> >
> > /etc/ethers file #not the same as arp -s and arp -f !!
> > arp -a output
> > arp -s and arp -f input # not the same as /etc/ethers!!
>
> The apps in ports don't seem to do what you (or I) want.  After looking
> them over,
> in the end I wrote a sh script to compare `arp -an` output with a list
> of "known" MACs, and it would notice when a new MAC appeared or an
> existing
> MAC disappeared (most everything is on a wireless DHCP so lots of
> transient
> behaviour).
>
> When a new one appears, or an existing one disappears, it logs to
> syslog.
>
> Previously unseen MACs are logged slightly differently, so the network
> management
> app can issue an alert.
>
> In general I think the average home network is approximately similar or
> even more
> complex than a simple small business network.  So lots of management
> features
> are worthwhile: segmentation, MAC and IP surveillance, and a network
> management
> app.
>
>
> --J
>

Re: Multiple instances of OSPFD in different RDomains - rcctl behavior

[Henry Bonath]

Thanks Stuart.

I did some more digging and found that salt itself was the culprit.
In my formula, I had a state to write out /etc/rc.conf.local followed
by a state to start the ospf2d service.
I created the state for /etc/rc.conf.local, as a file.managed state,
not understanding that the service.running state was responsible for
the modification of /etc/rc.conf.local in the first place.

The state that starts the ospf2d service uses the results of
'/usr/sbin/rcctl getdef ospf2d flags' in order to set the flags,
unless additional arguments are fed via **kwargs.

Here is my resultant working state:

enable_ospf2_service:
  service.running:
- name: ospf2d
- enable: True
- kwarg:
  flags: '-f /etc/ospf2d.conf'

This should be helpful for anyone else running Saltstack in an OpenBSD
environment and needing to feed custom flags to a process in the
future.


On Wed, Feb 20, 2019 at 5:07 AM Stuart Henderson  wrote:
>
> On 2019-02-19, Henry Bonath  wrote:
> > --- /var/backups/etc_rc.conf.local.current  Wed Jan 16 01:30:06 2019
> > +++ /etc/rc.conf.local  Fri Feb 15 13:05:17 2019
> > @@ -1,9 +1,7 @@
> >  bgpd_flags=
> >  ldpd_flags=
> > -ospf2d_flags=-f /etc/ospf2d.conf
> >  ospf2d_rtable=2
> >  ospfd_flags=
> >  pf=NO
> >  pkg_scripts=salt_minion ospf2d
> >  salt_minion_rtable=3
> >
> > Is my syntax incorrect? Would /etc/daily be doing something here to my
> > configuration?
> >
> > Why would this line keep being automatically removed?
>
> It's unlikely to be /etc/daily at 13:05:17. Check system logs for around
> that time, consider turning on process accounting to see if it gives any
> clues?
>
>

Re: Multiple instances of OSPFD in different RDomains - rcctl behavior

[Henry Bonath]

That was actually how I noticed it in the first place. I was running a 
highstate and it kept wanting to change my rc.conf.local and put the 
ospf2d_flags line back in. 

I do not run any salt states automatically, that would be an obvious 
workaround. I was just hoping to get some clarification as to my approach, and 
if I wasn’t doing something correctly in regards to working with multiple 
rdomains. 

This is on OpenBSD 6.4 btw...

Thanks!
-Henry


> On Feb 19, 2019, at 9:47 PM, Scott Reese  wrote:
> 
> - Original Message -
>> From: "Henry Bonath" 
>> To: "misc" 
>> Sent: Tuesday, February 19, 2019 2:03:31 PM
>> Subject: Multiple instances of OSPFD in different RDomains - rcctl behavior
> 
>> Hello, I am seeing some strange behavior with my /etc/rc.conf.local
>> regarding my configuration for running two instances of OSPFD in
>> different RDomains.
>> 
>> The way I have this configured, is I have a symlink: /etc/rc.d/ospf2d
>> -> /etc/rc.d/ospfd so that the ospfd that runs in rdomain 2 has its
>> own entry in rc.conf.local, pointing to its own config file.
>> 
>> In my /etc/rc.conf.local I have the following:
>> #
>> bgpd_flags=
>> ldpd_flags=
>> ospf2d_flags=-f /etc/ospf2d.conf
>> ospf2d_rtable=2
>> ospfd_flags=
>> pf=NO
>> pkg_scripts=salt_minion ospf2d
>> salt_minion_rtable=3
>> #
>> 
>> However I notice that something is removing the "ospf2d_flags=..."
>> line as output from daily insecurity mail:
>> 
>> ==
>> /etc/rc.conf.local diffs (-OLD  +NEW)
>> ==
>> --- /var/backups/etc_rc.conf.local.current  Wed Jan 16 01:30:06 2019
>> +++ /etc/rc.conf.local  Fri Feb 15 13:05:17 2019
>> @@ -1,9 +1,7 @@
>> bgpd_flags=
>> ldpd_flags=
>> -ospf2d_flags=-f /etc/ospf2d.conf
>> ospf2d_rtable=2
>> ospfd_flags=
>> pf=NO
>> pkg_scripts=salt_minion ospf2d
>> salt_minion_rtable=3
>> 
>> Is my syntax incorrect? Would /etc/daily be doing something here to my
>> configuration?
>> Why would this line keep being automatically removed?
>> 
>> Thanks in advance!
> 
> Greetings Henry:
> 
> Looks like you're running Saltstack. Any chance that your Salt master
> has a copy of the rc.conf.local that doesn't have the ospf2d_flags line
> and is resetting the file back to its "correct" values?
> 
> -Scott
> 

Multiple instances of OSPFD in different RDomains - rcctl behavior

[Henry Bonath]

Hello, I am seeing some strange behavior with my /etc/rc.conf.local
regarding my configuration for running two instances of OSPFD in
different RDomains.

The way I have this configured, is I have a symlink: /etc/rc.d/ospf2d
-> /etc/rc.d/ospfd so that the ospfd that runs in rdomain 2 has its
own entry in rc.conf.local, pointing to its own config file.

In my /etc/rc.conf.local I have the following:
#
bgpd_flags=
ldpd_flags=
ospf2d_flags=-f /etc/ospf2d.conf
ospf2d_rtable=2
ospfd_flags=
pf=NO
pkg_scripts=salt_minion ospf2d
salt_minion_rtable=3
#

However I notice that something is removing the "ospf2d_flags=..."
line as output from daily insecurity mail:

==
/etc/rc.conf.local diffs (-OLD  +NEW)
==
--- /var/backups/etc_rc.conf.local.current  Wed Jan 16 01:30:06 2019
+++ /etc/rc.conf.local  Fri Feb 15 13:05:17 2019
@@ -1,9 +1,7 @@
 bgpd_flags=
 ldpd_flags=
-ospf2d_flags=-f /etc/ospf2d.conf
 ospf2d_rtable=2
 ospfd_flags=
 pf=NO
 pkg_scripts=salt_minion ospf2d
 salt_minion_rtable=3

Is my syntax incorrect? Would /etc/daily be doing something here to my
configuration?
Why would this line keep being automatically removed?

Thanks in advance!

Re: Ignore MTU on OSPFD

[Henry Bonath]

Remi, thank you for confirming.

On Mon, Jan 14, 2019 at 4:03 PM Remi Locherer  wrote:

> On Mon, Jan 14, 2019 at 03:08:32PM -0500, Henry Bonath wrote:
> > Is it possible to set to ignore MTU on OpenOSPFD?
>
> No, this is not supported.
>
> >
> > For example on Cisco IOS I can add the command "ip ospf mtu-ignore"
> >
> > I am having some issues if the MTU is mismatched and some neighbors will
> be
> > stuck in Exstart or Exchange.
>
> Exactly. If the MTU differs between neighbors the adjacency will not come
> up.
>
> > Other times those neighbors work fine, and it's unclear whether the MTU
> is
> > coming into play, however those neighbors do have MTU of 9000.
>
> Maybe it is worth checking that you configured the MTU for L2 and for L3 on
> these Cisco devices.
>

Ignore MTU on OSPFD

[Henry Bonath]

Is it possible to set to ignore MTU on OpenOSPFD?

For example on Cisco IOS I can add the command "ip ospf mtu-ignore"

I am having some issues if the MTU is mismatched and some neighbors will be
stuck in Exstart or Exchange.
Other times those neighbors work fine, and it's unclear whether the MTU is
coming into play, however those neighbors do have MTU of 9000.

Thanks in advance.

bgpctl display mpls label stack of VPNv4 routes

[Henry Bonath]

Hello,
Does anyone know a way to view the label stack of VPNv4 routes learned via
MP-BGP?

I am currently running a POC of trying out OpenBSD as a Virtual MPLS PE for
some of our hosted tenants, and was finding some issues routing to certain
prefixes via MPLS because packets were being sent to an incorrect label.

I'm trying to see if I can find out what label is being sent for the VPNv4
destination, however I am not finding a way to do that using the normal
tools aside from running tcpdump and using wireshark to look at the UPDATE
messages coming in from the route-reflectors.

Any suggestions?

Thanks!
-Henry

Re: OpenBGPD Route Reflector - not reflecting VPNv4 Routes

[Henry Bonath]

Thank you Claudio!

I didn't even think of that, as these Route Reflectors are completely
out-of-band and not in the path of routing at all.
Of course they wouldn't work without having a route to the nexthop :-)

I'm much more versed in troubleshooting BGP on IOS, but with all the
work you just put into OpenBGPD I wanted to put it to the task.

Thanks so much for your help! It is working now:

RR$ bgpctl show ip bgp nei 100.92.127.37 out
flags: * = Valid,  = Selected, I = via IBGP, A = Announced,
   S = Stale, E = Error
origin validation state: N = not-found, V = valid, ! = invalid
origin: i = IGP, e = EGP, ? = Incomplete

flags ovs destination  gateway  lpref   med aspath origin
I*> N rd 1234:5678 172.29.20.0/24 100.92.127.101 100 0 i


On Thu, Dec 20, 2018 at 5:49 PM Claudio Jeker  wrote:
>
> On Thu, Dec 20, 2018 at 04:52:34PM -0500, Henry Bonath wrote:
> > Hello, I am having an issue with some route-reflectors I set up to try
> > to support a new MPLS backbone.
> > The majority of the MPLS Routers are Cisco IOS, with some of the PE
> > devices running OpenBSD.
> > The Route Reflectors are OpenBSD 6.4. The route reflectors are not
> > neighbors of each other.
> >
> > Here is my config:
> > 
> > ASN="1234"
> > AS $ASN
> > router-id 172.16.16.211
> >
> > group "IBGP" {
> > remote-as $ASN
> > announce IPv4 vpn
> > route-reflector 172.16.16.211
> > local-address 172.16.16.211
> > neighbor 100.92.64.0/18 {
> > }
> >
> > }
> > # IBGP: allow all updates to and from our IBGP neighbors
> > allow from any
> > allow to any
> >
> > 
> >
> > On the reflectors themselves, if I issue a "bgpctl show rib" I do see
> > VPNv4 routes, and "bgpctl show summary" I see that I am receiving
> > prefixes:
> > 
> > RR$ bgpctl show rib
> > flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
> >S = Stale, E = Error
> > origin validation state: N = not-found, V = valid, ! = invalid
> > origin: i = IGP, e = EGP, ? = Incomplete
> >
> > flags ovs destination  gateway  lpref   med aspath origin
> > I   N rd 1234:5678 10.25.80.0/24 100.92.127.20  100 0 ?
> > I   N rd 1234:5678 172.29.20.0/24 100.92.127.101 100 0 i
> > 
>
> These routes are not valid (*) is missing. Which does result in them not
> being selected and because of that not reflected. At least I would look
> into that. Normally this is cause because the nexthop is not valid. Maybe
> you need to add the IGP routes or in the worst case use 'nexthop qualify
> via default'.
>
> > If I do the same on a PE, it shows Zero prefixes received from either
> > route reflector:
> > 
> > PE$ bgpctl show rib
> > flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
> >S = Stale, E = Error
> > origin validation state: N = not-found, V = valid, ! = invalid
> > origin: i = IGP, e = EGP, ? = Incomplete
> >
> > flags ovs destination  gateway  lpref   med aspath origin
> > I*> N rd 1234:5678 10.25.80.0/24 100.92.127.20  100 0 ?
> > AI*>N rd 1234:5678 172.29.20.0/24 rd 0:0 0.0.0.0 100 0 i
> > [hbonath@hb-mplspe-01]:~$ bgpctl show summ
> > Neighbor   ASMsgRcvdMsgSent  OutQ Up/Down  
> > State/PrfRcvd
> > bgp-rr-02   1234 41 42 0 00:19:08  0
> > bgp-rr-01   1234 41 42 0 00:19:08  0
> > 
> >
> > What am I missing here? Does it have to do with the flags that the
> > Route-Reflector is showing?
> > Thanks in advance!
> >
>
> --
> :wq Claudio
>

OpenBGPD Route Reflector - not reflecting VPNv4 Routes

[Henry Bonath]

Hello, I am having an issue with some route-reflectors I set up to try
to support a new MPLS backbone.
The majority of the MPLS Routers are Cisco IOS, with some of the PE
devices running OpenBSD.
The Route Reflectors are OpenBSD 6.4. The route reflectors are not
neighbors of each other.

Here is my config:

ASN="1234"
AS $ASN
router-id 172.16.16.211

group "IBGP" {
remote-as $ASN
announce IPv4 vpn
route-reflector 172.16.16.211
local-address 172.16.16.211
neighbor 100.92.64.0/18 {
}

}
# IBGP: allow all updates to and from our IBGP neighbors
allow from any
allow to any



On the reflectors themselves, if I issue a "bgpctl show rib" I do see
VPNv4 routes, and "bgpctl show summary" I see that I am receiving
prefixes:

RR$ bgpctl show rib
flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
   S = Stale, E = Error
origin validation state: N = not-found, V = valid, ! = invalid
origin: i = IGP, e = EGP, ? = Incomplete

flags ovs destination  gateway  lpref   med aspath origin
I   N rd 1234:5678 10.25.80.0/24 100.92.127.20  100 0 ?
I   N rd 1234:5678 172.29.20.0/24 100.92.127.101 100 0 i


If I do the same on a PE, it shows Zero prefixes received from either
route reflector:

PE$ bgpctl show rib
flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
   S = Stale, E = Error
origin validation state: N = not-found, V = valid, ! = invalid
origin: i = IGP, e = EGP, ? = Incomplete

flags ovs destination  gateway  lpref   med aspath origin
I*> N rd 1234:5678 10.25.80.0/24 100.92.127.20  100 0 ?
AI*>N rd 1234:5678 172.29.20.0/24 rd 0:0 0.0.0.0 100 0 i
[hbonath@hb-mplspe-01]:~$ bgpctl show summ
Neighbor   ASMsgRcvdMsgSent  OutQ Up/Down  State/PrfRcvd
bgp-rr-02   1234 41 42 0 00:19:08  0
bgp-rr-01   1234 41 42 0 00:19:08  0


What am I missing here? Does it have to do with the flags that the
Route-Reflector is showing?
Thanks in advance!

Re: Using /32 resp. /128 netmask for carp ips

[Henry Bonath]

To add to this, just as when using other first-hop redundancy protocols
like VRRP or HSRP on a Router or Layer-3 switch,
we only want the single IP address to float between the redundant hosts,
and not the entire subnet.
So we define the most specific subnet mask for IPv4, which is
255.255.255.255 or /32 or if using IPv6, /128.


On Fri, Nov 23, 2018 at 1:16 PM Janne Johansson  wrote:

> Den fre 23 nov. 2018 kl 18:50 skrev Joerg Streckfuss <
> streckf...@dfn-cert.de>:
> >
> > Dear list,
> >
> > i want to know why it is good practice to use /32 netmask for ipv4
> > respectively /128 netmask for ipv6 addresses on carp interfaces, while
> using the
> > "real" netmask for example /24 for a dedicated address on an interface.
>
> So that the real interface gets used for outgoing traffic generated on
> the boxes, like ntp,
> syslog, mails and so forth, even if the carp currently is not up (ie not
> master)
>
> --
> May the most significant bit of your life be positive.
>
>

Re: Redistributing between bgpd and ospfd

[Henry Bonath]

Claudio -

One use case where I personally ran into this need in the past is in an
MPLS PE-CE where OSPF is running between the Provider and Customer. (L3VPN)
One would want to redistribute the Customers OSPF routes into BGP as VPNv4
prefixes into the customers VRF in the provider network.

We typically run Cisco on our CPE's and do exactly this with our customers,
with a redistribute ospf statement under "address-family vpnv4 vrf
cusomerVRF"
I'd *love* to be able to do the same with OpenBSD and not have to fork out
Cisco money at the customer premise.

That being said, EIGRPD would also benefit here, as I have customers that
run EIGRP and want to use that on their CE's.

Thanks for everything that you do, and keep up the great work!

On Mon, Oct 15, 2018 at 8:37 AM Claudio Jeker 
wrote:

> On Mon, Oct 15, 2018 at 02:48:31PM +0300, Gregory Edigarov wrote:
> > On 15.10.18 12:58, Sebastian Benoit wrote:
> > > open...@kene.nu(open...@kene.nu) on 2018.10.15 11:05:41 +0200:
> > > > Hello,
> > > >
> > > > I am trying to get bgpd and ospfd play nicely with route
> redistribution.
> > > >
> > > > So far the only way I have found that suits my need is to use
> > > > bgpd.conf network statements and rtlabels.
> > > >
> > > > So, to make ospfd learn route from bgpd I use rtlabels. So in
> bgpd.conf:
> > > > match from  set rtlabel from_bgpd
> > > >
> > > > And in ospfd.conf:
> > > > redistribute rtlabel from_bgpd
> > > >
> > > >
> > > > So far so good. But the other way around, to bake bgpd learn from
> > > > ospfd it becomes a bit more tedious. The only way I have found to
> make
> > > > bgpd announce ospf originated routes (to its bgp peers) is via
> network
> > > > statements in bgpd.conf. These network statements are not conditional
> > > > on the availability of such a route in ospf though so they are not
> > > > very dynamic anymore.
> > > >
> > > > I understand that it according to standard
> > > > (https://tools.ietf.org/html/rfc1364) should be something that is
> > > > explicit for type 1 and 2 LSAs.
> > > >
> > > > What is the recommended way to achieve dynamic explicit route
> > > > redistribution in both directions?
> > > Network statements are the correct way.
> > >
> > > You can use
> > >
> > >   network (inet|inet6) priority ...
> > >   network (inet|inet6) rtlabel ...
> > >
> > > So with
> > >
> > >network inet priority  32
> > >
> > > you should be able to redistribute all ospf routes into bgp.
> > >
> > > If this does not help, please explain your problem further (and
> include your
> > > config).
> > >
> > > (Note that you should run OpenBSD 6.4 (just use the latest snapshot)
> for
> > > this as there was at least a bugfix for route-labels.)
> > wouldn't it be nice to have rtlabels in ospf(6)d? I would even prefer
> > setting them per area, or per interface where a route was learned.
> > just wondering why is it not implemented yet. is that too complex
> change? or
> > just not necessary?
> >
>
> Until now there has not been a need for this. In general and probably best
> common practice is to not mix BGP and OSPF. Instead OSPF is building the
> underlaying network to run BGP on top of. This is why benno@ was asking
> for the use case.
>
> By the way, because of the nature of OSPF it does not make sense to tag
> routes by interface, doing it by area could be an option but that comes
> with some edge cases that need further inspection.
>
> --
> :wq Claudio
>
>

Re: CARP on Hyper-V VM

[Henry Bonath]

Were you able to resolve?

I have a SCVMM environment and I ran into a similar issue, there is a bug
in VMM 2016 with the NDIS extension but I believe its resolved in 1807.
I have not been able to test, but would like to know if you had any
success, as I was not able to use CARP at all in Hyper-V as you stated.

On Tue, Oct 16, 2018 at 6:41 AM Markus Rosjat  wrote:

> Hi Ricardo,
>
> > You must set the VM's network adapter to 'Enable MAC address spoofing'
> > under 'Advanced Features'.
>
> nope this isn't solving the problem. I can only ping the virtual ip from
> the local machine still. It might need the NDIS Extention enabled on the
> vSwitch too but I did't changed that because of the probable network
> disconnection. I will give it a shot later.
>
> regards
>
> MArkus
>
> --
> Markus Rosjatfon: +49 351 8107224mail: ros...@ghweb.de
>
> G+H Webservice GbR Gorzolla, Herrmann
> Königsbrücker Str. 70, 01099 Dresden
>
> http://www.ghweb.de
> fon: +49 351 8107220   fax: +49 351 8107227
>
> Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before
> you print it, think about your responsibility and commitment to the
> ENVIRONMENT
>
>

Re: OpenBSD site

[Henry Bonath]

This is amazing to know, thank you!

On Sat, Oct 27, 2018 at 3:11 PM  wrote:

> Knowing OpenBSD philosophy, you should probably NOT expect a CMS :).
>
> But you don't need to guess when you can check for yourself - all the
> sources are available for an anonymous CVS as described in [1].
>
> You can easily have an up-to-date local copy on your machine by first
> reading manual pages on cvs(1), httpd(8) and httpd.conf(5) and then doing
> something like (as root):
>
> # mkdir -p /var/www/htdocs/openbsd
> # cd /var/www/htdocs/openbsd
> # cvs -qd anon...@anoncvs.ca.openbsd.org:/cvs checkout -P www
>
> and adding the following section to /etc/httpd.conf:
>
> server "openbsd-doc" {
> listen on * port 81
> root "/htdocs/openbsd/www"
> }
>
> and enabling httpd:
>
> # rcctl enable httpd
>
> After that, navigate to http://localhost:81 and enjoy browsing an offline
> copy of OpenBSD website.
>
> [1] https://www.openbsd.org/anoncvs.html
>
>
> On Sat, Oct 27, 2018, at 4:24 AM, Janne Johansson wrote:
> > Manual edits, no hurry to jump on this weeks fashionable web
> > framework, testing with lynx goes a long way to keep it simple and
> > readable.
> >
> > Den lör 27 okt. 2018 kl 11:14 skrev misc nick :
> > >
> > > I was wondering how you maintain and update such high quality content
> in OpenBSD's site.
> > > Do you manually edit html files, use a cms, or something else? I am
> asking to shamelessly
> > > copy your best practices. ;-)
> > >
> > > Thanks,
> > > Nick
> > >
> >
> >
> > --
> > May the most significant bit of your life be positive.
> >
>
>

Re: "no route to host" from pkg_add

[Henry Bonath]

Also could it be that you are using IPv6, not IPv4? (and your IPv6 is
missing its gateway)
If the IPv6 gateway is bad/missing you'll get that "no route to host"
message.

On Fri, Aug 10, 2018 at 4:31 PM, Stuart Henderson 
wrote:

> On 2018-08-07, traveller  wrote:
> > After OpenBSD, one too many “/“
>
> That won't cause this.
>
>
>
> > On Aug 7, 2018, 11:16 AM -0700, Benjamin Walkenhorst <
> walkenhorst.benja...@gmail.com>, wrote:
> >> Hello everyone,
> >>
> >> I recently installed OpenBSD 6.3 in a VPS.
> >>
> >> In the last few days, I get an error message when running pkg_add, "no
> route to host".
> >> I have tried setting various hosts in /etc/installurl, but the problem
> remains.
> >>
> >> When I run pkg_add, this is the output I get I get:
> >> [20:02|root@myhost:~]# pkg_add nmap
> >> https://fastly.cdn.openbsd.org/pub/OpenBSD//6.3/packages-stable/amd64/:
> ftp: connect: No route to host
> >> https://fastly.cdn.openbsd.org/pub/OpenBSD//6.3/packages/amd64/: ftp:
> connect: No route to host
> >> https://fastly.cdn.openbsd.org/pub/OpenBSD//6.3/packages/amd64/: empty
> >> Can't find nmap
> >>
> >> When I try to ping the host specified in /etc/installurl or call
> traceroute, everything seems to work as expected.
>
> How about "ftp -o- https://fastly.cdn.openbsd.org/pub/OpenBSD/;,
> does that fail too?
>
>
>

Re: IPv6 Static Configuration Gateway Address - Link Local or Global Unicast?

[Henry Bonath]

I have always used the Router's global address when configuring a static
route or static default gateway.
I have seen routing protocols like OSPF/BGP/etc. use link-local addresses
for nexthop, but when statically configuring,
I've always used the global address that is located within the same subnet
as the host's address.

-Henry

On Wed, Jul 18, 2018 at 4:45 PM, Aham Brahmasmi 
wrote:

> Hello misc,
>
> I am wondering whether the good volks here would be able to share
> their insight on configuring the IPv6 gateway address for a machine
> which has been assigned a static IPv6 address.
>
> Based on my layman research, there are two options:
> 1) Link local gateway address - fe80::1%em0 (Preferable)
> 2) Global unicast gateway address (router's IPv6 address) - xx:
>
> Which of the above is preferable? The reason I wish to ask is, after
> trying to understand IPv6, I have understood that I do not understand
> much.
>
> But based on what little I do understand, the switches need to have RA
> guards, to protect from rogue RAs. Unfortunately, the baremetal provider
> that I am working with has not yet been able to understand my concerns
> and queries regarding the mitigations they have put in place for this
> impersonation and other vectors. This has led me to use the fully static
> configuration approach as outlined by Enno Rey in his APNIC blog post -
> https://blog.apnic.net/2017/01/16/ipv6-configuration-approaches-servers/
> .
>
> Additionally, I came across net.inet6.ip6.accept_rtadv to disable
> accepting router advertisements. However, I could not find it. So,
> code searching led me to a commit [1] in sys/netinet6/in6.h which
> removed the sysctl and introduced IFXF_AUTOCONF6. Searching for that
> led me to inet6 autoconf. So, my current understanding is that
> unless autoconf is specified, the router advertisements are not
> accepted. Similarly, net.inet6.icmp6.rediraccept seems to have been
> removed and is now dependent on IFXF_AUTOCONF6 [2].
> Please correct me if I am wrong.
>
> Finally, if there are things an IPv6 rookie should know but tends to
> learn after getting burnt, pointers towards the same will be much
> appreciated.
>
> Thanks.
>
> Regards,
> ab
> [1] - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/
> netinet6/in6.h?rev=1.73=text/x-cvsweb-markup
> [2] - https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/
> netinet6/icmp6.c?rev=1.148=text/x-cvsweb-markup
> -|-|-|-|-|-|-|--
>
>

Re: Coming from FreeBSD, lower networking performance

[Henry Bonath]

Have you looked into IPerf? https://iperf.fr/

This is what I typically use for testing network throughput.
Downloading a file is a bit more complex and involves things
like the source server/latency/etc. as well as disk performance.
(I know a 100MB file isnt much but still...)

IPerf has a lot of knobs to tweak, like number of threads, TCP window size,
etc.
You will need 2 hosts, one to act as server and one as client.
I recommend the latest stable version of iperf3, which is available as a
package:
$ doas pkg_add iperf3

Hope this helps.

On Fri, Jul 13, 2018 at 7:20 PM, Sijmen J. Mulder  wrote:

> Hi all,
>
> After migrating a VPS from FreeBSD to OpenBSD I noticed reduced networking
> performance. Both incoming and outgoing traffic seems to be 2-3 times
> slower on average. By testing 100MB file transfers I've mostly eliminated
> the following factors:
>
>  - Protocol and ciphers (tested SCP, SFTP, FTP+TLS, HTTP, HTTPS)
>  - Client software
>  - Peer host
>  - VM provider/platform
>
> The easiest way to show and test this difference is as such:
>
>  1. Install either FreeBSD 11.2 or OpenBSD 6.3 on a machine or VM
>  2. Install curl, then `time curl -O http://download.
> thinkbroadband.com/100MB.zip`
>
> On both my VPS provider and my own PC with VirtualBox VMs the difference
> is about 3x for the above test. Similar results happen when scp-ing a file
> to the machine.
>
> Any ideas on the cause of this? Any additional tests or tweaks I could try?
>
> Sijmen
>
>