rwth-multicast

rwth-multicast@lists.rwth-aachen.de

15 Diskussionen

Re: [rwth-multicast] Multicast troubleshooting: xorp.conf

von Malte Möller

On 27.09.2012 13:44, Jens Hektor wrote: > Bitte an an Hitnet und WEH: > > Könnt Ihr unter > > http://netzags-wiki.halifax.rwth-aachen.de/index.php/Multicast#Routing > > auch mal Eure Konfigs einstellen, parallel zur Halifax. Endlich habe wieder etwas Zeit mich damit zu beschäftigen, ich habe die Konfiguration vom WEH für uns angepasst und bekomme damit nun unsere Sender wieder in die RWTH hinaus, dadurch sollte zumindest die Unicast Umsetzung von Carsten wieder mit unserem derzeit kleinen Angebot stabil laufen. Was mir damit nicht gelingt ist der Empfang von externen Ankündigungen. Daher habe die Seite http://streams.rz.rwth-aachen.de/beacon4/ mit einigen Rechner von uns befüllt. Das Ergebnis verwirrt mich: Ich interpretiere es so, dass unsere internen Schnittstellen zwar nicht die externe Schnittstelle unseres Router erreichen, jedoch sehr wohl die 137.226.33.59. Das ist die Adresse von http://streams.c-otto.de/ im 137.226.33.56/29. Diese VM hat eine dedizierte Leitung in dieses Netz und außerdem die in der Tabelle auch zu sehende 137.226.111.232 im internen Netz. Sobald ich einen der beiden dbeacon Prozesse auf dieser VM beende tauchen keinerlei interne Beacons mehr auf. Ich hoffe das ist ein Feature von dbeacon, wiederum verwirrend ist dass das nicht bei unserem Router klappt. z.B. beim OPH würde mich noch eine Quelle im inneren statt im Transportnetz interessieren. Das ganze werde ich mir aber frühestens am Mittwoch genauer anschauen können, über weitere Konfigs wäre ich sehr glücklich: http://netzags-wiki.halifax.rwth-aachen.de/index.php/Multicast#Configs_der_… Grüße Malte

11 Jahre, 7 Monate

Re: [rwth-multicast] [Vorstand] Multicast troubleshooting: xorp.conf

von Carsten Otto

On Fri, Sep 28, 2012 at 11:34:46AM +0200, Ansgar Röber wrote: > Dass Problem im Hitnet wird also sein, dass der Xorp seinen eigenen > Candidat RP erst sehr spät zugewiesen bekommt (per Bootstrap) und diesen > dann nach ner Zeit wieder "vergisst". Ich erinnere mich dunkel an Probleme dieser Art (Timeout wird erreicht, RP wird vergessen). Meine Vermutung ist, dass Xorp den eigenen RP natürlich kennt, aber nur dann dauerhaft akzeptiert, wenn dieser auch vom BSR angekündigt wird. Das macht der (RWTH-?)BSR aber vermutlich nicht. Wollen wir überhaupt zusätzlich zu 224/4 noch weitere RPs haben? Wenn ja, muss der BSR konfiguriert werden? Gibt es Probleme mit den Prioritäten der RPs? Ich glaube anfangs war der RWTH-RP auf höchster Priorität? > In den Zeiten wo er den eigenen RP nicht "kennt", vermute ich, werden > dann die Logmeldungen produziert. Das sehe ich auch so. Ciao, -- Carsten Otto carsten(a)c-otto.de www.c-otto.de

11 Jahre, 7 Monate

Multicast troubleshooting: xorp.conf

von "Ansgar Röber (Multicast-Liste)"

