Unitymedia Entertain TV am Unitymedia Anschluß

[Andreas1969]

Wie der Titel es schon sagt, hat das eventuell schon jemand am Laufen :kratz:

Folgende Ausgangssituation:

Standort A Telekom Vectoring 100/40 Anschluß (wird nächste Woche geschaltet) mit Entertain TV Plus Paket. Router ist eine Fritzbox 7590.
Standort B Unitymedia Anschluß 100/5 DSLITE mit Fritzbox 6360 (Bridge Mode freigeschaltet). Ein Router an der Bridge bekommt ne IPV6 und ein 59er Subnet.
PS: Am Tarif Standort B kann ich nichts ändern / optimieren, da dort noch mehrere kostenlose Mobilfunkkarten drüber laufen, die bei einer Änderung wegfallen würden. Daher ist momentan auch nicht geplant, den Anschluß auf Telekom umzustellen, obwohl Vectoring verfügbar ist.

An Standort A soll dann ein MR 401 und zwei MR 201 laufen, was ja auch ohne Probleme so funktioniert.
An Standort B soll dann noch ein weiterer MR201 laufen, der an den Anschluß Standort A per VPN angebunden wird.

Problem ist aber, dass über eine normale VPN Verbindung das VLAN für´s Entertain Paket wohl nicht so ohne weiteres übertragen wird.
Da der Anschluß Standort B nur über DSLITE verfügt (aus oben genannten Gründen kann ich den auch nicht auf DS, bzw. einen aktuellen Tarif umstellen), muß das VPN für das Entertain-VLAN zwingend über V6 laufen.
Durch das V6-VPN muss dann das V4-VLAN für´s Entertain getunnelt werden.

Hat jemand ne Idee, wie man das am Besten bewerkstelligt :kratz:
Idealerweise würde ich gerne am BridgePort der 6360 einen separaten Router anschließen, der nur den Entertain Receiver versorgt, sodaß das restliche Netzwerk am Standort B unangetastet bleibt.

Würde mich über funktionierende Vorschläge freuen.
@Robert, meine Hoffnung setze ich jetzt speziell mal in Dich, ich denke mal, Du hast Dich mit so etwas schon mal auseinandergesetzt

 

[Wechseler]

Das hat nichts mit VLANs zu tun, du möchtest Multicast über VPN. Selbst bei einer Layer2-Bridge wird das nicht ganz einfach.

 

[Andreas1969]

Das hat nichts mit VLANs zu tun, du möchtest Multicast über VPN. Selbst bei einer Layer2-Bridge wird das nicht ganz einfach.

Ja, vermutlich hast Du Recht, Multicast dann wohl.
Hab mich damit noch nicht weiter auseinander gesetzt.
Daher auch die Frage, ob's schon jemand erfolgreich am Laufen hat. Man muss ja das Rad nicht jedesmal neu erfinden :zwinker:
Zum Glück hab ich ja noch den UM 400/40 Anschluss an Standort A parallel laufen. Da kann ich ja relativ einfach testen und muss nicht jedesmal zu Standort B fahren, um zu schauen, ob der Receiver läuft :super:

 

[boba]

Für ipv4 würde mir dazu folgendes einfallen:

- beide LANs via lan2lan vpn Kopplung verbinden. Fritzboxen können das. Der Router auf Standort A hat eine öffentlich erreichbare ipv4 Adresse, d.h. das kann der Brückenkopf sein, auf den sich der Router aus Standort B verbindet. Andersrum geht die Verbindung wegen dslite nicht.
- Ein LAN erhält (z.B.) 192.168.1.* und eines 192.168.2.*.
- statische Routen auf beiden vpn Routern so einrichten, dass man von jeder Maschine aus LAN A jede Maschine aus LAN B mit ihrer jeweiligen LAN Adresse anpingen kann.
- Im vpn Router von Standort B statische Routen für die IP-Bereiche der Entertain-Server eintragen, und zwar so, dass Pakete, die an die Entertain IP Bereiche gehen sollen, an die LAN Adresse des vpn Routers von Standort B geschickt werden.
- statt ipv4 lan2lan vpn über Fritzbox könnte man ipv4 auch über openvpn ipv6 tunneln. In dem Fall wäre allerdings das Routing komplizierter einzurichten, weil die openvpn Server die Router für das vpn darstellen, während die Fritzboxen die Router fürs Internet darstellen.

