Il traffico arriva ma non passa

Per un sito che è ONLINE con BGP stabilito. Se le route sono il problema, iniziare con BGP.

1. Viene scartato qualcosa, e perché? dropstats-non-zero. Eseguirlo due volte mentre si riproduce il problema: si tratta di totali cumulativi, quindi un contatore diverso da zero non significa nulla di per sé, mentre uno in aumento significa tutto.

2. Trovare la connessione specifica. flow-l-match con l’indirizzo, oppure indirizzo e porta. L’azione sul flusso è la risposta: F inoltro, D scarto, N NAT. Un flusso presente con azione D è una decisione di policy deliberata e rimanda alla policy anziché alla connettività.

3. Nessun flusso? Il traffico non raggiunge il piano dati. Verificare che il piano dati abbia acquisito l’interfaccia attesa con vif, e confrontare i suoi contatori con quanto riportato da ip.

   Le due viste differiscono legittimamente, perché il traffico gestito dal piano dati non raggiunge mai il kernel. RX pari a zero sull’interfaccia attesa invece non è normale.

4. Flusso presente e in inoltro, ma ancora non arriva? Verificare dove viene instradato: rt per la route, poi nh per risolvere il next hop. Un next hop di tipo Drop è un blackhole, mentre un next hop Tunnel mette il tunnel stesso nell’ambito di analisi.

5. Se il percorso passa attraverso un tunnel, verificare che sia attivo e che trasporti byte con ipsec-statusall. Un tunnel stabilito da ore con contatori quasi a zero è attivo ma inutilizzato, il che rimanda nuovamente al routing.

Argo e Linux mantengono stati separati

La maggior parte dei sintomi confusi del piano dati deriva dalla lettura della vista del kernel e dal presupposto che sia autorevole. ip mostra ciò che Linux crede; rt, nh e vif mostrano ciò che inoltra il traffico. Quando non concordano, è il piano dati a muovere i pacchetti.