> On 27.09.2012 15:45, Jan Niehusmann wrote: >> Aber gerne. Xorp mit pim aktiviert. Keine Änderung, es kommen immer >> noch massig dieser Meldungen: >> >> [ 2012/09/27 15:37:35 WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from MFEA_4: vif_index = 3 src = 137.226.181.9 dst = 239.254.38.14 len = 1344: no RP address for this group Also ich vermute, dass im Hitnet der Bootstrap-Mechanismus Probleme macht. > Bootstrap, cksum 0x9d90 (correct) tag=0 hashmlen=30 BSRprio=64 BSR=n7k-ww10-trsh-3-et3-7.noc.rwth-aachen.de > (group0: base-address.mcast.net/4 RPcnt=1 FRPcnt=1 RP0=n6k-sw23.noc.RWTh-Aachen.DE,holdtime=2m30s,prio=0) > (group1: 239.254.2.0/24 RPcnt=1 FRPcnt=1 RP0=d193.hermann.rwth-aachen.de,holdtime=2m30s,prio=0) > (group2: 239.254.18.0/24 RPcnt=1 FRPcnt=1 RP0=fw.hilton.rwth-aachen.de,holdtime=2m30s,prio=19) > (group3: 239.255.255.255 RPcnt=2 FRPcnt=2 RP0=router.farue.rwth-aachen.de,holdtime=2m59s,prio=192 RP1=fw.hilton.rwth-aachen.de,holdtime=2m30s,prio=19) Soweit ich das verstehe haben wir als BSR 134.130.9.74 (früher war der glaube ich im DFN) Die RPs fürs Hilton etc tauchen dort ja auch richtig auf und werden von unserem XOPR (trotz Bootstrap disable: true) in die RP-Liste für die Zeit der "holdtime"(2m30s) aufgenommen. Es scheint aber so zu sein, dass das nächste Bootstrap-"Paket" erst viel später nach dieser Zeit kommt, sodass nach einer Zeit die RPs aus der Liste wieder verschwinden... Zunächst: > root@router> show pim rps > RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix > 134.130.8.11 static 192 -1 -1 17 224.0.0.0/4 > 134.130.56.193 bootstrap 0 150 4 0 239.254.2.0/24 > 137.226.39.194 bootstrap 19 150 4 0 239.254.18.0/24 > 137.226.153.1 bootstrap 192 179 33 0 239.255.255.255/32 > 137.226.39.194 bootstrap 19 150 4 1 239.255.255.255/32 Etwas später: > root@router> show pim rps > RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix > 134.130.8.11 static 192 -1 -1 18 224.0.0.0/4 > 137.226.153.1 bootstrap 192 179 28 1 239.255.255.255/32 Noch ein bisschen später: > root@router> show pim rps > RP Type Pri Holdtime Timeout ActiveGroups GroupPrefix > 134.130.8.11 static 192 -1 -1 17 224.0.0.0/4 Dass Problem im Hitnet wird also sein, dass der Xorp seinen eigenen Candidat RP erst sehr spät zugewiesen bekommt (per Bootstrap) und diesen dann nach ner Zeit wieder "vergisst". In den Zeiten wo er den eigenen RP nicht "kennt", vermute ich, werden dann die Logmeldungen produziert. Viele Grüße, Ansgar (WEH) PS: Ich habe mal die rwth-multicast -Liste in den cc genommen... evtl. wäre es sinnvoller, wenn sich da alle Interessierten/Betroffenen(oder die netzag-Listen) eintragen und man nich immer aufpassen muss, ob alle im cc stehen -- Ansgar Röber WEH Zi. 16-15, Rütscher Str. 165, 52072 Aachen E-Mail: ansgar.roeber(a)rwth-aachen.de Jabber: ansgar.roeber(a)jabber.rwth-aachen.de -- Ansgar Röber, NetzAG Verein zur Förderung des studentischen Zusammenlebens im Walter-Eilender-Haus, kurz WEH e.V. Rütscher Str. 165, 52072 Aachen http://www.weh.rwth-aachen.de - netag(a)weh.rwth-aachen.de Jabber: ansgar.roeber(a)jabber.rwth-aachen.de

11 Jahre, 7 Monate

Nichts geht mehr im weh

von Sebastian Hoogen

Hallo Zusammen, seit einiger Zeit sehe ich keine Groups mehr. Hatte jemand schon mal an ein solches Problem? Danke Schönen Gruß Sebastian (netag-weh) root@router> show pim neighbors Interface DRpriority NeighborAddr V Mode Holdtime Timeout eth1 1 137.226.118.241 2 Sparse 105 84 root@router> show pim join Group Source RP Flags 239.255.255.250 137.226.140.26 RP_ADDR_UNKNOWN SG SPT DirectlyConnectedS Upstream interface (S): eth0 Upstream interface (RP): UNKNOWN Upstream MRIB next hop (RP): UNKNOWN Upstream MRIB next hop (S): UNKNOWN Upstream RPF'(S,G): UNKNOWN Upstream state: Joined Register state: RegisterJoin RegisterCouldRegister Join timer: 18 KAT(S,G) running: true Local receiver include WC: ... Local receiver include SG: ... Local receiver exclude SG: ... Joins RP: ... Joins WC: ... Joins SG: ..O Join state: ..O Prune state: ... Prune pending state: ... I am assert winner state: ... I am assert loser state: ... Assert winner WC: ... Assert winner SG: ... Assert lost WC: ... Assert lost SG: ... Assert lost SG_RPT: ... Assert tracking SG: O.O Could assert WC: ... Could assert SG: ..O I am DR: OOO Immediate olist RP: ... Immediate olist WC: ... Immediate olist SG: ..O Inherited olist SG: ..O Inherited olist SG_RPT: ... PIM include WC: ... PIM include SG: ... PIM exclude SG: ... 239.255.255.250 137.226.140.47 RP_ADDR_UNKNOWN SG SPT DirectlyConnectedS Upstream interface (S): eth0 Upstream interface (RP): UNKNOWN Upstream MRIB next hop (RP): UNKNOWN Upstream MRIB next hop (S): UNKNOWN Upstream RPF'(S,G): UNKNOWN Upstream state: Joined Register state: RegisterJoin RegisterCouldRegister Join timer: 18 KAT(S,G) running: true Local receiver include WC: ... Local receiver include SG: ... Local receiver exclude SG: ... Joins RP: ... Joins WC: ... Joins SG: ..O Join state: ..O Prune state: ... Prune pending state: ... I am assert winner state: ... I am assert loser state: ... Assert winner WC: ... Assert winner SG: ... Assert lost WC: ... Assert lost SG: ... Assert lost SG_RPT: ... Assert tracking SG: O.O Could assert WC: ... Could assert SG: ..O I am DR: OOO Immediate olist RP: ... Immediate olist WC: ... Immediate olist SG: ..O Inherited olist SG: ..O Inherited olist SG_RPT: ... PIM include WC: ... PIM include SG: ... PIM exclude SG: ... 239.255.255.250 137.226.140.205 RP_ADDR_UNKNOWN SG SPT DirectlyConnectedS Upstream interface (S): eth0 Upstream interface (RP): UNKNOWN Upstream MRIB next hop (RP): UNKNOWN Upstream MRIB next hop (S): UNKNOWN Upstream RPF'(S,G): UNKNOWN Upstream state: Joined Register state: RegisterJoin RegisterCouldRegister Join timer: 57 KAT(S,G) running: true Local receiver include WC: ... Local receiver include SG: ... Local receiver exclude SG: ... Joins RP: ... Joins WC: ... Joins SG: ..O Join state: ..O Prune state: ... Prune pending state: ... I am assert winner state: ... I am assert loser state: ... Assert winner WC: ... Assert winner SG: ... Assert lost WC: ... Assert lost SG: ... Assert lost SG_RPT: ... Assert tracking SG: O.O Could assert WC: ... Could assert SG: ..O I am DR: OOO Immediate olist RP: ... Immediate olist WC: ... Immediate olist SG: ..O Inherited olist SG: ..O Inherited olist SG_RPT: ... PIM include WC: ... PIM include SG: ... PIM exclude SG: ... 239.255.255.250 137.226.141.51 RP_ADDR_UNKNOWN SG SPT DirectlyConnectedS Upstream interface (S): eth0 Upstream interface (RP): UNKNOWN Upstream MRIB next hop (RP): UNKNOWN Upstream MRIB next hop (S): UNKNOWN Upstream RPF'(S,G): UNKNOWN Upstream state: Joined Register state: RegisterJoin RegisterCouldRegister Join timer: 42 KAT(S,G) running: true Local receiver include WC: ... Local receiver include SG: ... Local receiver exclude SG: ... Joins RP: ... Joins WC: ... Joins SG: ..O Join state: ..O Prune state: ... Prune pending state: ... I am assert winner state: ... I am assert loser state: ... Assert winner WC: ... Assert winner SG: ... Assert lost WC: ... Assert lost SG: ... Assert lost SG_RPT: ... Assert tracking SG: O.O Could assert WC: ... Could assert SG: ..O I am DR: OOO Immediate olist RP: ... Immediate olist WC: ... Immediate olist SG: ..O Inherited olist SG: ..O Inherited olist SG_RPT: ... PIM include WC: ... PIM include SG: ... PIM exclude SG: ...

16 Jahre, 11 Monate

Demag multicast stream

von Alex Dubielczyk

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)

