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
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
> 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
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)
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
-----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-----
-------- 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
>
> > 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