2.5 GbE in the homelab: when it pays off

Your network card says 2.5 Gbit/s. Your hard disk says: nice try. Find out which of the two decides before you buy a single cable.

The short answer

2.5 Gigabit Ethernet (2.5GBASE-T) pays off when the network is really the slowest link between two devices: a NAS with fast disks or SSDs, a workstation that moves large files, or an internet line above 1 Gbit/s. It is standardised in IEEE 802.3bz and aims to run over existing Cat5e cabling [1][2][3]. You need a network card on both ends, a switch whose ports all speak 2.5G, and a measurement that proves the gain. Our assessment: measure first. A real 1GbE link carries about 118 MB/s of useful payload, and a single fast hard disk can exceed that in large sequential transfers (the Seagate IronWolf data sheet lists sustained transfer rates of up to 240 MB/s [13], and the WD Red Pro data sheet up to 287 MB/s [14]). So even one disk can benefit significantly from 2.5G. What counts is the measured bottleneck from end to end: storage, CPU, protocol and the rest of the path, not the number of disks. Several disks, SSDs or an internet line above 1 Gbit/s can help as well [13][14]. If the measurement shows the link is full, the upgrade is cheap and low-risk. If not, you would buy speed you cannot use.

How it works

1. What 2.5GBASE-T is. IEEE approved the amendment 802.3bz-2016 on 22 September 2016 and published it on 18 October 2016. It defines Ethernet at 2.5 and 5 Gbit/s over twisted-pair copper [1]. The NBASE-T Alliance, the industry group behind the technology, describes it as a way to speed up existing Cat5e and Cat6 networks without changing the cabling [2]. A 2.5G port also negotiates down to 1 Gbit/s and 100 Mbit/s with older devices; vendor datasheets of 2.5G switches list "100M/1G/2.5G" ports [12]. The connector stays the usual RJ-45.
2. The numbers on paper. 2.5 Gbit/s is 312.5 MB/s on the wire, and 1 Gbit/s is 125 MB/s. Real transfers carry protocol overhead. With the standard frame size of 1,500 bytes, a TCP stream with common options moves roughly 94 percent of the line rate as payload. That gives about 118 MB/s on a gigabit link and about 294 MB/s on a 2.5G link (our calculation, not a measurement). A copy of 100 GB takes about 14 minutes at 118 MB/s and about 6 minutes at 294 MB/s, if nothing else slows it down.
3. Where the real bottleneck sits. Look at the storage first. Seagate's datasheet for its 3.5-inch IronWolf NAS drives (10 to 18 TB) lists a maximum sustained transfer rate of up to 240 MB/s, measured at the outer edge of the platter [13]. Western Digital's datasheet for the Red Pro lists internal transfer rates of up to 287 MB/s for its largest models [14]. These are best-case figures at the start of the disk. Both drives use SATA 6 Gbit/s, which is about 600 MB/s after line encoding (our calculation) [13][14]. Reading the numbers: one fast disk can fill a gigabit link and still fits under a 2.5G link. Several disks in an array, or SSDs, can deliver more than 294 MB/s, and then the 2.5G link becomes the limit. Small files and many parallel requests are a different story. They are limited by latency and the file-sharing protocol, not by the link (our assessment). The NAS CPU and the disk on the receiving computer count as well.
4. The internet line. If your provider sells more than 1 Gbit/s, a router, switch or computer with only a 1G port caps what one device can reach. A router with a 2.5G or faster WAN port, and one client on 2.5G, can use the whole line. Check the actual line speed with a test first, and check the link between your modem-router and your own router. Our own records show why. As of 14 October 2026, the cable line is listed with 1.1 Gbit/s downstream according to the modem-router. A link between the modem-router and our router had been measured at only 100 Mbit/s on 7 October 2026, with cable swap and final measurement still open. We do not state today's link speed. A 2.5G upgrade inside the LAN would not have helped that link.
5. Cables: Cat5e is the target. The IEEE task force set the goal of a 2.5 Gbit/s PHY for at least 100 m on four-pair Class D (Cat5e) cabling for the defined use cases [3]. In the committee's own tests, 2.5 Gbit/s links worked in the cabling configurations of the use cases [4]. The tests also showed that crosstalk from neighbouring cables in a bundle matters. Separating cables at both ends was the "big lever", according to the test summary [4]. For 5 Gbit/s the task force's objective is Cat6 for 100 m [3]. For 10GBASE-T, one vendor datasheet lists Cat6 only up to 55 m, while 2.5GBASE-T on Cat5e or better reaches 100 m [18]. Our assessment: most existing Cat5e runs in a home or small office should work. If a port falls back to 1 Gbit/s, suspect the patch cable, a damaged or very long run, or a tightly bundled cable, in this order, and swap the short patch cable first.
6. Network cards and Linux drivers. Two chip families cover most 2.5G cards and motherboards. Intel's I225 and I226 use the in-kernel driver igc. Intel notes that a standalone, out-of-tree igc driver is unsupported, and its support matrix marks I225 as supported with Linux 5.8 and I226 with 5.16.18 [5]. Early I225 silicon has a documented erratum. Intel's specification update (revision 1.2, November 2020) says the first version (V1) accepts a minimum inter-packet gap of 8 bytes instead of the 5 the standard requires, so with some link partners packets are dropped and the link falls below 1 Gbit/s, in some cases to 1 to 10 Mbit/s. Intel lists limiting the speed to 1 Gbit/s as a workaround and states that V2 fixes it [7]. A separate Intel support article for I225-V boards describes dropped connections and tells you to update the firmware (NVM) and the driver through the board manufacturer's download page [6]. For Realtek's RTL8125, the Linux maintainer added support to the in-kernel r8169 driver, which went into Linux 5.4 and needs a recent linux-firmware package [8]. The RTL8125B variant was announced for Linux 5.9 [9]. Realtek also publishes a separate r8125 vendor driver. Users in the Red Hat bug report had to build that module themselves, which taints the kernel and needs a rebuild after kernel updates [9]. Our assessment: before you buy, find the exact chip, check which kernel driver your distribution uses (lspci -nnk), and prefer cards whose chip the in-kernel driver already supports. We did not research other chip makers for this article.
7. Switches: unmanaged, managed, fans, power. An unmanaged switch has no configuration. A managed switch adds VLANs, monitoring and more, at the price of setup work. The datasheets we read show typical differences. Zyxel's 5-port unmanaged XMG100 lists a maximum power consumption of 9.12 W, a minimum of 1.56 W and a fanless design, with one 10G SFP+ uplink next to five 2.5G ports [10]. TRENDnet's TEG-S351 lists 4.5 W maximum and no fan [11]. In the managed class, Zyxel's XMG1915 family covers an 8-port smart-managed model with a maximum of 13.13 W, 0 dBA acoustic noise and no fan, while the 16-port PoE model of the same family has a smart fan, an acoustic range of 19.71 to 42 dBA and a maximum of 230.81 W because of its PoE budget [12]. Read these as limits from the datasheets, not as the power you will see at the wall, and measure with a plug meter if it matters. Our assessment: a 2.5G switch for a desk or shelf should be fanless and unmanaged unless you need VLANs. Every switch between two 2.5G devices must also speak 2.5G, or the slowest hop decides the speed. Leave jumbo frames off until every device on the path supports them.
8. Measure with ethtool and iperf3. First check what each side negotiated: sudo ethtool enp5s0 | grep -E 'Speed|Duplex|Link detected' should say Speed: 2500Mb/s [17]. Then measure the network alone with iperf3, which generates its own data and takes disks out of the picture [15]. Start the server on one machine with iperf3 -s (TCP port 5201 by default) and run the client on the other: iperf3 -c 192.0.2.10 -t 30 -O 3. -t sets the duration in seconds, and -O 3 leaves out the first three seconds, which skips TCP slow start [16]. Add -R to test the other direction [15] and -P 4 to run four streams in parallel [16]. A healthy 2.5G link shows values around 2.3 to 2.4 Gbit/s with the default frame size (our calculation from item 2). Values near 940 Mbit/s mean the link negotiated 1 Gbit/s. To see whether the storage is the bottleneck, the iperf3 documentation offers -F, which uses a file as the data source or sink, and notes that it does not turn iperf3 into a file-transfer tool [15]. Finally copy a real large file and compare. If iperf3 shows 2.3 Gbit/s and the copy shows 110 MB/s, the disk or the file-sharing protocol is the limit.

