aqui
Goto Top

Cisco IOS Entertain IP-TV Konfig ?

Kurze Frage an die Forums Community die einen Cisco IOS Router mit Entertain TV benutzen.
Ich habe aktuell einen 880er an einem älteren VDSL Anschluss der in der letzten Woche auf Entertain upgegraded wurde. Ich kann derzeit nicht sicher sagen ob das mit oder ohne BNG rennt oder ob Entertain überhaupt schon aktiv geschaltet wurde darauf. Feedback der Telekom steht noch aus.
VDSL ist dort schon seit ca. 2 Jahren aktiv und die Router Internet Connection und VoIP rennen fehlerlos. Es geht rein ums Multicasting mit Entertain.
Hier die aktuelle benutzte Konfig: (Unwichtiges weggelassen)
interface Ethernet0.7
 description VDSL Internet Verbindung - VLAN 7 tagged
 encapsulation dot1Q 7
 pppoe enable group global
 pppoe-client dial-pool-number 1
!
interface Ethernet0.8
 description VDSL Multicast Verbindung - VLAN 8 tagged
 encapsulation dot1Q 8
 ip dhcp client broadcast-flag clear
 ip address dhcp
 ip pim sparse-mode
 ip igmp version 3
 ip igmp query-interval 15
 ip igmp proxy-service
!
interface Vlan1
 description Lokales LAN
 ip address 192.168.1.254 255.255.255.0
 ip nat inside
 ip tcp adjust-mss 1452
 ip pim sparse-mode
 ip igmp helper-address 10.41.127.254
 ip igmp version 3
 ip igmp explicit-tracking
 ip igmp query-interval 15
 ip igmp proxy-service
!
interface Dialer0
 description Dialin T-Online VDSL
 ip address negotiated
 ip pim sparse-mode
 ip igmp version 3
 ip igmp query-interval 15
 ip igmp proxy-service
 ip mtu 1492
 ip nat outside
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 ppp authentication pap callin
 ppp ipcp dns request
 ppp ipcp mask request
 ppp ipcp route default
 no cdp enable
!
ip dns server
ip pim rp-address 10.41.127.254 
Bewusst ist sämtliche Firewall Konfig und ACLs am Dialer Port erstmal weggelassen um die Multicast Negotiation nicht irgendwie zu behindern.
Internet Dialin, VoIP klappen wie gewohnt aber Multicasting nada....
Ein show ip int brief zeigt keine negotiatete RFC1918 IP wie sie ja aktuell wohl üblich sind am .08er Subinterface. Was schlussfolgern lässt das Multicasting (Entertain) generell nicht aktiviert ist auf dem Anschluss. Oder noch ein anderer Fehler besteht ?!
Ein show dhcp lease zeigt ebenso keine aktiven IPs. show ip igmp groups auch keine MC Gruppen.
Der Versuch mit einem VLC eine der Programm Multicast Gruppen zu öffnen siehe_hier scheiterte auch was aber wegen der fehlenden Adressierung zu erwarten war.

Lange Rede.... Ein Output der o.a. Show Kommandos und ggf. eine aktuell laufende Konfig wäre mal interessant.

Content-Key: 356506

Url: https://administrator.de/contentid/356506

Ausgedruckt am: 29.03.2024 um 07:03 Uhr

Mitglied: aqui
Lösung aqui 01.12.2017, aktualisiert am 19.08.2018 um 11:52:11 Uhr
Goto Top
Case closed ! Konfig rennt.
Knackpunkt ist der derzeitige Dualismus das es die Option mit 0.8er Subinterface gibt und die modernere ohne. Stichwort: Telekom BNG Anschluss, All-IP
Im Zweifel muss man am betroffenen Anschluss beide testen. An dem o.a. Anschluss rennt es mit einer modernen ZBF Firewall Konfig sowohl in SD als auch HD ruckelfrei unter VLC und Kodi ohne 0.8er Subinterface (BNG, ohne VLAN 8 Tagging) mit folgender Konfig:
ip multicast-routing
!
interface Vlan1
 description Lokales LAN
 ip address 192.168.1.254 255.255.255.0
 no ip redirects
 ip pim sparse-mode
 ip nat inside
 ip virtual-reassembly in
 zone-member security Localnet
 ip tcp adjust-mss 1452
 ip igmp helper-address 62.155.243.102
 ip igmp version 3
 ip igmp explicit-tracking
 ip igmp proxy-service
!
interface Dialer0
 description Dialin Telekom xDSL
 ip address negotiated
 no ip redirects
 no ip proxy-arp
 ip mtu 1492
 ip pim sparse-mode
 ip nat outside
 ip virtual-reassembly in
 zone-member security Internet
 encapsulation ppp
 ip igmp version 3
 ip igmp proxy-service
 dialer pool 1
 dialer-group 1
 no keepalive
 ppp authentication pap callin
 ...
!
ip pim rp-address 62.155.243.102
ip pim ssm default 
Interessantes Detail am Rande...
Nach dem Öffnen des IP-TV RTP Streams im VLC Player z.B. rtp://@239.35.10.5:10000 für das ZDF in SD Auflösung via WLAN war das Bild mit extrem starken Artefakten und erheblichen Rucklern behaftet. Via Kabel aber fehlerlos.
Grund war ein uralt AP der weder WMM noch die Multicast zu Unicast Konvertierung im WLAN supportete.
Mit aktueller AP Hardware war dann auch das Streaming via WLAN fehlerfrei in SD und HD.
Mitglied: the-buccaneer
the-buccaneer 01.12.2017 um 23:09:50 Uhr
Goto Top
Danke. Ist es nicht manchmal einsam da oben? face-wink

Mit Speedport wär das nicht passiert... ;-P

Der Hinweis mit dem AP ist Gold wert!

LG
Buc
Mitglied: aqui
aqui 04.12.2017 aktualisiert um 12:40:48 Uhr
Goto Top
Mit Speedport wär das nicht passiert...
Stimmt, wäre aber langweilig und außerdem geht das mit erheblichem Feature Verlust und Netzwerk Optionen einher....
Mal ganz abgesehen davon das Provider HW immer unterste Schublade ist.
Und was am allerschlimmsten ist da hängt man mit TR069 Schnüffelprotokoll offen an der Telekom. Siehe hier
Da traue ich der Cisco ZFW Firewall doch erheblich mehr face-wink
Mitglied: the-buccaneer
the-buccaneer 07.12.2017 um 00:04:26 Uhr
Goto Top
Bei den Kaufgeräten konnte man das doch abschalten???. face-wink

Duck und wech...
Mitglied: Manini
Lösung Manini 28.03.2018 aktualisiert um 17:01:29 Uhr
Goto Top
Ich wurde gestern auch von Vlan8 auf BNG umgestellt und verzweifle an der Konfig wie kommst du auf die neue RP Adresse ?
Sonst konnte man ja über die DHCP oder per ACL auf Vlan 8 schauen.
Grüße
Edit: 5 min später fallt einem dann immer die Lösung ein...
falls noch jemand seinen RP sucht mittels sh ppp all bekommt man die entsprechende IP des Routers auf der anderen Seite

