Newsgroup: it.comp.reti.ip-admin
Titolo: problemi misteriosi MTU

Buondì a tutti,
sperando di aver azzeccato il newsgroup giusto (anches e temo sia più un 
problema da it.religione.esorcismi):
ho un troncone di rete gestito da fastweb che collega due sedi distanti 
fra loro e finisce (in vlan) ad un gateway (iptables) debian (squeeze).
A fronte dell'insorgere di una serie di problemi misteriosi fra cui 
connettività apparentemente dipendente dalla cipher string di ssh mi 
accorgo che i pacchetti con MTU sopra ai 1100 tendono a perdersi (non 
parlo di frammentazione, proprio si perdono) con percentuale che aumenta 
fino al 100% intorno ai 1400, mentre scendendo intorno a 1000 la 
situazione torna accettabile. Percentuali variabili di giornata in 
giornata e apparentemente poco deterministiche.
Questo in realtà accade pingando con pacchetti di dimensione variabile 
l'interfaccia del router fastweb più lontana dal mio gateway (quella 
della sede remota) mentre se pingo il router fastweb più vicino al 
gateway non ne perdo manco uno.
 
Uno dice: facile, catzi di fastweb, apro una chiamata. Arriva l'omino, 
stacca il cavo del router, lo attacca al suo pc e vediamo che i ping a 
1500 verso la sede remota vanno come un violino, grazie e arrivederci. 
Riattacco il mio gateway, stesse pippe di prima.
Seguono informazioni addizionali:
  - Fra il gw e il router c'è uno switch hp procurve di mezzo che 
permette di far arrivare quella e altre reti come vlan in un unico cavo. 
Premesso che le altre vlan non hanno problemi ho comunque provato a 
riavviare il router e cambiare porta senza che cambiasse alcunché
  - Sì, ho provato a cambiare anche tutti i cavi coinvolti
  - No, non ho errori nelle interfacce di rete
  - No, nelle conf di gw (e dello switch) non sono intervenuti 
cambiamenti dalla presidenza Scalfari (a parte aggiornamenti di 
sicurezza debian).
 
Quello che al momento mi crea grosse difficoltà è capire quali problemi 
(evidentimente miei) possano portare a problemi che intervengono 
evidentemente *solo* sui router più lontani.
 
ciao

 evidentemente *solo* sui router più lontani.
io farei un "reverse engineering", partendo dalla stessa situazione 
dell'omino... e continuando passo passo fino a individuare il nodo 
incasinato.



un "passive tap" ed un portatile con sopra wireshark potrebbero essere
utili; ad esempio si potrebbe collegare il "tap" tra lo switch ed il
router ed usare wireshark per vedere che diavolo succede :D
 
 
 


Grazie a entrambi degli spunti, ho prima seguito il consiglio di meddix, 
e le cose si son fatte sempre più assurde (per me):
1) ho attaccato il mio portatile al cvlo del router simulando l'ip del 
nostro gateway e ho avuto gli stessi identici problemi (pacchetti persi 
sopra ai 1100).
2) sono riuscito a rintracciare telefonicamente il tecnico fastweb 
indagando su come fosse settato il pc per i test che aveva fatto lui 
(che avevano funzionato), appurando che a parità di indirizzamento la 
differenza principale è che il suo portatile è un win7 e il mio una 
fedora 20.
3) rifaccio i test con il mio portatile ma facendolo partire con 
windows, e arrivo alla seguente:
 
da un terminale linux (debian o fedora con kernel compresi fra 2.6.32 e 
3.19.8) mi fallisce sempre un:
ping -s 1472 $ip_remoto
 
dal cmd di win7 mi funziona sempre un:
ping -l 1472 -f $ip_lontano
 
(che non capisco bene perché funziona anche quando il routing del pc win 
in questione passa dal gateway debian)
 
