Ik gebruik al een tijdje Tweak en voor dat canal digitaal er was had ik het ook via mijn eigen router opgezet dat de IPTV ook werkt. Nu heb ik een tijdje Ziggo TV gebruikt maar dacht ik ga IPTV weer eens aan de praat krijgen op mn nieuwe edgerouter.
Echter loop ik tegen een probleem aan, de IGMP proxy lijkt te werken, althans ik ontvang hier en daar al wat multicast verkeer. Echter wil de router niet routen naar de IPTV netwerk.
Mijn eth1.4 ontvangt gewoon een IP adres en gateway van Tweak. Op dit moment is dit 10.10.56.119/21 en gateway van 10.10.56.1. Maar als ik ook maar iets binnen die IP range probeer te bereiken, zelfs de gateway, krijg ik āDestination Host Unreachableā. Dit zou betekenen dat er geen route is naar de host. Maar de host is in principe ādirectly connectedā.
De routing table ziet er als volgt uit:
IP Route Table for VRF ādefaultā
S *> 0.0.0.0/0 [210/0] via 185.227.72.1, eth1.34
S 0.0.0.0/0 [254/0] via 10.10.56.1, eth1.4
C *> 10.10.56.0/21 is directly connected, eth1.4
S 10.10.56.0/21 [1/0] via 10.10.56.1 inactive
C *> 127.0.0.0/8 is directly connected, lo
S *> 185.24.175.0/24 [1/0] via 10.10.56.1, eth1.4
S *> 185.41.48.0/24 [1/0] via 10.10.56.1, eth1.4
C *> 185.227.72.0/22 is directly connected, eth1.34
C *> 192.168.0.0/22 is directly connected, eth8
Iemand enig idee hoe dit zou kunnen? Zoals ik al aangaf betreft het een edgerouter config.
Hier ben ik inderdaad al uitgebreid doorheen gegaan. De error zelf vind ik gewoon raar.
Want āDestination Host Unreachableā betekent meestal dat de router geen route heeft om dat netwerk waar die host zich zou bevinden te bereiken. Maar dit netwerk staat in de route table en is zelfs directly connected. Dit zou dus naar mijn kennis nooit een destination host unreachable error mogen geven. Wel bijvoorbeeld een time out of een destination host unreachable van eventuele router verder in de stream als ik hem bijvoorbeeld over de verkeerde gateway stuur.
āDestination host unreachableā op een directly connected netwerk betekent dat er geen antwoord komt op het ARP request. Wat daar dan weer de oorzaak van isā¦
Ik heb even een package capture gedaan via de edgerouter. Het lijkt er op dat ik inderdaad geen reactie krijg op ARP requests voor de gateway IP van Tweak.
Zijn er nog dingen die ik zou moeten testen voor ik tweak de schuld ga geven? eth1 is een glasvezel SFP module die direct op de glasvezel zit die naar tweak gaat. Geen apparatuur wat er tussen zit en eventueel kan storen lijkt me.
Je pingt trouwens het ānetwerkā-adres, wil je eens een legitieme host (185.24.175.1) pingen? Die moet reageren, als die niet reageert gaat er wat fout in de configuratie.
Dit maakt niet uit, maar heb het voor de zekerheid nog even gecheckt en het ip wat je aangeeft geeft het zelfde result aan. Dat er wat fout zit ergens begrijp ik, vandaar ook de vraag hier op t forum. Maar als de router een ARP request doet voor wie de gateway IP heeft, zou de switch of router waar de fiber aan vast zit in de netwerkcentrale van dronten een reply moeten geven. Deze reply lijkt er niet te komen wat waarschijnlijk een fout aan de kant van tweak aangeeft.
Het zou ook kunnen dat dat niet de gateway IP is, maar in dat geval krijg ik verkeerde adres gegevens via DHCP, wat wederom dan een fout van tweak lijkt te zijn.
Nu nog een 3e mogelijke optie, tweak heeft me geblokkeerd. In het verleden heb ik wel een werkende config gehad. Maar door omwisselen van switches was mn vlan configuratie niet meer goed en stuurde ik multicast traffic terug naar tweak. Hier kreeg ik een email van en had dit direct opgelost. Maar toen der tijd gebruikte ik al geen tv (anders had ik ook wel gemerkt dat ik de configuratie verpest had).
Dus wellicht mogelijk dat tweak toen iets geblokkeerd heeft, ik heb hier ook een email naar tweak voor uitstaan maar alsnog goed om even naar de config te kijken natuurlijk.
In ieder geval, de blokkade van de eerste keer dat je een foutieve multicast-configuratie had zat er tot nu nog steeds op. Die is nu dus verwijderd en hoogstwaarschijnlijk werkt het nu weer.
Ja, maar je was al op de hoogte
Tot vandaag heb ik geen reactie gezien, dus vandaar dat je tot vandaag geblokkeerd was. Maar goed, mooi dat het nu opgelost is
Ik was niet op de hoogte dat ik geblokkeerd was. Ik kreeg alleen "We hebben geconstateerd dat er vanaf je router een multicast router wordt gedraaid. Dit verstoort mogelijk het IPTV verkeer in Dronten. Zou je zsm je router goed kunnen configureren?
". nog geen uur later had ik alle multicast uitgeschakeld en de dag erop kreeg ik "Bedankt voor uw reactie. Wij zullen u informeren met verdere info. ". Daarna nooit wat gehoord.
Hier kan ik niet uit halen dat ik geblokt was, en laat staan nog steeds zou zijn. Geeft niet, kan gebeuren maar dan moet er niet gezegd worden: āje was al op de hoogteā.
Kun je vertellen hoe je dat opgelost hebt met multicast routerā¦ ik heb dat ook ooit veroorzaakt en moet dat gaan uitzoeken hoe op te lossen ;-)ā¦ Dan kan ik mijn sfp gebruiken can mijn switch ipv een mediaconverterā¦
Contact opgenomen via e-mail. Daar hebben ze de blokkade opgeheven. Maar oppassen met SFP van switch gebruiken als je die ook gebruikt voor de rest van je netwerk, anders blokkeren ze je zo weer als je verkeer die kant op stuurt.
Wellicht aan te raden om de switch die je gebruikt met SFP niet te gebruiken voor intern netwerk. Sowieso wel zo veilig. Niet gedacht aan een router met SFP poort?
Het gaat erom dat multicast verkeer een soort broadcast verkeer is, igmp snooping zou dit tegen moeten houden maar in mijn geval gebeurde dit niet.
Ik heb het opgelost door mijn lokale netwerk niet meer opdezelfde switch te hangen waar de provider op hangt. Tweak gaat mn router in, en router naar mn LAN.
Voorheen had ik tweak -> switch vlan x -> router, router terug naar zelfde switch op andere vlan. Maar dit ging natuurlijk multicast verkeer naar tweak sturen wat niet gewenst is.
Dank je wel zal eens mijn vriend Google is vragen ā¦ zou toch moeten werken sfp naar een switch Port die weer een wan wordt en de usg in gaat. Vraag me af of igmp snooping ook aan moet staan op je vlan4 of daar juist niet.