Router#sh ppp all
Interface/ID OPEN+ Nego* Fail-     Stage    Peer Address    Peer Name
------------ --------------------- -------- --------------- --------------------
Vi3          LCP+ IPCP+ IPV6CP+    LocalT   62.155.243.116  JUNOS
Mitglied: aqui
aqui 28.03.2018 um 20:19:26 Uhr
Goto Top
Das ist aber NICHT der Multicast Rendzvous Point bzw. muss es nicht sein ! Ist er vermutlich auch nicht.
Der Rendezvous Point liegt sehr wahscheinlich niemals auf einem PPPoE Dialin System.
Das was da angezeigt wird ist die PPP Tunnel IP nicht die des Multicast RPs.
Die lautet anderes:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Mitglied: Manini
Manini 28.03.2018 um 20:55:33 Uhr
Goto Top
OK ich bin davon ausgegangen das die Tunnel Endpunkt IP = RP IP ist bei BNG.
Da bei BNG Vlan 8 tot ist gibt es noch eine andere Möglichkeit an die RP IP zu kommen ?
Mitglied: aqui
aqui 29.03.2018, aktualisiert am 18.01.2020 um 19:10:33 Uhr
Goto Top
Ja !
Dieses_PDF beschreibt wie es geht:
Ist auch im Cisco_Tutorial hier verlinkt.
Mitglied: Manini
Manini 29.03.2018 um 10:58:04 Uhr
Goto Top
Hi ja das ist bekannt. Über die ACL auf dem Dialer bekomme ich auch nur die Tunnelentpunkt IP deshalb war meine Annahme das das der RP ist.
Und die ist über sh ppp all schneller zu bekommen.

Mar 28 10:21:54: %SEC-6-IPACCESSLOGSP: list IGMP denied igmp 62.155.243.116 -> 224.0.0.1 (0), 5 packets
Mar 28 10:27:53: %SEC-6-IPACCESSLOGSP: list IGMP denied igmp 62.155.243.116 -> 224.0.0.1 (0), 6 packets
Mar 28 10:32:53: %SEC-6-IPACCESSLOGSP: list IGMP denied igmp 62.155.243.116 -> 224.0.0.1 (0), 5 packets
Mar 28 10:37:53: %SEC-6-IPACCESSLOGSP: list IGMP denied igmp 62.155.243.116 -> 224.0.0.1 (0), 5 packets
Mitglied: aqui
aqui 29.03.2018 aktualisiert um 13:25:04 Uhr
Goto Top
Wichtig ist die IGMP Kommunikation dafür. Siehe die Multicast Adressen. Dadrin versteckt sich auch der RP. Der Autor des PDF filtert ja danach und dann sieht er es natürlich. Der ACL Filter ist hier nur Mittel zum Zweck.
Die PIM relevanten show Kommandos zeigen das ja auch.
Dein Output oben ist richtig ! Die 62.155.243.116 sollte dann die RP Adresse sein.
Stimmt die mit dem PPP show output überein ?

Hab den RP gerade eben hier auch mal auf die PPP Tunnel IP umkonfiguriert und es klappt tatsächlich.
Interessant auch das die RP Adresse im Kommando sh ip mroute auch schon so angezeigt wird.
Erstmal so lassen. Ein lokaler RP ist allemal besser aus Sicht der Performance.
Wenn das stabil klappt wäre das eine sehr gute Option schnell die lokale RP Adresse rauszubekommen ohne die Frickelei mit dem Filter.
Nur damit das angezeigt wird muss man mindestens einmal das PIM Routing aktiviert haben.
Danke auf alle Fälle für das hilfreiche Feedback. face-smile
Mitglied: Manini
Lösung Manini 29.03.2018 aktualisiert um 13:50:11 Uhr
Goto Top
Jepp genau die IPs stimmen überein.
Die IGMP konfig passt auch mein Problem der RP scheint nicht zu stimmen face-sad

Die Multicast Gruppen stimmen, Vlan 101 beherberg Testlaptop und Mediareciever keine Firewall.
Router#sh ip igmp groups
IGMP Connected Group Membership
Group Address    Interface                Uptime    Expires   Last Reporter   Group Accounted
239.255.255.250  Vlan101                  03:19:13  00:02:20  10.101.10.1
239.35.100.5     Vlan101                  03:19:13  00:02:20  10.101.10.1
239.35.10.2      Vlan101                  03:18:48  00:02:46  10.101.10.1

Router#sh ip pim rp
Group: 239.255.255.250, RP: 62.155.243.116, uptime 00:02:58, expires never
Group: 239.35.100.5, RP: 62.155.243.116, uptime 00:02:58, expires never
Group: 239.35.10.2, RP: 62.155.243.116, uptime 00:02:58, expires never
Group: 224.0.1.40, RP: 62.155.243.116, uptime 00:02:58, expires never

Router#sh ip multicast interface dialer 1
Dialer1 is up, line protocol is up
  Internet address is x.x.x.x/32
  Multicast routing: enabled
  Multicast switching: fast
  Multicast packets in/out: 0/0
  Multicast TTL threshold: 0
  Multicast Tagswitching: disabled


Ich bekomme übers Dialer Interface partou nichts rein.
Daher meine ursprüngliche Frage ob du eine andere Möglichkeit der RP Bestimmung hast aber wenn das nicht der Fall ist liegt das Problem evtl. doch bei der Telekom vor der Unstellung auf BNG lief es ja.


Edit: zu deinem Edit dann hab ich jetzt echt 0 Plan warum es bei mir nicht klap lol
Mitglied: aqui
aqui 29.03.2018 aktualisiert um 14:14:08 Uhr
Goto Top
Ooops...ich war jetzt der Meinung das es bei dir genau auch damit klappt ? Oder war das jetzt im Spaß gemeint ??

Zum schnellen Testen kannst du VLC nehmen und das mit den entsprechenden Multicast Gruppen im VLAN 101 austesten:
https://iptv.blog/artikel/multicastadressliste/
Das sollte bei dir sofort funktionieren ?!
!
interface Vlan101
description Lokales LAN
ip pim sparse-mode
ip igmp helper-address 62.155.243.116
ip igmp version 3
ip igmp explicit-tracking
ip igmp proxy-service
!
interface Dialer0
description Dialin T-Online DSL
mtu 1492
ip pim sparse-mode
ip igmp version 3
ip igmp proxy-service
!
ip pim rp-address 62.155.243.116
ip pim ssm default
!