con grande sconforto ora passerò a studiarmi le affinità e divergenze 
fra il compagno ping windows e noi (cit) sperando che emerga qualcosa di 
illuminante
 
 
 
 
 

Per completezza aggiungo un entusiasmante capitolo alla saga:
 
Il ping di windows passa anche a 1500 byte mentre tools come mturoute 
(sempre sotto windows) concordano con il ping di linux definendo l'mtu 
massimo della rete intorno ai 1100, sopra si perdono cose.
 
Preso dalla disperazione viviseziono i pacchetti ICMP notando che le 
uniche differenze riguardano differenze di TTL imho trascurabili e il 
payload content del pacchetto che varia come segue:
 
- il ping di windows ripete una sfilza di alfabeti minuscoli
- in tutte le altre implementazioni il contenuto è sempre ciclico ma 
presenta più caratteri/simboli/variabilità
 
Il tiro da metàcampo che ha fatto un mio collega è ipotizzare che uno 
dei router di fastweb abbia *un poco* di ram fritta e che fallisca il 
checksum dei pacchetti relativamente più pacchetti grandi e complessi 
droppandoli con nonchalance.
I pacchetti che escono dal ping di windows sono grandi ma "semplici" e 
non innescherebbero il problema.
 
(condizionale d'obbligo)
 
(seguiranno aggiornamenti)


 l'mtu massimo della rete intorno ai 1100, sopra si perdono cose.
 
giusto per curiosità, visto che hai un box windows sottomano, tirati
giù questo tool 
https://www.pingplotter.com/freeware.html
, pulisci il
"# of times to trace", imposta il "trace delay" ad un secondo e poi
immetti il nome o l'IP di un qualsiasi host o nodo e fai partire il
tool; niente di che, ma sarei curioso di vedere cosa ti dice; se poi
non ti va di usare windows, potresti comunque provare a "fare un giro"
con MTR 
http://www.bitwizard.nl/mtr/
 ;-)
 


Non ho ancora avuto tempo di provare pingplotter ma avevo l'urgenza di 
un grosso GRAZIE per la segnalazione di mtr che ha l'opzione che cercavo 
(il -B per cambiare il bit pattern del payload) e mi ha confermato che 
variando quello s'innesca il problema.
Dopo l'ennesima mezzorata al telefono con un tecnico fastsbriz il 
problema parrebbe un media converter difettoso a valle del primo dei 
loro router, oggi viene qualcuno a sostituirlo, attendo trepidante.

 router, oggi viene qualcuno a sostituirlo, attendo trepidante.
 
certo che sei stato fortunato; non solo hai trovato "vita intelligente"
dall'altro capo del telefono, ma addirittura qualcuno che ti ha anche
spiegato la causa del problema; miracolo :) !!
 
 

 spiegato la causa del problema; miracolo:)  !!
 
E infatti ho peccato di ottimismo, han cambiato il primo router e media 
converter della catena ma il problema persiste. Poi mi hanno passato 
l'ennesimo tecnico diverso dai precedenti che come tutti quelli con cui 
inizio a parlare pensa che il problema sia nella mia testa e non nella 
loro rete.
Ho proposto una mediazione tipo "vi mando via mail test riproducibili".
Il risultato è che ora mi chiama un tecnico diverso ogni 2h dicendo 
"prova ora" senza che cambi alcunché.
 
