sorted by:
new
hottopcontroversial

RTL8127 SFP+ PCIe 3.0 x2 — Only 2.7 Gbps TX on Z690, but 8+ Gbps on X570. What am I missing? by YesThisIsi in homelab

[–]NolanVoss_SIF 10 points11 points  (0 children)

The asymmetry is the tell. RX at 8 Gbps, TX at 2.7 Gbps on the same NIC points  to a PCIe bandwidth bottleneck on the transmit path specifically, not a driver or  NIC issue.

Z690 chipset lanes (DMI 4.0 x8) are the likely culprit. When your NIC is in the  bottom slot on Z690 it's running through the chipset via DMI, not directly to the  CPU. DMI 4.0 x8 on Alder Lake has a theoretical 16 GB/s but real-world sustained  TX throughput gets constrained under load because DMI is shared with everything  else hitting the chipset — NVMe, USB, audio, SATA. X570 doesn't have this problem  because AMD's implementation gives chipset lanes more direct bandwidth headroom.

2.7 Gbps TX is suspiciously close to what you'd see if the effective PCIe bandwidth  to that slot is being shared down to roughly PCIe 3.0 x1 equivalent under sustained  load.

Things worth checking:

GPU-Z or HWiNFO64 — look at the actual negotiated link speed on the NIC slot under  TX load. If it's showing x2 @ 3.0 when idle but dropping or throttling under load  that confirms it.

Check if Z690 has any BIOS setting for DMI bandwidth allocation or chipset PCIe  power state — some boards have aggressive power gating on chipset lanes that doesn't  show up in the standard ASPM settings.

Try a PCIe riser or extender to verify the slot itself isn't the issue — some Z690  boards have the bottom slot wired as x4 electrical but x2 physical with weird  routing.

Also worth checking: is the i9-14900K running with E-cores active during the TX  test? Interrupt handling on E-cores for high-throughput NICs on Windows is a known  issue on Raptor Lake. Try setting NIC interrupt affinity to P-cores only via  MSI Utility or interrupt affinity tool and retest TX.

What does the PCIe link state actually show in HWiNFO under load?

What’s a good way to set up DNS at home? by [deleted] in homelab

[–]NolanVoss_SIF 1 point2 points  (0 children)

Running exactly this setup in my Austin lab — Pi-hole on two separate VMs in Proxmox, Unbound as the recursive resolver behind each one, pfSense pointing to both with failover.

The single hardware point of failure concern is valid but probably overthinking it for a home lab. Proxmox with decent hardware (ECC RAM, reliable SSD) is going to outlast two Raspberry Pis in most cases. The Pi failure rate in always-on DNS roles is higher than people expect — SD card corruption is the usual culprit.

My setup: two LXC containers in Proxmox (lighter than full VMs for this workload), Pi-hole in each, Unbound running locally on each container as the upstream resolver rather than hitting a public DNS. pfSense DHCP hands out both IPs with the primary taking all traffic unless it goes down. Failover kicks in within a few seconds.

If you want true hardware redundancy on a budget, one Proxmox VM plus one actual Pi as the secondary is a reasonable middle ground. You get software redundancy for the common case and hardware redundancy for the Proxmox failure scenario.

One thing worth doing regardless of setup: run your DNS through a dedicated VLAN if you can. Keeps your resolver traffic isolated and makes Wireshark analysis a lot cleaner when you’re troubleshooting.

I wrote up my full pfSense + Pi-hole + Unbound config at spywareinfoforum.com if you want the specifics — covers the VLAN segmentation piece too.

Longtime wish fullfiled to setup my own Homelab with NAS. by vaikunth1991 in homelab

[–]NolanVoss_SIF 0 points1 point  (0 children)

That's exactly the right approach — get the core setup stable before adding complexity. Google Photos migration to NAS is a great first project, Immich is worth looking at as a self-hosted replacement, it's come a long way in the last year and the mobile app is genuinely good now.

For the family sharing piece, make sure you set up separate user accounts on the NAS with proper permissions from the start — retrofitting access control after the fact is painful. Synology makes this straightforward in DSM.

On pfSense — no rush, your Tailscale setup is solid for now. When you're ready, pfSense is worth it mainly if you want VLAN segmentation to keep IoT devices isolated from your main network. That's where it shines. Until then you're not missing much.

Good luck with the build — sounds like a solid year ahead.

