edofullo Domanda molto stupida... hai provato a tirare giù la PPPoE per cambiare IP?
Yep! 
79, 80, 95, 217 pure mi pare di aver ottenuto, e no, non pare legato ad un particolare netblock.
Giann Se vuoi più tardi ti faccio una misurazione da tutte le sonde ripe tim e ti mando i risultati
Si, è un dato oggettivo e quindi potenzialmente utile, anche se mi aspetterei pure una conferma (che da lì non si vede niente), visto che mtr va come una scheggia pure se il browser va in time out.
Ah piccola postilla: login.aruba.it in particolare a me risponde soltanto sulla 443
Potresti provare a fare un sniff anche se non si aprono, per capire se non si apre proprio la sessione TCP(come credo).
Se hai una macchina Linux con te
Prova un po’ di curl con diverse porte sorgenti.
curl --local-port 10000 https://www.aruba.it
curl --local-port 10001 https://www.aruba.it
curl --local-port 10002 https://www.aruba.itAltri metodi di debug non mi vengono in mente.
gandalf2016 Prova un po’ di curl con diverse porte sorgenti.
il range delle porte è importante sceglierlo in qualche modo particolare?
Ho preso le tue per iniziare e mi da un errore sulla 10001 (su una ventina di porte provate)
sudo curl --local-port 10001 https://webmail.pec.it
curl: (45) bind failed with errno 125: Address already in use
giuse56 Però noto che la webmail oggi è particolarmente lenta ad aprirsi
Non so che dirti, in LTE appare tutto normale.
mark129 il range delle porte è importante sceglierlo in qualche modo particolare?
No, giusto per vedere se era qualcosa sempre con ECMP
mark129 sudo curl --local-port 10001 https://webmail.pec.it
curl: (45) bind failed with errno 125: Address already in use
La statava usando per altro… non è un problema.
Sembra tutto a posto dai test che hai fatto… manca solo lo sniff ormai con tcpdump
gandalf2016 manca solo lo sniff ormai con tcpdump
Mi viene un dubbio metodologico: per cercare il guaio vado a sniffare solo la pppoe incriminata, mica tutta la lan, vero?
O semplicemente restringo con dst port 443?
Apparentemente risolto (con workaround) il problema.
Ora mi resta da capire che cosa non vada più bene in quel setup che era così come dall'inizio dell'anno.
@gandalf2016 tu hai ancora l'edgerouter "in produzione", oppure ormai usi altri gateway?
gandalf2016 Perché ?
Perché il workaround con cui la rete è ripartita (intendo, senza glitch tipo quello di aruba, verificato pure su altri indirizzi, tipo www.hype.it) è il seguente (e tu forse puoi avere qualche suggerimento di prima mano).
La FTTC è dei miei, tra me e loro c'è un ponte radio (così gestisco la loro rete, la domotica, le telecamere) questo ponte radio va un un EP-R6 (ER-X SFP da esterno), e da qui con l'interfaccia eth4 ad un TIM HUB su cui è attestata la FTTC per il loro accesso ad Internet.
Ora, se l'interfaccia verso Internet è eth4, quindi doppio NAT (ecco il workaround) il problema sparisce.
Se l'interfaccia verso internet è pppoe4 (pppoe diretta su parent eth4), quindi senza doppio NAT, il problema si ripresenta.
Ma che gliene importa a 'sto Edgepoint se la default route passa per eth4 o pppoe4? E soprattutto, il setup con la pppoe4 era in piedi da quando Lorenzo ha attivato loro la FTTC ad inizio anno, per cui perché per 9 mesi si, ed ora non più?
mark129 MSS Clamping sulla ppp che tiri su sul router dei tuoi a 1452 lo stai facendo?
Così mi verrebbe da dire che sembra una problematica di MSS e MTU
Col doppio NAT il problema sparisce perchè il clamping lo fa il modem TIM
i comandi da dare sono i seguenti:
configure
set firewall options mss-clamp mss 1452
set firewall options mss-clamp interface-type pppoe
commit;save
gandalf2016 MSS Clamping sulla ppp che tiri su sul router dei tuoi a 1452 lo stai facendo?
Ce l'ho più basso, 1412, non credo possa essere un problema perché è lo stesso di inizio anno... o si? Mo' provo.
Tra l'altro il "glitch" compare pure random sullo speedtest
speedtest -s 36728
Speedtest by Ookla
Server: TIM SpA - Pescara (id = 36728) ISP: Telecom Italia Latency: 14.78 ms (0.83 ms jitter)Download: 22.02 Mbps (data used: 34.3 MB)
Upload: 5.16 Mbps (data used: 2.3 MB)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/93db3daa-9992-409a-bfa6-9268b3c2a45e
speedtest -s 3667
Speedtest by Ookla
Server: TIM SpA - Milan (id = 3667) ISP: Telecom Italia Latency: 19.95 ms (0.34 ms jitter)Download: FAILED
[error] Cannot read: Impossibile stabilire la connessione. Risposta non corretta della parte connessa dopo l'intervallo di tempo oppure mancata risposta dall'host collegato.
Ma è solo una nota di colore.
gandalf2016 Giusta considerazione ma perché solo verso Aruba? Vuoi che per "fortuna" tutte le sue destinazioni di uso comune passino per dei router che fanno clamping ad un valore inferiore al suo link? 
[cancellato] Giusta considerazione
Esatto, giusto l'hint ( gandalf2016 ) e giusta la tua considerazione: pare sia proprio il valore clamping, messo a 1452 va come deve andare.
Ma perché con 1412 non funzionava, anzi non funziona più? L'avevo scelto più basso apposta per non avere rotture, al costo di perdere un po' di throughput.
S'è corrotto qualcosa sulla flash di queste scatolette (ridammi la memoria su usb stick, Ubiquiti!)?
Rimetto 1412 e controllo.
mark129 Rimetto 1412 e controllo.
Controllato, pure con 1412 è tornato a funzionare.
Ne devo concludere che questo glitch dovesse aver a che fare con la memoria interna di quel router.
Resta l'interrogativo di [cancellato] in piedi, anche se probabilmente ci sono più cose in Internet, tra autenticazioni, mtu, dns e bgp, di quante uno ne potrà mai immaginare (cfr. Amleto).
Intanto grazie a tutti per il supporto (decisivo).
Informativa privacy
-
Informativa cookie
-
Termini e condizioni
-
Regolamento
-
Disclaimer
-
🏳️🌈
P.I. IT16712091004 - info@fibraclick.it
♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile
