Quattro porte 2.5GbE, due porte 10GbE RJ45, scocca fanless e un'auto-negoziazione che non sbaglia un colpo. Il TRENDnet TEG-S762 è entrato nel mio rack come switch dedicato al nodo failover del cluster Proxmox — quello dove un giorno o l'altro toccherà migrare i container critici se il nodo principale ha un'emergenza. Volevo uno switch piccolo, silenzioso, che non strozzasse il 2.5G della NIC dell'host. L'ho collegato e il link è salito al primo colpo a 2500 Mbps full duplex.
In collaborazione con TRENDnet — sample TEG-S762 fornito per la review. Test, misure e impressioni sono interamente miei.
Ho ricevuto il sample da TRENDnet e l'ho messo subito al lavoro sul pve2. Il primo benchmark dice già la cosa che volevo verificare: il path pve↔pve2 attraverso MokerLink core e TRENDnet failover, con i due switch interconnessi a 2.5G, satura davvero a 2.5G end-to-end.
TRENDnet TEG-S762: cosa metti in casa con sei porte
Il TEG-S762 è un unmanaged puro — niente web UI, niente VLAN, niente STP. Lo colleghi e funziona. Sei porte totali: quattro RJ45 2.5GBASE-T (1G/2.5G) e due RJ45 10GBASE-T (1G/2.5G/10G). Tutto rame, niente slot SFP+: le due porte 10G di questo esemplare sono RJ45 10GBASE-T native, non moduli ottici.
A differenza del MokerLink POE-2G080110GSM managed o dell'Hasivo S600WP, qui non c'è nessuna pagina di configurazione su 192.168.x.x. Lo switch fa una cosa sola: muove pacchetti, auto-negozia la velocità su ogni porta e tiene il link stabile. Per il ruolo che gli ho dato — switch dedicato al nodo failover, fuori dal core managed — è esattamente quello che serve.
Le due porte 10GBASE-T sono il dettaglio che cambia il prezzo e l'utilità rispetto a un classico 4-port 2.5G. Per portare 10G a un host con NIC RJ45 10GbE basta un cavo Cat6a (o Cat7), senza cercare moduli SFP+ compatibili o transceiver dedicati.
Scheda tecnica TRENDnet TEG-S762
Parametro: Porte 2.5G · Valore: 4× RJ45 2.5GBASE-T (1G/2.5G)
Parametro: Porte 10G · Valore: 2× RJ45 10GBASE-T (1G/2.5G/10G)
Hasivo S600WP benchmark 2.5G: 10GBase-T uplink e zero bad packet in 10 giorni di produzione
Benchmark reale dell'Hasivo S600WP-4GT-1SX-1XGT-SE dopo tre settimane in produzione: 2353 Mbps, 0 retransmit e 0 bad packet sul test reverse. L’analisi completa del bottleneck RTL8125 single-queue e come lo switch risulta innocente in tutti i test.
Parametro: Temperatura operativa · Valore: 0 °C – 40 °C
Parametro: Certificazioni · Valore: CE, FCC, LVD
I numeri sono allineati a uno switch 2.5G di seconda generazione, con il bonus delle due porte 10GBASE-T. La capacità di switching da 60 Gbps è coerente con la somma full duplex delle porte (4 × 2.5 + 2 × 10) × 2 = 60 Gbps — tutto il traffico massimo possibile può attraversare lo switch contemporaneamente. MAC table 4K e buffer 1 MB sono allineati alla concorrenza nello stesso tier.
Il test sul pve2: auto-negoziazione, link stability e latenza
Ho collegato il TEG-S762 sul nodo failover del cluster Proxmox — pve2, un Intel i7-6700K con due NIC Realtek a bordo (RTL8125B 2.5G su enp5s0 e RTL8111/8168 1G su enp6s0), bondate in mode active-backup per resistere alla caduta di una delle due. Il TRENDnet è andato sulla NIC primaria, quella 2.5G capable.
Subito dopo aver inserito il cavo, dmesg sul pve2 ha registrato un evento pulito:
text
r8169 0000:05:00.0 enp5s0: Link is Up - 2.5Gbps/Full - flow control rx/tx
bond0: (slave enp5s0): link status definitely up, 2500 Mbps full duplex
bond0: (slave enp5s0): making interface the new active one
Auto-negoziazione corretta a 2500 Mbps full duplex, flow control rx/tx attivi. Niente forzature di velocità, niente ethtool advertise da impostare a mano: il TEG-S762 e la RTL8125B si sono parlate al primo tentativo. ethtool enp5s0 conferma a regime: speed 2500Mb/s, duplex Full, auto-negotiation on, link partner advertised auto-negotiation Yes.
La latenza ICMP da pve2 verso il gateway Deciso DEC750 — path che attraversa il TRENDnet, l'uplink 2.5G verso il MokerLink core e la porta del firewall — è il primo numero misurabile end-to-end:
text
100 packets transmitted, 100 received, 0% packet loss, time 20583ms
rtt min/avg/max/mdev = 0.102/0.209/3.925/0.375 ms
Cento ping a intervallo di 200 ms, media 0.209 ms con un picco isolato a 3.9 ms (mdev 0.375 ms). Niente packet loss e media sotto i 250 µs su due hop di switch più il firewall: lo switch non aggiunge latenza misurabile al path. Il TEG-S762 fa quello che ti aspetti — sposta i frame e basta.
Benchmark iperf3: 2.33 Gbits/sec end-to-end
Ho lanciato la metodologia iperf3 standard del lab tra il nodo principale (pve, 10.0.10.200, collegato al MokerLink core) e pve2 (10.0.10.66, collegato al TEG-S762). Path completo: NIC RTL8125 di pve → MokerLink → uplink 2.5G → TRENDnet TEG-S762 → bond0/enp5s0 di pve2.
Il path satura al ~93% del 2.5 Gbps teorico, esattamente quello che ci si aspetta da una catena tutta Realtek 2.5G in full duplex con MTU 1500 e zero offload exotici. Sedici giga di traffico in sessanta secondi con 664 retransmit TCP — rumore di fondo a quel volume di dati.
Snapshot di ip -s link show enp5s0 sul pve2 prima e dopo un run iperf3 da 30 secondi (8.22 GB trasferiti, 2.35 Gbits/sec, 0 retransmit):
Sei milioni di pacchetti ricevuti senza un singolo errore frame né missed delta. Il link tra TRENDnet e pve2 è pulito. Lato pve ethtool enp9s0 conferma 2500 Mb/s full duplex, auto-negoziazione on, advertised fino a 2500baseT/Full.
Detta in chiaro: il TEG-S762 sul nodo failover non frena nulla. La catena MokerLink ↔ TRENDnet a 2.5G regge il throughput sostenuto del 2.5G end-to-end, e il TRENDnet partecipa alla rete come una porta in più del backbone — proprio quello che voglio da uno switch unmanaged in quel ruolo.
Bond active-backup: il TRENDnet nel failover Proxmox
Il pve2 monta un bond Linux in mode active-backup con primario enp5s0 (2.5G via TRENDnet) e backup enp6s0 (1G verso un altro switch del rack). Il bond è specifico del pve2 — sul nodo principale la NIC 2.5G arriva direttamente al vmbr0 senza fault tolerance, perché lì la priorità è il throughput. Sul failover voglio invece la garanzia che un cavo strappato non isoli il nodo:
text
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: enp5s0 (primary_reselect always)
Currently Active Slave: enp5s0
MII Status: up
Slave Interface: enp5s0 — Speed: 2500 Mbps, Duplex: full
Slave Interface: enp6s0 — MII Status: down (cavo backup)
Il dettaglio importante per chi vuole replicare il setup è che il TEG-S762 ha rispettato il flow control rx/tx negoziato dalla NIC. Lo slave primario è rimasto attivo per tutta la durata dei benchmark, MII Status up, nessun warning del driver r8169 nel journalctl -k durante i run iperf3. Il bond ha visto lo switch come una porta onesta e non ha mai avuto bisogno di intervenire.
Il test di failover vero e proprio (mettere down enp5s0 e cronometrare la rolling-over al backup 1G) è materiale per un articolo dedicato sul bonding Proxmox — qui mi limito a registrare che il link primario tiene.
Quando ha senso il TEG-S762 nel lab
Non è uno switch da rack core. Per quello c'è il MokerLink POE managed con web UI, VLAN e gestione PoE granulare. Il TEG-S762 occupa una nicchia diversa: lo switch per la zona del lab dove ti serve un punto di aggregazione veloce e silenzioso — senza dover entrare in una pagina web ogni volta che colleghi qualcosa.
Casi d'uso concreti in casa mia: nodo failover Proxmox con bond, banco montaggio video con NAS e workstation 2.5G, area test dove arrivano switch e prodotti da provare prima di metterli in produzione. In tutti questi scenari le VLAN non servono, il PoE non serve, ma servono link 2.5G affidabili e — quando ti tocca — la possibilità di tirare un cavo Cat6a verso un endpoint 10G senza cercare moduli SFP+ o switch managed.
Il prezzo è il punto da pesare: il TEG-S762 sta nella fascia degli switch 2.5G unmanaged "premium", ma con due porte 10GBASE-T a bordo. Chi cerca solo 2.5G senza il 10G trova alternative più economiche; chi vuole tenere aperta la porta verso il 10G in rame senza investire in un managed completo trova qui un buon equilibrio. I 13.37W max dichiarati e la dissipazione completamente passiva sono coerenti con uno switch da tenere acceso 24/7 senza pensieri di consumo o rumore.
Verdetto del primo giro
Lo switch è in rete, il nodo failover è cablato, la stabilità è confermata e il path 2.5G end-to-end è verificato a 2.33 Gbits/sec sostenuti. Il TEG-S762 ha fatto la prima cosa che gli ho chiesto: stare in piedi, parlare 2.5G al pve2, lasciar passare il throughput sostenuto del 2.5G verso pve attraverso il MokerLink core senza un singolo errore frame.
Da qui in poi il TEG-S762 resta in lab. Ci saranno altri test in arrivo nelle prossime settimane — quando ci sarà qualcosa da raccontare, ne parlerò in un articolo dedicato.
Domande frequenti
Il TEG-S762 supporta il PoE?
No. Il TEG-S762 è un unmanaged plug-and-play senza alimentazione PoE su nessuna porta. Se ti serve PoE per AP WiFi o telecamere, serve un modello diverso (o uno switch managed PoE come il MokerLink POE-2G080110GSM).
Quante porte ha esattamente il TEG-S762?
Sei porte totali, tutte RJ45 in rame: 4 porte 2.5GBASE-T (1G/2.5G) e 2 porte 10GBASE-T (1G/2.5G/10G). Su questo esemplare non ci sono slot SFP+ né moduli ottici.
Posso usare il TEG-S762 come uplink 10G del rack?
Sì, le due porte 10GBASE-T permettono di collegare il TEG-S762 a un altro switch o a un NAS via cavo Cat6a o Cat7 fino a 10 Gbps. Va detto però che senza VLAN o STP a bordo, il TEG-S762 non è adatto a topologie complesse — funziona meglio come switch periferico aggregato a un core managed.
Quanto consuma il TEG-S762?
Il consumo massimo dichiarato da TRENDnet è 13.37W con alimentatore esterno (input 90–264 VAC). La dissipazione è completamente passiva (fanless), e la temperatura operativa nominale è 0–40 °C. È uno switch silenzioso adatto a stare in un ambiente di lavoro o vicino a una workstation.
Aggiornamento (18/05/2026): una versione precedente di questo articolo indicava l'unità come "revisione V3". Si trattava di una mia deduzione non verificata sull'etichetta, non di un dato confermato da TRENDnet — l'ho rimossa. La pagina prodotto ufficiale descrive il TEG-S762 con 2 porte 10G SFP+, mentre l'esemplare qui recensito monta 2 porte 10GBASE-T in rame: la sigla di revisione esatta è in corso di verifica con TRENDnet e l'articolo verrà aggiornato appena confermata. La configurazione hardware descritta (4×2.5G + 2×10G RJ45, tutto rame, nessuno slot SFP+) è esattamente quella dell'unità ricevuta e testata.
Resta Aggiornato
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.