Re: wrong pkg_add url after sysupgrade
I was confused by this myself. Thanks Paul.On 10 Oct 2019 7:01 am, shadrock uhuru wrote: > > On 10/9/19 2:56 PM, Paul de Weerd wrote: > > On Wed, Oct 09, 2019 at 01:40:42PM +, shadrock uhuru wrote: > | after trying sysupgrade for the first time on my laptop running snapshots > | running the following command returns no such dir. > | > | doas pkg_add -u > | https://ftp.OpenBSD.org/pub/OpenBSD/6.6/packages/amd64/: no such dir > | pkg_info p5-finance > | https://ftp.OpenBSD.org/pub/OpenBSD/6.6/packages/amd64/: no such dir > | > | my /etc/installurl has > | cat /etc/installurl > | https://ftp.OpenBSD.org/pub/OpenBSD > | > | does this need editing > | if so what url should i use ? > > Same url, different command: pkg_add -u -Dsnap > > Twice a year there's a brief window where snapshots have the name of > the upcoming release. During that time, you must add -Dsnap to > pkg_add. It doesn't hurt to have -Dsnap when you're running something > -current or -beta, so if you always run snaps, best to train you > muscle memory to do -Dsnap always :) > > Cheers, > > Paul 'WEiRD' de Weerd > > > thanks Paul
Problems with route installation to fib from OSPF
Hello OpenBSD team, We are facing an issue with OSPF related routes and would like to request your help as it seems to be a OSPF to FIB route replication issue. This happened already once in a different location, that one is running OpenBSD 6.3 and the site of the current report is OpenBSD 6.5 *Describing:* We have a setup with a FW cluster of 2 hosts talking OSPF to 2 Ubuntu boxes running Quagga. The 2 Ubuntu boxes run keepalived between them to install a secondary IP address on the interface, the service IP address. OSPF is configured to advertise this floating service IP and it's advertised only when it's available in the interface. OSPF is configured to not become DR/BDR in Ubuntu hosts *Initial state:* Service is active in ubuntu host A, everything working. root@fw1:~# ospfctl show nei ID Pri State DeadTime Address Iface Uptime (...) 10.10.53.28 1 FULL/OTHER 00:00:04 10.10.53.28 vlan1353 00:16:01 172.16.50.3 1 FULL/DR 00:00:04 10.10.53.27 vlan1353 03w2d10h 10.10.53.29 1 FULL/OTHER 00:00:04 10.10.53.29 vlan1353 00:04:38 *Facing the issue:* Ubuntu host A is shutdown, keepalived converges to host B and OSPF advertises the network, but service IP is unreachable. FW receives the correct update and we see the new nexthop correct in "ospfctl show rib", root@fw1:~# ospfctl show rib |grep 10.250.250.153 10.250.250.153/32 10.10.53.29 Intra-Area Network 110 00:03:10 root@fw1:~# however FIB still points to old nexthop, the 10.10.53.28. The new nexthop should end in .29. root@fw1:~# route -n get 10.250.250.153 route to: 10.250.250.153 destination: 10.250.250.153 mask: 255.255.255.255 gateway: 10.10.53.28 interface: vlan1353 if address: 10.10.53.26 priority: 32 (ospf) flags: use mtu expire 8298 0 0 root@fw1:~# in logs we see this message: Oct 10 07:41:53 fw1 ospfd[44713]: send_rtmsg: action 1, prefix 10.250.250.153/32: File exists Oct 10 07:42:03 fw1 ospfd[44713]: send_rtmsg: action 1, prefix 10.250.250.153/32: File exists This prefix is the service IP. *The FIX (manual):* To fix this we need to delete the route manually and since after deleting it doesn't get the new route automatically installed in FIB, we then reload the FIB. Sequence of commands: root@fw1:~# route -n show | grep 10.250.250 10.250.250.53/32 10.10.11.155 UG 0 510172 - 48 vlan1150 10.250.250.153/32 10.10.53.28 UGP 1 18861 - 32 vlan1353 10.250.250.153/32 10.10.11.155 UG 0 0 - 48 vlan1150 root@fw1:~# route del 10.250.250.153/32 10.10.53.28 del host 10.250.250.153/32: gateway 10.10.53.28 root@fw1:~# route -n show | grep 10.250.250 10.250.250.53/32 10.10.11.155 UG 0 510185 - 48 vlan1150 10.250.250.153/32 10.10.11.155 UG 0 1550 - 48 vlan1150 root@fw1:~# route -n show | grep 10.250.250 10.250.250.53/32 10.10.11.155 UG 0 510187 - 48 vlan1150 10.250.250.153/32 10.10.11.155 UG 0 3806 - 48 vlan1150 root@fw1:~# route -n show | grep 10.250.250 10.250.250.53/32 10.10.11.155 UG 0 510187 - 48 vlan1150 10.250.250.153/32 10.10.11.155 UG 0 4711 - 48 vlan1150 root@fw1:~# root@fw1:~# route -n show | grep 10.250.250 10.250.250.53/32 10.10.11.155 UG 0 510188 - 48 vlan1150 10.250.250.153/32 10.10.11.155 UG 0 7373 - 48 vlan1150 root@fw1:~# root@fw1:~# root@fw1:~# route -n show | grep 10.250.250 10.250.250.53/32 10.10.11.155 UG 0 510188 - 48 vlan1150 10.250.250.153/32 10.10.11.155 UG 0 8505 - 48 vlan1150 root@fw1:~# root@fw1:~# ospfctl fib reload reload request sent. root@fw1:~# root@fw1:~# route -n show | grep 10.250.250 10.250.250.53/32 10.10.11.155 UG 0 20 - 48 vlan1150 10.250.250.153/32 10.10.53.29 UG 0 106 - 32 vlan1353 10.250.250.153/32 10.10.11.155 UG 0 0 - 48 vlan1150 root@fw1:~# At this point service is restored, and the problem is not reproduce-able anymore. The difference I see is that the new route doesn't have the Multipath flag anymore. *Details about OpenBSD:* *dmesg.boot:* OpenBSD 6.5 (GENERIC.MP) #5: Thu Aug 29 20:38:30 CEST 2019 r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16930836480 (16146MB) avail mem = 16408076288 (15647MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7af09000 (59 entries) bios0: vendor Dell Inc. version "2.0.1" date 04/11/2016 bios0: Dell Inc. PowerEdge R430 acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP MCEJ WD__ SLIC HPET APIC MCFG MSCT SLIT SRAT SSDT SSDT SSDT PRAD DMAR HEST BERT ERST EINJ
Problems with route installation to fib from OSPF
Hello OpenBSD team, We are facing an issue with OSPF related routes and would like to request your help as it seems to be a OSPF to FIB route replication issue. This happened already once in a different location, that one is running OpenBSD 6.3 and the site of the current report is OpenBSD 6.5 *Describing:* We have a setup with a FW cluster of 2 hosts talking OSPF to 2 Ubuntu boxes running Quagga. The 2 Ubuntu boxes run keepalived between them to install a secondary IP address on the interface, the service IP address. OSPF is configured to advertise this floating service IP and it's advertised only when it's available in the interface. OSPF is configured to not become DR/BDR in Ubuntu hosts *Initial state:* Service is active in ubuntu host A, everything working. root@fw1:~# ospfctl show nei ID Pri State DeadTime Address Iface Uptime (...) 10.10.53.28 1 FULL/OTHER 00:00:04 10.10.53.28 vlan1353 00:16:01 172.16.50.3 1 FULL/DR 00:00:04 10.10.53.27 vlan1353 03w2d10h 10.10.53.29 1 FULL/OTHER 00:00:04 10.10.53.29 vlan1353 00:04:38 *Facing the issue:* Ubuntu host A is shutdown, keepalived converges to host B and OSPF advertises the network, but service IP is unreachable. FW receives the correct update and we see the new nexthop correct in "ospfctl show rib", root@fw1:~# ospfctl show rib |grep 10.250.250.153 10.250.250.153/32 10.10.53.29 Intra-Area Network 110 00:03:10 root@fw1:~# however FIB still points to old nexthop, the 10.10.53.28. The new nexthop should end in .29. root@fw1:~# route -n get 10.250.250.153 route to: 10.250.250.153 destination: 10.250.250.153 mask: 255.255.255.255 gateway: 10.10.53.28 interface: vlan1353 if address: 10.10.53.26 priority: 32 (ospf) flags: use mtu expire 8298 0 0 root@fw1:~# in logs we see this message: Oct 10 07:41:53 fw1 ospfd[44713]: send_rtmsg: action 1, prefix 10.250.250.153/32: File exists Oct 10 07:42:03 fw1 ospfd[44713]: send_rtmsg: action 1, prefix 10.250.250.153/32: File exists This prefix is the service IP. *The FIX (manual):* To fix this we need to delete the route manually and since after deleting it doesn't get the new route automatically installed in FIB, we then reload the FIB. Sequence of commands: root@fw1:~# route -n show | grep 10.250.250 10.250.250.53/32 10.10.11.155 UG 0 510172 - 48 vlan1150 10.250.250.153/32 10.10.53.28 UGP 1 18861 - 32 vlan1353 10.250.250.153/32 10.10.11.155 UG 0 0 - 48 vlan1150 root@fw1:~# route del 10.250.250.153/32 10.10.53.28 del host 10.250.250.153/32: gateway 10.10.53.28 root@fw1:~# route -n show | grep 10.250.250 10.250.250.53/32 10.10.11.155 UG 0 510185 - 48 vlan1150 10.250.250.153/32 10.10.11.155 UG 0 1550 - 48 vlan1150 root@fw1:~# route -n show | grep 10.250.250 10.250.250.53/32 10.10.11.155 UG 0 510187 - 48 vlan1150 10.250.250.153/32 10.10.11.155 UG 0 3806 - 48 vlan1150 root@fw1:~# route -n show | grep 10.250.250 10.250.250.53/32 10.10.11.155 UG 0 510187 - 48 vlan1150 10.250.250.153/32 10.10.11.155 UG 0 4711 - 48 vlan1150 root@fw1:~# root@fw1:~# route -n show | grep 10.250.250 10.250.250.53/32 10.10.11.155 UG 0 510188 - 48 vlan1150 10.250.250.153/32 10.10.11.155 UG 0 7373 - 48 vlan1150 root@fw1:~# root@fw1:~# root@fw1:~# route -n show | grep 10.250.250 10.250.250.53/32 10.10.11.155 UG 0 510188 - 48 vlan1150 10.250.250.153/32 10.10.11.155 UG 0 8505 - 48 vlan1150 root@fw1:~# root@fw1:~# ospfctl fib reload reload request sent. root@fw1:~# root@fw1:~# route -n show | grep 10.250.250 10.250.250.53/32 10.10.11.155 UG 0 20 - 48 vlan1150 10.250.250.153/32 10.10.53.29 UG 0 106 - 32 vlan1353 10.250.250.153/32 10.10.11.155 UG 0 0 - 48 vlan1150 root@fw1:~# At this point service is restored, and the problem is not reproduce-able anymore. The difference I see is that the new route doesn't have the Multipath flag anymore. *Details about OpenBSD:* *dmesg.boot:* OpenBSD 6.5 (GENERIC.MP) #5: Thu Aug 29 20:38:30 CEST 2019 r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16930836480 (16146MB) avail mem = 16408076288 (15647MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7af09000 (59 entries) bios0: vendor Dell Inc. version "2.0.1" date 04/11/2016 bios0: Dell Inc. PowerEdge R430 acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP MCEJ WD__ SLIC HPET APIC MCFG MSCT SLIT SRAT SSDT SSDT SSDT PRAD DMAR HEST BERT ERST EINJ
Re: bgpctl(8) community question
On Mon, Oct 07, 2019 at 04:48:34PM -0500, Adam Thompson wrote: > [OpenBSD 6.5-STABLE, up to date] > > When using bgpctl(8), I'm able to do almost everything I need, but I'm > having trouble figuring out how to do one thing: > > How do I show routes that do NOT have a community (or ext-community, or > large-community) attribute? > > The best I can come up with so far is a fairly ugly AWK script that buffers > the detailed route output, then emits it if it doesn't see a Communities: > line. Am I missing a better way? > > Thanks, > -Adam > > N.B. manually looking through N sets of DFZ route tables isn't going to > happen, I need a mostly-automatic solution. Currently there is no other way to filter on prefixes which don't have a community. You can use the ssv output to make the filtering easier or you tag the prefixes with a different community (first set community on all routes and then delete community again from those where you set the other community). Adding a 'not' option to community matching should be possible. I will look into that after 6.6 is out. -- :wq Claudio
denverton acpi reboot
it works, (did not in 6.4 ) who s the awesome fellow who did that Thank you -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
relayd: Binding to port range
Hi, it seems relayd's configuration syntax does not allow specifying port ranges, like 9740:10200. Am I correct? Thanks! Norman
Re: relayd: Binding to port range
On Thu, Oct 10, 2019 at 04:45:37PM +0200, Norman Golisz wrote: > it seems relayd's configuration syntax does not allow specifying port > ranges, like 9740:10200. Am I correct? Depends on where; search for "range" in relayd.conf(5).
Certain size packets not passing through a L2 over L3 IPsec tunnel
I've set up a L2overL3 tunnel using the template as found in "man etherip". I am running OpenBSD 5.9, which I believe is the first version to support the etherip interface. I find the bridge/tunnel does not pass a small range of specific sized packets. E.g. if 1.2.3.4 is at the far end of the tunnel and I am pinging from the local end: ping -s 1388 1.2.3.4 works ping -s 1396 1.2.3.4 works All other sizes, 1389 to 1395 inclusive fail. Is there some way to remedy this? Thanks in advance. Russell P. Sutherland Email: russell . sutherland @ utoronto dawt ca Network Engineer, I+TS Voice: +1.416.978.0470 4 Bancroft Ave., Rm. 102 Cell: +1.416.803.0080 University of TorontoFax: +1.416.978.6620 Toronto, ON M5S 1C1
Re: Contribute to base
On Wed, Oct 09, 2019 at 08:49:56PM +0200, ports wrote: > Hello everybody, > > I've been a great fan of openbsd for a while and wanted to start out > contributing to openbsd's base. > > For that reason I wondered if there is a recommended way of getting to > know how the internals of openbsd work. Or isn't there ? Just head first > and see what looks most interesting? > > Thanks for your time. > > I'd appreciate any hints or tips. Most people getting to be developers have an itch to scratch. Use the system. Soon enough you'll find something you don't like or that could work better. That's the rabbit hole.
Re: Certain size packets not passing through a L2 over L3 IPsec tunnel
On 10/10/19 4:25 PM, Russell Sutherland wrote: > I've set up a L2overL3 tunnel using the template as found in "man etherip". I > am running OpenBSD 5.9, which I believe is the first version to support the > etherip interface. > > I find the bridge/tunnel does not pass a small range of specific sized > packets. > > E.g. if 1.2.3.4 is at the far end of the tunnel and I am pinging from the > local end: > > ping -s 1388 1.2.3.4 works > ping -s 1396 1.2.3.4 works > > All other sizes, 1389 to 1395 inclusive fail. > > Is there some way to remedy this? Just a friendly advice here. I am almost sure you will not get an answer on this as 5.9 is pretty old and not supported anymore for a few years now. We are at 6.5 and may be one week or two max to the release at 6.6 I would try 6.6 first and see how it works for you. There have been a truck load of changes from the 5.9 Hope this help you some even if that doesn't answer your question. However the suggestion is very valid. Daniel
