Hallo multicaster, das Demag-Wohnheim möchte gerne einen multicast-stream ins Hochschulnetz einspeisen. Zunächst als Werbemaßnahme für unser Sommerfest, später ggf. für eine Webcam mit Blick von unserem Dach aus. Leider fehlt uns etwas die praktische Erfahrung mit dem Thema und wir schrecken vor wilden Experimenten etwas zurück, weil wir bestehende Streams nicht stören wollen. Folgende Fragen würden daher wir gerne klären: a) So wie es aussieht, brauchen wir ja eine Adresse aus dem Local Scope 239.255.0.0/16, 239.254.0.0/16 bzw. 239.253.0.0/16. Wer regelt die Vergabe der Adressen aus diesem Bereich? Welche "Reichweite" haben wir mit diesem Scope, bzw. an welchen Grenzen wird das begrenzt? Wir wollen ja im Hochschulnetz bleiben... b) Ist es richtig, dass die TTL im Zusammenhang mit der Reichweite nur innerhalb des Scopes von Bedeutung ist? D.h. selbst wenn ich eine hohe TTL einstelle, bleibe ich mit einer Adresse aus dem "Local Scope" regional stark begrenzt? Welchen Wert wählt man sinnvollerweise für die TTL, um Rechner im Hochschulnetz zu erreichen? In einem DFN-Dokument zur Router-Konfiguration habe ich die Information gelesen, dass die DFN-Router standardmäßig einen Threshold von 32 eingestellt haben sollten. Daran könnte man ja mit der Anzahl der hops etwa abschätzen wie groß man den Wert wählen müsste?! c) auf den Hinweis von Jens Hektor hin, habe ich mal beacon installiert, um unsere multicast-Anbindung zu testen. Leider werden wir über http://beacon.noc.dfn.de aber nur in den Local *-Seiten gelistet, nicht in den Central * Seiten. Woran liegt das? Da das Sommerfest bereits am 30.06 ist, würden wir gerne möglichst zügig eine laufende Konfiguration zusammenstellen. Wenn jemand nützliche Hinweise geben kann, würden wir uns freuen. Gruß, Alex (Netz-AG, SMS Demag Kolleg)
On Fri, Jun 23, 2006 at 01:47:04PM +0200, Alex Dubielczyk wrote:
das Demag-Wohnheim möchte gerne einen multicast-stream ins Hochschulnetz einspeisen. Zunächst als Werbemaßnahme für unser Sommerfest, später ggf. für eine Webcam mit Blick von unserem Dach aus. Leider fehlt uns etwas die praktische Erfahrung mit dem Thema und wir schrecken vor wilden Experimenten etwas zurück, weil wir bestehende Streams nicht stören wollen.
Sowas habe ich für die Halifax-Party auch vor - in HD(T)V :)
a) So wie es aussieht, brauchen wir ja eine Adresse aus dem Local Scope 239.255.0.0/16, 239.254.0.0/16 bzw. 239.253.0.0/16. Wer regelt die Vergabe der Adressen aus diesem Bereich? Welche "Reichweite" haben wir mit diesem Scope, bzw. an welchen Grenzen wird das begrenzt? Wir wollen ja im Hochschulnetz bleiben...
239.254.0.0/16 ist das einzige brauchbare Netz, da Multicast hier (bzw. DFN) sehr merkwürdig geregelt ist. Die 239.0.0.0-Adressen sind laut Jens Hektor an der RWTH-Grenze gesperrt, gehen also nicht raus. Zusätzlich sollte ein TTL von 24 verwendet werden.
b) Ist es richtig, dass die TTL im Zusammenhang mit der Reichweite nur innerhalb des Scopes von Bedeutung ist? D.h. selbst wenn ich eine hohe TTL einstelle, bleibe ich mit einer Adresse aus dem "Local Scope" regional stark begrenzt?
Richtig, wenn das Scope richtig implementiert ist (denke ich).
Welchen Wert wählt man sinnvollerweise für die TTL, um Rechner im Hochschulnetz zu erreichen? In einem DFN-Dokument zur Router-Konfiguration habe ich die Information gelesen, dass die DFN-Router standardmäßig einen Threshold von 32 eingestellt haben sollten. Daran könnte man ja mit der Anzahl der hops etwa abschätzen wie groß man den Wert wählen müsste?!
Die RWTH-Firewall schneidet 24 ab, also ist eine TTL von 24 hier richtig.
c) auf den Hinweis von Jens Hektor hin, habe ich mal beacon installiert, um unsere multicast-Anbindung zu testen. Leider werden wir über http://beacon.noc.dfn.de aber nur in den Local *-Seiten gelistet, nicht in den Central * Seiten. Woran liegt das?
Wüsste ich gerade nicht... Firewall? :)
Da das Sommerfest bereits am 30.06 ist, würden wir gerne möglichst zügig eine laufende Konfiguration zusammenstellen. Wenn jemand nützliche Hinweise geben kann, würden wir uns freuen.
Habt ihr XORP laufen? Wenn ja, setzt einen Cand-RP für 239.254.17.0/24 auf und lasst in dem Adressbereich eure Streams laufen. Ciao, -- Carsten Otto c-otto@gmx.de www.c-otto.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Dubielczyk wrote:
c) auf den Hinweis von Jens Hektor hin, habe ich mal beacon installiert, um unsere multicast-Anbindung zu testen. Leider werden wir über http://beacon.noc.dfn.de aber nur in den Local *-Seiten gelistet, nicht in den Central * Seiten. Woran liegt das?
ich sehe nichts. Welche Beacon Version lasst Ihr laufen? 1.1 wäre sinnvoll. - -- Jens Hektor, Rechen- und Kommunikationszentrum, Wendlingweg 10, 52074 Aachen Centre for Computing and Communication, RWTH Aachen University, Germany mailto:hektor@RZ.RWTH-Aachen.DE, Tel.: +49 241 80 29206, Raum: 2.07 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRJvduRsVN+J7zzuXAQI8Cgf+L7nGohnsrXt99IxDPLjlBWPdAVJlphEq ZyYAUGx1ocVYfTAAmh4H08OezL6GC8I456iSeHH0zWsaC8vk/XZlU2r5pxlRlC9q wb40/Eey/OsWFwUOZCGVrM/9jvIhEzh2rlnKP5qz4PLDtUyTObQPvAFC8TfxsgJ+ NDeZCpW2xLiOriB6w/dI2KoCKjqCba5TprnsygCj0FQlzmDQLnRTrFOxlAzioveI Xqffydu+47MuKMScGG9fEoLrXGzkNzhBvoqJFy0Zb0MXIvFe+a9eosSD0eygZ1KA bU8mzhKffuOEYGfp2K82MLip7rmLfEun53r5iwuMi5a6IcZ1l0ztoQ== =my30 -----END PGP SIGNATURE-----
Jens Hektor schrieb:
c) auf den Hinweis von Jens Hektor hin, habe ich mal beacon installiert, um unsere multicast-Anbindung zu testen. Leider werden wir über http://beacon.noc.dfn.de aber nur in den Local *-Seiten gelistet, nicht in den Central * Seiten. Woran liegt das?
ich sehe nichts. Welche Beacon Version lasst Ihr laufen? 1.1 wäre sinnvoll.
Guck z.B. mal unter "local loss". Da stehen wir interessanter Weise drin. In den anderen Listen nicht. Ich hab den Verdacht, dass ich da irgendwas noch nicht ganz kapiert hab. Version ist 1.3. Leider waren die Informationen auf http://www.ip-mcast.de/beacon-intro.txt zur Konfiguration wohl etwas veraltet. Daher habe ich die Konfiguration "zusammengeraten". Ich vermute, dass da noch etwas falsch ist: Hier mal die Config-Parameter: GROUP = 233.2.168.5 #233.4.200.18 # NLANR/DAST default Beacon group PORT = 10002 # NLANR/DAST default Beacon port TTL = 127 CONTACTNAME = Alexander Dubielczyk CONTACTINFO = alexanderd@demag.rwth-aachen.de CONTACTLOCATION = SMS-Demag Kolleg, RWTH-Aachen, Germany NOTIFYEMAIL = alexanderd@demag.rwth-aachen.de SHOWIP = 1 SHOWSSRC = 1 SHOWREPORTS = 1 OUTPUTDIR = /home/alexanderd/work/beacon/outputfiles INTERFACE = 134.130.58.251 CENTRALSERVERNAME = beacon.noc.dfn.de WRITEHISTORY = 1 SERVERTCPPORT = 10004 Ausgabe vom Programmstart (vor allem die sporadischen Fehlschläge beim Öffnen des Sockets zum Server sind auffällig): ============================ SCHNIPP ========================= Getting configuration information from file "/usr/local/etc/beacon.conf". Opening session on interface "134.130.58.251". Starting Beacon "1.3-0" as "root" on Fri Jun 23 14:16:40 2006. This host is "itchy.demag.rwth-aachen.de", ssrc = 0x5e9c0f81, PID = 7107. Multicast Group = 233.2.168.5, Port = 10002, TTL = 127. OS = "linux" Output files being written to "/home/alexanderd/work/beacon/outputfiles/" Alarm/Notification notices will be sent to alexanderd@demag.rwth-aachen.de when those features are implemented. Go to http://beacon.noc.dfn.de to see this Beacon's output. Opening client connection Connection to Central Server established! client not defined Opening client connection client not defined Opening client connection client not defined Opening client connection client not defined ============================ SCHNAPP ========================= Gruß, Alex
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alex Dubielczyk wrote:
Version ist 1.3. Leider waren die Informationen auf
Hm, ich weiss nicht, ob 1.3 mit 1.1 zusammen harmoniert. Besser wäre 1.1 (daher vermutlich das "Client not defined") Andererseits geht Eure Subscription nicht auf das Internet-Interface raus. Was für Switches habt Ihr? IGMP ist enabled/funktioniert? - ----------------------------------------------------------- c3750-sw23-wohnheime#sho ip mroute 233.2.168.5 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, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode [...] (134.130.3.75, 233.2.168.5), 08:13:26/00:03:26, flags: JT Incoming interface: Vlan849, RPF nbr 137.226.39.129, Mroute Outgoing interface list: Vlan723, Forward/Sparse-Dense, 00:33:27/00:02:24 Vlan641, Forward/Sparse, 08:13:26/00:03:17 Vlan635, Forward/Sparse, 08:13:26/00:03:11 Vlan639, Forward/Sparse, 08:13:26/00:02:34 Vlan732, Forward/Sparse, 08:13:26/00:03:01 [...] (134.130.58.251, 233.2.168.5), 00:33:26/00:03:29, flags: FT Incoming interface: Vlan723, RPF nbr 0.0.0.0, Registering Outgoing interface list: Vlan641, Forward/Sparse, 00:33:26/00:03:17 Vlan635, Forward/Sparse, 00:33:26/00:03:11 Vlan639, Forward/Sparse, 00:33:26/00:02:34 Vlan732, Forward/Sparse, 00:33:26/00:03:01 [...] - ----------------------------------------------------------- - -- Jens Hektor, Rechen- und Kommunikationszentrum, Wendlingweg 10, 52074 Aachen Centre for Computing and Communication, RWTH Aachen University, Germany mailto:hektor@RZ.RWTH-Aachen.DE, Tel.: +49 241 80 29206, Raum: 2.07 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRJvkgRsVN+J7zzuXAQIcSwgAjUx39QQcgl7vM91ysPf1kUlGkdkV5IrE ySnlbQO0Hsg+2SmQkOoQsRw6gxK7ZPlxj+B23Ziijr8W5NhsP755+dBBA3ItxY+N WFtlWMJxfGFTP3fnf/DflEwA5rcSzEcF5N9x5zwkQ4+/7/q8nKKs8ok/afzmqADp W9zV9YlD3odJKtZ8MH6klItROswAx8wqJgc4gKSiTJuL+rSQ6ro45C7C1hBiq7aK SXETSPNw13XT/obfDemKxORJHGL0rinxsllqk2quLrRveVfobclih+6bweJ94dGL IeRYDEooOEjeluUhExRtajk6rabqqSdT5ROHxhUzjVx8wmPIDd9vrg== =pQfq -----END PGP SIGNATURE-----
Jens Hektor schrieb:
Hm, ich weiss nicht, ob 1.3 mit 1.1 zusammen harmoniert. Besser wäre 1.1 (daher vermutlich das "Client not defined")
Versuch ich gleich mal (wenn ich die Version noch irgendwo bekomme...).
Was für Switches habt Ihr?
Unser Uplink läuft auf einen C3560G auf. Von dort aus geht es dann weiter zum FAHO, Dorf bzw. in unseren Demag-Hausverteiler (3COM Superstack II/III). Da der Cisco-Switch erst seit ein paar Tagen in Betrieb ist, ist da auch bisher kaum was drauf konfiguriert worden. Allerdings empfangen alle Bewohner der Hügel-Wohnheime die TV-Streams und wir konnten auch von einem Rechner an unserem Superstack aus erfolgreich einen Stream über den C3560G hinweg bis ins FAHO-Wohnheim übertragen. IGMP scheint als grundsätzlich "irgendwie" zu funktionieren. Die Pakete von den Beacons kommen auch über das Interface an unserem lokalen Beacon-Rechner rein: --------------------------------------------------------------------------------------------------------------- [root@itchy:/home/alexanderd/]tcpdump -i eth0|grep UDP 15:18:00.217011 IP ip2-253.halifax.RWTH-Aachen.DE.10002 > 233.2.168.5.10002: UDP, length: 26 15:18:00.224991 IP intranet.hilton.RWTH-Aachen.DE.10002 > 233.2.168.5.10002: UDP, length: 26 15:18:00.229778 IP fw.halifax.RWTH-Aachen.DE.10002 > 233.2.168.5.10002: UDP, length: 26 15:18:00.232004 IP d195.hermann.RWTH-Aachen.DE.10002 > 233.2.168.5.10002: UDP, length: 26 15:18:00.235910 IP noc10.rz.RWTH-Aachen.DE.10002 > 233.2.168.5.10002: UDP, length: 26 15:18:00.250966 IP testsun1-223.rrzn.uni-hannover.de.10002 > 233.2.168.5.10002: UDP, length: 26 15:18:00.258065 IP itchy.demag.rwth-aachen.de.10002 > 233.2.168.5.10002: UDP, length: 26 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Das sollte doch eigentlich bedeuten, dass unser Rechner versucht, Pakete an die Group zu verschicken, oder? 15:18:00.274590 IP router.oph.RWTH-Aachen.DE.10002 > 233.2.168.5.10002: UDP, length: 26 15:18:00.301717 IP ip2-253.halifax.RWTH-Aachen.DE.10002 > 233.2.168.5.10002: UDP, length: 26 15:18:00.308927 IP intranet.hilton.RWTH-Aachen.DE.10002 > 233.2.168.5.10002: UDP, length: 26 -------------------------------------------------------------------------------------------------------------- Ich werde noch mal die Konfiguration unseres Beacon-Rechners checken, vielleicht liegt da noch ein Problem. Ansonsten könnte ich temporär einen Stream mit den von Carsten vorgeschlagenen Parametern per VLC laufen lassen. Der sollte dann ja eigentlich bis zu Euch durchkommen!? Gruß, Alex
On Fri, Jun 23, 2006 at 03:40:38PM +0200, Alex Dubielczyk wrote:
Da der Cisco-Switch erst seit ein paar Tagen in Betrieb ist, ist da auch bisher kaum was drauf konfiguriert worden. Allerdings empfangen alle Bewohner der Hügel-Wohnheime die TV-Streams und wir konnten auch von einem Rechner an unserem Superstack aus erfolgreich einen Stream über den C3560G hinweg bis ins FAHO-Wohnheim übertragen. IGMP scheint als grundsätzlich "irgendwie" zu funktionieren.
...und wenn es nur Broadcast ist.
15:18:00.258065 IP itchy.demag.rwth-aachen.de.10002 > 233.2.168.5.10002: UDP, length: 26 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Das sollte doch eigentlich bedeuten, dass unser Rechner versucht, Pakete an die Group zu verschicken, oder?
Ja.
Ich werde noch mal die Konfiguration unseres Beacon-Rechners checken, vielleicht liegt da noch ein Problem. Ansonsten könnte ich temporär einen Stream mit den von Carsten vorgeschlagenen Parametern per VLC laufen lassen. Der sollte dann ja eigentlich bis zu Euch durchkommen!?
Ja. -- Carsten Otto c-otto@gmx.de www.c-otto.de
Hallo Leute, ich habe mitlerweile noch mal alles mögliche bei uns betreffend multicast-Konfiguration gecheckt. Ich vermute mitlerweile, dass das Problem eher an unserem Uplink als an der lokalen Konfiguration liegt. Vielleicht noch mal folgende Informationszusammenfassung zur Problemeingrenzung: - bei uns findet hinter dem Uplink nur noch ein reines Switching statt. Kein Router, keine Firewall, die irgendwie was rausfiltern könnten. Unser Standard-GW ist die 134.130.58.254 - lokal innerhalb dieser geswitchten Umgebung klappt das Streaming problemlos auch über mehrere Switche hinweg (ohne broadcast! ;-)) - ich habe mir gerade mal mit einem Port-Mirroring den Traffic auf unserem Uplink-Port angesehen. Da gehen definitv die multicast Pakete raus: 09:36:37.881366 IP itchy.demag.RWTH-Aachen.DE.10002 > 233.2.168.5.10002: UDP, length: 26 09:36:46.731004 IP itchy.demag.RWTH-Aachen.DE.10002 > 233.2.168.5.10002: UDP, length: 26 - EinVersuch, gestern abend mit Unterstützung von Carsten einen Stream bis ins Halifax durchzubringen ist gescheitert. Wir haben dabei 239.254.16.199 auf Port 1234 benutzt. Da Jens gestern geschrieben hat, dass er auf dem Wohnheims-Switch keine eingehenden Pakete von uns bekommt, liegt die Vermutung nahe, dass die irgendwo auf dem Weg zum Wohnheimsswitch verloren gehen. Da wäre nämlich noch mindestens ein Switch im Bau-Ing-Gebäude, auf den unser LWL-Uplink aufläuft. Könnte es sein, dass die Pakete dort hängen bleiben? Ich hab leider keine genaue Vorstellung, wie das dort "verdrahtet" ist, bin aber bisher stillschweigend davon ausgegangen, dass wir da einfach nur durchgeswitched werden. Das sollte dann ja auch in beide Richtungen gehen?! Eine andere Sache, die für mich noch nicht ganz durchsichtig ist, sind die RPs. Kann es sein, dass der Versuch gestern abend mit dem Halifax scheitern musste, weil der RP ja auf deren Router liegt, der über uns aber gar nichts weiß, weil wir in einem anderen Subnet liegen? Andererseits sollte beacon es ja dann trotzdem tun :-/ Ideen? Gruß, Alex
On Sat, Jun 24, 2006 at 12:01:51PM +0200, Alex Dubielczyk wrote:
Da Jens gestern geschrieben hat, dass er auf dem Wohnheims-Switch keine eingehenden Pakete von uns bekommt, liegt die Vermutung nahe, dass die irgendwo auf dem Weg zum Wohnheimsswitch verloren gehen. Da wäre nämlich noch mindestens ein Switch im Bau-Ing-Gebäude, auf den unser LWL-Uplink aufläuft. Könnte es sein, dass die Pakete dort hängen bleiben? Ich hab leider keine genaue Vorstellung, wie das dort "verdrahtet" ist, bin aber bisher stillschweigend davon ausgegangen, dass wir da einfach nur durchgeswitched werden. Das sollte dann ja auch in beide Richtungen gehen?!
Das wird vermutlich, wie sonst auch überall, eine direkte Glasfaserverbindung ohne aktive Komponenten sein.
Eine andere Sache, die für mich noch nicht ganz durchsichtig ist, sind die RPs. Kann es sein, dass der Versuch gestern abend mit dem Halifax scheitern musste, weil der RP ja auf deren Router liegt, der über uns aber gar nichts weiß, weil wir in einem anderen Subnet liegen? Andererseits sollte beacon es ja dann trotzdem tun :-/
Das sollte so schon funktionieren, da jeder Router die nötigen Informationen vom BSR bekommt. Der WH-Router müsste also direkt zur Halifax-Firewall schicken. Über euren Rechner muss unser RP nichts wissen denke ich. Ciao, -- Carsten Otto c-otto@gmx.de www.c-otto.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Alex Dubielczyk wrote:
Da Jens gestern geschrieben hat, dass er auf dem Wohnheims-Switch keine eingehenden Pakete von uns bekommt,
blubber. Das habe ich nicht geschrieben. Bitte genauer lesen und verstehen und nicht falsch zitieren. Was nicht stimmt, ist das dynamisch (via IGMP) generierte Multicast-Routing: - ----------------- c3750-sw23-wohnheime>sho ip mroute 233.2.168.5 134.130.58.251 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, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (134.130.58.251, 233.2.168.5), 00:01:19/00:03:29, flags: FT Incoming interface: Vlan723, RPF nbr 0.0.0.0, Registering Outgoing interface list: Vlan641, Forward/Sparse, 00:01:19/00:03:15 Vlan732, Forward/Sparse, 00:01:19/00:03:12 Vlan639, Forward/Sparse, 00:01:19/00:03:16 Vlan635, Forward/Sparse, 00:01:19/00:03:16 - ----------------- Es fehlt ein Eintrag: - ----------------- Vlan849, Forward/Sparse-Dense, 09:03:03/00:02:55 (ttl-threshold 8) - ----------------- [...]
Ideen?
Ja, haufenweise. Erstmal sollte der Cisco-Switch *vernünftig* konfiguriert werden. Ich kann Die mal die typischen Zeilen schicken, die wir rein tun. Da Ihr Euch bestimmt noch nicht über Vlans Gedanken gemacht habt, sollte man dann dieses über die serielle Leitung auf den Switch pumpsen lassen. Schick mir mal am besten Eure Config (ohne die Passworte), dann kriegst Du von mir das was fehlt. Eventuell liegt da schon dass Problem. Haben Eure 3coms aktuelle Firmware? Ist der Beacon-Rechner direkt am Cisco oder liegt da noch ein anderer Switch dazwischen? Ist auf dem Beacon Rechner eine Fiorewall aktiv, wenn ja, was für eine? Gruss, Jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEVAwUBRJ0cChsVN+J7zzuXAQI/Sgf/Zng7YNUjB7BmSlreFK+YPKzl6d+JCOgd zEbPGHc3n7kYj+MKV6ssRyGPQUbfyQvjkC5I/y2fNCbtgnPp2OR/1eNI9Ry9QjNF 8EgJGK2amzjWHXqHKAvaPLHv2enggdx9FKmLFJluYD7cBfOPoZ7fppD34z8fTSeN EhBR8KiCeKItph9mtEPcbkfoTG8oha67vDP7lQeeE+1pGk/Y8/8uXyJOJclW98WS 0qDu5AqJGiFrQ9zUPw+wSETlGC92K/KJiR6PQx2SC/sroiSrSyu3duhv1pj4BqL1 3vyX4dQ4orbHxsZ0fChvQQMO9PnRxvT6oplVeeBbFRiOmIHCDFcJjg== =H0zM -----END PGP SIGNATURE-----
Jens Hektor schrieb:
Was nicht stimmt, ist das dynamisch (via IGMP) generierte Multicast-Routing:
Ich nehm alles zurück :-)
Schick mir mal am besten Eure Config (ohne die Passworte), dann kriegst Du von mir das was fehlt. Eventuell liegt da schon dass Problem.
Ist auf dem Weg.
Haben Eure 3coms aktuelle Firmware?
Ja.
Ist der Beacon-Rechner direkt am Cisco oder liegt da noch ein anderer Switch dazwischen?
Direkt am Cisco-Switch. Der Test gestern abend liefen von einem Windows-PC (VLC) am 3COM-Stack aus. Könnte ich testweise auch mal umstecken, damit der 3COM-Stack als Fehlerquelle ausgeschlossen werden kann.
Ist auf dem Beacon Rechner eine Fiorewall aktiv, wenn ja, was für eine?
Zum IPv6: Benutzen wir nirgends. Es war lediglich ein für IPv6 gepatchtes beacon 1.1 Gruß, Alex
participants (3)
-
Alex Dubielczyk -
Carsten Otto -
Jens Hektor