Newsgroup: it.comp.os.linux.sys
Titolo: Perdita pacchetti con MTR

Secondo voi cosa può portare a perdita di pacchetti
abbastanza frequente con MTR (tra me ed il mio gateway)
mentre con un fping in esecuzione da oltre 3 ore e frequenza
di 1millisecondo (-p1 -l), non mostra alcuna perdita?
Non ne riesco a venire a capo, se ci fossero problemi
di collegamento tra me ed il mio router, lo vedrei anche
con fping e quantomeno lo vedrei anche tramite le nic dei
due server.
Nonostante ciò, le nic non mostrano alcuna perdita di
pacchetti o pacchetti dropped, fping e ping non mostrano
assolutamente nulla, mentre mtr da una caterva di errori.
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 due server.
Boh, è assurdo.
La rete è così:
ADSL -> router A -> switch A -> router B -> switch B -> server
se dal server faccio un mtr verso il router B, non ricevo errori.
se dal server faccio un mtr verso il router A, ricevo errori (molti).
se dal server faccio un mtr verso il next-hop ADSL, ricevo errori (molti).
Sembrerebbe un problema sullo switch A, ma:
se dal router B faccio un mtr verso router A, non ricevo errori
se dal router B faccio un mtr verso l'ADSL, ricevo errori.
In pratica, riesco a fare correttamente solo 1 hop, se ne faccio
2 o più, ricevo vagonate di errori (ma sulle nic coinvolte non viene
riportato alcun errore ne alcuna collisione, solo mtr ed smokeping
mi mostrano errori)


 mi mostrano errori)
Ho controllato tutti gli apparati della catena, cambiato tutti i cavi,
nessun apparato mostra errori di ricezione/trasmissione eppure, MTR
continua a generare vagonate di errori.
Non so cos'altro verificare.
Ho provato a staccare l'autonegoziazione su tutti gli apparati. Niente,
stesso risultato. (anzi, a dire il vero, se tra due apparati cisco
stacco l'autoneg e forzo 1000/full su ambo i lati, il line-protocol non
va su e non si accende nemmeno una luce. Si, ho già provato a cambiare
i cavi)


 continua a generare vagonate di errori.
Qualche idea?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito ï¿œ di fare il possibile per la


 Qualche idea?
man mtr
--------
Some  modern  routers  give a lower priority to ICMP ECHO packets than to 
other network traffic.  Consequently, the reliability of these routers 
reported by mtr will be significantly lower than the actual reliability 
of these routers.
Ovviamente solo tu sai che switch, router, server, cavi, vasellina, dildi 
utilizzi ma non è raro vedere router che droppano pacchetti ICMP Diretti 
a loro, consapevolmente.
Poi se vuoi, sempre per tua gradevole cultura, puoi andare di tcpdump/
wireshark/${pcap_based_software} per capire perchè MTR si comporta in un 
modo ed altri in un altro modo.

 modo ed altri in un altro modo.
AFAIK, mtr manda dei ping con TTL estremamente basso, il ping normale
funziona, mtr no.
Domani controllo con tshark ma non sarà facile.

 of these routers.
Girovagando per la rete sembrerebbe che solo gli ICMP destinati al
router stesso vengano
messi in bassa priorità, quelli in transito non subiscono QoS.
Se così fosse, sarebbe un bene, perchè il ping invia un echo-request
in transito, MTR invece invia un echo-request con ttl basso
(incrementandolo man mano) che vien rimbalzato dai vari device
attraversati, quindi potrebbe essere considerato come diretto verso
l'apparato stesso e di conseguenza messo in bassa priorità.
La stessa cosa, però, mi si presenta anche su due switch HP, ma stando
a Google, anche gli HP filtrano gli ICMP, quindi potrebbe essere OK
anche in questo caso.
Però, mi fa strano che persino smokeping segni pacchetti persi (e lui
fa un ping, non un trace, quindi traffico ICMP di transito) inoltre,
solo da 2-3 giorni si presenta questa problematica, fino a 2-3 giorni
fa non avevo alcun tipo di pacchetto perso.

 messi in bassa priorità, quelli in transito non subiscono QoS.
Ma anche no:
http://www.cisco.com/en/US/tech/tk364/technologies_tech_note09186a00801ae32a.shtml#topic1
"This limitation does not affect other packets like ICMP echo requests
or ICMP "time exceeded" messages."
quindi è ufficiale: non so cos'altro controllare. Certo non è un
problema di rate-limit, Cisco non filtra i time exceeded.

 problema di rate-limit, Cisco non filtra i time exceeded.
Mi arrendo, se qualcuno sapesse cosa controllare, mi mandi pure
fatture.
'Sti packet-loss mi stan sulle balle, non mi permettono di capire se
ci son veramente problemi oppure no nella rete, visto che ho
costantemente
allarmi di smokeping ed i grafici falsati.

 allarmi di smokeping ed i grafici falsati.
Mistero svilato. Non so se è un bug o che altro.
Se la macchina che sta eseguendo mtr (o fping) riceve degli errori
icmp (anche non inviati
dal software stesso), mtr li conteggia come errori.
Nel mio caso, la macchina con mtr è la stessa che esegue zabbix ed il
suo discovery snmp, pertanto è normale avere di rimbalzo vagonate di
errori icmp (alcuni server non rispondono affatto). Se MTR è in
esecuzione proprio mentre zabbix fa il discovery, vien conteggiato un
errore.
Idem per FPING.
Si può risolvere in qualche modo? Ho smokeping sullo stesso server di
Zabbix, ogni volta che zabbix genera un errore icmp (per i motivi su
citati), smokeping/fping lo intercetta mi sporca il grafico e mi invia
un alert.

 dal software stesso), mtr li conteggia come errori.
Complimenti per aver svelato il mistero.
Sinceramente proprio non ci avevo pensato.
il codice di fping lo conosco, quello di MTR no ma ti posso spiegare che 
ICMP su linux è gestito tramite RAW SOCKETS.
fping quando invia pacchetti vi inserisce dei checksum in modo tale che, 
al ritorno degli stessi, possa discernere se sono suoi (e considerarli) o 
sono di altri ( e quindi ignorarli).
Evidentemente MTR non fa questi controlli e, di conseguenza, fixare il 
problema potrebbe essere una richiesta da fare agli sviluppatori.
Leggo però che MTR ha un flag -u. Forse può aiutarti.

 Leggo però che MTR ha un flag -u. Forse può aiutarti.
Dici che tramite UDP non dovrei aver problemi?
Proviamo:
 -- mtr in icmp:
vagonate di errori, sin da subito o quasi
 -- mtr in udp:
vagonate di errori uguale.
No, non mi aiuta :)