Das sollte zum Erfolg führen bei dir.
Die alternative Rendezvous Point IP 62.155.243.102 funktioniert immer, egal von wo.
Mitglied: Manini
Manini 31.03.2018 um 15:01:10 Uhr
Goto Top
Ne läuft leider nicht.
Auch mit der 62.155.243.102 als RP und Helper kein Mutlicast, Unicast geht ohne Probleme auf dem Media Reciever (ersten 5? Sekunden Bild/Ton) daher sollten sie zumindest das richtige Profil auf dem BNG eingetragen haben und Entertain sollte frei geschaltet sein.
Kannst du mir sagen welches IOS du laufen hast ? Das ist das Einzige was ich noch ändern kann.
Mitglied: aqui
aqui 31.03.2018 aktualisiert um 17:05:54 Uhr
Goto Top
Auch mit der 62.155.243.102 als RP und Helper kein Mutlicast
Hast du es mal mit VLC statt dem Receiver versucht ??
Der Telekom Receiver ist eine gruselige Diva, der braucht erstmal eine TFTP Session um ein Image und die Konfig zu laden (sieht man mit Wireshark). Ohne das er das Image und die Konfig booten kann kommt der nicht hoch und funktioniert nicht.
Ohne das du TFTP in der Firewall erstmal freigibst wird das also nix mit dem. NTP will er auch noch.
Deshalb... teste das erstmal IMMER VORHER mit VLC ob es generell funktioniert !!
VLC sollte immer klappen und ist ein wasserdichtes Indiz das deine MC Konfig sauber rennt.
Zudem kannst du auf dem VLC Rechner den Kabelhai mitlaufen lassen und genau sehen woran es scheitert !
Mitglied: Manini
Manini 31.03.2018 um 22:16:30 Uhr
Goto Top
Ja ich hab es auch mit VLC getestet selbe Ergebniss bekomme kein Stream aufgebaut.

Interface Konfiguration Lan & WAN:

interface Vlan101
 ip address 10.101.10.222 255.255.255.0
 no ip redirects
 ip pim sparse-mode
 ip nat inside
 ip virtual-reassembly in
 ip tcp adjust-mss 1452
 ip igmp helper-address 62.155.243.116
 ip igmp version 3
 ip igmp explicit-tracking
 ip igmp proxy-service
end

interface Dialer1
 mtu 1492
 ip address negotiated
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip pim sparse-mode
 ip nat outside
 ip virtual-reassembly in
 encapsulation ppp
 ip tcp adjust-mss 1448
 ip igmp version 3
 ip igmp proxy-service
 dialer pool 1
 dialer idle-timeout 0
 dialer hold-queue 100
 dialer-group 1
 ipv6 address autoconfig
 ipv6 enable
 no ipv6 nd ra suppress
 ipv6 dhcp client pd DTAG-Prefix rapid-commit
 ppp authentication chap callin
 ppp chap hostname xxx@t-online.de
 ppp chap password 7 xxx
 ppp ipcp dns request
 ppp ipcp mask request
 ppp ipcp route default
 ppp timeout retry 50
 no cdp enable
 service-policy output out-telekom
end

In Wireshark sehe ich die IGMP Joins sowie auf dem Router Lan Interface.

debug ip pim
debug ip igmp

Router#
Mar 31 22:09:46: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.255.255.250
Mar 31 22:09:46: PIM(0): Insert (*,239.255.255.250) join in nbr 62.155.243.116's queue  
Mar 31 22:09:46: PIM(0): Building Join/Prune packet for nbr 62.155.243.116
Mar 31 22:09:46: PIM(0):  Adding v2 (62.155.243.116/32, 239.255.255.250), WC-bit, RPT-bit, S-bit Join
Mar 31 22:09:46: PIM(0): Send v2 join/prune to 62.155.243.116 (Dialer1)
Mar 31 22:09:48: IGMP(0): Received v3 Report for 1 group on Vlan101 from 10.101.10.2
Mar 31 22:09:48: IGMP(0): Received Group record for group 232.0.20.35, mode 5 from 10.101.10.2 for 1 sources
Mar 31 22:09:48: IGMP(0): WAVL Insert group: 232.0.20.35 interface: Vlan101Successful
Mar 31 22:09:48: IGMP(0): Create source 87.141.215.251
Mar 31 22:09:48: IGMP(0): Updating expiration time on (87.141.215.251,232.0.20.35) to 180 secs
Mar 31 22:09:48: IGMP(0): Setting source flags 4 on (87.141.215.251,232.0.20.35)
Mar 31 22:09:48: IGMP_ET(0): Adding Host 10.101.10.2 for 232.0.20.35 on Vlan101
Mar 31 22:09:48: IGMP_ET(0): host 10.101.10.2 report for 232.0.20.35 (1 srcs) on Vlan101
Mar 31 22:09:48: IGMP_ET(0): Host 10.101.10.2 add src 87.141.215.251 for 232.0.20.35 on Vlan101
Mar 31 22:09:48: IGMP(0): MRT Add/Update Vlan101 for (87.141.215.251,232.0.20.35) by 1
Mar 31 22:09:48: PIM(0): Insert (87.141.215.251,232.0.20.35) join in nbr 62.155.243.116's queue  
Mar 31 22:09:48: IGMP(0): Helper v3 Report out Dialer1
Mar 31 22:09:48: PIM(0): Building Join/Prune packet for nbr 62.155.243.116
Mar 31 22:09:48: PIM(0):  Adding v2 (87.141.215.251/32, 232.0.20.35), S-bit Join
Mar 31 22:09:48: PIM(0): Send v2 join/prune to 62.155.243.116 (Dialer1)
Mar 31 22:09:48: IGMP(0): Received v3 Report for 1 group on Vlan101 from 10.101.10.2
Mar 31 22:09:48: IGMP(0): Received Group record for group 232.0.20.35, mode 5 from 10.101.10.2 for 1 sources
Mar 31 22:09:48: IGMP(0): Updating expiration time on (87.141.215.251,232.0.20.35) to 180 secs
Mar 31 22:09:48: IGMP_ET(0): host 10.101.10.2 report for 232.0.20.35 (1 srcs) on Vlan101
Mar 31 22:09:48: IGMP(0): MRT Add/Update Vlan101 for (87.141.215.251,232.0.20.35) by 1
Mar 31 22:09:48: IGMP(0): Helper v3 Report out Dialer1
Mar 31 22:10:09: IGMP(0): Send v3 general Query on Vlan101
Mar 31 22:10:09: IGMP(0): Set report delay to 4.0 seconds to respond to General Query on Vlan101
Mar 31 22:10:09: IGMP(0): Received v3 Report for 1 group on Vlan101 from 10.101.10.2
Mar 31 22:10:09: IGMP(0): Received Group record for group 232.0.20.35, mode 1 from 10.101.10.2 for 1 sources
Mar 31 22:10:09: IGMP(0): Updating expiration time on (87.141.215.251,232.0.20.35) to 180 secs
Mar 31 22:10:09: IGMP_ET(0): host 10.101.10.2 report for 232.0.20.35 (1 srcs) on Vlan101
Mar 31 22:10:09: IGMP(0): MRT Add/Update Vlan101 for (87.141.215.251,232.0.20.35) by 1
Mar 31 22:10:09: IGMP(0): Helper v3 Report out Dialer1
Mar 31 22:10:09: IGMP(0): Received v3 Query on Dialer1 from 62.155.243.116
Mar 31 22:10:13: IGMP(0): Building v3 Report on Vlan101

Router#sh ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.255.255.250), 00:00:28/00:02:31, RP 62.155.243.116, flags: SJC
  Incoming interface: Dialer1, RPF nbr 62.155.243.116
  Outgoing interface list:
    Vlan101, Forward/Sparse, 00:00:28/00:02:31

(87.141.215.251, 232.0.20.35), 00:00:19/00:02:40, flags: sTI
  Incoming interface: Dialer1, RPF nbr 62.155.243.116
  Outgoing interface list:
    Vlan101, Forward/Sparse, 00:00:19/00:02:40