17 Jahre, 10 Monate

Re: [rwth-multicast] Demag multicast stream

von Alex Dubielczyk

Daniel Sievers schrieb: > Du brauchst 1.1 (siehe attachment). Ich hatte auch das Problem, dass es > mit 1.3 nicht zusammen gearbeitet hat. > Ich hatte gestern schon mal die 1.1 mit IPv6-Path testweise installiert. War das einzige Paket auf dem Versionsstand, das ich noch im Netz finden konnte. Das Ergebnis hatte sich nicht geändert. Dein Paket tut es aber jetzt! Sollte man mal irgendwo zum allgemeinen Download ablegen?! Damit wäre die Theorie vom störenden Switch auf dem Weg zum Wohnheimsswitch aber wohl auch direkt vom Tisch. Dann kann ich jetzt ja mal weiterschauen... Danke schon mal für Eure Hilfe! Alex

17 Jahre, 10 Monate

Re: [rwth-multicast] Multicast Kullen

von Jens Hektor

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexander Grümmer wrote: > Hallo das Kullen hat auch einen Xorp! Stimmt. Janz verjessen. > Hast du das besagte Zaubercommando auch bei uns aktiviert weil hier der > Stream alle 5 min stehen bleibt. Jetzt ja. Noch jemand janz ohne Fahrschein? *In jeder Zeile zwei J*ens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iQEVAwUBQ6cAoRsVN+J7zzuXAQJbOAgAkneAdW7YOBHXXsJO+/wFNzfapKjPw5ub /a/03/u4Z+4WkhQF83iZcSKVZzivZrO1ec5d+U9FNNvHz8fzn+dkBf+HhjDXY0kh g3TeDU47Q14cHyQAmAzTb8874PxcdqMJWuDdg+WXgPP8xaOGqbO0WQ2num+LwkcB QjHpucJ/YRpi5ceDhI7OVLGBcLQOXVFiaurS6pednPdEMsTh0LmQsJsl+nLZ0N0v elsesj/R5CRuSgsXmBRyIVtSGLKcY4j+QvdhjGBs76Maip3SnVPndLfy7BsYWclS pQR4VLnS+oKypJwflglApGGqlnyvS1xuuVGfJNbYWhnVpDCxttrmrg== =KrEB -----END PGP SIGNATURE-----

