Messages

Correct. But problems with Intel chipset have been reported earlier:

https://www.hwcooling.net/en/realtek-rtl8126-suffers-from-instability-no-5-0gb-s-ethernet-this-year/

It is also clear that the cards have a problem with ASPM:

https://forums.servethehome.com/index.php?threads/realtek-10-gbe-usb-adapters-might-be-on-the-way.47683/post-489414

Wanna buy my adapters?

Correct: RA mode must be unmanaged for SLAAC. I only saw "RA is not selected either", so you use RADVD.

[client]

It does not work like that (you already noticed, didn't you?).

Like with IPv4, there is two sides:

- WAN
- LAN

On WAN, you have to use whatever means it takes to get a WAN IP, often DHCPv4 and DHCPv6 as a client.

On LAN, you use DHCPv4 and (probably DHCPv6) as server. ALternatively, you can use SLAAC (RA) instead for IPv6.

You did neither: ISC DHCPv6, DNSmasq, RAdvd, all disabled. So how would clients get what they need. You must have IPv6 supplied to your LAN, otherwise it will not work.

There is a guide on how to do this via DNSmasq only in the official docs, instead, I prefer to do it like this.

No, but the reports on the internet were all over the place and some were Intel boards, too, like this:

https://www.reddit.com/r/Fedora/comments/1p1syhw/realtek_rtl8127_dropping_out/

Nope. In that BIOS, I can only set the PCIe speed for the CPU lanes and the chipset lanes separately, not per slot. And since the CPU lanes are solely used for the graphics card, I can only set all of the chipset lanes together, crippling my NVME drives.

Apart from that, I suspect that these problems are with the NICs - when you skim through the reports, you will find newer affected chipsets like X870. I doubt that my Asrock board is the culprit here and maybe even going back to PCIe 3.0 would not cut it.

After having seen these corruption problems and all my time invested chasing ghosts, I won't place any more bets on these things, either.

P.S.: I have an Aquantia here, as well. Never worked right. I even had a conversation with their CEO on that back in the day...

[TL;DR: The newer Realtek chips RTL8126 and RTL8127 do not run reliably on older hardware that "supports" PCIe 4.0.]

Well, you could say I should have known better - yet, I tried:

Recently, I saw an article about the new RealTek RTL8127 NIC. On paper, it looks fine: 10/5/2.5/1 Gbps, low power draw and PCIe 4.0 x1 interface, which makes it easy to fit into any mainboard - or so it seems.

Main main reason to use it were the shortcomings of other high speed RJ45 adapters, like the X550-T1. That one:

- uses much more power
- needs a PCIe 3.0 x4 slot
- cannot handle autonegotiation on some OSes

Because I have not-so-good CAT.5E cabling, I like to use 5 Gbps, but with newer Windows drivers, you cannot even fix speeds at NBase-T (5 or 2.5 Gobs), so you are mostly stuck with 1 or 10 Gbps only. Linux is a prominent example where the driver allows intermediate speeds, see this for details.

I already had a Realtek RTL8126, which can do 5 Gbps at most, but that one had a quirk: On cold boots, it was sometimes not detected at all. Only a power-cycle would help. The internet is full of discussions about that. So, I went for it and bought the RTL8127...

...only to find that it had the same quirk.

But now comes the hard part: My Windows 11 installation has gone awry in the last few weeks. Basically, I could not start Steam and Ollama any more. Nothing I did could repair it.

On I went with a new installation from scratch and restoration of my user files afterwards. Then, I had to install every application again.
System worked fine for ~24 hours, then I noticed strange things happening: My desktop icons flashed ever 0.5 seconds and I could no longer set the default browser. No repairs worked here, either.

Since I still had the profile backup, I decided to repeat the whole process. While I was doing that, I tried to relocate the RTL8127 into another PCIe slot. This time, the restoration of my user profile showed 3 CRC errors. I was quite sure there were no problems on the source.


So, the plot thickened: Obviously, in my X570 board, the PCIe 4.0 slots attached to the chipset have problems. The X570 chipset was the first to use PCIe 4.0, so the implementation may be flaky. At the time, nobody would have noticed, because most PCIe cards only supported PCIe 3.0 anyway.

Now, the problem manifests in two ways:

1. The NICs may sometimes go undetected during cold start PCIe training.
2. The data that is transferred to the mainboard can get corrupted. This became very obvious when I installed some 500 GByte of software and data over the network.

I am quite sure that this caused all the other problems, too.


TL;DR: The newer Realtek chips RTL8126 and RTL8127 do not run reliably on older hardware that "supports" PCIe 4.0.

Of course, this is independent of OS. You might also say that is not Realtek's fault, but at least, it does not happen with the Intel X550-T1, which only uses PCIe 3.0. BTW: It only works with either PCIe x4 or x1, so my x2 slot was a waste.

OpnSense, wenn es auf ZFS installiert ist, hat ein eingebautes Snapshot-Feature - dazu braucht es keine VM.

[may]

SFP+ slots support at least 1 and 10 Gbps speeds. Only some support 2.5 and 5 Gbps with a mode called HSGMII, which needs different frequencies.

Thus, the dual-slot AX adapter may support SGMII frequency / mode, just not mixed with another module that uses frequencies for 1 or 10 GBps (not withstanding that some SFP+ ethernet modules work with 10 Gbps on the SFP+ side and can adapt to 1/2.5/5/10 Gbps on the ethernet side).

That being said, I think 1000 Mbps SGMII mode is different from "normal" 1000 Mbps mode like what is used in an SFP slot - at least I think I remember to have seen something in the speed and duplex settings of my DEC750 ax interfaces, but I am not sure.

The Luleey modules is known to not work with a Mellanox Connect-X3 and maybe others. Because of the problems with HSGMII speeds, I have switched to external GPON ONTs with 2.5 Gbps ethernet - those work just fine.

At this time, I would probably go directly to an XGS-PON SFP+ stick - it should work with 10 Gbps right away and you can still use it when you ISP makes the switch.

This does not look like an MTU issue if you can use those ping sizes - it look just fine.

Did you also use traffic shaping? Maybe the old ISP had lower speeds and you shape it to fit? Happened before...

Just saw that you disabled all shaping...

No idea what could be wrong.

The HP Elitedesk 800 G3 i7-7700 as per spec sheet has an onboard Intel I219-LM adapter that might do funny things because it is equipped with Intel VPro.

This function may still be active if the device came from a company that uses central device management. You can probably disable it in the BIOS, but YMMV.

same config (dual stack, IPv6 via PPPoE) gives me lower MTUs:

1. Same config as who?
2. Note the caveat to reboot after having applied the settings.
3. When you read the HOWTO closely, you will find that this does not work in all cases - especially, your ISP must support it. The safe value to set MTU to with PPPoE (regardless of VLAN) is 1492.

[note that after changing those values, the results will only be reproducable after a reboot, because the order of settings matter (i.e. they influence one another)]

I always configure this like shown here, which also uses full 1500 bytes MTU.

My result looks like your first picture, i.e.:

Direction Tested	Maximum Size	Segment	Client Sent	MSS	Notes
Server to Client	IPv4	1460	1460	OK
Client to Server	IPv4	unlimited	(n/a)	OK
Server to Client	IPv6	1440	1440	OK
lient to Server	IPv6	unlimited	(n/a)	OK

Code Select Expand

got in probe for mss 536 (max seg 1460)
got in probe for mss 1460 (max seg 1460)
got in probe for mss 1460 (max seg 1460)
finished in probing, maximum mss 1460 peer mss 1460 initial peer mss 1460
got out probe for mss 520
got out probe for mss 1461
got out probe for mss 9000
finished out probing, maximum mss 9000
got in probe for mss 536 (max seg 1440)
got in probe for mss 1440 (max seg 1440)
got in probe for mss 1440 (max seg 1440)
finished in probing, maximum mss 1440 peer mss 1440 initial peer mss 1440
got out probe for mss 520
got out probe for mss 1441
got out probe for mss 9000

And there are my exact settings (note that after changing those values, the results will only be reproducable after a reboot, because the order of settings matter (i.e. they influence one another)).

You cannot view this attachment.

You cannot view this attachment.

You cannot view this attachment.

You cannot view this attachment.

What exactly do you mean "use the device's MAC instead"? Is it possible to use MAC addresses instead of IPs in OPNsense? Or are you talking about the LLA (fe80:) address?

Yes, via a MAC alias.

I thought if a device used the IPv4 address of the DNS server, the DNS server would only give an IPv4, or the client would default to sticking with IPv4. If this is the case that the client will get an IPv6 and use the IPv6, then yes, it really wouln't matter if I just keep the DNS servers with IPv4 addresses.

That misconception is very common. And wrong, as I wrote.

Yes, for those clients that can only use SLAAC (Android and IoT devices being main culprits on my network), I don't bother with DHCPv6 for those devices. But the systems that do support DHCPv6, I setup for SLAAC + a fixed GUA address, as a couple I have open to the WAN via GUA IPv6 addresses.

As I said: You can do the same via MAC aliases and do not have to rely on the device using any specific EUI-64. If you read my HOWTO, you will also understand why DHCPv6 is completely unneeded:

1. You do not need it to regulate traffic - even more so, you cannot rely any device to use any IPv6 you hand out via DHCPv6. Use MAC-based aliases, if you want to.

2. You also do not need it to make your devices "addressable" with a fixed assigment of a DNS name <-> IPv6, becaus you can do that as well via IPv4.

3. You do not need to distribute a DNSv6 server, because a DNSv4 server can do the same.

[does not change the content of the html]

The reverse proxy cannot handle all of what is needed when you want to present two websites via different URI paths.

Say, your backend server creates web pages containing embedded image links with the absolute path itself knows about, like, when server1.domain.internal shows a snippet of: <img src="/images/xyz.jpg">. Since the reverse proxy does not change the content of the html, it will then not reference https://myapps.domain.internal/app1/image/xyz.jpg, but https://myapps.domain.internal/image/xyz.jpg, which is wrong. Same goes for CSS and Javascript snippets.

And that does not even consider cases where your internal server creates absolute links like <img src="https://server1.domain.internal:8001/images/xyz.jpg">, like many applications do.

So, in order to make this work, the paths may not change unless you can configure your backend application to use either relative paths only or you can configure its "real" URL to be https://myapps.domain.internal/app1/.

An alternative remedy could be to use app1.domain.internal and app2.domain.internal, so your URI paths do not change (but that only addresses the "absolute path", not the "full URL"  problem). The reverse proxy differentiates the backend "by name" instead of "by path" in that case.

This "partial IPv6" (aka dynamic IPv6 alias) is only available as firewall alias and its main purpose is to create firewall rules for IPv6 clients when you have dynamic IPv6 prefixes. BTW: the more general approach would be to use the device's MAC instead, because the EUI-64 is not the only way an IPv6 device can communicate - think of IPv6 privacy extensions. It is no means to specify IPv6 addresses anywhere else.

As for DNS (or any other) services on your network: Keep in mind that you do not need a specific DNSv6 server at all, because IPv6 can be resolved via DNSv4 just fine. So, if you have dual stack on your LAN and have a working DNSv4 server, you are all set.

Thus, you usually do not need to distribute DNSv6 via DHCPv6 at all. Strictly speaking, you do not need DHCPv6 either and with dynamic IPv6 prefixes, you should probably better use SLAAC in the first place. See this for why.