(*, 224.0.1.40), 00:00:29/00:02:33, RP 62.155.243.116, flags: SJCL
  Incoming interface: Dialer1, RPF nbr 62.155.243.116
  Outgoing interface list:
    Vlan101, Forward/Sparse, 00:00:29/00:02:33

Habe trotzdem 0 multicast pakete auf dem Dialer Interface
Mitglied: aqui
aqui 31.03.2018 aktualisiert um 22:56:23 Uhr
Goto Top
Mmmmhhh, sieht soweit alles richtig aus ! Auch die show Kommandos zeigen das alles sauber rennt. Unverständlich...??
Nur mal nachgefragt:
!
ip pim rp-address 62.155.243.116
ip pim ssm default
!

Hast du als Global Kommandos konfiguriert, oder ?? Nur weil das oben fehlte.
Du hast noch einen Fehler auf dem Dialer. Dort konfiguriert man niemals die Max TCP Segment Size. Das gehört ausschliesslich nur auf das LAN Interface. Zudem ist der Wert falsch. ip tcp adjust-mss 1452 gehört also nur aufs LAN Interface vlan 101. Vom Dialer muss das entfernt werden, dort steht nur die MTU.
Ich denke nicht das das ursächlicher Fehler ist aber dennoch solltest du das korrigieren.
OT> Bei IPv6 im Dialer ist auch ipv6 address autoconfig default besser damit die v6 Default Route auf dies Interface gemapped wird. </OT>

Was mir noch auffiel ist die Tatsache das die Telekom zwar IGMP v3 erfordert, konfiguriert man das allerdings auch in der Version 3 auf dem angeschlossenen Switch hast du den Effekt das nur das Unicast wieder rüberkommt und er beim Umschalten auf Multicast abbricht.
Warum das so ist konnte ich nicht ergründen. Ich hatte das mit einem Catalyst 2960 und einem SG200 getestet.
Im Vergleich dazu funktionierte per Zufall aber ein billiger TP-Link der gar kein v3 supportet mit IGMPv2 fehlerlos.
Nachdem der 2960 und SG200 dann testweise auf IGMPv2 umkonfiguriert wurde funktioniert das Multicasting auch damit fehlerfrei.
Warum v3 konsistent nicht rennt hab ich jetzt noch nicht weiter untersucht. Beide Versionen sind ja kompatibel.
Ggf. ist das bei dir auch der Fall wenn du IGMP sinnvollerweise auf der L2 Switch Infrastruktur aktiviert hast ?!

Beim Test mit VLC
http://iptv.blog/artikel/multicastadressliste/
musst du aufpassen ob du Entertain oder Entertain-TV an deinem Anschluss hast. Die RTP URL Formate sind vollkommen unterschiedlich.
Hier funktioniert z.B. nur Entertain mit dem VLC URL Format rtp://@239.35.10.5:10000
Entertain-TV geht nicht !
Es ist also nicht trivial welche der XSPF Playlisten oder URLs du für Entertain runterlädst und in VLC startest !!
Ggf. ist das noch einen Versuch wert.
Mitglied: Manini
Manini 03.04.2018 um 21:37:51 Uhr
Goto Top
Jepp
ip pim rp und ssm sind konfiguriert.
Ich spiele nochmal n bisschen mit der IGMP Version evtl bringt das ja der Tipp ist nicht schlecht das VLAN 101 hängt auf einem Switch HWIC in dem 2901 evtl. ist das ja wirklich der Fehler.
Ja bei den IP Listen teste ich zur Sicherheit immer beide. Der Medienreciever nimmt Entertain und mit VLC teste ich immer beides.
Mitglied: aqui
aqui 04.04.2018 um 10:07:48 Uhr
Goto Top
einem Switch HWIC in dem 2901
Bahnhof ?? Ist jetzt nicht wirklich verständlich...
Der Medienreceiver macht noch irgendwas anderes als der Rest der Welt, das musste ich auch feststellen. Ich habe hier diverse Kodis im Netz als IP TV Fernseher und VLC. Damit lässt sich HD usw. alles problemlos und flüssig ohne jeglichen Abbruch sehen.
Der Telekom Receiver hat ständig Abbrüche, Artefakte und ist sehr rumpelig.
Sieht man sich den Streaming Aufbau mal im Wireshark an gibt es da erhebliche Unterschiede. VLC und Kodi machen einen klassischen IGMP Join, abbonnieren die Gruppe und gut iss.
Der Receiver kontaktiert diverse Telekom Server vorher, zieht dort irgendwelche Daten und startet nach 3 Minuten mit seinem rumpeligen Streaming. Vermutlich holt er sich da noch irgendwelche EPGs, dümmliche Serien oder sonstwas.
Irgendwie ist der "besonders" vom Verhalten. Deshalb besser immer VLC zum Testen nehmen.
Mitglied: Manini
Manini 04.04.2018 um 11:11:24 Uhr
Goto Top
Zitat von @aqui:

Bahnhof ?? Ist jetzt nicht wirklich verständlich...

Damit ich auf 3 Ports komme in dem Cisco 2901 ist da ein HWIC-4ESG eingebaut das hat aber nur Layer 2 Ports wie die 880er Router.

Ich glaube ich habe das Problem gefunden. Ich habe jetzt mal auf dem VLAN 101 IGMPv2 eingestellt jetzt bekomme ich im debug eine Fehlermeldung die ich vorher nicht hatte.

DNS source lookup failed for (*, 232.0.10.35), IGMP report ignored
Anscheint hat das SSM Probleme hast du Telekom DNS eingetragen ? Wenn ja welche Adressen ?
Mitglied: aqui
aqui 05.04.2018 aktualisiert um 11:51:39 Uhr
Goto Top
Damit ich auf 3 Ports komme
Aaaahhh...Groschen gefallen, sorry face-wink
hast du Telekom DNS eingetragen ? Wenn ja welche Adressen ?
Die Ciscos rennen hier immer alle als Proxy DNS und die DNS IPs kommen stinknormal über die PPPoE Negotiation !
Mit show hosts kannst du sie sehen. Sie sind in D regional unterschiedlich um die Laufzeiten möglichst gering zu halten.
Mitglied: Manini
Manini 05.04.2018 um 12:33:54 Uhr
Goto Top
OK macht keinen unterschied ob über ppp ipcp dns request oder statisch telekom dns eingetragen Fehlermeldung bleibt da wenn ich versucht EntertainTV Adressen mit SSM zu öffnen face-sad Ich glaube ich lasse es einfach sein kündige und kaufe mit sat->ip server für die Schüssel auf dem Dach weniger ärger als mit Entertain
Mitglied: aqui
aqui 05.04.2018 aktualisiert um 12:54:04 Uhr
Goto Top
Das ist schon komisch. Ich habe nie solche Probleme erlebt mit Cisco und Entertain.
Die show Kommandos zeigen ja eigentlich auch das alles soweit OK ist.
Du solltest nochmal mal 2 Tests machen wenn du noch Lust zum Troubleshooten hast:
1.)
An den Router nichts anschliessen als einen einzigen PC. So kann es keinerlei Wechselwirkungen mit IGMP geben die ggf. vom LAN kommen. OK, dummer ungemanagter Switch vom Blödmarkt geht auch face-wink Alles was irgendwie lokal IGMP macht muss deaktiviert sein.
Damit schliesst du IGMP Probleme dann sicher aus, denn dann ist nur der Router selber am IGMP beteiligt.
2.)
Sollte das auch fehlschlagen dann auf dem VLC Rechner einen Wireshark starten und mal den MC Prozess genau ansehen was da passiert. Dort MUSS dann was zu sehen sein.
Mitglied: Manini
Manini 06.04.2018 um 14:14:33 Uhr
Goto Top
So hab aus dem Regal einen neuen originalverpackten 1921er genommen, aufgebaut noch nie gelaufen nur IPs NAT Multicast config.
Läuft nicht face-sad
Ich vermute da ist was bei der Umstellung schiefgelaufen ich werde mal ein Ticket bei der Telekom aufmachen kann ja irgendwie nicht sein....
Wireshark habe ich auch mal dran gehängt IGMP schaut alles gut aus Client sendet Join Router gibt das weiter bekommen von Telekom RP sogar entsprechend Meldung zurück aber kein Multicast Traffic....
Mitglied: aqui
aqui 06.04.2018 aktualisiert um 16:11:26 Uhr
Goto Top
was bei der Umstellung schiefgelaufen ich werde mal ein Ticket bei der Telekom aufmachen kann
Ja, was anderes bleibt de facto nicht mehr übrig !
Die sollen mal einen "Masterreset" an deinem Anschluss für Entertain machen ! face-wink
Mitglied: Cyberurmel
Cyberurmel 21.04.2018 um 11:17:51 Uhr
Goto Top
HiAqui,