18 Jahre, 4 Monate

Routen gefixed

von Jens Hektor

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, hatte die MCast Routen für die Transportnetze Halifax, Hermannstrasse und Hilton falsch gesetzt. Das ist jetzt behoben. Ob jetzt besser klappt? Jedenfalls ist Sammy's Beacon jetzt schon über 10 Minuten sichtbar. Gruss, Jens - -- 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 Fedora - http://enigmail.mozdev.org iQEVAwUBQ6aa4BsVN+J7zzuXAQJWZAf/fIziHs5R7DBM+UNp2AOOFWsRUUpitBH4 wNw+rTWGYi9aTX+Ms7a1Zjo9MjyyP6iVP30Ja2dlcrFjuBQQxP69HP+iw82mI/Rs Z3CjGj6ezyNVSQoJB0+8eX+T4Qkv0LU9YEN4U3gt2i2aiqBbMi8ZlzNwaKeEeAR8 ZxycDl99baEgozU0Web2cwjd4Sl5JGyWXT82TTu/yMAQyarkwh9AsQHa/cmKMB+C VP+EDRL5L4+ram0sLFmyJ/tKjrxsocv2KOe2wWtfNrFV610Uzabr3YXaXSONpWqR HXVAEu57HkOLlBrUzo4DXp5dgLyx+3wWyRIX/IwOseuFAsyiHXngNg== =1GTR -----END PGP SIGNATURE-----