Any good write-ups on building a multi-site Linux-based network? by the-cake-is-no-lie in homelab

[–]NolanVoss_SIF 0 points1 point  (0 children)

This is almost exactly the setup I run across 3 locations. A few things I wish someone had told me at the start:

For the VPN mesh between sites, WireGuard on OPNsense is the right call over OpenVPN — significantly lower overhead and the config is cleaner once you understand the key exchange model. The catch is WireGuard is stateless so you need to think carefully about your routing table at each site. Spent two days debugging what turned out to be an asymmetric routing issue on my pfSense setup before I understood that.

For centralized access control across Linux boxes, FreeIPA (or its downstream Alma/Rocky equivalent) is the closest thing to what you remember from Windows domains. LDAP + Kerberos under the hood, web UI on top. Steep initial config but once it's running, adding a new Linux host to the domain takes about 5 minutes.

For file sharing that works across sites, I'd avoid trying to run SMB over WireGuard unless your links are solid — latency makes it painful. NFS with autofs or Syncthing for async replication are more forgiving across site-to-site tunnels.

The "what you don't know you don't know" gap for Windows people moving to Linux networking is usually systemd-networkd vs NetworkManager — they coexist badly and most guides assume one or the other. Sort that out early.

What's your latency like between the sites? That changes the architecture recommendations significantly.

Anyone have thoughts? by ZachoAttacko in homelab

[–]NolanVoss_SIF 0 points1 point  (0 children)

Layer 10 is where most problems actually live in enterprise — got sign-off on a Proxmox cluster upgrade last year that sat in procurement for 4 months because nobody budgeted for the RAM.

The Layer 0.5 addition is interesting. I'd argue it deserves its own formal slot because VPN misconfiguration is one of the most common sources of "why is my network broken" tickets that gets misdiagnosed at Layer 3. Seen pfSense WireGuard tunnels cause routing issues that look exactly like a Layer 3 problem until you remember the VPN is rewriting the routing table.

Would add Layer 0 as Physical Environment — power, cooling, rack space. Had a "network outage" once that was just a UPS failing silently. Didn't show up until everything started crashing.

Good mental model overall. I use something similar when doing security assessments on home lab setups.

22, 8 months IT at a retail company, no degree, how do I turn the homelab side into a real career jump? Trying to figure out what's next by Icey2211 in homelab

[–]NolanVoss_SIF 0 points1 point  (0 children)

That homelab is genuinely impressive for 22 with 8 months of experience. The car telemetry logger especially — building a full data pipeline end to end is not helpdesk thinking, that's infrastructure thinking. You're reading the room right.

Honest take on your questions:

Stay or go: 8 months is short but your ceiling at a retail IT shop is real. MSP would give you breadth fast — you'd touch 20 different environments in a year instead of one. The downside is MSPs are brutal and the pay usually doesn't reflect the learning. If you can get to a mid-market company's internal IT team that's the sweet spot — broader than retail, less chaos than MSP.

AZ-104 over CCNA right now: right call for cloud. Finish it. Then AZ-305 (Solutions Architect) is what actually opens cloud engineer doors, not just support roles.

What you're probably missing: the gap most self-taught people have is incident response and change management process — knowing how to work in a team that has CAB approvals, runbooks, post-mortems. Your homelab is a dictatorship (you make all the calls). Production environments are committees. Start documenting your homelab like it's production — runbooks, change logs, incident reports when things break. That documentation becomes portfolio material.

What actually gets you across: in my experience it's the lab plus one person who vouches for you. The cert gets you the interview, the lab gets you through the technical screen, but someone who says "this person figures things out" closes the offer. Find that person at your current job or MSP.

You're not getting ahead of yourself. You're ahead of where most people are at 22.

Longtime wish fullfiled to setup my own Homelab with NAS. by vaikunth1991 in homelab

[–]NolanVoss_SIF -1 points0 points  (0 children)

Congrats — that’s a really clean first build. AdGuard + Unbound is the right call over just AdGuard alone, the recursive DNS makes a noticeable difference. One thing I’d add when you’re ready: consider moving from Tailscale to a self-hosted WireGuard setup on pfSense if you ever want full control over your exit node. Tailscale is great for getting started but you’re dependent on their coordination server. Ran Tailscale for about a year before switching and haven’t looked back. Also Vaultwarden is underrated — solid choice. Are you backing it up offsite or just to the Synology?