klink mich mal wieder ein. Nachdem nun lange alles ziemlich gut gelaufen ist , jetzt wieder Probleme:

Erst kamen wieder Ruckler. Ok.. Hab dann nochmal debuggt und gesehen der Timer machte Probleme. Richtiggestellt.
3 Tage kein Ruckler. Dann hat sich irgendwas aufgehangen und ich musste den cisco neu booten.
Bäm wieder Ruckler. Config war gesichert und keine Timer fehler im debug.
Bin dann über den Thread gestoßen habe auch Kleinigkeiten angepesst wie die tcp adjust raus aus Dialer .
Jetzt hab ich das Phänomen , das gar kein Multicast mehr geht. Argh

Soweit ich sehe passt aber alles ..Habe ja das Entertain TV
10 sek Bild dann Zeitlupe dann gibt er auf.

Der RP muss stimmen ging ja vorher auch .. Trotzdem nochmal geschaut mit ACL ..ist dasselbe.
#show ip pim interface

Address          Interface                Ver/   Nbr    Query  DR     DR
                                          Mode   Count  Intvl  Prior
192.168.5.2      GigabitEthernet0/1       v2/S   0      30     1      192.168.5.2
91.37.152.100    Dialer0                  v2/S   1      30     1      0.0.0.0
0.0.0.0          Virtual-Access2          v2/S   0      30     1      0.0.0.0

Stimmt das mit dem Virtual Access? Ist mir noch nicht aufegfallen gewesen.
show ip multicast interface
GigabitEthernet0/1 is up, line protocol is up
  Internet address is 192.168.5.2/24
  Multicast routing: enabled
  Multicast switching: fast
  Multicast packets in/out: 6847/46851
  Multicast TTL threshold: 0
  Multicast Tagswitching: disabled
Dialer0 is up, line protocol is up
  Internet address is 91.37.152.100/32
  Multicast routing: enabled
  Multicast switching: fast
  Multicast packets in/out: 46851/0
  Multicast TTL threshold: 0
  Multicast Tagswitching: disabled
Virtual-Access2 is up, line protocol is up
  Internet protocol processing: disabled

Da stimmt doch was mit dem Dialer nicht(mehr) oder?

Keine Packets out?

nterface Dialer0
 description VDSL Einwahl Interface
 ip address negotiated
 ip access-group 111 in
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip mtu 1492
 ip inspect myfw out
 ip pim sparse-mode
 ip nat outside
 ip virtual-reassembly in
 encapsulation ppp
 ip igmp version 3
 ip igmp query-interval 15
 ip igmp proxy-service
 dialer pool 1
 dialer-group 1
 no keepalive
 ppp authentication chap callin
 ppp chap hostname xxx
 ppp chap password  xxx
 ppp ipcp dns request
 ppp ipcp mask request
 ppp ipcp route default
 no cdp enable

Extended IP access list 111
    100 permit udp any eq 5060 any (80 matches)
    109 permit udp host 194.25.134.196 eq ntp any
    120 permit igmp host 62.155.246.164 any (112 matches)
    130 permit icmp host 62.155.246.164 any (41 matches)
    140 permit ip any 224.0.0.0 15.255.255.255 (77851 matches)
    150 permit udp any gt 40000 any (3 matches)
    999 deny ip any any log (900 matches)

Access list sieht auch gut aus bis auf den Ntp ..der matcht nicht ..

hast du ne Idee ?? ach ja ..rebooted nochmal heute morgen. Also die Zahlen sind nicht alt face-smile

dankevorab

Greets
Cyb
Mitglied: aqui
aqui 30.04.2018 aktualisiert um 11:03:01 Uhr
Goto Top
Checke mit show ppp all deine lokale RP Adresse und passe die Konfig auf diese an.
Lass die Query Intervall Konfig weg und belasse die im Default. Kein explicit Tracking auf dem Dialer !
Also nur das hier auf den Interfaces und nichts anderes:
!
interface VLAN1
decription Lokales LAN
ip igmp helper-address 62.155.x.y
ip igmp version 3
ip igmp explicit-tracking
ip igmp proxy-service
!
Interface Dialer 0
description Telekom xDSL Interface
ip pim sparse-mode
ip igmp version 3
ip igmp proxy-service
!
ip pim rp-address 62.155.x.y
ip pim ssm default
Mitglied: Cyberurmel
Cyberurmel 31.05.2018 um 09:29:36 Uhr
Goto Top
Hi Aqui,

danke.. erstmal.
Mir fehlt einfach die Zeit face-sad
Das mit der ZBFW muss ich nochmal testen. Entertain läuft soweit ..auch mit VLC (alt und entertain TV adressen)
Ich habe auch gemerkt, das mein Modem Vigor mal ein update der Firmware gebraucht hat. Vielleicht lag es auch daran zum Teil.
So ich test das mit der ZBFW noch und dann gehts weiter face-smile