18 Jahre, 4 Monate

[Fwd: Re: [Xorp-users] join messages not sent out (from IGMP to PIM)]

von Daniel Sievers

-------- Original Message -------- Subject: Re: [Xorp-users] join messages not sent out (from IGMP to PIM) Date: Thu, 08 Dec 2005 11:38:35 -0800 From: Pavlin Radoslavov <pavlin(a)icir.org> To: Daniel Sievers <sievers(a)hilton.rwth-aachen.de> CC: Pavlin Radoslavov <pavlin(a)icir.org> > There is still another thing I do not understand though: > > Our xorp router receives multicast traffic from a cisco 3750 pim-sm > enabled router. The cisco will send igmp queries to 224.0.0.1 and xorp > will reply for "all-routers.mcast.net" and "pim-routers.mcast.net", but > it will never report for the multicast groups joined by clients in the > LAN behind the xorp router (,it will show the RPs and igmp groups as > joined though in the shell). > > So is this the correct behaviour? Should a pim router decide whether it Yes, this is the correct behavior. The XORP router replies for the all-routes and pim-routers groups because it has joined those two groups. > forwards multicast traffic to another pim router (and not client!) based > on pim join status solely, or should xorp always reply to IGMP queries > from another pim router by reporting all the groups joined on the > client-side LAN? Yes, in case of PIM-SM routers, the forwarding is based solely on the PIM Join status. > (The reason I'm asking is that the Cisco router will stop forwarding > traffic after 5 minutes of running xorp. Crafting an igmp report packet > for a particular multicast group will make it forward traffic again for > a limited period of time.) To track the problem, wait until the Cisco router stops forwarding the traffic, and then check the related state: 1. The PIM Join state inside Cisco 2. The PIM Join state inside XORP 3. The IGMP group state inside XORP. Pavlin

18 Jahre, 4 Monate

Re: [rwth-multicast] [Xorp-users] join messages not sent out (from IGMP to PIM)

von Pavlin Radoslavov

> > > To track the problem, wait until the Cisco router stops forwarding > > the traffic, and then check the related state: > > 1. The PIM Join state inside Cisco > > 2. The PIM Join state inside XORP > > 3. The IGMP group state inside XORP. > > > > Yes, unfortunately all of them look good :) > > I believe there might be a bug in the Cisco Software. (it's a Catalyst > 3750, in the documentation I was able to find what you said about > PIM-Snooping and it should support it) > > Setup is > LAN <-> xorp DR <-> C3750 <-> RP(xorp) <-> Source > > The Cisco has attached other LANs, some of them running xorp, others > have a bridge between their LAN and the Cisco and thus do not need xorp. (*) > So maybe the bug even occurs only because of the mixed setup, where the > C3750 has to perform IGMP Snooping on some, while PIM-Snooping on other > ports. > > The behaviour is weird: > -After launching xorp, multicast groups will only be received from the > Cisco for about 5 minutes > -Crafting an IGMP Join for specific multicast groups will make it send > again (that specific group only) for 2 minutes or so > > -Also it sends IGMP Queries to xorp, but according to the documentation > the IGMP Querier should be automatically disabled due to our setup (e.g. > having PIM routers attached) You could try to run tcpdump on the "xorp DR <-> C3750" and on the "3750 <-> RP(xorp)" links to see whether the control (PIM and IGMP) and data traffic is as expected. The extra IGMP Queries are harmless (modulo the extra traffic if you care about it), but it is important to verify whether the PIM Snooping is working. > Guess we should contact Cisco about this.... > > Thanks again! > -Daniel > > > (*) Btw, Sammy and Carsten Otto (C-Otto), who told me that you have > helped them greatly too so far with a whole bunch of mails, are > administrating networks attached to that same C3750 on our campus network :) It's a small world. :) Pavlin

18 Jahre, 4 Monate

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

rwth-multicast