• FTTHInfratel

  • Presunta configurazione errata OLT | AREA BIANCA C/D

Buonasera a tutti

ultimamente nel gruppo telegram abbiamo discusso a riguardo di problemi di prestazioni verso alcuni server che presumibilmente hanno BBR disabilitato...

Attenzione ⚠️ Questo SOLO IN AREA BIANCA C/D, abbiamo fatto tutti i test del caso in area nera A/B, loro non hanno problemi del genere, vanno al massimo su tutti i server.

Eravamo giunti alla conclusione che il problema fosse l'ONT (NOKIA G-010G-Q) pero' sembrerebbe improbabile

Test su server speedtest 1434 e 8211 (BBR non attivo)
Test su server speedtest 7839 (BBR ATTIVO CORREGGO NON BBR, pero' va meglio degli altri lo stesso)

  • Dalla mia linea su Windtre 1000/300 [ Saletto di Borgo Veneto(PD), PCN Ospedaletto Euganeo(PD) ]

  • Dalla linea del mio amico su Dimensione 1000/300 (stesso comune, stesso pcn)

Inoltre tramite l'uso di una vpn (Proton VPN piano gratuito) riesco anch'io a raggiungere velocita' di 800/900mbps
Test con VPN sulla mia linea:

Volevamo raccogliere piu' informazioni possibili a riguardo, per poterlo segnalare a Open Fiber nel caso, magari con l'aiuto di qualcuno che e' in contatto con loro

Grazie in anticipo 🙂

    Dubito che sia un problema di OLT.
    Al massimo è il rilegamento.

      • [cancellato]

      • Messaggio #3
      • Modificato

      andreagdipaolo Snì... tieni conto che entrambi i provider usano PPPoE, e OF trasporta le S/C-VLAN fino al BRAS, lato rilegamento ci sono 3 livelli di tunnelling... In teoria sì non dovrebbe c'entrare nemmeno l'OLT, salvo che non abbia qualche ispezione del traffico nelle PPPoE per fare QoS sull'albero.

      Piuttosto... non è che il "colpevole" possa essere un MTU troppo grande? Se il rilegamento usa un tunnel IP su un trasporto a 1500 byte magari frammenta... Wireguard per impostazione predefinita usa un MTU ridicolmente basso per assicurare compatibilità con tutti i tunnel possibili. @xzvice provato a impostare lato WAN un MTU a 1400 byte o giù di lì al posto dei 1492 canonici della PPPoE?

      • xzvice ha risposto a questo messaggio

          [cancellato] @"xzvice" provato a impostare lato WAN un MTU a 1400 byte o giù di lì al posto dei 1492 canonici della PPPoE?

          Prova con MTU 1492 e 1400: https://streamable.com/n7h9k8

          ho provato anche 1280, che sembrerebbe essere il valore di default di wireguard ma non e' cambiato nulla

          (ho solo cambiato l'MTU nella pppoe del router)

              • [cancellato]

              • Messaggio #5

              xzvice Peccato, mi sarebbe piaciuta come soluzione 😄

              • xzvice ha risposto a questo messaggio

                  [cancellato] l'idea mia e' che essendo il server proton "buono" (nel senso di buono come il server di fastweb) allora il traffico li' da of=>w3=> arriva senza problemi, poi dopo dipende solo dalla saturazione del server vpn, nel mio caso era libero quindi andava al massimo

                      Ciao, anche io sono in area bianca e noto da tempo questa differenza importante tra host che hanno implementato BBR e non.

                      ISP: Dimensione
                      Provenienza: Trentino Alto Adige

                      CWNET: https://www.speedtest.net/result/c/a900e446-7356-4c64-b6fa-3f65ab2d3479
                      CDLAN: https://www.speedtest.net/result/c/0d095571-7154-47e4-9c81-0bfd9d36ed83
                      Fastweb: https://www.speedtest.net/result/c/a29e8bd8-6db7-430e-b803-e71e0ad7b0c6

                      Anche nel mio caso, se provo ad utilizzare una VPN, bypasso la "problematica".

                      • [cancellato]

                      • Messaggio #8
                      • Modificato

                      xzvice Beh però wireguard gira su UDP, quindi tutte le supposizioni sull'algoritmo di congestion control diventano "fragili".

                      Potrebbe essere qualche interfaccia satura da qualche parte nella rete di trasporto OF, magari da priorità al traffico UDP per minimizzare i packet loss. Sto pensando a voce alta eh... però non mi si spiega come alcuni server in realtà diano velocità buona anche direttamente in HTTP/TCP e altri no. Ok che l'algoritmo di congestion control magari è più "aggressivo" nell'utilizzare la capacity dei link, però mi pare un po' alta come differenza.

                      BTW, provate con i server incriminati a fare un test alle 4 di mattina. Scommetterei che va a banda piena...

                          [cancellato] BTW, provate con i server incriminati a fare un test alle 4 di mattina. Scommetterei che va a banda piena...

                          Nono, vanno identici giorno e notte 🤔

                            [cancellato] BTW, provate con i server incriminati a fare un test alle 4 di mattina. Scommetterei che va a banda piena...

                            Al massimo vanno peggio (nelle ore con più traffico), non meglio di quello che è il "loro massimo".

                            La cosa è nata perché @xzvice si lamentava che sulla sua FTTH Wind i server di Wind stessa andavano a metà della banda (circa 500Mbps), la cosa era stata bollata dal gruppo Telegram come "Wind fa shaping sui suoi stessi server perché ha un kit di consegna sottodimensionato, cambia operatore e risolvi". Poi sono saltati altri utenti con altri ISP, collegati sia allo stesso che altri PCN, con problema analogo e il dubbio che Wind non c'entrasse nulla è diventata quasi certezza.

                            La cosa curiosa è che non è un semplice BBR, non BRR, ci sono server che non dovrebbero far uso di BBR (come Fastweb Milano) che vanno a banda piena (> 900Mbps).
                            Altra cosa curiosa che mi fa escludere che il tutto dipenda dalla congestione di un link, è che il PCN dell'OP è in grado di reggere due speedtest 1Gbps simultanei (da due linee diverse) e che nel suo caso la consegna wind è a pochi km dal PCN. Mi sembra altamente improbabile beccare lo stesso link congestionato degli utenti che hanno la consegna a 200km dal PCN.
                            Un utente inoltre afferma che pur non avendo mai visto quei server incriminati a banda piena, è cambiata la velocità massima raggiungibile dagli stessi con il cambio ISP, nello specifico con fibertelecom erano a circa 800Mbps, con aruba circa 600Mbps.

                              Mi verrebbe da dire che a questo punto sia un QoS "brutto" lato OLT (o comunque apparati OF), per quanto assurdo possa essere.
                              Mi spiego peggio, quando il PCN viene inizialmente rilegato con ponte radio viene applicato un sistema di QoS più pesante per evitare la saturazione "con un utente".
                              Dopodiché, quando il PCN viene rilegato in FTTH, OF non aggiorna la configurazione e quindi gli utenti rimangono con il QoS "vecchio", che ovviamente cappa più del dovuto.

                              BRR ed UDP sono solitamente degli ottimi modi per ignorare il QoS basilare, vedasi roba tipo quello dei Fritz, dove puoi impostare limiti semplici ma ti basta poco per superarli senza problemi.
                              Forse FW Milano usa un TCP-CC che non è BRR, ma nemmeno Cubic, bisognerebbe se ci sono differenze tra i vari server, o forse è semplicemente questione di "sfiga" con un bug in stile mikrotik (dove un IP si spacca e tutti gli altri funzionano bene, in questo caso il server FW Milano sarebbe spaccato)

                                LucaTheHacker Mi spiego peggio, quando il PCN viene inizialmente rilegato con ponte radio viene applicato un sistema di QoS più pesante per evitare la saturazione "con un utente".
                                Dopodiché, quando il PCN viene rilegato in FTTH, OF non aggiorna la configurazione e quindi gli utenti rimangono con il QoS "vecchio", che ovviamente cappa più del dovuto.

                                mai avuto rilegamento radio il mio, parliamo di molti PCN con la stessa problematica, e ipoteticamente tutti ma non ne siamo ancora certi, non abbiamo gli strumenti necessari per testarlo, se non un ISP

                                  Vorrei invocare @giusgius e @[cancellato]:

                                  se riusciste a raccogliere delle "prove" riguardo questo problema potreste magari segnalarlo a OF direttamente...

                                  qui non si tratta solo di speedtest, come un server speedtest va male, tanti altri andranno a meno della meta', esempio riot games e tanto altro...

                                  Se poteste fare qualcosa ve ne saremmo grati...

                                    xzvice Partecipo anche io al thread segnalando che pure io, come utente C&D, ottengo un comportamento simile a questo.

                                    Per il periodo in cui sono stato con Fiber Telecom avevo speedtest pieni stile area A&B (poi di sera con le partite crollava tutto a picco a livello inutilizzabile, ma è un altro discorso) mentre con altri ISP (prima Tiscali, da non considerare più di tanto per via dei suoi noti problemi, e ora Aruba) il comportamento, a spanne, è sempre stato quello indicato nel primo post.

                                    LucaTheHacker Mi verrebbe da dire che a questo punto sia un QoS "brutto" lato OLT (o comunque apparati OF), per quanto assurdo possa essere.

                                    Tenendo conto che con FT avevo dei massimi più alti ma dei minimi molto più bassi, ora con Aruba questo si traduce in massimi più bassi ma minimi più alti, quindi quest'ipotesi da te formulata potrebbe avere un senso anche se non credo che sia una cosa effettuata a livello di OLT.

                                    [cancellato] BTW, provate con i server incriminati a fare un test alle 4 di mattina. Scommetterei che va a banda piena...

                                    Non vanno mai a banda piena, nemmeno alle 4 di mattina; il massimo che ho visto sarà stato forse 650-700 mbps, che ci si avvicina ma non sono i canonici 940 mbps. NB: con FT andavano a banda piena negli orari scarichi.

                                            xzvice te lo dico in maniera molto diretta: una cosa di questo tipo, segnalata a OF, va dritta nel cestino.
                                            Ricordate che sono linee condivise, best effort, con bassa BMG. Non possiamo segnalare una cosa del genere 😅

                                                giusgius peccato... me ne dovro' fare una ragione.. grazie lo stesso per la risposta 😔

                                                pero' il fatto che siano condivise/best effort/con bassa BMG non c'entra comunque tanto... il backhauling dei pcn sono ok... su molti server si fanno velocita' massime, il problema e' verso server specifici...

                                                    xzvice no no chiaro, però intendo comunque che non rientra in una cosa contrattualmente “contestabile” lato loro

                                                        beastlukas
                                                        Sono almeno 12 mesi che non eseguo uno SpeedTest, allo scopo di valutare la mia linea !
                                                        X deformazione professionale vorrei che ci fosse il modo, lato utente, di testare solo la tratta fra OLT e ONT perché gli SpeedTest lasciano sempre il tempo che trovano come ha giustamente sottolineato beastlukas viste le possibili variabili: rilegatura PCN, Saturazione Linea, ISP, ecc...

                                                        Allo stato attuale a parte qualche fuori servizio programmato non ho mai avuto problemi di banda lavorando in Smartworking; gradirei forse una maggiore velocità in Upload per una migliore Performace verso il Cloud aziendale !

                                                        Attualmente il mio ISP offre solo una 1000/300. spero solo che in seguito possa, come altri ISP, integrare l'offerta oltre 2,5G/500, con un taglio intermedio 1000/500; il sogno sarebbe un profilo 1000/1000 in grado di sfruttare al meglio la mia rete interna.

                                                        Paolo

                                                            giusgius però intendo comunque che non rientra in una cosa contrattualmente “contestabile” lato loro

                                                            Domanda ingenua e non rivolta solo direttamente a te: perché un utente qualsiasi come @MiloZ può segnalare a FT, Telia, Cogent o Sparkle che ci sono problemi spesso "non contrattualmente contestabili" ed essere preso in considerazione, ed invece con OF non c'è possibilità di far indagare (a quanto riferisci) il perché ci siano hiccup di questo tipo sulla loro rete?

                                                                giusgius non c’è alcunché da contestare. Questa è pura curiosità sul perché vi siano queste differenze tra aree nere e bianche. Magari una config. errata lato OF che se segnalata potrebbe benissimo essere fixata. Chi lo dice che sia una cosa VOLUTA e non un errore umano? Una piccola segnalazione a nome di tutti potrebbe essere fatta. Purtroppo noi utenti non abbiamo alcun modo di interfacciarci con OF, quindi è l’ISP stesso che deve perlomeno provare a farlo.

                                                                    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