When 2.5G pays off

A worked example (calculation, not a test)

This is a plan for your own network, not a report on our systems. Assume a NAS with four hard disks in an array, one workstation, a gigabit switch and Cat5e cables. First measure the starting point: iperf3 -s on the NAS, iperf3 -c <NAS-IP> -t 30 -O 3 on the workstation. A result near 940 Mbit/s says the link is full; a copy of a 100 GB folder at about 118 MB/s takes about 14 minutes. Compare that with the disks: four drives at 210 MB/s, the datasheet value for the smaller 10 and 12 TB models (the 14 to 18 TB models list 240 MB/s), would sum to 840 MB/s as an upper bound [13], more than the link can carry, though real array speeds are lower. So the link is the limit. Replace the workstation's network card (or use the 2.5G port on its board) and the NAS port (or add a card) and the switch with a 2.5G model. Reuse the Cat5e cables. Then run the same iperf3 command again. A result near 2.35 Gbit/s confirms the link; the 100 GB copy should then take about 6 minutes if the array keeps up. If the iperf3 value is high and the copy is still slow, stop spending money on the network and look at the disks or the protocol.

Checklist

• Measure your current network with iperf3 -s and iperf3 -c before you buy anything, in both directions with -R.
• Compare the result with the datasheet speed of your drives and with your real file copies, and write down the numbers.
• Check the negotiated speed on every device with ethtool and note ports that sit at 100 Mbit/s or 1 Gbit/s unexpectedly.
• Find the exact chip of every card or board, and check which kernel driver lspci -nnk shows.
• Update the board or card firmware from the manufacturer if you use an Intel I225-V, and read Intel's notes on the first silicon revision [6][7].
• Plan every hop between the two devices: each switch and each port on the path must support 2.5G.
• Reuse existing Cat5e cables first, and replace only the patch cable if a link falls back to 1 Gbit/s [3][4].
• Choose a fanless unmanaged switch for a desk, a managed one only when you need VLANs, and check the datasheet for maximum power and noise [10][12].
• Keep jumbo frames off until all devices on the path are set up for them.
• Repeat the measurement after the upgrade and keep the before and after numbers.