Pawz con tutti i requisiti tecnologici richiesti alla fine solo una piccola fetta dell'utenza

No, perché la maggioranza della utenza ha il modem Tim che supporta la configurazione
Non è poi un dramma se alcuni utenti andranno in unicast
Inoltre per l’utente non ha particolari vantaggi, è solo l’operatore ad alleggerirsi la sua rete col multicast.

Chi ha modem liberi quindi dorma tranquillo che vedrà ugualmente tutto

  • DrGix ha risposto a questo messaggio
  • DrGix ha messo mi piace.

    gandalf2016 però sarebbe carino capire quale è la configurazione migliore tra quelle possibili.
    A me piacerebbe avere il timbox che si apre una sessione pppoe tutta sua sulla vlan 835 e da solo si prende la configurazione per instaurare la connessione bridged sulla vlan 836 per il multicast... non avrò controllo su qos e non lo vedrò da dentro la rete ma sarebbe tutto molto più "user friendly" senza smadonnare con igmp snooping, vlan e firewallate del caso...

      DrGix A me piacerebbe avere il timbox che si apre una sessione pppoe tutta sua sulla vlan 835 e da solo si prende la configurazione per instaurare la connessione bridged sulla vlan 836 per il multicast...

      Il problema è che hanno detto sopra che multicast su PPPoE non è una grande idea (per TIM) perchè avresti n flussi tra BRAS e utente (e quindi anche tra BRAS e armadio).

      DrGix e da solo si prende la configurazione per instaurare la connessione bridged sulla vlan 836 per il multicast...

      In che senso? La PPPoE è "incapsulata" nella VLAN di 802.1, non viceversa.
      Una volta che sul router hai taggato la WAN sulla 835 se un dispositivo si apre una nuova PPPoE non può usare una VLAN diversa, penso.

      Il router invece può avere due interfacce (virtuali) su due VLAN diverse.


      Detto questo, si sbrighino a passare a IPoE/DHCP anche sulla rete dati normale 😐

      E comunque il mio mikrotik continua a non trovare assolutamente nulla, provato anche PPPoE Scan ma non trova nessun concentrator.

        • [cancellato]

        edofullo comunque il mio mikrotik continua a non trovare assolutamente nulla

        Come scrivevo in altro commento la tua linea potrebbe non essere ancora stata oggetto di riconfigurazione con aggiunta del PVC video.

          [cancellato] Aspetto pazientemente 😇 (anche se del calcio frega ben poco 😅)

          edofullo (e quindi anche tra BRAS e armadio).

          Aspetta anche peggio di BRAS armadio… perché prima del BRAS hai altri router/switch con non vedi nel traceroute.

            gandalf2016 In che senso? Il bras non può ricevere un singolo flusso multicast e "moltiplicarlo" tu tutte le PPPoE che ha connesse?

              edofullo sì, evidenziavo soltanto che prima dell’utente, tra BRAS e armadio ci sono altri router e switch

              • [cancellato]

              • Modificato

              DrGix A me piacerebbe avere il timbox che si apre una sessione pppoe tutta sua

              Così TIM però si trova di colpo milioni di utenti (almeno sperano) che di colpo usano due IP invece di uno. Vabbè che ne hanno tanti, ma forse non vogliono usarli proprio così - senza contare le modifiche per assicurare che non ci siano problemi con assegnazioni e routing - comunque ogni box avrebbe bisogno di un indirizzo unicast.

              edofullo non può usare una VLAN diversa

              QinQ?

                Si, però mi sembra una complicazione un po' inutile, visti anche i problemi detti sopra.

                [cancellato] non credo che sia tecnicamente necessario assegnare un ip pubblico. Di soluzioni, anche fantasiose, per semplificare la vita ai "modem liberi" ce ne sarebbero. Una estrema potrebbe essere quella di permettere di bypassare interamente il router collegando direttamente l'ont al sagemcom facendo fare tutto a lui anche a costo di rinunciare momentaneamente ad internet.
                Alla fine mi sembra di capire che le partite (che tanto non vedrò) saranno trasmesse anche in unicast... per cui come soluzione estrema in caso di saturazione della rete tim non la escluderei per principio.
                Quello che mi sembra certo è che la maggioranza dei router "commerciali" con firmware stock non è compatibile con il multicast tim 😟 e per chi ha (o crede di avere) hardware adeguato ci sarà da applicarsi parecchio per avere una configurazione funzionante...

                  DrGix Comunque dato che il traffico multicast non passa dentro il PPPoE non vedo perché si dovrebbe apire una sessione PPPoE il timbox😅

                    simonebortolin per non dover configurare niente... apre la sessione pppoe e si scarica la configurazione dal ACS server tramite tr-069. Purtroppo però non si può incapsulare la vlan 836 nella 835 e quindi qualunque configurazione non funzionerebbe senza uno switch managed tra ont e TVB (timvisionbox🤣) dove le relative porte hanno le vlan 835 ed 836 taggate...

                      DrGix Esatto....
                      Però il TR69 è visto molto ma molto male nell'altro topic

                      • [cancellato]

                      DrGix non credo che sia tecnicamente necessario assegnare un ip pubblico

                      Vero, però questo gli complicherebbe la configurazione - dover assegnare indirizzi diversi a seconda di chi fa la richiesta. Più facile se lo fai con un PVC su una VLAN diversa.

                      simonebortolin Comunque dato che il traffico multicast non passa dentro il PPPoE

                      Non è che non ci passa, è che essendo appunto la sessione "point-to-point" non c'è più alcuno step intermedio che possa fare la duplicazione dei pacchetti solo quando necessario, quindi il traffico deve essere "duplicato" per tutti i destinatari sul BRAS creando n flussi anche quando senza PPPoE sarebbe possibile invece avere un unico flusso multicast fino al dispositivo al quale fanno capo i router degli utenti.

                      In realtà dopo la terminazione della PPPoE sul router, ridiventa traffico multicast normale (a meno che il BRAS non lo trasformi in unicast). e a valle del router i dispositivi lo possono gestire normalmente.

                        [cancellato] Per me il traffico multicast potrebbe essere indipendente da quello PPPoE, e quindi passare per router diverse all'interno della rete interna a TIM, quindi bypassare il bras.

                          Domanda da profano di IGMP, VLAN e PVC, immagino che il router riceve dal TIMVISION Box la richiesta di un flusso multicast che poi la inoltra al PVC dedicato, corretto? E allora come fa il router a sapere che va inoltrata lì e non al PVC normale? Da una tabella di routing?

                            WhiteArean95 Il multicast, in parole povere, in IPv4, è di tipo subscrive-notify di tipo distribuito (in parole povere):

                            Il Timvision Box invia la richiesta di subscribel al router, il router la invia al router superiorie, il router superiore a quello ancora più superiore, finché non si arriva al server che invia in multicast. Ogni router si segna a quali device deve inviare i pacchetti multicast, e poi il server mutlicast invia il flusso all'ultimo router, che lo invia a quello precedente fino ad arrivare al proprio router domestico, che esso lo inoltra al timvisio Box

                            La VLAN serve solamente per fare una sessione separata da quella PPPoE (in quanto non avrebbe senso mandare il traffico multicast su una connessione PPPoE in quanto si duplicano i flussi video fino al BRAS e quindi sull'uplink dell'ONU ci sono n flussi video e non uno solo, vedi thread precedenti, stessa cosa vale per gli albero GPON), così si guadagnano pure qualche kbps/s dovuti all'hoverhead della PPPoE.

                            Inoltre il BRAS potrebbe essere diverso dal server multicast. Comunque semplicemente ci sono due Virtual LAN: una per il PPPoE, la 835 e una per il mutlicast, la 836, ognuna delle due con due sottoreti diverse, per esempio 10.35.0.X e 10.36.0.X

                              DrGix il mio router supporta il multi vlan peccato non possa testarlo perché non ho tim come operatore.

                              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