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,
Am 28.09.2012 11:46, schrieb Carsten Otto:
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?
Im Prinzip müsste es ja auch funktionieren, wenn alle Wohnheime allein den "Master" RP 134.130.8.11 für 224.0.0.0/4 statisch eintragen...
Ob dass dann Traffic-Nachteile hat weiß ich nicht. Werden dann erstmal alle Sender/Streams an den RP geschickt (also aus dem Wohnheim raus), auch wenn vielleicht nur ein Sender außerhalb des Wohnheims aboniert wurde?
Grüße,
On Fri, Sep 28, 2012 at 11:56:20AM +0200, Ansgar Röber wrote:
Ob dass dann Traffic-Nachteile hat weiß ich nicht. Werden dann erstmal alle Sender/Streams an den RP geschickt (also aus dem Wohnheim raus), auch wenn vielleicht nur ein Sender außerhalb des Wohnheims aboniert wurde?
Wikipedia:
When a data source first sends to a group, its Designated Router (DR) unicasts Register messages to the Rendezvous Point (RP) with the source's data packets encapsulated within. -> alles geht per Unicast zum RP
If the data rate is high, the RP can send source-specific Join/Prune messages back towards the source and the source's data packets will follow the resulting forwarding state and travel un-encapsulated to the RP. -> der RP kann (!) sagen "ist genug", dann gehen die Daten nur dahin, wo sie wirklich gebraucht werden. Ausprobieren?
Whether they arrive encapsulated or natively, the RP forwards the source's de-capsulated data packets down the RP-centered distribution tree toward group members. -> die Daten gehen im Normalfall über dem RP zu den Clients
If the data rate warrants it, routers with local receivers can join a source-specific, shortest path, distribution tree, and prune this source's packets off the shared RP-centered tree. -> Abkürzungen sind erlaubt, statt source - x - rp - x - client geht auch direkt source - x - client
Ich bin stark dafür, auf allen beteiligten Rechnern Xorp der neuesten Version laufen zu lassen, keinen Cand-RP aufzusetzen, den RZ-RP statisch zu konfigurieren und dann zu gucken, was passiert. Die beteiligten Router sollten, sofern man das denn versteht, natürlich die oben genannten Abkürzungen aktiviert haben.
Ciao,
rwth-multicast@lists.rwth-aachen.de
-
Ansgar Röber -
Carsten Otto