Danke
greets
Cyb
Mitglied: aqui
aqui 31.05.2018 aktualisiert um 10:12:24 Uhr
Goto Top
Na, dann sind wir mal gespannt !
Viel Erfolg beim Testen. face-smile
(Kann dir aber schon vorab sagen das es klappt. Hier werkeln diverse Cisco's mit ZFW und Entertain)
Mitglied: Manini
Manini 19.12.2018 um 22:00:26 Uhr
Goto Top
Hi Cyberurmel,
jemals zum laufen bekommen ?
Hab mir jetzt einen MR3xx geholt selbes Problem 10 sek Bild dann Zeitlupe dann gibt er auf.
Grüße
Mitglied: aqui
aqui 19.12.2018 um 22:18:59 Uhr
Goto Top
Das zeigt das die Multicast Konfig fehlerhaft ist.
Hast du hinter dem Router noch einen Switch der IGMP kann und ist dort IGMPv2 aktiviert ??

Was passiert wenn du einen PC Mit VLC anschliesst und damit Entertain ansiehst ? Klappt das ??
Die Multicast Adressen dazu findest du wie immer hier:
https://iptv.blog/artikel/multicastadressliste/comment-page-13/#comments
Mitglied: Manini
Manini 19.12.2018 um 22:24:54 Uhr
Goto Top
Hi aqui,
genau das ist das Problem wenn du weiter oben guckst da waren wir schonmal dran im April habe dann aber erstmal aufgegeben da mir die Telekom nicht helfen konnte und meinte es müsste an meinem Cisco liegen ich solle ein Speedport kaufen. Jetzt hab ich umgestellt auf Magenta XXL + TV in der Hoffnung das dies mein Problem löst leider nicht face-sad
Mitglied: aqui
aqui 20.12.2018 aktualisiert um 10:39:31 Uhr
Goto Top
meinte es müsste an meinem Cisco liegen ich solle ein Speedport kaufen.
He he he face-smile
Soviel mal zur Telekom "Fachkompetenz" !
Genau diese Routermodelle werden übrigens massenhaft von selbiger Telekom bei Business Kunden aufgestellt. Auch das D Backbone der Telekom ist zum großen Teil Cisco (mit etwas Juniper)
Die Kollegen vom 1st Level Support sollten wohl besser mal die Business Leute vom Helpdesk fragen...
Ist vermutlich auch sicher nur ein namenloser Call Center die das im Auftrag machen und beim nächsten Call dann Gas- oder Stromkunden abfackeln. Die haben ein eingeschweisstes Merkblatt vor sich und lesen nur Standardantworten vor. Muss man sich also nicht groß wundern...
Egal, muss man sicher hier auch nicht weiter kommentieren.

Deshalb hier nochmals die Frage...
Was ist wenn du testweise mal VLC nutzt ??
Kannst du damit das TV Bild empfangen ?? Oder bleibt das auch stehen ?
Mitglied: Manini
Manini 20.12.2018 aktualisiert um 15:03:28 Uhr
Goto Top
Über VLC mit der Liste von https://iptv.blog/artikel/multicastadressliste/ geht garnichts da bekomme ich nichtmal die ersten paar Sekunden Bild.
Direkt am Router selber Port wie der Entertain Reciever der bekommt Bild.

EDIT:

Kannst du mir einen gefallen tun und mir dein
sh ppp all
sh ip igmp groups
sh ip pim rp

sowie ein debug mit folgenden befehlen wenn du auf ARD HD umschaltest geben ?
debug ip pim
debug ip igmp

Ich vermute bald es muss irgendeine eigenheit bei den FTTH Anschlüssen geben ich finde nämlich nur Personen mit A/VDSL Anschlüssen bei den es funktioniert !
Mitglied: aqui
aqui 22.12.2018 um 17:53:34 Uhr
Goto Top
geht garnichts da bekomme ich nichtmal die ersten paar Sekunden Bild.
Das kann 2 Ursachen haben:
  • 1.) Deine Multicast Konfig ist komplett falsch oder fehlerhaft. Was gibt dir ein show ppp all uns show ip pim neig aus ?
  • 2.) Du nutzt die falschen Multicast Gruppen !

Punkt 2 ist am wahrscheinlichsten wenn du mit den entsprechenden Show Kommandos einen validen Output bekommst.
Die Gruppen unterscheiden sich je nachdem ob du Entertain hast oder Magenta TV !!!
ARD = rtp:@239.35.10.4:10000 (Entertain)
ARD = rtp:
87.141.215.251@232.0.20.35:10000 (Magenta TV)
Hast du das beachtet bei VLC ?
Mitglied: Manini
Manini 22.12.2018 um 18:48:18 Uhr
Goto Top
Interface/ID OPEN+ Nego* Fail-     Stage    Peer Address    Peer Name
------------ --------------------- -------- --------------- --------------------
Vi3          LCP+ IPCP+ IPV6CP+    LocalT   62.155.243.116  JUNOS

Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
62.155.243.116    Dialer1                  2d22h/now         v2    0 /

Jo habs mit den Listen für Entertain als auch MagentaTV (hab ich) probiert.
Mitglied: aqui
aqui 22.12.2018 um 18:56:29 Uhr
Goto Top
Mmmhhh, schon komisch. Multicast seitig sieht das gut aus !
Hast du deine Rendezvous Point IP auch umgestellt auf 62.155.243.116 ?
Kannst du nochmal ein sh ip igmp mem posten ?
Mitglied: Manini
Manini 22.12.2018 um 19:41:49 Uhr
Goto Top
Test mit Laptop VLC ARD HD
 Channel/Group                  Reporter        Uptime   Exp.  Flags  Interface
 *,239.255.255.250              0/3             2d06h    02:06 3AT    Vl101
