VLAN inoltrata in LAN da Orbi RBRE960

Orbi RBRE960 inoltra il tag VLAN PPPoE WAN (XXXX) nella LAN a metà flusso, causando ai client cablati senza impostazioni NIC VLAN-aware di bloccarsi silenziosamente durante i trasferimenti

Prodotti

• Router: Orbi RBRE960, firmware V7.2.8.8
• Satellite: 2x RBSE960 (backhaul wireless, sospetto che il cablato non funzioni per il medesimo problema), stessa versione firmware

Topologia

• ONT in modalità bridge: l’Orbi stabilisce la sessione PPPoE direttamente verso l’ONT. PPPoE MTU 1492.
• Configurazione VLAN sull’Orbi: una singola regola, tag XXXX, applicata a tutte le porte cablate e a tutte le wireless, La pagina VLAN dell’Orbi non permette di limitare il tag a una singola porta. La parte wireless tuttavia non sembra afflitta dal problema.

Sintomo Su un flusso TCP di lunga durata da un client cablato LAN verso un host WAN, i frame per quel flusso arrivano non taggati per circa il primo secondo. L’Orbi poi inizia a inoltrare i frame per lo stesso flusso nella LAN con tag 802.1Q VLAN XXXX (la VLAN PPPoE lato WAN), con sorgente l’indirizzo MAC lato LAN del router. I client privi di un’interfaccia VLAN XXXX scartano questi frame a livello 2, prima di IP/TCP, quindi il flusso sembra bloccarsi con throughput zero mentre il server remoto continua a ritrasmettere (anch’esso taggato) finché rinuncia e invia FIN/RST, che escono di nuovo non taggati. Il guasto è per flusso e fissato nel tempo (~1 s dall’inizio del flusso), indipendente dal throughput.

Passi per riprodurre

1. Collegare un client Linux direttamente a una porta LAN dell’Orbi (nessuno switch intermedio).
2. Avviare un download di lunga durata (multi-GB) da un qualsiasi server HTTP esterno, campionando il throughput a intervalli di 2 s o meno.
3. Eseguire tcpdump -e sul client durante il download.
4. Osservare: i frame arrivano non taggati per ~1 s, poi a metà flusso passano al tag 802.1Q XXXX; il client scarta i frame taggati (nessuna interfaccia VLAN corrispondente) e il flusso si blocca; i pacchetti di chiusura FIN/RST sono di nuovo non taggati.
5. Controllo alternativo su Windows: commutare l’impostazione del driver NIC “VLAN Priority Tag” (o equivalente gestione 802.1Q) tra attivata e disattivata ripetendo lo stesso download lungo. Con l’impostazione attiva, il driver accetta i frame taggati e il trasferimento si completa; con l’impostazione disattivata, lo stesso trasferimento si blocca in modo identico al caso Linux.

Evidenze

• Riprodotto indipendentemente su due host Linux cablati differenti in due occasioni diverse, incluso un host collegato direttamente alla porta LAN dell’Orbi (saltando tutti gli switch e cablaggi intermedi).
• Per-flusso, fissato nel tempo: un nuovo flusso avviato più tardi nella sessione si blocca di nuovo allo stesso punto ~1 s; il tempo di blocco è identico a basso throughput (~2,5 MB/s) e ad alto throughput (~30 MB/s).
• Test di controllo su Windows, stessa porta e cavo: 1,37 GB trasferiti senza blocchi con “VLAN Priority Tag” abilitato; la stessa configurazione si è bloccata a 36,6 MB con l’impostazione disabilitata.
• I contatori kernel sui client interessati non mostrano errori di checksum, né scarti in coda, né scarti per out-of-order a livello IP/TCP: la perdita è interamente a livello 2 (i frame con VLAN sconosciuta vengono scartati silenziosamente prima di raggiungere lo stack IP, quindi i contatori di rete standard non li vedono).

Cosa è stato escluso

• Errata configurazione VLAN del router: verificata.
• Bug specifico del client/OS: riprodotto su due sistemi Linux indipendenti con hardware NIC diverso, e dimostrato dipendente dalla gestione VLAN del driver su Windows.
• Cavi LAN, porta switch o NIC del client come causa primaria: stessa porta e cavo producono successo o fallimento a seconda solo del fatto che OS/driver gestisca o meno il tag VLAN XXXX.
• DNS, PMTU/MTU, scaling finestra TCP, SACK, timestamp, rigidità conntrack: variati indipendentemente sul client senza cambiare l’esito.
• Downgrade firmware come workaround: lo stesso comportamento era già presente su versioni firmware precedenti a V7.2.8.8, secondo la nostra esperienza pregressa con questo router.

Ipotesi non confermata Il punto in cui inizia l’inoltro taggato (~1 s nel flusso) è coerente con il passaggio del flusso a un percorso di NAT/hardware acceleration per flussi. Non siamo riusciti a confermarlo in modo indipendente: abilitare il Traffic Meter (segnalato altrove come disabilitante l’accelerazione hardware su alcuni router Netgear) non ha modificato il sintomo, ma non avevamo modo di verificare che l’accelerazione fosse effettivamente disabilitata durante i test.

Richiesta Confermate se si tratta di un problema noto e fornite una correzione (firmware di manutenzione o beta) oppure una soluzione ufficiale — per esempio un metodo supportato per disabilitare l’hardware NAT/flow acceleration su questo percorso WAN VLAN, o per garantire che il tag VLAN richiesto dall’ISP venga rimosso prima che i frame raggiungano le porte LAN. Possiamo fornire i file pcap tcpdump -e citati sopra su richiesta.