Gebruik een eigen router i.p.v. de Experia Box

Ik had een soortgelijk iets. Had ook mijn edgerouter gekoppeld maar kreeg ook geen telefonie. Een KPN moderator heeft toen iets afgerond want volgens hun was mijn installatie nog niet afgerond.

Daarna werkte het gelijk. Misschien had ik ook die experia er aan moeten hangen en resetten. 

VLAN 4 mocht niet baten. IPTV valt na 5min weer uit. :(

Dus als jouw omvormer gewhitelist wordt voor multicasts dan houdt jouw TV er na een paar minuten mee op. Zolang jouw omvormer niet gewhitelist is blijft de televisie het doen. 

Klopt het bovenstaande?

Yes, correct.

Als de TV ontvanger en de omvormer op verschillende vlans zitten dan zouden ze niet zomaar elkaar in de weg kunnen zitten. Ik ben nog wel benieuwd hoe de IGMP proxy server geconfigureerd is want ik neem aan dat downstream alleen het vlan van de TV ontvanger actief is.

@1337lutz,

Ik zit even mee te lezen en gezien we , buiten de ER om, dezelfde apparatuur gebruiken denk ik dat je de omvormer niet apart hoeft te enablen voor multicast. Ik draai net als jij ITPV op een apart VLAN waar IGMP snooping op aanstaat. Echter staat via de unifi controller ook IGMP Snooping aan, door het vinkje aan te zetten op het LAN (default VLAN 1). Op mijn unifi AP's (SSID's) staat IGMP snooping uit (dit handelen de switches af) en ik gebruik op whitlisting, dus wat je nog zou kunnen proberen om (tijdelijk) een gasten SSID op te zetten en daar de omvormer op te laten draaien, zonder hier apart op je controller Multicast aan te zetten. 

Zoals wjb al heeft aangeven, kijk goed naar je settings van je IGMP Proxy server en of het aangemaakte VLAN ook zijn werk doet.

https://help.ui.com/hc/en-us/articles/204961854-EdgeRouter-IGMP-Proxy

Hey guys,

Thanks voor alle tips!

Dit is de output van mijn config.boot betreffende de igmp proxy:

protocols {
    igmp-proxy {
        interface eth0.4 {
            alt-subnet 0.0.0.0/0
            role upstream
            threshold 1
        }
        interface eth1.4 {
            alt-subnet 192.168.4.0/24
            role downstream
            threshold 1
        }
    }
    static {
        interface-route6 ::/0 {
            next-hop-interface pppoe0 {
            }
        }
    }
}

en de NAT rule:

nat {
        rule 5000 {
            description IPTV
            destination {
                address 213.75.112.0/21
            }
            log disable
            outbound-interface eth0.4
            protocol all
            source {
                address 192.168.4.0/24
            }
            type masquerade
        }
        rule 5010 {
            description Internet
            log disable
            outbound-interface pppoe0
            protocol all
            type masquerade
        }
    }

@Multiedje In principe staat mijn omvormer al op een los netwerk op VLAN 55, de IPTV zit nu op VLAN 4. Zou jij zeggen om dus IGMP snooping uit te zetten voor de network (IoT WIFI - VLAN 55)? die fungeert in de controller als een VLAN only

Ik heb niet apart op WLAN IGMP Snooping aanstaan, gezien de AP's aan de switches hangen die de snooping afhandelen. Er is dus 0 multicast verkeer op mijn WLAN, dit zou ik alleen krijgen als ik via de bridge poort van de AC Pro een STB ga aansluiten. Gezien ik IPTV via een apart VLAN heb lopen kan ik de betreffende poort isoleren daar gaat alleen Multicast verkeer over.

Dus in jou geval, IGMP snooping aan op VLAN4 en dan hoef je volgens mij niets te doen met Multicast op VLAN 55. Als je de controller en de firewall rules van je ER goed inricht dan moet dat werken. Als voorbeeld op mijn ER4. Verkeer van eth2 kan niet op eth1 komen middels de firewall rules. Zo kan dus ook onbedoeld multicast verkeer niet door mijn overige netwerk heen gaan.

