[cancellato]
Dalle mie due linee TIM nessun problema...
Host di Aruba non rispondono (Time out) da rete TIM (AS3269)
[cancellato] Dalle mie due linee TIM nessun problema...
Infatti chiedevo idee (per un troubleshooting se non per una soluzione).
[cancellato] A quale IP vengono risolti i nomi? Magari hai un DNS che fa le bizze...
Dubbio che possa essere il solito colpevole? Il setup prevede forwarding fatto da DNSmasq alla LAN, utilizzando Google (8.8.4.4/8.8.8.8) e TIM Mobile (217.200.201.66/67) per l'hotspot, e sempre Google e TIM Fisso (85.38.28.0/1) per la FTTC. Lo nslookup pare identico in entrambi i casi:
Server predefinito: UnKnown
Address: 192.168.1.3webmail.pec.it
Server: UnKnown
Address: 192.168.1.3Risposta da un server non autorevole:
Nome: webrid.arubapec.it
Addresses: 95.110.216.14
62.149.152.225
Aliases: webmail.pec.it62.149.152.225
Server: UnKnown
Address: 192.168.1.3*** UnKnown non è in grado di trovare 62.149.152.225: Non-existent domain
95.110.216.14
Server: UnKnown
Address: 192.168.1.3Nome: mx.pec.aruba.it
Address: 95.110.216.14
Idem l'MTR (a parte instradamento e latenza, ovvio): con l'hotspot
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.3 - 0 | 24 | 24 | 0 | 0 | 0 | 0 |
| 192.168.88.1 - 0 | 24 | 24 | 0 | 0 | 1 | 0 |
| 62.149.152.225 - 0 | 24 | 24 | 56 | 76 | 145 | 87 |
|_____________________________________________||||||___|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
con la fttc:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.3 - 0 | 112 | 112 | 0 | 0 | 2 | 0 |
| No response from host - 100 | 23 | 0 | 0 | 0 | 0 | 0 |
| 172.18.25.44 - 0 | 112 | 112 | 7 | 8 | 14 | 11 |
| 172.18.25.212 - 0 | 112 | 112 | 14 | 16 | 20 | 18 |
| 172.19.184.20 - 0 | 112 | 112 | 14 | 15 | 17 | 15 |
| 172.17.51.57 - 0 | 112 | 112 | 14 | 15 | 38 | 14 |
|host-217-141-211-26.business.telecomitalia.it - 0 | 112 | 112 | 15 | 15 | 22 | 15 |
| cr1-be2-707.it1.aruba.it - 0 | 112 | 112 | 26 | 26 | 28 | 26 |
| cs1-02-vi3902.it1.aruba.it - 0 | 112 | 112 | 26 | 26 | 28 | 26 |
| 62.149.152.225 - 0 | 112 | 112 | 26 | 26 | 28 | 26 |
|_____________________________________________||||||___|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
Non so che pesci prendere.
[cancellato]
mark129 chiedevo idee
Claro...era giusto per escludere che fosse una criticità massiva, caso mai qualcuno avesse il dubbio...
Se vuoi più tardi ti faccio una misurazione da tutte le sonde ripe tim e ti mando i risultati
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.
[cancellato]
Ah piccola postilla: login.aruba.it in particolare a me risponde soltanto sulla 443
- Modificato
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.
- Modificato
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.
- Modificato
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?
- Modificato
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?
- Modificato
- Modificato
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ù?
- Modificato
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.