Bei ip6 bin ich überfragt. Da gibts ja weder vpn noch NAT (was oben zweimal zum Einsatz kommt, um das LAN B so zu NATten, dass es aus Sicht der Entertain-Server als Teil von LAN A erscheint).

Allerdings setzt du dich mit so einer Konfiguration sicherlich über die Nutzungsbedingungen für Entertain hinweg. Ich würde es nicht tun.

 

[Andreas1969]

Allerdings setzt du dich mit so einer Konfiguration sicherlich über die Nutzungsbedingungen für Entertain hinweg. Ich würde es nicht tun.

Das sehe ich jetzt nicht als Problem, da Standort B nur eine Erweiterung meiner Räumlichkeiten ist.
Hab ich keine Bauchschmerzen :traurig:

Für ipv4 würde mir dazu folgendes einfallen:

- beide LANs via lan2lan vpn Kopplung verbinden. Fritzboxen können das.

Nee, Fritzboxen können das eben nicht :traurig:
Da gibt es doch noch den MTU Bug, wenn eine Seite DSLITE hat. Aber ich werde das auch noch testen. Eventuell wurde der MTU Bug in Fritz OS 7 ja behoben, sodass eine Verbindung zwischen IPV4 Box und DSLITE Box jetzt möglich ist.

 

[Andreas1969]

Das Blöde ist auch, dass ich an Standort B nicht in einen aktuellen Tarif wechseln kann, um DS zu buchen. Die TKO Option ist ja vorhanden, aber der Tarif ist zu alt.
Für die 40€ könnte ich dort ja auch die 400/40 buchen, aber dann fallen 4 der 5 Mobilfunkkarten hinten rüber.

 

[Wechseler]

- Im vpn Router von Standort B statische Routen für die IP-Bereiche der Entertain-Server eintragen, und zwar so, dass Pakete, die an die Entertain IP Bereiche gehen sollen, an die LAN Adresse des vpn Routers von Standort B geschickt werden.

Multicast-Routing funktioniert so nicht. :zwinker: Ich bezweifel, daß die Fritzbox das überhaupt kann.

 

[Wechseler]

Das hat nichts mit VLANs zu tun, du möchtest Multicast über VPN. Selbst bei einer Layer2-Bridge wird das nicht ganz einfach.

Ja, vermutlich hast Du Recht, Multicast dann wohl.
Hab mich damit noch nicht weiter auseinander gesetzt.
Daher auch die Frage, ob's schon jemand erfolgreich am Laufen hat. Man muss ja das Rad nicht jedesmal neu erfinden :zwinker:

Ich hatte Multicast-IPTV zuletzt 2009 laufen und das war eine ziemliche Schererei, insbesondere im Hinblick auf WLAN.

Hier hat sich schon mal jemand dran versucht:
https://forums.openvpn.net/viewtopic.php?t=21509

 

[Ool3eiV3aetooChu]

Moin,

ich hatte das seinerzeit über den igmpproxy gelöst. Frag mich aber nicht, wie mein setup genau aussah, lang (über 10 Jahre) ist's her :kratz:

 

[boba]

Sorry, ich habe nicht gewusst, dass Entertain multicast verwendet. Ich hatte irgendwie nur an ganz klassischen unicast tcp oder udp Datenverkehr gedacht. Multicast geht nicht einfach so durch NAT hindurch.

 

[Schlichi83]

