Circa il 15% di perdita di pacchetti attraverso un S+RJ10 SFP+ in rame su un CRS518-16XS-2XQ mentre il percorso diretto a 100G è pulito
Mandiamo traffico da un server di laboratorio in un CRS518-16XS-2XQ tramite un uplink 100G QSFP28, ed esce dallo switch attraverso un S+RJ10 in rame MikroTik verso un host con un normale RJ45 1G. Il lato ricevente perde una fetta grossa dei pacchetti e non riesco ad appenderlo a niente di evidente.
Setup:
- MikroTik CRS518-16XS-2XQ, uplink 100G QSFP28 dalla sorgente di traffico
- S+RJ10 in rame MikroTik in una delle cage, dispositivo RJ45 1G all'altro capo
- cattura in corso sull'host ricevente
Cosa dice la cattura:
100G QSFP28 uplink -> CRS518-16XS-2XQ -> S+RJ10 -> 1G RJ45 host
capture on the 1G host: ~15% of the packets never arrive
same source, direct 100G connection: nothing missing
switch CPU load: 1%Provato finora:
- collegata la stessa sorgente direttamente a 100G, zero perdite, quindi il mittente di per sé va bene
- abbassato il carico CPU dello switch, ora sta all'1% e la perdita continua comunque
- reinserito l'S+RJ10 e cambiato il patch cord verso il dispositivo 1G
Il modulo in rame è il mio sospettato principale a questo punto, ma il link è pulito e l'interfaccia non mostra nessun errore. È noto che l'S+RJ10 mangi traffico così, o dovrei guardare da qualche altra parte dentro lo switch?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
400-500 Mbps di media con un mittente a raffiche è tutta la storia. Il tuo traffico non è distribuito in modo uniforme: raffiche brevi lasciano la sorgente più veloci di 1 Gbps, e tutto quello che sta sopra quella soglia deve stare nel buffer di uscita della porta finché il lato 1G non lo svuota. Quando il buffer è pieno, lo switch scarta. È esattamente quello che ti sta dicendo il movimento di rx-overflow, ed è per questo che la connessione diretta a 100G non mostra nulla: lì non c'è nessun salto di velocità contro cui fare da buffer.
Il transceiver è innocente. Qualsiasi cosa in quella cage, rame o fibra, si comporterebbe allo stesso modo, perché la perdita avviene nel salto da 100G a 1G e non dentro il modulo.
Due cose da fare. La vera soluzione è sul mittente: ritmalo in modo che i pacchetti siano distribuiti uniformemente invece di essere scritti a raffiche. Una volta che la sorgente smette di produrre raffiche sopra il rate di uscita, la perdita sparisce.
Sullo switch puoi rendere la situazione del buffer meno ostile:
Questo guadagna margine e lascia che una raffica duri più a lungo, ma non rimuove la causa: se il mittente fa raffiche abbastanza forti e abbastanza a lungo, nessuna dimensione di buffer ti salva. Continua a guardare le statistiche QoS dello switch e i contatori rx-overflow dopo il cambiamento, così vedi se stai ancora toccando il soffitto o solo sfiorandolo ogni tanto.
Vale la pena tenere a mente la lezione generale: una porta con link pulito, nessun errore e un modulo sano può comunque perdere una quota a due cifre di traffico puramente per un salto di velocità tra porte.
Prima di dare la colpa al modulo, guarda cosa dicono davvero i contatori di porta. Esegui
sulla porta di ingresso 100G e sulla cage con l'S+RJ10, e vai a guardare in particolare la riga rx-overflow invece dei soliti contatori di errore rx/tx. Un SFP+ in rame davvero rotto si annuncia con errori FCS o un link che sbatte su e giù, non con un ordinato taglio del 15% su uno stream altrimenti sano.
Seconda domanda: qual è il rate medio su quel percorso, e hai idea dei picchi? Perdere un pacchetto su sette con la CPU all'1% puzza molto più di una porta di uscita che finisce il buffer che di un guasto al transceiver.
Prima i contatori: nessun errore su nessuna delle due porte, il link resta su tutto il tempo e il modulo non riporta niente di insolito. rx-overflow è l'unico punto dove i numeri si muovono.
Sul rate, il percorso fa in media 400-500 Mbps, quindi sulla carta non è nemmeno vicino a saturare il lato 1G. Non ho una misura dei picchi, ma il traffico è a raffiche per natura: il mittente scrive un blocco e poi sta zitto per un po'. La CPU resta all'1% mentre i pacchetti spariscono.
Guasto diverso, stessa lezione sul fidarsi dei contatori più che dell'intuito. Avevo un CRS354-48G-4S+2Q+RM su SwOS 2.18 con Rx FCS Errors in crescita costante su entrambe le porte QSFP+, e Rx MAC Errors a un ritmo più basso. Entrambe le porte stavano a 40G full duplex con MTU 1500, e dall'altra parte c'erano host ESXi con schede Mellanox ConnectX-3 Pro CX324A.
La parte interessante: il lato NIC non riportava assolutamente nulla.
Pulito. Cavi di bontà nota non cambiavano niente, e le porte 10G SFP+ della stessa scatola sono rimaste senza errori per tutto il tempo. Non ho mai avuto una diagnosi vera: spostare lo switch da SwOS a RouterOS ha fatto sparire i contatori, cosa che conto come nascondere il problema piuttosto che risolverlo.
Il metodo che ha retto: azzera i contatori, rileggili a intervallo fisso e guarda se gli errori seguono il volume di traffico. Nel tuo caso seguiranno le raffiche, nel mio non seguivano nulla di utile, e quella differenza da sola ti dice da che parte continuare a scavare.
Una cosa da tenere a mente mentre sperimenti su quella porta: non ricorrere a velocità e duplex forzati come via d'uscita. Il comportamento documentato dei moduli in rame MikroTik, S-RJ01 e S+RJ10 allo stesso modo, è che funzionano solo con l'auto-negoziazione attiva: fissa il rate staticamente e il link non sale per niente. La pratica in parte lo contraddice, visto che alcuni possessori di RB5009 e RB4011 riportano il contrario e sono riusciti a stabilizzare un S-RJ01 solo forzando 1G full duplex, quindi è una cosa da "prova entrambe sul tuo hardware" piuttosto che una regola. In ogni caso è una deviazione dal tuo vero problema, che sta sul lato buffer.
L'altro dettaglio sull'S+RJ10 utile da sapere per dopo: assorbe notevolmente più potenza di un'ottica normale e scalda, quindi non è raccomandato in un dispositivo raffreddato passivamente senza aria extra. Se quel modulo mai inizia a comportarsi male in uno chassis caldo, la temperatura è la prima cosa che controllerei.