Re: Feedback on redesigned OpenBSD.org
On Wed, 2023-08-09 at 14:01 -0500, mich...@mlpdesign.com wrote: > Hi everyone > > WHAT: > = > I greatly respect OpenBSD; while I don't have OS tech level expertise > to contribute - I do have some design skills and wanted to contribute > to the community and project. > > So I created a new CSS (stylesheet) for OpenBSD.org > > It can be viewed at: > > https://www.openbsd.design/cvs/www/index.html > This is really great and modern. My only question is why other pages are centered while the front page isn't. -- David
Re: Feedback on redesigned OpenBSD.org
On my desktop with dual 4K screens @3840x2160 (16:9) resolution the new design is basically illegible because the css wrongly determines this to be a high resolution small screen (aka phone) which is a step backwards, browser-zooming to 200% is not really an option because that also changes the layout. Also centering text blocks on the page really doesn't improve legibility on big screens.
ipsec hardware recommendation
Hi, I have star topology network where dozens of spokes communicate with other spokes through central hub over GRE tunnels protected with transport-mode ipsec. This worked great for years, but lately all the locations got bandwidth upgrade (spokes: 10Mbit -> 50Mbit, hub: 2x200Mbit -> 2x500Mbit), and I'm starting to experience problems. Spokes have APU4D4s, and my tests show they can push up to 30Mbit/s of ipsec bidirectionally. Hub has HPE DL360g9 with Xeon CPU E5-2623 v4 @ 2.60GHz and bge NICs, and it seems it can push no more than 200Mbit/s of ipsec bidirectionally (I have no chance to test this thoroughly in a lab, but what I see in production indicate this strongly). Are there any commands I can run which would indicate ipsec traffic is being throttled due to hardware being underspecced? top shows CPU is more than 50% idle. netstat shows ~1 Ierrs / Ifail (no Oerrs / Ifail) on interfaces that deal with ipsec for two months worth of uptime. Would replacing Xeon box with AMD EPYC 7262 likely result in an improvement? Should I go for some NICs other than bge? What hardware do I need at Hub location to accomodate ~400Mbit/s of ipsec bidirectionally? Thank you in advance, -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
Re: Feedback on redesigned OpenBSD.org
Hi Mark On my desktop with dual 4K screens @3840x2160 (16:9) resolution the new design is basically illegible because the css wrongly determines this to be a high resolution small screen (aka phone) which is a step backwards, browser-zooming to 200% is not really an option because that also changes the layout. Also centering text blocks on the page really doesn't improve legibility on big screens. Would you mind elaborating on what is the cause of it being illegible? E.g. font too small, the web design isn't scaling / adjusting to browser settings, etc.
Re: ipsec hardware recommendation
On Fri, Aug 11, 2023 at 01:08:07PM +0200, Marko Cupać said: Are there any commands I can run which would indicate ipsec traffic is being throttled due to hardware being underspecced? top shows CPU is more than 50% idle. netstat shows ~1 Ierrs / Ifail (no Oerrs / Ifail) on interfaces that deal with ipsec for two months worth of uptime. I believe the crypto work will show up as system% in systat(1) and top(1). I'm not sure if it is still the case but at one point it was single-threaded. Would replacing Xeon box with AMD EPYC 7262 likely result in an improvement? Should I go for some NICs other than bge? What hardware do I need at Hub location to accomodate ~400Mbit/s of ipsec bidirectionally? I would start by testing your throughput without ipsec to a system on your local ethernet segment. Maybe using something like iperf. If you can exceed your ipsec throughput you know it probably isn't the NIC driver. Try to set it up so you are testing forwarding performance. I have a Xeon D-1521 with ix(4) NICs and I can forward enough (unencrypted traffic) to saturate the 1Gbe ports on the switch. -- Please direct replies to the list.
Re: ipsec hardware recommendation
On 2023-08-11, Marko Cupać wrote: > Hi, > > I have star topology network where dozens of spokes communicate with > other spokes through central hub over GRE tunnels protected with > transport-mode ipsec. > > This worked great for years, but lately all the locations got bandwidth > upgrade (spokes: 10Mbit -> 50Mbit, hub: 2x200Mbit -> 2x500Mbit), and I'm > starting to experience problems. > > Spokes have APU4D4s, and my tests show they can push up to 30Mbit/s of > ipsec bidirectionally. Hub has HPE DL360g9 with Xeon CPU E5-2623 v4 @ > 2.60GHz and bge NICs, and it seems it can push no more than 200Mbit/s > of ipsec bidirectionally (I have no chance to test this thoroughly in a > lab, but what I see in production indicate this strongly). If possible, I suggest putting a fast client machine (laptop or server) on local network near the server and doing some tests that way. If you post your IPsec configuration, perhaps someone can suggest whether the choice of ciphers etc could be improved. It can make quite a difference. > Are there any commands I can run which would indicate ipsec traffic is > being throttled due to hardware being underspecced? top shows CPU is > more than 50% idle. netstat shows ~1 Ierrs / Ifail (no Oerrs / > Ifail) on interfaces that deal with ipsec for two months worth of > uptime. > > Would replacing Xeon box with AMD EPYC 7262 likely result in an > improvement? Should I go for some NICs other than bge? What hardware do > I need at Hub location to accomodate ~400Mbit/s of ipsec > bidirectionally? I doubt the NIC choice will be hugely important, in terms of overall network traffic pretty much anything should be able to cope with the available bandwidth. EPYC is certainly a bunch faster than the 2016 Xeon, but the 'Jaguar' AMDs in the APUs are going to be the slowest point overall. You also don't mention which OpenBSD versions you're using. That could make quite a difference. -- Please keep replies on the mailing list.
Re: Feedback on redesigned OpenBSD.org
When I first saw it there was this "aha" feeling that it was a big improvement. Good stuff! Then I read a few of the comments and looked at the pages with a bit more of a critical eye. So here are some comments and suggestions: - font size is too small; but so is the original. Lato at 14px is similar to Times Roman at 16px in words per line but it's still too small. (Chrome on windows, 100% zoom).Try 14.5px and letterspacing 0.1px and see if this is better for you. - the black box OpenBSD in top left of the index.html or part of the headers of other pages is not pretty. Think about perhaps changing to light gray, or a link colour. (Too bad there is no colour branding or other trademark colours otherwise a light blue would work.) - the h2 header font is a bit too compressed, a little more whitespace between glyphs would look less anxious. Noticed while looking at FAQ pages. Overall the revision looks really good, thanks for the effort. Hope some of this can be committed. J
Re: Feedback on redesigned OpenBSD.org
David Demelier said on Fri, 11 Aug 2023 09:48:05 +0200 >On Wed, 2023-08-09 at 14:01 -0500, mich...@mlpdesign.com wrote: >> Hi everyone >> >> WHAT: >> = >> I greatly respect OpenBSD; while I don't have OS tech level expertise >> to contribute - I do have some design skills and wanted to contribute >> to the community and project. >> >> So I created a new CSS (stylesheet) for OpenBSD.org >> >> It can be viewed at: >> >> https://www.openbsd.design/cvs/www/index.html >> > >This is really great and modern. My only question is why other pages >are centered while the front page isn't. The front page has a clickable table of contents on the left, whereas the other pages don't. So my question is, how much more work would it be to have the clickable table of contents on *every* page. By the way, I haven't looked at your HTML or CSS yet, but aesthetically I find your presentation clean and elegant. Very nice! Three possible improvements: 1) You've obviously gone the extra mile to make this site mobile friendly, and you've done it well. You might want to think about making increasing the line spacing of the clickable table of contents so one can thumb links without fatfingering. 2) Just my personal opinion: Links should be full underlined. Yes, it's not pretty, and it's so 1995, but underlined and colored links leave no doubt as to what they are and they can be quickly found with a visual scan of the document. I love that you give the user feedback on hover (changing the dots to solid underline). The more feedback the better. What I'm doing on my newer web pages (http://troubleshooters.com/web/index.htm for instance) is to change colors for hover AND for click, letting the user know "I heard you". I also change link colors once that link has been visited. I think the more feedback the user has, the better. I use full underlying with color changes to tell the user what's happening. Like I said, following my advice on link user feedback would be trading a little aesthetics for greater user feedback, so your mileage may differ. 3) I'm not sure, but I have a feeling you set your default font to be a certain size (a little bit small). If this is true, I'd recommend putting the size and exact typeface in the hands of the user's browser settings, to accommodate users of all varying visual abilities and preferences. If you follow this advice, please don't change your specifying sans-serif and your already perfect line spacing for text in and between paragraphs. I teach HTML and CSS and I couldn't have made a site this beautiful. Good work! SteveT Steve Litt Autumn 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm
Re: Feedback on redesigned OpenBSD.org
j...@bitminer.ca said on Fri, 11 Aug 2023 09:52:18 -0600 >- font size is too small; but so is the original. Lato at 14px is >similar to Times Roman at 16px in words per line but it's still too >small. (Chrome on windows, 100% zoom).Try 14.5px and >letterspacing 0.1px and see if this is better for you. In my opinion websites should specify neither the font face (Lato or Times or whatever) nor the size, either in points or percentage, especially points. This allows all visitors to read the content in a fontface they actually have on their system, and a size matching their visual acuity. SteveT Steve Litt Autumn 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm
Pausing/Freezing issues with Protectli FW4B
I'm having an issue with my Protectli FW4B that's become more of a problem lately. Essentially, it's the same thing that this person [0] encountered. I'm having keystrokes momentarily freeze when typing via ssh and am getting some ping spikes that happen anywhere from every 10-30 seconds and going from well under 1 ms in the typical case up to around 800 ms when spiking. The freezes coincide with the spikes. When connected via serial, I see the same pausing when typing or even pinging localhost, and the pausing coincides with the ping spikes remotely. ping will pause at the same time I get a spike remotely, but the actual ping time doesn't fluctuate out of the ordinary. I tried the things Stuart recommended [1] in the thread. Everything seems normal, but I admit I'm not sure what all of the finer details mean. I've included them below. I'm not too sure it's a network issue given what I'm seeing when connected via serial, but I'm also not sure if it smells of a hardware, locking/scheduling issue, or what. The base part of router is fairly simple: I enable IP forwarding in sysctl.conf, em0 is the WAN port, and em1-em3 provide different subnets for different purposes. I'm also using pf, dhcpd, unbound, wg, and vnstat. All of this works as-is, and I've tried completely disabling vnstat and pf. FWIW, this is a 1Gbps fiber connection. top shows CPU usage trends around 5%, memory usage around 25%, and 0% swap being used. Any pointers where I can investigate next would be appreciated. Tim [0] https://marc.info/?l=openbsd-misc&m=159166807203817&w=2 [1] https://marc.info/?l=openbsd-misc&m=159764612717042&w=2 --- ping 64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=0.640 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=0.601 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=139.876 ms 64 bytes from 10.0.0.1: icmp_seq=3 ttl=255 time=0.742 ms 64 bytes from 10.0.0.1: icmp_seq=4 ttl=255 time=0.744 ms 64 bytes from 10.0.0.1: icmp_seq=5 ttl=255 time=0.779 ms 64 bytes from 10.0.0.1: icmp_seq=6 ttl=255 time=0.477 ms 64 bytes from 10.0.0.1: icmp_seq=7 ttl=255 time=0.675 ms 64 bytes from 10.0.0.1: icmp_seq=8 ttl=255 time=0.753 ms 64 bytes from 10.0.0.1: icmp_seq=9 ttl=255 time=0.734 ms 64 bytes from 10.0.0.1: icmp_seq=10 ttl=255 time=0.782 ms 64 bytes from 10.0.0.1: icmp_seq=11 ttl=255 time=0.788 ms 64 bytes from 10.0.0.1: icmp_seq=12 ttl=255 time=0.698 ms 64 bytes from 10.0.0.1: icmp_seq=13 ttl=255 time=122.548 ms 64 bytes from 10.0.0.1: icmp_seq=14 ttl=255 time=0.736 ms 64 bytes from 10.0.0.1: icmp_seq=15 ttl=255 time=0.748 ms 64 bytes from 10.0.0.1: icmp_seq=16 ttl=255 time=0.816 ms 64 bytes from 10.0.0.1: icmp_seq=17 ttl=255 time=0.735 ms 64 bytes from 10.0.0.1: icmp_seq=18 ttl=255 time=0.732 ms 64 bytes from 10.0.0.1: icmp_seq=19 ttl=255 time=0.735 ms 64 bytes from 10.0.0.1: icmp_seq=20 ttl=255 time=0.706 ms 64 bytes from 10.0.0.1: icmp_seq=21 ttl=255 time=0.802 ms 64 bytes from 10.0.0.1: icmp_seq=22 ttl=255 time=0.545 ms 64 bytes from 10.0.0.1: icmp_seq=23 ttl=255 time=0.739 ms 64 bytes from 10.0.0.1: icmp_seq=24 ttl=255 time=99.840 ms 64 bytes from 10.0.0.1: icmp_seq=25 ttl=255 time=0.702 ms 64 bytes from 10.0.0.1: icmp_seq=26 ttl=255 time=0.837 ms 64 bytes from 10.0.0.1: icmp_seq=27 ttl=255 time=0.672 ms 64 bytes from 10.0.0.1: icmp_seq=28 ttl=255 time=0.772 ms 64 bytes from 10.0.0.1: icmp_seq=29 ttl=255 time=0.438 ms 64 bytes from 10.0.0.1: icmp_seq=30 ttl=255 time=0.819 ms 64 bytes from 10.0.0.1: icmp_seq=31 ttl=255 time=0.556 ms 64 bytes from 10.0.0.1: icmp_seq=32 ttl=255 time=0.685 ms 64 bytes from 10.0.0.1: icmp_seq=33 ttl=255 time=0.757 ms 64 bytes from 10.0.0.1: icmp_seq=34 ttl=255 time=0.797 ms 64 bytes from 10.0.0.1: icmp_seq=35 ttl=255 time=82.728 ms --- dmesg OpenBSD 7.3 (GENERIC.MP) #3: Tue Jul 25 08:20:26 MDT 2023 r...@syspatch-73-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8473063424 (8080MB) avail mem = 8196857856 (7817MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xec120 (49 entries) bios0: vendor American Megatrends Inc. version "5.11" date 06/18/2021 bios0: Protectli FW4B acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT UEFI LPIT CSRT acpi0: wakeup devices SIO1(S0) BRC1(S0) XHC1(S4) HDEF(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU J3160 @ 1.60GHz, 1600.34 MHz, 06-4c-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 24K
Re: Pausing/Freezing issues with Protectli FW4B
On 2023-08-11, Tim Baumgard wrote: > I'm having an issue with my Protectli FW4B that's become more of a > problem lately. Essentially, it's the same thing that this person [0] > encountered. IIRC those are the machines that have problems if there's no display connected
Re: Pausing/Freezing issues with Protectli FW4B
On Fri, Aug 11, 2023 at 5:56 PM Stuart Henderson wrote: > > On 2023-08-11, Tim Baumgard wrote: > > I'm having an issue with my Protectli FW4B that's become more of a > > problem lately. Essentially, it's the same thing that this person [0] > > encountered. > > IIRC those are the machines that have problems if there's no display connected I put in a dummy HDMI plug from another piece of tricky hardware, and that seems to have fixed it. 200 pings and not a single spike over 1 ms. Thanks! Tim
Re: Feedback on redesigned OpenBSD.org
Hi all Ok, here's is update2 to the design. Note: I still need to break this down into individual patches for review but wanted to get feedback on the aesthetics first. v1: https://www.openbsd.design/cvs/www/index.html v2: https://www.openbsd.design/cvs/www2/index.html What's Change in v2: Based on feedback either directly or on the mailing list, I did the following: *** Note: I have only focused on the Light Theme for this version *** - Removed puffy from footer - Removed all web fonts (just system defaults now) - Increased the line-height - Reverted most (but not all) colors back to either browser defaults or what's on openbsd.org - Increased font-size (and specified it in 'em') - Removed the max-width of 840px (now full-width) - Removed/reverted the black OpenBSD logo back to what's on openbsd.org For what it's worth, here's my thoughts about the new design: Polish: My main concern is that it's not as polished as v1, and that could determine future OpenBSD users. Readability: Readability is significantly worse in v2 vs. v1 - Line Length, by making the line length unlimited in width, it makes it extremely difficult to read body text. Reason being, your eye needs to track to the next line. The rule of thumb is, the longer the line length the bigger the line-heigh needs to be. When the line length can be unlimited long, it's difficult to set an appropriate line-heigh which hurts readability. - Colors, the more colors that are present, the more distracting a website will become. That's ok if it's a marketing website, but a site that's primarily documentation - you want to reduce the color palette down to only 2 (3 max) colors. This is why technical manuals are mostly created in grayscale, because color very much distracts the eyes and makes it more difficult to read body text. I feel like v2 color palette, which are peoples ask to revert to the previous color palette causes that. (And I still haven't revert to all of the openbsd.org colors) But that's just my opinion. Ask: I'm curious to hear from others if v2 is more aligned with your desire for the look of the updated site. -mlp
[cpb_m...@bennettconstruction.us: I would like help matching my outgoing domains to the right IP for smtpd]
- Forwarded message from Chris Bennett - To: misc@openbsd.org From: Chris Bennett Subject: I would like help matching my outgoing domains to the right IP for smtpd Date: Fri, 11 Aug 2023 18:13:59 -0700 Hello, as I was updating to the new IP ranges, I changed ~all to -all (My old IP's were crap filled with spam, so I just didn't send mails to the big guys.) I tried sending to gmail.com and got smacked that the spf was referring to an unexpected address on the server. I found that I was getting "random" choices from the tables I had setup. Reading the manpage carefully, I saw that this was the correct behaviour. If the headers in this email are correct, then I have the right action. I can't figure out how to match the outgoing mails to the correct IP/mx they are coming from. Just one server, different A records for the mx versus domain name. Right now, I'm just forcing all local to this action. After several hours trying different options and testing sending to my other server, I'm coming up blank. Except that I now understand much more from the manpages that confused me previously. I've been reading a lot of other manpages lately, too. Time well spent. Any advice would be nice. -- Chris Bennett - End forwarded message - --
Re: Feedback on redesigned OpenBSD.org
I'm going to add my couple bits worth.
Summary: I prefer v2 apart from line length; a max might be better.
I'm reading on a laptop with a fairly large display (1920x1200), using
Chrome.
On Fri, 11 Aug 2023 18:33:03 -0500, mich...@mlpdesign.com wrote:
[snip]
> What's Changed in v2:
>
[...]
> - Removed all web fonts (just system defaults now)
I can't tell if I like the system fonts better than the custom ones,
because they're not equal in size, so there are too many combined
differences to be sure.
> - Increased the line-height>
Specified in ex? Or something else?
[ ...]
> - Increased font-size (and specified it in 'em')
The overall change in font is much better for me. I recognize that
small and fancy seems to appeal more to those with a twenty-year old's
eyesight (20:20), but my eyes are presbyopic and larger fonts appeal
much more. Using em to specify relative sizes also means that my
default choices are consulted, and I like that.
> - Removed the max-width of 840px (now full-width)
Not too happy about this, though; it's definitely harder to track lines
as long as they end up being (I can solve that myself by narrowing the
window, of course, but I usually can't be bothered). I've found it
useful to specify line height in ex, and max width in em. For sites
with large blocks of text in paragraphs, setting the max width for p to
somewhere around 50-60 em tends to make the text fit the eight to ten
word English standard (it's maybe a little generous, but I find it
avoids the problem of lines so long one gets lost somewhere between
left margin and right).
> For what it's worth, here's my thoughts about the new design:
>
> Readability: Readability is significantly worse in v2 vs. v1
I will defer to other's sense of style, but for readability I have to
strongly disagree; at least within my setup v2 is much more readable
and (importantly, I think) gives more deference to my preferences on
default sizes and font choices.
> - Line Length, by making the line length unlimited in width, it makes it
> extremely difficult to read body text. Reason being, your eye needs to
> track to the next line. The rule of thumb is, the longer the line length
> the bigger the line-heigh needs to be. When the line length can be
> unlimited long, it's difficult to set an appropriate line-heigh which hurts
> readability.
Agreed. I think you ought to restore a max, also specified in em, with
a corresponding line height in ex.
>
> - Colors, the more colors that are present, the more distracting a website
> will become. That's ok if it's a marketing website, but a site that's
> primarily
> documentation - you want to reduce the color palette down to only 2 (3 max)
> colors. This is why technical manuals are mostly created in grayscale,
> because color very much distracts the eyes and makes it more difficult to
> read body text. I feel like v2 color palette, which are peoples ask
> to revert
> to the previous color palette causes that. (And I still haven't revert to
> all of the openbsd.org colors)
I'd kind of like to see a v2 with your typographically-selected colors
for text blocks restored (that is, mostly grayscale, so black on white
(or dark gray on cream, for that stylish effect, perhaps) in the light
theme. It might, though, be worthwhile to maintain project team's
colors for highlights and headings and accents and things. I dunno.
Amy!
--
Amelia A. Lewisamyzing {at} talsever.com
Money can't buy happiness, but poverty can't buy *anything*.
Re: Feedback on redesigned OpenBSD.org
When did it become an assumption that we would adopt any of these changes?
I would like help matching my outgoing domains to the right IP for smtpd
Hello, as I was updating to the new IP ranges, I changed ~all to -all (My old IP's were crap filled with spam, so I just didn't send mails to the big guys.) I tried sending to gmail.com and got smacked that the spf was referring to an unexpected address on the server. I found that I was getting "random" choices from the tables I had setup. Reading the manpage carefully, I saw that this was the correct behaviour. If the headers in this email are correct, then I have the right action. I can't figure out how to match the outgoing mails to the correct IP/mx they are coming from. Just one server, different A records for the mx versus domain name. Right now, I'm just forcing all local to this action. After several hours trying different options and testing sending to my other server, I'm coming up blank. Except that I now understand much more from the manpages that confused me previously. I've been reading a lot of other manpages lately, too. Time well spent. Any advice would be nice. -- Chris Bennett
Re: ipsec hardware recommendation
> On 11 Aug 2023, at 21:08, Marko Cupać wrote: > > Hi, > > I have star topology network where dozens of spokes communicate with > other spokes through central hub over GRE tunnels protected with > transport-mode ipsec. > > This worked great for years, but lately all the locations got bandwidth > upgrade (spokes: 10Mbit -> 50Mbit, hub: 2x200Mbit -> 2x500Mbit), and I'm > starting to experience problems. > > Spokes have APU4D4s, and my tests show they can push up to 30Mbit/s of > ipsec bidirectionally. Hub has HPE DL360g9 with Xeon CPU E5-2623 v4 @ > 2.60GHz and bge NICs, and it seems it can push no more than 200Mbit/s > of ipsec bidirectionally (I have no chance to test this thoroughly in a > lab, but what I see in production indicate this strongly). > > Are there any commands I can run which would indicate ipsec traffic is > being throttled due to hardware being underspecced? top shows CPU is > more than 50% idle. netstat shows ~1 Ierrs / Ifail (no Oerrs / > Ifail) on interfaces that deal with ipsec for two months worth of > uptime. > > Would replacing Xeon box with AMD EPYC 7262 likely result in an > improvement? Should I go for some NICs other than bge? What hardware do > I need at Hub location to accomodate ~400Mbit/s of ipsec > bidirectionally? >From recent experience it looks like IPsec, and the crypto processing in >particular, still runs under the giant kernel lock. This means you're only >going to go as fast as a single core can go, and you'll be particularly >sensitive to contention on that lock. The things you can do Right Now(tm) are: - upgrade to a system with the fastest single core performance you can afford - upgrade to -current the pf purge code has been taken out from under the big kernel lock. if you have a lot of pf states, this will give more time to crypto. - pick faster crypto algorithms you might already be using the fastest, so maybe this wont help. - terminate ipsec on multiple hosts two kernels will be faster than one. however, this adds complexity to the network, so not an obvious benefit. - try wireguard? if it's a single tunnel IP tunnel (ie, one gre(4), and not egre(4)) between the hubs and spokes then wg might be simpler and faster. simpler because wg is less layers than gre over ipsec, and faster cos it should be able to do crypto in parallel. in the future i'm sure the ipsec stack will improve, but it's hard work that takes time. dlg > > Thank you in advance, > > > -- > Before enlightenment - chop wood, draw water. > After enlightenment - chop wood, draw water. > > Marko Cupać > https://www.mimar.rs/ >
Re: Feedback on redesigned OpenBSD.org
Hi Theo No assumption on my part at least. I’d hugely value hearing you input if you have time though. E.g. are you open to these types of updates. If so, which parts would & wouldn’t you be supportive of. Etc. Thanks in advance. On 2023-08-11 21:11, Theo de Raadt wrote: When did it become an assumption that we would adopt any of these changes?
Re: Feedback on redesigned OpenBSD.org
On Fri, 11 Aug 2023 20:11:02 -0600, Theo de Raadt wrote:
> When did it become an assumption that we would adopt any of these
> changes?
I don't think that it did become an assumption, but as a number of
people have responded to the initial design, to the point that the
designer offered a revision, I thought I might add to the discussion. I
apologize if it was out place to do so.
Amy!
--
Amelia A. Lewisamyzing {at} talsever.com
Never imagine yourself not to be otherwise than what it might appear to
others that what you were or might have been was not otherwise than what
you had been would have appeared to them to be otherwise.
-- The Duchess [Lewis Carroll]
Re: I would like help matching my outgoing domains to the right IP for smtpd
Am 12.08.2023 03:13 schrieb Chris Bennett: I can't figure out how to match the outgoing mails to the correct IP/mx they are coming from. Just one server, different A records for the mx versus domain name. Difficult to understand what you're trying there... I kinda understand that you have multiple IP-addresses on that smtpd machine and need to send from a "correct" one? If so, check back that 'action' with a relay delivery has a 'src' option. HTH, -- pb
Re: I would like help matching my outgoing domains to the right IP for smtpd
On Sat, Aug 12, 2023 at 03:49:12AM +, Philipp Buehler wrote: > Am 12.08.2023 03:13 schrieb Chris Bennett: > > I can't figure out how to match the outgoing mails to the correct IP/mx > > they are coming from. Just one server, different A records for the mx > > versus domain name. > > Difficult to understand what you're trying there... > I kinda understand that you have multiple IP-addresses on that smtpd > machine and need to send from a "correct" one? > If so, check back that 'action' with a relay delivery has a 'src' option. > > HTH, > -- > pb > I have one server with multiple IP addresses. For example, bennettconstruction.us at one IP, with A record mx.bennettconstruction.us at the same machine, different IP with it's own A record. Plus, several other website and mail domains on the same server. In each case, each has it's own A record and IP, one for a domain name, the other for it's mail domain. bennettconstruction.us 1.2.3.4 mx.bennettconstruction.us 1.2.3.5 moron.org 1.2.3.6 mail.moron.org 1.2.3.7 wisecracker.com 1.2.3.8 mx.wisecracker.com 1.2.3.9 I'm trying to get the proper mail server to match the sent From: domain. Also, with this switch changing the hostname, root now comes through bennettconstruction.us instead of the other one that was the hostname before. The change in hostname was planned. In case it's relevant, I always use ssh and neomutt to the server for reading and sending. I only use K9 on my phone to read or click a link. Thank you for putting up with my hard to understand posts. It's not deliberate, but a lifelong problem. -- Chris Bennett
Re: Feedback on redesigned OpenBSD.org
Aug 12, 2023 01:43:10 mich...@mlpdesign.com: > > Ask: I'm curious to hear from others if v2 is more aligned with your desire > for the look of the updated site. I think is much better. And I think that when you align to standards it is difficult to lose in readability. I'm just checking by my tablet and verifying the vertical orientation I still find small the font under a certain screen width.. ;D -- Daniele Bonini Aug 12, 2023 01:43:10 mich...@mlpdesign.com: > > Ask: I'm curious to hear from others if v2 is more aligned with your desire > for the look of the updated site.
Re: I would like help matching my outgoing domains to the right IP for smtpd
On Sat, Aug 12, 2023 at 03:49:12AM +, Philipp Buehler wrote: > Am 12.08.2023 03:13 schrieb Chris Bennett: > > I can't figure out how to match the outgoing mails to the correct IP/mx > > they are coming from. Just one server, different A records for the mx > > versus domain name. > > Difficult to understand what you're trying there... > I kinda understand that you have multiple IP-addresses on that smtpd > machine and need to send from a "correct" one? > If so, check back that 'action' with a relay delivery has a 'src' option. > > HTH, > -- > pb > action "benn_to_outbound" relay src 108.181.26.184 helo mx.bennettconstruction.us If this is correct, it works fine. However, right now, I am forcing a match with match from local for anyaction "benn_to_outbound" I haven't been able to think of a way to match each individual one. -- Chris Bennett