Ich sehe hier noch ein ganz anderes Problem:
Ich hab selbst mal versucht Fernsehsignale vom Sattelit ungesetzt auf IP (via TVHeadend) von einem Telekom zu einem UM Anschluss zu übertragen. Trotz 40 Up bei der Telekom und 150 Down bei UM kamen aber nur ca. 10 MBit zwischen den Anschlüssen zustande. Das liegt am schlechten Routing zwischen beiden Anbietern. Wenn ich einen anderen Server (z.B. Amazon Web Services) dazwischen geschalten habe, dann bin ich auf über 30 MBit gekommen. Jedenfalls haben die 10 MBit nur für SD Übertragungen gereicht. Bei HD gab es immer wieder Störungen.

Greets
Schlichi83

 

[Andreas1969]

PS: Am Tarif Standort B kann ich nichts ändern / optimieren, da dort noch mehrere kostenlose Mobilfunkkarten drüber laufen, die bei einer Änderung wegfallen würden. Daher ist momentan auch nicht geplant, den Anschluß auf Telekom umzustellen, obwohl Vectoring verfügbar ist.

Das Problem mit den kostenlosen Mobilfunkkarten hat sich soeben erledigt.
Hab gerade bei der Telekom 3 kostenlose Family Cards Basic gebucht.
Für Magente 1 Kunden entfällt nämlich der monatliche Grundpreis von 4,95€. :smile:
Das muss wohl ganz neu sein.

Family Card Basic
• Voraussetzung ist ein bestehender Telekom Mobilfunk-Laufzeitvertrag mit einem monatlichen Grundpreis von mindestens 29,95 €.
• Der monatliche Grundpreis beträgt 4,95 €.
• Für MagentaEINS Kunden entfällt der monatliche Grundpreis von 4,95 €. Dieser zusätzliche Rabatt wird nach der Buchung automatisch von Ihrer monatlichen Rechnung abgezogen.
• Bereitstellungspreis: 9,95 €.
• Mindestlaufzeit: 1 Monat.
• Im monatlichen Grundpreis der Family Card Basic sind eine Telefon- und SMS-Flat ins Telekom Mobilfunknetz enthalten.
• Gespräche und SMS ins dt. Festnetz und andere dt. Mobilfunknetze: 0,09 €/Min. bzw. 0,09 €/SMS.
• Ab einem Datenvolumen von 300 MB wird die Bandbreite im jeweiligen Monat auf max. 64 KBit/s (Download) und 16 KBit/s (Upload) beschränkt.
• Die HotSpot Flatrate gilt für die Nutzung an inländischen HotSpots der Telekom Deutschland GmbH.
• Zudem beinhaltet der Tarif Roaming in der EU und in der Schweiz mit der Option All Inclusive.
• In der EU ist Roaming für vorübergehende Reisen mit angemessener Nutzung enthalten.
• In der Schweiz darf eine angemessene Nutzung (1.000 Minuten und 1.000 SMS pro Monat sowie ein monatliches Datenvolumen in Höhe des jeweiligen Inlandsvolumens vor Bandbreitenbeschränkung) nicht überschritten werden.
• Bei Wegfall des Telekom Mobilfunk-Laufzeitvertrages gelten die Konditionen des Tarifs MagentaMobil Prepaid S.
• Pro bestehendem Telekom Mobilfunk-Laufzeitvertrag dürfen max. 4 Family Cards bzw. CombiCards Data zugebucht werden.
• Insgesamt können pro Monat max. 3 Datenpässe (SpeedOn/DayFlat unlimited) hinzugebucht werden.

 

[stevenwort]

Ja der Family Card Basic wurde zur IFA letzte Woche Freitag vorgestellt.

 

[Andreas1969]

Allerdings setzt du dich mit so einer Konfiguration sicherlich über die Nutzungsbedingungen für Entertain hinweg. Ich würde es nicht tun.

Das sehe ich jetzt nicht als Problem, da Standort B nur eine Erweiterung meiner Räumlichkeiten ist.
Hab ich keine Bauchschmerzen :traurig:

Für ipv4 würde mir dazu folgendes einfallen:

- beide LANs via lan2lan vpn Kopplung verbinden. Fritzboxen können das.