/*,232.0.20.35                  1/0             00:00:18 stop  3MAT   Vl101
 87.141.215.251,232.0.20.35     1/0             00:00:18 02:42 T      Vl101

sh run | i 62.155.243.116
 ip igmp helper-address 62.155.243.116 (int vlan 101)
 ip igmp helper-address 62.155.243.116 (gi0/0)
 ip pim rp-address 62.155.243.116
Mitglied: aqui
aqui 22.12.2018 um 20:14:35 Uhr
Goto Top
Sieht alles gut und richtig aus.... face-sad
Klingt blöd aber hilft manchmal wenn sich Multicast mal weggehängt hat: Reload des Routers.
Hast du das auch mal gemacht ?
Hilft das auch nicht musst du dann wohl doch mal den Wireshark rauskramen.
Öffne dann mal VLC, Netzwerkstream öffnen und gib die Gruppen mal an oben und sieh dir lokal am Wireshark mal an was da passiert.
Mitglied: Manini
Manini 23.12.2018 um 13:20:16 Uhr
Goto Top
Ja reload habe ich getestet
Router firmware getauscht (15.2 / 15.3 / aktuell 15.7)
Router getauscht 2901 -> 1921 -> 886
Macht alles keinen Unterschied selben Symptome.

Hab mir jetzt mal Wireshark Mitschnitt angeguckt werd ich nicht schlau drauß.
IGMP Traffic ist weitestgehend identisch ohne jetzt einen Vergleich zu haben würde ich sagen das ist alles OK.
Mit VLC bekomme ich Null Traffic von außen es antwortet einfach nichts.
Der Mediareciver bekommt Daten aber nur per Unicast Null Multicast.

Ich fange langsam an zu zweifeln und werde wohl mal eine Fritzbox kaufen die soll laut Hotline funktionieren lol
Mitglied: aqui
aqui 24.12.2018 um 12:35:10 Uhr
Goto Top
werd ich nicht schlau draus....
Warum nicht ?? Wo liegt genau dein Problem ?!
Du siehst doch genau Absender und Empfänger und wie der IGMP Aufbau abläuft...oder nicht.
Das was du schchilderst lässt eher vermuten das dein Multicast Anschluss gestört ist. Da wird eine FB wohl auch nix nützen und ist eher verbranntes Geld face-sad
Mitglied: Manini
Manini 24.12.2018 um 14:37:03 Uhr
Goto Top
Zitat von @aqui:

werd ich nicht schlau draus....
Warum nicht ?? Wo liegt genau dein Problem ?!
Du siehst doch genau Absender und Empfänger und wie der IGMP Aufbau abläuft...oder nicht.

Genau wie gesagt IGMP ist alles gut aber warum dann nichts passiert und ich kein Traffic bekomme da werd ich nicht schlau drauß.
Ich gehe auch davon aus das das Problem am Anschluss liegt aber Telekom macht keine Diagnose weil der Router nicht supportet ist und es daher ein Router Problem ist.
Mitglied: aqui
aqui 24.12.2018 um 15:08:03 Uhr
Goto Top
Der Router ist schon supportet !! Der ist offiziell im Business Portfolio der Telekom ! Die kennen wohl ihre eigenen Produkte nicht face-sad
Kannst du dir sonst leihweise mal einen Speedport oder FB besorgen ?
Mitglied: Manini
Manini 26.12.2018 um 15:00:23 Uhr
Goto Top
Ne leider nicht deshalb spiele ich mit dem Gedanken eine FB zu kaufen die auch offiziell supportet wird sonst drehe ich mich hier noch ein Jahr im Kreis.

Ja das die von der Geschäftskunden Seite unterstützt werden ist mir klar aber das haben die doch in den Entertain Team kein Plan von face-sad
Mitglied: aqui
aqui 26.12.2018 um 16:29:31 Uhr
Goto Top
Oder nimm erstmal ne gebrauchte FB von eBay. Dann musst du nicht so viel Geld in so einen Plasterouter versenken face-wink
Mitglied: Manini
Manini 01.01.2019 um 16:18:52 Uhr
Goto Top
Frohes neues
gleich was zum Lachen Fritzbox 4020 von ebay geht auch nicht :D sollte aber laut Telekom da hier die neuste firmware 7.01 drauf geht.
Laptop dran VLC kein Bild ¯\_(ツ)_/¯
Mitglied: aqui
aqui 02.01.2019 aktualisiert um 17:33:59 Uhr
Goto Top
face-smile Aber das war vorauszusehen !!
Bleibt dabei: Multicasting (sprich IP-TV) ist an deinem Anschluss gestört !
Mitglied: Manini
Manini 13.01.2019 um 15:53:04 Uhr
Goto Top
Lag wohl an der Fritzbox mit ner anderen geht es ohne Probleme. Multicast alles....
Zurück zum Cisco nix geht.

Letzter versuch neuer 1921 mit minimaler Konfiguration auch kein Erfolg

Current configuration : 2175 bytes
!
! Last configuration change at 14:20:21 UTC Sun Jan 13 2019
!
version 15.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
!
!
!
!
!
!
!
!
!
!
ip dhcp pool TESTENTERTAIN
 network 10.101.10.0 255.255.255.0
 default-router 10.101.10.222
 dns-server 217.237.151.142 217.237.149.142 217.237.150.205
!
!
!
ip multicast-routing
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
cts logging verbose
!
!
!
!
!
redundancy
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Embedded-Service-Engine0/0
 no ip address
 shutdown
!
interface GigabitEthernet0/0
 ip address 10.101.10.222 255.255.255.0
 ip pim sparse-mode
 ip nat inside
 ip virtual-reassembly in
 ip igmp helper-address 62.155.243.116
 ip igmp version 3
 ip igmp explicit-tracking
 duplex auto
 speed auto
!
interface GigabitEthernet0/1
 no ip address
 no ip route-cache cef
 duplex auto
 speed auto
 no cdp enable
!
interface GigabitEthernet0/1.7
 encapsulation dot1Q 7
 pppoe enable group global
 pppoe-client dial-pool-number 1
!
interface Dialer1
 mtu 1492
 ip address negotiated
 ip pim sparse-mode
 ip nat outside
 ip virtual-reassembly in
 encapsulation ppp
 ip igmp version 3
 dialer pool 1
 dialer idle-timeout 0
 dialer hold-queue 100
 dialer-group 1
 ppp authentication chap pap callin
 ppp chap hostname xxxxxxxxxxxxxxxxxxxxxxxxxxxxx0001@t-online.de
 ppp chap password 7 xxxxxxxxxxxxxxxxxxxxx
 ppp timeout retry 50
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
ip pim rp-address 62.155.243.116
ip pim ssm default
ip nat inside source list NAT-RANGE interface Dialer1 overload
ip route 0.0.0.0 0.0.0.0 Dialer1
!
ip access-list extended NAT-RANGE
 permit ip any any
!
!
!
!
control-plane
!
!
!
line con 0
line aux 0
line 2
 no activation-character
 no exec
 transport preferred none
 transport output pad telnet rlogin lapb-ta mop udptn v120 ssh
 stopbits 1
line vty 0 4
 login
 transport input none
!
scheduler allocate 20000 1000
!
end

Router#

Übersehe ich noch irgedwas ?
Mitglied: aqui
aqui 13.01.2019 aktualisiert um 16:36:44 Uhr
Goto Top
Dein Dialer Interface hat einen gravierenden Konfig Fehler !!!
!
interface Dialer0
description Dialin T-Online DSL
mtu 1492
ip address negotiated
no ip redirects
no ip proxy-arp
ip pim sparse-mode
ip nat outside
ip virtual-reassembly in
encapsulation ppp
ip igmp version 3
ip igmp proxy-service
<<---
dialer pool 1
dialer-group 1
no cdp enable
ipv6 address autoconfig default
ipv6 enable
ipv6 nd autoconfig default-route
no ipv6 redirects
no ipv6 unreachables
ipv6 verify unicast reverse-path
ipv6 dhcp client pd provider-v6-prefix rapid-commit
no keepalive
ppp authentication pap callin
ppp pap sent-username xyz password Geheim
ppp ipcp dns request
ppp ipcp mask request
ppp ipcp route default
!

Auch dein lokales LAN Interface hat den gleichen Fehler !!!
!
interface xyz
description Lokales LAN
ip address 192.168.1.254 255.255.255.0
no ip redirects
ip pim sparse-mode
ip nat inside
ip virtual-reassembly in
ip tcp adjust-mss 1452
ip igmp helper-address 62.155.x.y
ip igmp version 3
ip igmp explicit-tracking
ip igmp proxy-service
<<---
!


Deine NAT ACL solltest du auch mal etwas einschränken statt so einen Schrotschuß !!

ip access-list extended NAT-RANGE
permit ip 10.101.10.0 0.0.0.255 any

...wäre da schon etwas sinnvoller !
Mitglied: Manini
Manini 13.01.2019 um 17:02:39 Uhr
Goto Top
ip igmp proxy-service hinzugefügt (dachte das kann bei meganta tv entfallen)
macht aber keinen unterschied läuft nicht.
Mitglied: aqui
aqui 13.01.2019 um 17:08:10 Uhr
Goto Top
Reboot gemacht ?? Das ist wichtig.
Dann kann nur noch der RP falsch sein !
Probiere mal einen anderen wie 62.155.241.4

Hilft das auch nicht, dann musst du den Wireshark bemühen.
Normal ist das wenigstens nicht.
Hast du mit einem VLC Client und beiden RTP Stream Adressen probiert ??
Mitglied: Manini
Manini 17.01.2019 um 18:38:14 Uhr
Goto Top
So ich hab mir jetzt mal den traffic mit einer trap abgegriffen und glaube das Problem gefunden zu haben.

Wenn ich den wireshark output von cisco und fritzbox vergleiche sehe ich bei der fritzbox die membership reports bei cisco sehe ich 0 ausgehenden IGMP traffic.

Das ist wiederum sehr misteriös da debug ip igmp mir sagt er sendet Pakete

Jan 17 18:31:26: IGMP(0): Received v3 Report for 2 groups on Vlan101 from 10.101.10.3
Jan 17 18:31:26: IGMP(0): Received Group record for group 232.0.20.35, mode 5 from 10.101.10.3 for 1 sources
Jan 17 18:31:26: IGMP(0): Updating expiration time on (87.141.215.251,232.0.20.35) to 180 secs
Jan 17 18:31:26: IGMP_ET(0): host 10.101.10.3 report for 232.0.20.35 (1 srcs) on Vlan101
Jan 17 18:31:26: IGMP(0): MRT Add/Update Vlan101 for (87.141.215.251,232.0.20.35) by 1
Jan 17 18:31:26: IGMP(0): Received Group record for group 232.0.20.35, mode 3 from 10.101.10.3 for 1 sources
Jan 17 18:31:26: IGMP(0): Updating expiration time on (87.141.215.251,232.0.20.35) to 180 secs
Jan 17 18:31:26: IGMP_ET(0): host 10.101.10.3 report for 232.0.20.35 (1 srcs) on Vlan101
Jan 17 18:31:26: IGMP(0): MRT Add/Update Vlan101 for (87.141.215.251,232.0.20.35) by 1
-->>>Jan 17 18:31:26: IGMP(0): Helper v3 Report out Dialer1<<<---
Jan 17 18:31:26: IGMP(0): Received v3 Report for 2 groups on Vlan101 from 10.101.10.3
Jan 17 18:31:26: IGMP(0): Received Group record for group 232.0.20.35, mode 5 from 10.101.10.3 for 1 sources
Jan 17 18:31:26: IGMP(0): Updating expiration time on (87.141.215.251,232.0.20.35) to 180 secs
Jan 17 18:31:26: IGMP_ET(0): host 10.101.10.3 report for 232.0.20.35 (1 srcs)
Jan 17 18:31:26: IGMP(0): MRT Add/Update Vlan101 for (87.141.215.251,232.0.20.35) by 1
Jan 17 18:31:26: IGMP(0): Received Group record for group 232.0.20.35, mode 3 from 10.101.10.3 for 1 sources
Jan 17 18:31:26: IGMP(0): Updating expiration time on (87.141.215.251,232.0.20.35) to 180 secs
Jan 17 18:31:26: IGMP_ET(0): host 10.101.10.3 report for 232.0.20.35 (1 srcs) on Vlan101
Jan 17 18:31:26: IGMP(0): MRT Add/Update Vlan101 for (87.141.215.251,232.0.20.35) by 1
Jan 17 18:31:26: IGMP(0): Helper v3 Report out Dial

Kannst du mir deine IOS version mitteilen und den router den du benutzt auf dem es funktioniert ? Ich will ein IOS bug ausschließen.
Mitglied: aqui
aqui 18.01.2019 um 14:35:04 Uhr
Goto Top
Aber immer doch...
Cisco IOS Software, C880 Software (C880DATA-UNIVERSALK9-M), Version 15.6(3)M5, RELEASE SOFTWARE (fc1)
Cisco886va#sh flash:
-#- --length-- -----date/time------ path
1     48369856 Aug 25 2018 12:13:40 +02:00 c880data-universalk9-mz.156-3.M5.bin
2      2310912 Sep 2 2017 10:09:20 +02:00 VA_B_38V_d24m.bin 
Der 2te File ist das Modem Image.
es ist ein 886va
Mitglied: Manini
Manini 18.01.2019 um 14:45:36 Uhr
Goto Top
Danke face-smile
886VA hab ich sogar da mal gucken ob das läuft aber dein IOS ist ja auch relativ neu..

Wenn das auch nix hilft gehen mir die Ideen aus.
Mitglied: Manini
Lösung Manini 22.01.2019 um 20:03:55 Uhr
Goto Top
Holy s*it ich habe endlich alle Fehler gefunden hauptsächlich dank der Beispiel Konfiguration von aqui !!

Fehler 1:

sh ip pim neighbor zeigt als Adresse nur 0.0.0.0

Router#sh ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
      L - DR Load-balancing Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
0.0.0.0    Dialer1                  02:11:05/now      v2    0 /
Router#

Grund dafür ist eine statisch gesetzte default route wie z.B.

ip route 0.0.0.0 0.0.0.0 Dialer 1

Die default route sollte über den Dialer gelernt werden mittels:

interface Dialer 1
 ppp ipcp route default

Router#sh ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
      P - Proxy Capable, S - State Refresh Capable, G - GenID Capable,
      L - DR Load-balancing Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
62.155.243.116    Dialer1                  02:28:38/now      v2    0 /
Router#


Fehler 2:

Keine permit any ACL für NAT overloading verwenden

ip nat inside source list NAT interface Dialer1 overload

Funktioniert:

Extended IP access list NAT
    10 permit ip 192.168.0.0 0.0.255.255 any (2333 matches)
    20 permit ip 10.0.0.0 0.255.255.255 any (2191 matches)



Funktioniert nicht:

Extended IP access list NAT
    10 permit ip any any
 


Fehler 3:

debug ip igmp gibt folgende Fehlermeldung aus

Jan 21 19:05:29: IGMP(0): DNS source lookup failed for (*, 232.0.20.35), IGMP report ignored

anstatt der korrekten Zuordnung

Jan 22 19:58:04: IGMP(0): MRT Add/Update Vlan200 for (87.141.215.251,232.0.20.35) by 2
Jan 22 19:58:04: IGMP(0): Updating CSR expiration time on (87.141.215.251,232.0.20.35) to 180 secs

SSM funktioniert nicht kein Bild

Abhilfe kann man schaffen in dem man das mapping statisch macht

ip access-list standard 20
permit 232.0.0.0 0.255.255.255

ip igmp ssm-map static 20 87.141.215.251

dann funktionert alles wieder.
Warum der Fehler auftritt konnte ich bis jetzt nicht feststellen es funktioniert auch zum Teil ohne Probleme aber manchmal klappt es nicht.
Mit dem statischen Mapping funktioniert es immer solange sich die 87.141.215.251 nicht ändert scheint aber bei allen gleich zu sein.
Mitglied: aqui
aqui 22.01.2019 aktualisiert um 20:21:54 Uhr
Goto Top
Klasse !
Sehr gute Troubleshooting Arbeit ! Glückwunsch das nun alles rennt wie es soll. face-smile
Wie immer die kleinen, gemeinen Flüchtigkeitsfehler... face-wink
Wie gesagt hier rennt es fehlerlos auch ohne statisches SSM Mapping.