protocols {
    igmp-proxy {
        interface eth0.4 {
            alt-subnet 0.0.0.0/0
            role upstream
            threshold 1
        }
        interface eth1.4 {
            alt-subnet 0.0.0.0/0
            role downstream
            threshold 1
Zo te zien staat je alt-subnet op je VLAN niet goed, zie vorig screenshot

Ik hang hier even wat meer info aan van wat ik nu heb qua settings:

De IPTV zit nu op VLAN4 via de UAP InWall (deze heeft 2 outputs) met de port vastgezet op VLAN 4.

Ik heb zojuist block multicast op deze IOT wifi uitgezet.

Output: show ip multicast interfaces

Intf             BytesIn        PktsIn      BytesOut       PktsOut            Local
eth1               0.00b             0         0.00b             0    192.168.2.254
eth1.55            0.00b             0         0.00b             0     192.168.55.1
eth1.50            0.00b             0         0.00b             0     192.168.50.1
eth0.4          917.96MB        709842         0.00b             0    10.137.96.251
eth1.4             0.00b             0      918.01MB        709880      192.168.4.1
pppoe0             0.00b             0         0.00b             0     xxxx

@1337lutz,

Ik heb, buiten VLAN 4 en LAN, geen IGMP snooping aanstaan. Je LAN (gateway)staat overigens in je ER op 192.168.2.254 en op je controller settings op 192.168.2.1

Welk merk en type switch gebruik je overigens?

Multiedje schreef:

@1337lutz,

Ik heb, buiten VLAN 4 en LAN, geen IGMP snooping aanstaan. Je LAN (gateway)staat overigens in je ER op 192.168.2.254 en op je controller settings op 192.168.2.1

 

Scherp, aangepast.

Ik heb mijn Block LAN to WLAN Multicast and Broadcast Data voor het IoT WIFI weer aangezet en toen handmatig mijn mac adres van ER3 eth1, RPI en mijn omvormer toegevoegd. Pas dan is de omvormer weer toegankelijk via het web interface / speedwire (protocol).

1337lutz schreef:

Multiedje schreef:

@1337lutz,

Ik heb, buiten VLAN 4 en LAN, geen IGMP snooping aanstaan. Je LAN (gateway)staat overigens in je ER op 192.168.2.254 en op je controller settings op 192.168.2.1

 

Scherp, aangepast.

Ik heb mijn Block LAN to WLAN Multicast and Broadcast Data voor het IoT WIFI weer aangezet en toen handmatig mijn mac adres van ER3 eth1, RPI en mijn omvormer toegevoegd. Pas dan is de omvormer weer toegankelijk via het web interface / speedwire (protocol).

Ben benieuwd of het nu werkt/blijft werken. Wel ben ik benieuwd waarom je de PI (tenzij deze via wifi is geconnecteerd) wil opnemen in je whitlist. Kijk ook nog even goed naar je Proxy settings (mijn vorige opmerking) 

protocols {
    igmp-proxy {
        interface eth0.4 {
            alt-subnet 0.0.0.0/0
            role upstream
            threshold 1
        }
        interface eth1.4 {
            alt-subnet 0.0.0.0/0
            role downstream
            threshold 1

Multiedje schreef:

1337lutz schreef:

Multiedje schreef:

@1337lutz,

Ik heb, buiten VLAN 4 en LAN, geen IGMP snooping aanstaan. Je LAN (gateway)staat overigens in je ER op 192.168.2.254 en op je controller settings op 192.168.2.1

 

Scherp, aangepast.

Ik heb mijn Block LAN to WLAN Multicast and Broadcast Data voor het IoT WIFI weer aangezet en toen handmatig mijn mac adres van ER3 eth1, RPI en mijn omvormer toegevoegd. Pas dan is de omvormer weer toegankelijk via het web interface / speedwire (protocol).

Ben benieuwd of het nu werkt/blijft werken. Wel ben ik benieuwd waarom je de PI (tenzij deze via wifi is geconnecteerd) wil opnemen in je whitlist. Kijk ook nog even goed naar je Proxy settings (mijn vorige opmerking) 

protocols {
    igmp-proxy {
        interface eth0.4 {
            alt-subnet 0.0.0.0/0
            role upstream
            threshold 1
        }
        interface eth1.4 {
            alt-subnet 0.0.0.0/0
            role downstream
            threshold 1

Proxy heb ik opgenomen.

Pi heb ik inderdaad verwijderd en kan nog steeds goed verbinden met de omvormer.

TV loopt echter nu weer vast. (na whitelisten omvormer)

1337lutz schreef:

Multiedje schreef:

1337lutz schreef:

Multiedje schreef:

@1337lutz,

Ik heb, buiten VLAN 4 en LAN, geen IGMP snooping aanstaan. Je LAN (gateway)staat overigens in je ER op 192.168.2.254 en op je controller settings op 192.168.2.1

 

Scherp, aangepast.

Ik heb mijn Block LAN to WLAN Multicast and Broadcast Data voor het IoT WIFI weer aangezet en toen handmatig mijn mac adres van ER3 eth1, RPI en mijn omvormer toegevoegd. Pas dan is de omvormer weer toegankelijk via het web interface / speedwire (protocol).

Ben benieuwd of het nu werkt/blijft werken. Wel ben ik benieuwd waarom je de PI (tenzij deze via wifi is geconnecteerd) wil opnemen in je whitlist. Kijk ook nog even goed naar je Proxy settings (mijn vorige opmerking) 

protocols {
    igmp-proxy {
        interface eth0.4 {
            alt-subnet 0.0.0.0/0
            role upstream
            threshold 1
        }
        interface eth1.4 {
            alt-subnet 0.0.0.0/0
            role downstream
            threshold 1

Proxy heb ik opgenomen.

Pi heb ik inderdaad verwijderd en kan nog steeds goed verbinden met de omvormer.

 

TV loopt echter nu weer vast.

restart igmp-proxy of/en even de STB's power eraf halen, ze moeten wel even de weg kunnen vinden;-)

EDIT: reboot via gui wil na SAVE ook werken.

Multiedje schreef:

1337lutz schreef:

Multiedje schreef:

1337lutz schreef:

Multiedje schreef:

@1337lutz,

Ik heb, buiten VLAN 4 en LAN, geen IGMP snooping aanstaan. Je LAN (gateway)staat overigens in je ER op 192.168.2.254 en op je controller settings op 192.168.2.1

 

Scherp, aangepast.

Ik heb mijn Block LAN to WLAN Multicast and Broadcast Data voor het IoT WIFI weer aangezet en toen handmatig mijn mac adres van ER3 eth1, RPI en mijn omvormer toegevoegd. Pas dan is de omvormer weer toegankelijk via het web interface / speedwire (protocol).

Ben benieuwd of het nu werkt/blijft werken. Wel ben ik benieuwd waarom je de PI (tenzij deze via wifi is geconnecteerd) wil opnemen in je whitlist. Kijk ook nog even goed naar je Proxy settings (mijn vorige opmerking) 

protocols {
    igmp-proxy {
        interface eth0.4 {
            alt-subnet 0.0.0.0/0
            role upstream
            threshold 1
        }
        interface eth1.4 {
            alt-subnet 0.0.0.0/0
            role downstream
            threshold 1

Proxy heb ik opgenomen.

Pi heb ik inderdaad verwijderd en kan nog steeds goed verbinden met de omvormer.

 

TV loopt echter nu weer vast.

restart igmp-proxy of/en even de STB's power eraf halen, ze moeten wel even de weg kunnen vinden;-)

EDIT: reboot via gui wil na SAVE ook werken.

Heb restart proxy gedaan EN de STB uit en aan gezet, na 10min krijg ik wederom de melding dat de zender niet beschikbaar is. 🤷‍♂️

Ik ben niet zo behendig in het interface van de ER, maar kan ik niet alle incoming igmp/multicast traffic naar eth 1.04 blokkeren?

@1337lutz,

Dus VLAN 4 aanmaken, je DHCP aanmaken, je NAT aanpassen op de ER

VLAN 4 (only)  met IGMP snooping aan op je controller.

Poorten op je switch aanpassen t.b.v. IPTV VLAN 4

Op je Controller Force Provision op de switches en AP's

SAVE en reboot op je ER

Ik zou bijna die kant op komen

@Multiedje Dat is precies wat ik heb:

1337lutz schreef:

@Multiedje Dat is precies wat ik heb:

 

Je moet het in de settings van de ER gaan zoeken. Heb je de DNS en interfaces al nagekeken?

Multiedje schreef:

Je moet het in de settings van de ER gaan zoeken. Heb je de DNS en interfaces al nagekeken?

 

Daar had ik alleen eth1 staan. Ik heb zojuist ook de andere 3 VLANs toegevoegd, klopt dat?

Edit: Heeft verder niets geholpen.

1337lutz schreef:

Multiedje schreef:

Je moet het in de settings van de ER gaan zoeken. Heb je de DNS en interfaces al nagekeken?

 

Daar had ik alleen eth1 staan. Ik heb zojuist ook de andere 3 VLANs toegevoegd, klopt dat?

YEP, ik denk dat de STB's de juiste weg niet kunnen vinden.

Voor ik ga pitten, nog even helemaal terug naar de basis. Als ik het script van wjb inspoel (die in debasis hetzelfde werkt als de experibox) dan werkt IPTV bij mij zonder dat ik iets aanpas direct (mist je goede IGMP snooping switches hebt). Daarna ga ik de rest koppelen, gezien de familie TV wil kijken. Wij gebruiken beide unifi apparatuur, wat het een stuk makkelijker maakt op poorten toe te wijzen of uit te sluiten. Dus als je route voor routed IPTV verkeer in de kernel draait en je proxy, DHCP en VLAN goed staat dan werkt alles als een zonnetje.

zodra er 1 setting in de route niet klopt dan is het stotteren of hangen van het routed IPTV verkeer. Dit is denk ik een puur route instelling.

Kortom loopt alles netjes in de kernel, krijgen je STB's een IP uit het juiste V(LAN), draait je proxy server?

Nog vraagje, waar ik waarschijnlijk morgen pas op ga antwoorden, werkte het IPTV wel goed na de eerste inspoeling van het script van wjb?

Cheers , spreek je morgen, met alle hulp op dit topic komen we er wel uit

Multiedje schreef:

YEP, ik denk dat de STB's de juiste weg niet kunnen vinden.

Voor ik ga pitten, nog even helemaal terug naar de basis. Als ik het script van wjb inspoel (die in debasis hetzelfde werkt als de experibox) dan werkt IPTV bij mij zonder dat ik iets aanpas direct (mist je goede IGMP snooping switches hebt). Daarna ga ik de rest koppelen, gezien de familie TV wil kijken. Wij gebruiken beide unifi apparatuur, wat het een stuk makkelijker maakt op poorten toe te wijzen of uit te sluiten. Dus als je route voor routed IPTV verkeer in de kernel draait en je proxy, DHCP en VLAN goed staat dan werkt alles als een zonnetje.

zodra er 1 setting in de route niet klopt dan is het stotteren of hangen van het routed IPTV verkeer. Dit is denk ik een puur route instelling.

Kortom loopt alles netjes in de kernel, krijgen je STB's een IP uit het juiste V(LAN), draait je proxy server?

Nog vraagje, waar ik waarschijnlijk morgen pas op ga antwoorden, werkte het IPTV wel goed na de eerste inspoeling van het script van wjb?

 

Cheers , spreek je morgen, met alle hulp op dit topic komen we er wel uit

Ik ga ook mn nest in, laat genoeg ;)

Ja, alles werkte tot een maand geleden toen ik mn ER3 update naar 2.0.8 deed (van 1.10)+ misschien (niet zeker) een firmware update vanuit Unifi. Ben pas deze week er weer naar gaan kijken of ik het vastlopen kan verhelpen.

Ik merk nu dat het ook vastloopt als mn omvormer helemaal niet verbonden is, dus waarschijnlijk is het dan toch iets anders dan dat block multicast gedoe.

Kortom loopt alles netjes in de kernel

Ja, zie:

Krijgen je STB's een IP uit het juiste V(LAN)

Yes, zie screenshot

Draait je proxy server?

Ja, daar lijkt het wel op...

show ip multicast interfaces
Intf             BytesIn        PktsIn      BytesOut       PktsOut            Local
eth1               0.00b             0         0.00b             0    192.168.2.254
eth1.55            0.00b             0         0.00b             0     192.168.55.1
eth1.50            0.00b             0         0.00b             0     192.168.50.1
eth0.4          928.15MB        720601         0.00b             0     10.137.97.57
eth1.4             0.00b             0      928.15MB        720593      192.168.4.1

show ip multicast mfc
Group           Origin           In          Out                Pkts         Bytes  Wrong
224.3.2.6       213.75.167.58    eth0.4      eth1.4             3936        1.37MB      0
224.0.252.134   217.166.226.134  eth0.4      eth1.4           716674      926.79MB      0
233.89.188.1    192.168.2.2      eth0.4      eth1                 10       320.00b     10
239.254.127.63  192.168.2.12     eth0.4      eth1                  2       232.00b      2
239.255.255.250 192.168.50.165   eth0.4      eth1                 14        2.30KB     14
239.255.255.250 192.168.50.165   eth0.4      eth1.4               14        2.30KB     14
239.254.127.63  192.168.2.11     eth0.4      eth1                  4       464.00b      4
239.254.127.63  192.168.2.10     eth0.4      eth1                  5       580.00b      5
239.255.255.250 192.168.2.2      eth0.4      eth1                120       34.77KB    120
239.255.255.250 192.168.4.14     eth0.4      eth1               2036      900.39KB   2036
239.255.255.250 192.168.4.14     eth0.4      eth1.4             2036      900.39KB   2036
239.255.255.250 192.168.50.15    eth0.4      eth1                253       37.80KB    253
239.255.255.250 192.168.50.15    eth0.4      eth1.4              253       37.80KB    253
239.255.255.250 192.168.2.18     eth0.4      eth1                246       31.06KB    246
239.255.255.250 192.168.2.18     eth0.4      eth1.4              246       31.06KB    246
239.255.255.250 192.168.2.121    eth0.4      eth1                211       57.55KB    211
239.255.255.250 192.168.2.121    eth0.4      eth1.4              211       57.55KB    211

Dat laatste plaatje ziet er wel erg vreemd uit. Er staan een boel interfaces tussen die er volgens mij niet tussen horen te staan. Volgens mij klopt er het een en ander niet aan je config.

Ik zou in ieder geval alle overbodige vlans verwijderen.

Dit is bijv mijn output:

An sich is daar niets mis mee …

...maar je kunt interfaces binnen de IGMP proxy server uitsluiten door ze de rol "disabled" te geven.

Het adres 239.255.255.250 is een "IPv4 site-local address" t.b.v. SSDP (Simple Service Discovery Protocol) wat gebruikt wordt voor ondermeer UPnP.

Apparaten maken zichzelf zichtbaar m.b.v. SSDP en er is niet mis mee dat je dergelijke communicatie ziet.

Wel lijkt de EdgeRouter niet altijd de juiste interfaces te tonen.

In het bovenstaande screenshot staan apparaten uit het subnet 192.168.2.0/24 op eth1 terwijl ze op eth1.4 getoond worden.

Dat zal dan denk ik een firmware dingetje zijn. Ik draai nu die 2.0.9 firmware. En ja ik weet dat het een Beta release is maar wilde deze toch proberen gezien er aanmerkelijke verbeteringen in zitten aangaande die igmp proxy. Ik draai nu meer dan 6 dagen zonder ook maar een enkel issue.

En ik kan natuurlijk altijd weer downgraden indien noodzakelijk.

Goed te lezen dat jij geen problemen ervaart met EdgeOS versie 2.0.9 en de nieuwe IGMP proxy server (versie 0.2.1) die daar in opgenomen is.