Nee, Fritzboxen können das eben nicht :traurig:
Da gibt es doch noch den MTU Bug, wenn eine Seite DSLITE hat. Aber ich werde das auch noch testen. Eventuell wurde der MTU Bug in Fritz OS 7 ja behoben, sodass eine Verbindung zwischen IPV4 Box und DSLITE Box jetzt möglich ist.

So, die erste Erfolgsmeldung.
Eine Fritzbox VPN-Kopplung LAN-LAN zwischen meinem DS-Lite Anschluß bei UM und meinem Telekom Anschluß funktioniert jetzt mit Fritz OS 7.10 :zwinker:
AVM hat den VPN Bug in der 7.10 tatsächlich gefixt. :super:

Die Latenz ist für ne VPN Verbindung, die über´s UM AFTR läuft auch recht knackig, da hätte ich mit mehr gerechnet

Ping wird ausgeführt für 192.168.178.1 mit 32 Bytes Daten:
Antwort von 192.168.178.1: Bytes=32 Zeit=46ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=33ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=45ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=38ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=34ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=30ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=35ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=38ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=35ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=36ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=43ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=35ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=41ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=39ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=34ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=34ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=46ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=31ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=54ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=42ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=56ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=50ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=35ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=38ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=37ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=40ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=36ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=35ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=39ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=33ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=39ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=43ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=37ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=36ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=40ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=38ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=37ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=44ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=38ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=41ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=35ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=35ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=42ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=37ms TTL=63
Antwort von 192.168.178.1: Bytes=32 Zeit=37ms TTL=63
Ping-Statistik für 192.168.178.1: Pakete: Gesendet = 45, Empfangen = 45, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.: Minimum = 30ms, Maximum = 56ms, Mittelwert = 38ms

Routenverfolgung zu FRITZ-NAS [192.168.178.1]
über maximal 30 Hops: 1 <1 ms <1 ms <1 ms fritz.box [192.168.2.1] 2 34 ms 34 ms 32 ms FRITZ-NAS [192.168.178.1]
Ablaufverfolgung beendet.

 

[Andreas1969]

Neu ist auch die Funktion "Gesamten Netzwerkverkehr über die VPN-Verbindung senden", wurde in OS 7.10 auch eingeführt :zwinker:


Ich werde dann nächste Woche mal versuchen, einen Media Receiver der Telekom am Unitymedia Anschluß zum Laufen zu bringen (an LAN3 der dort laufenden Fritzbox 7590) :zwinker:

 

[Andreas1969]

Da es das OS 7.10 für die Kabelfritten ja noch nicht gibt, hab ich momentan folgendes Setup:

Am Telekom Super Vectoring Anschluss läuft eine 7590 mit Dual Stack
Am UM DS-Lite Anschluss läuft hinter der Provider 6360 am Bridge Port eine 7590 im DS-Lite Modus

Die VPN Verbindung zwischen den beiden Boxen läuft tadellos, warum hat AVM das nicht eher gefixt

 

[Conan179]

Da es das OS 7.10 für die Kabelfritten ja noch nicht gibt

Aber betas.

 

[Andreas1969]

Noch ein unschöner DS-Lite Effekt

Die VPN Verbindung zwischen einer IPV4 Fritte und einer DS-Lite Fritte funktioniert jetzt mit OS 7.10, es gibt aber exakt jede Stunde einen 1 sekündigen Ausfall in der VPN Verbindung.
Die Schuld liegt hier bei Unitymedia, da die dem DS-Lite Kunden exakt 1x pro Stunde eine neue IP4 Adresse auf dem AFTR zuwürfeln :wand:
Da bricht der Tunnel natürlich zusammen, baut sich aber sofort wieder auf.
Beim Live Streamen stört das aber, da jede Stunde für 1 Sekunde das Streaming unterbrochen wird.

Hier mal ein Auszug von der Fritte am IPV4 Anschluss, wo man erkennen kann, dass die Gegenseite jede Stunde eine neue IP4 Adresse vom AFTR zugewürfelt bekommt:

<i>
</i>05.05.19
01:59:49
VPN-Verbindung zu Test [95.222.29.18] IKE SA: DH2/AES-256/SHA2-512 IPsec SA: ESP-AES-256/SHA2-512/LT-3600 wurde erfolgreich hergestellt
05.05.19
02:58:50
VPN-Verbindung zu Test [95.222.29.22] IKE SA: DH2/AES-256/SHA2-512 IPsec SA: ESP-AES-256/SHA2-512/LT-3600 wurde erfolgreich hergestellt.
05.05.19
03:57:50
VPN-Verbindung zu Test [95.222.28.249] IKE SA: DH2/AES-256/SHA2-512 IPsec SA: ESP-AES-256/SHA2-512/LT-3600 wurde erfolgreich hergestellt.
05.05.19
04:56:50
VPN-Verbindung zu Test [95.222.29.6] IKE SA: DH2/AES-256/SHA2-512 IPsec SA: ESP-AES-256/SHA2-512/LT-3600 wurde erfolgreich hergestellt.
05.05.19
05:55:51
VPN-Verbindung zu Test [95.222.29.26] IKE SA: DH2/AES-256/SHA2-512 IPsec SA: ESP-AES-256/SHA2-512/LT-3600 wurde erfolgreich hergestellt.
05.05.19
06:54:51
VPN-Verbindung zu Test [95.222.28.193] IKE SA: DH2/AES-256/SHA2-512 IPsec SA: ESP-AES-256/SHA2-512/LT-3600 wurde erfolgreich hergestellt.
05.05.19
07:53:52
VPN-Verbindung zu Test [95.222.28.229] IKE SA: DH2/AES-256/SHA2-512 IPsec SA: ESP-AES-256/SHA2-512/LT-3600 wurde erfolgreich hergestellt.
05.05.19
08:52:52
VPN-Verbindung zu Test [95.222.28.252] IKE SA: DH2/AES-256/SHA2-512 IPsec SA: ESP-AES-256/SHA2-512/LT-3600 wurde erfolgreich hergestellt.
05.05.19
09:51:52
VPN-Verbindung zu Test [95.222.29.54] IKE SA: DH2/AES-256/SHA2-512 IPsec SA: ESP-AES-256/SHA2-512/LT-3600 wurde erfolgreich hergestellt.
05.05.19
10:50:53
VPN-Verbindung zu Test [95.222.28.215] IKE SA: DH2/AES-256/SHA2-512 IPsec SA: ESP-AES-256/SHA2-512/LT-3600 wurde erfolgreich hergestellt.

Die 95er Adressen sind ja die IP4 Adressen aus dem AFTR Pool

Auf der Gegenseite (Fritte am DS-Lite Anschluss) ist exakt zu den Zeiten, wo die AFTR IP4 Adresse wechselt folgender Eintrag zu sehen:

<i>
</i>05.05.19
05:55:50
VPN-Verbindung zu Test wurde getrennt. Ursache: 9 Dead Peer Detection
05.05.19
05:55:51
VPN-Verbindung zu Test [123.456.789.000] IKE SA: DH2/AES-256/SHA2-512 IPsec SA: ESP-AES-256/SHA2-512/LT-3600 wurde erfolgreich hergestellt.

Warum wechselt UM da genau jede Stunde die IP4 Adresse für den DS-Lite Kunden ???
Das erklärt eventuell auch, warum so viele Kunden unerklärliche Probleme mit DS-Lite haben.
Einige Anwendungen / Dienste kommen damit wohl absolut nicht zu recht.
Ich wusste auch bisher nicht, dass UM dem DS-Lite Kunden jede Stunde eine neu IP4 auf dem AFTR verbrät, das ist doch absoluter Quatsch, machen das andere Provider (speziell Vodafone) auch so

 

[Andreas1969]

1x pro Stunde eine kurze Unterbrechung in der VPN Verbindung ist mir doch ein bisschen too much. :hirnbump:

