• FTTCTIM
  • Host di Aruba non rispondono (Time out) da rete TIM (AS3269)

mark129 sì, per questione di pigrizia e incolumità.
Anche perché se tiro giù la rete a casa rischio insulti, si può sempre scaricare la colpa sui provider però 😂
Perché ?
Funziona discretamente bene

mark129 O semplicemente restringo con dst port 443?

sì, farei così

  • mark129 ha risposto a questo messaggio

    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.

        • [cancellato]

        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 ha risposto a questo messaggio

            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