Però, a conferma che dalle reti perfette non nasce niente ma dalle reti 
di letame nascono i fior (come cantava quello) ho avuto un paio di 
interazioni via mail con Eli Fulkerson, lo sviluppatore di mturoute, che 
è stato di una disponibilità veramente disarmante interessandosi alla 
vicenda e partorendo questa cosa:
http://www.elifulkerson.com/projects/deadbit.php
 
 
che fa in automatico quello che io ho fatto a manina (variare il 
contenuto dei pacchetti ICMP per vedere se innesca qualche problema).
La sto testando in questo momento ma non è facile (ci mette un botto e 
contemporaneamente i fastweb boys stanno riavviando tutto il riavviabile 
nei loro meandri)

 La sto testando in questo momento ma non è facile (ci mette un botto
 
"It runs pretty slow by default, waiting politely 1 second between
tests. If you want to finish in a reasonable amount of time, use "-i
whatever" to set a much smaller wait period."
 
;-D
 

A meri fini di completezza, aggiungiamo il tassello finale:
a seguito di ulteriori analisi (tipo tcpdumpare i pacchetti da una parte 
e dall'altra) è emerso che il problema occorreva in un'unica direzione.
Contemporaneamente è stata applicata una delicata pressione sui 
commerciali fastweb.
Una di queste due azioni ha causato un'impennata nella reattività 
cognitiva dei tecnici che in nottata hanno "cambiato una scheda in un 
apparato" e il problema è scomparso.
 
Resto tristemente curioso su cosa possa aver innescato un problema così 
buffo, ma tutto è bene quel che finisce.
 
ciao


 problema.
 
guarda, capisco quello che intendi, ma considerando la mia personale
esperienza, posso affermare che, tranne situazioni particolari, è molto
difficile (se non impossibile) per una piccola/media struttura che non
abbia contatti "interni" riuscire ad interloquire con una qualche forma
di "vita intelligente" all'interno di qualsivoglia ISP; in questi casi
la norma è la cosiddetta "escalation" che, in pratica, altro non è che
una specie di calvario fatto di chiamate ripetute che forza gli
operatori a passare le chiamate al livello successivo sino a che non si
riesce a parlare con qualcuno che, finalmente, capisce il problema e,
magari, lo risolve in pochi minuti... ma, come ho scritto, si tratta di
un vero e proprio calvario.
 
Il caso è diverso se uno ha conoscenze e/o se si tratta di una *grossa*
realtà, in quei casi, o chiami direttamente chi conosci, oppure hai dei
numeri di supporto diversi che ti mettono in contatto diretto con chi
gestisce le problematiche.
 
Ora, se da un lato capisco una strategia del genere (tutto sommato non
ha senso sprecare il tempo di gente qualificata per rispondere alla
signora pina che magari ha solo sbagliato a scrivere un URL),dall'altro
credo che nel caso di contratti "business", fossero anche "SoHo" tale
strategia debba (ok, dovrebbe :P) essere rivista 
 
 

 un vero e proprio calvario.
 
ObiWan coglie nel segno e descrive più o meno esattamente quello che è 
successo ma pure Allen perché se non avessi già perso tutti i capelli 
l'avrei fatto in questi ultimi 15 giorni. C'è stata anche l'aggravante 
"problema nuovo e misterioso" che non aiutava.
Comunque da un certo punto in poi mi hanno in effetti messo in contatto 
con gente che mi lasciava cellulare e mail aziendale per poter bypassare 
il call center.
 
Mi sono fatto carico di tutti i test e tcpdumpi del caso perché ad un 
certo punto l'alternativa sarebbe stata coordinarmi per fare da balia ad 
un tecnico qui e mandare un collega a far da balia ad un altro tecnico 
nella sede remota e dover configurare qualche switch in mirror per 
permetter loro di fare prove senza compromettere la (poca) funzionalità 
di rete rimasta.
 
Poi: numeri! (più che altro per sfogarmi)
in poco più di 20gg ho avuto a che fare con:
- 6 tecnici fastweb diversi al telefono, passando regolarmente i primi 
10 minuti a convincerli che non avevo allucinazioni e che il problema 
esisteva
- 2 tecnici di non precisate ditte sottoappaltanti venuti in sede per 
fare interventi di max 10 minuti e passarne 40 (storia vera) al telefono 
con fastweb per dire "ho fatto"
- la frase "ma il ping di windows funziona" ripetutami circa 18 volte
 
tutta esperienza, mettiamola così