Wenn UM da 1× pro Tag in der Nacht die IP Adresse wechseln würde, wäre das ja noch OK, aber jede Stunde :motz:

Auch schön, dass AVM den VPN Bug jetzt behoben hat, aber in dieser Form ist das für mich nicht brauchbar. :streber:

 

[Andreas1969]

Das wird demnächst dann wohl reichlich Gemecker geben, wenn das OS 7.10 für die Kabelfritten ausgerollt wird und die DS-Lite geplagten Kunden endlich das Fritzbox VPN nutzen wollen und feststellen, dass die VPN Verbindung jede Stunde kurz unterbrochen wird hone:
Die Hotline wird sich bedanken

 

[robbe]

Betrifft ja erstmal nur die freien Boxen. Ich vermute nach der ganzen Updateorgie seit letztem Sommer, die es so bei UM ja noch nie gegeben hat, wird man auf die 7.10 dort jetzt bestimmt erstmal ne Weile warten können.

 

[Andreas1969]

Naja, da wird es auch reichlich Kunden mit freier Fritzbox geben.
Und AVM wirbt im aktuellen Release der 7.10 ja damit, dass der VPN MTU Bug an DS-Lite Anschlüssen behoben wurde und jetzt eine VPN Verbindung zwischen einer DS-Lite Box und einer IPV4 Box uneingeschränkt möglich ist. Nur dass UM dem Kunden da noch in die Suppe spuckt, das wurde nicht erwähnt.

Vor allem ist da technisch gesehen für mich überhaupt kein Grund ersichtlich, warum UM den DS-Lite Kunden stündlich auf eine andere öffentliche IP aus dem AFTR Pool umbiegen muss

 

[Andreas1969]

Problem gelöst :zwinker:

Der VPN-Tunnel läuft jetzt unterbrechungsfrei und die vom AFTR zugewiesene IP ändert sich jetzt auch nicht mehr.

Das Problem an DS-Lite Anschlüssen ist folgendes, fließt IPV4 mäßig kein Traffic Richtung AFTR, wird dem Anschluss nach einer Stunde oder so die öffentliche IP vom AFTR entzogen.
Erst bei Anforderung neuen IPV4 Traffic´s vergibt das AFTR dem Anschluss eine neue (dann andere) IPV4 Adresse.
Da das komplette Netzwerk aber noch über die 6360 läuft und an der 7590, die am Bridge Port der 6360 hängt, nur 1 Rechner angeschlossen ist, der nur läuft, wenn ich vor Ort bin, wurde kein IPV4 Traffic erzeugt.
Es floss nur etwas IPV6 Traffic durch 2 registrierte Telefonnummern per V6 auf der Box.
Die IP4 vom AFTR wird dem Anschluß dann nach einer Stunde entzogen, der Tunnel bricht zusammen und durch den sofortigen Neuaufbau wird wieder eine IPV4 vom AFTR vergeben, da ja durch den erneuten Verbindungsaufbau des Tunnels IPV4 Traffic angefordert wird. Der Tunnel wird dann wieder aufgebaut.
Man muss also dafür sorgen, dass konstant IPV4 Traffic vom Anschluß Richtung AFTR fließt, damit es keine Probleme / Unterbrechungen mit der VPN Verbindung gibt.

Gelöst hab ich das jetzt so: Auf der 7590 am IPV4 Anschluß ein IP Telefon angelegt und auf der 7590 am DS-Lite Anschluß als SIP-Telefon eingerichtet.
Als Registrar dann die 192.168.2.1 der IPV4 Box eingetragen, damit die Telefonie durch den Tunnel läuft. So fließen ständig minimal Daten durch den Tunnel, bzw. dann auch als IPV4 Traffic Richtung AFTR, wodurch die Verbindung dann am Leben erhalten wird.

 

[sch4kal]

Das Entertain dürfte ohne IGMP Proxy oder entsprechendes Multicast Routing trotzdem nicht laufen, korrekt ?

 

[Conan179]

Tihihi AVM ist mal nicht schult.