adowoMAC 10 Geschrieben 25. Oktober 2006 Melden Teilen Geschrieben 25. Oktober 2006 Hallo, ich möchte mittels eines Cisco 3750 ein Multicast-Labor aufbauen. Mir ist der technische und logische Hintergrund klar, nur wie teilt ein Rechner, der an den Switch angeschlossen ist, dem ganzen mit, dass er in eine bestimmte IGMP bzw. Multicast Gruppe joinen möchte? Irgendwie schaffe ich es nicht so richtig dort den Bogen richtig zu spannen. Dies ist eben elementar wichtig, um meinen Versuchsaufbau zu testen. Gruß, Hendrik Zitieren Link zu diesem Kommentar
fu123 10 Geschrieben 25. Oktober 2006 Melden Teilen Geschrieben 25. Oktober 2006 Hallo, ich möchte mittels eines Cisco 3750 ein Multicast-Labor aufbauen. Mir ist der technische und logische Hintergrund klar, nur wie teilt ein Rechner, der an den Switch angeschlossen ist, dem ganzen mit, dass er in eine bestimmte IGMP bzw. Multicast Gruppe joinen möchte? Irgendwie schaffe ich es nicht so richtig dort den Bogen richtig zu spannen. Dies ist eben elementar wichtig, um meinen Versuchsaufbau zu testen. Gruß, Hendrik Hi, du kannst ein ip igmp join-group 224.1.1.1 auf dem Interface absetzen. Die 224.1.1.1 ist nur ein Beispiel. Range geht von 224.0.0.0 - 239.255.255.255 Sobald "ip multicast-routing" enabled ist und du einen PIM Modus festgelegt hast, kann der Router/Switch Multicast. Normalerweise sendet der Client einen Join für die Gruppe. Mit ip igmp join-group kannst du das simulieren um z.B. einen Ping auf eine Mcast Address von dem Interface zurückzubekommen. Als Mcast Server kann man zum testen z.B. vlc nehmen. Fu Zitieren Link zu diesem Kommentar
adowoMAC 10 Geschrieben 25. Oktober 2006 Autor Melden Teilen Geschrieben 25. Oktober 2006 Super :) damit komme ich schonmal 2-3 Schritte weiter! Zitieren Link zu diesem Kommentar
Blacky_24 10 Geschrieben 25. Oktober 2006 Melden Teilen Geschrieben 25. Oktober 2006 Hallo,Mir ist der technische und logische Hintergrund klar, Nö, offensichtlich nicht wirklich. Hallo,nur wie teilt ein Rechner, der an den Switch angeschlossen ist, dem ganzen mit, dass er in eine bestimmte IGMP bzw. Multicast Gruppe joinen möchte? Indem auf dem Rechner irgendeine Software läuft die in der Lage ist, als Multicast-Client einen Cast (MC-Gruppenadresse) an einem entsprechenden Server zu joinen (subscriben). Server kann alles mögliche sein, gängige Anwendung ist Mediastreaming, wird aber auch bei diverser Finanzsoftware gemacht (z.B. im Eurex-System der Deutschen Börse). Das ganze Netzwerkgebastel dazwischen dient eingentlich nur dazu, die Daten sicher zu verteilen und dafür zu sorgen, dass da nicht mehrere auf der gleichen Multicast-Adresse unterschiedliche Streams abonnieren - und es ist je nach Anforderung ggf. erforderlich, den Multicast über Router und durch Tunnel zu leiten - dann brauchst Du eben so tolle Sachen wie "PIM" und "ip multicast-routing". Gruss Markus Zitieren Link zu diesem Kommentar
adowoMAC 10 Geschrieben 26. Oktober 2006 Autor Melden Teilen Geschrieben 26. Oktober 2006 Also mein Switch macht nun fleissig Multicast, leider aber an alle Ports des Switches .. also egal ob ich will oder nicht, alle angeschlossenen Geräte empfangen den Multicast, den ich sende. Wie kann ich nun sagen, dass nur die Hosts den kram empfangen, die es auch haben wollen. Der Befehl "ip igmp join-group" ist bei mir auf dem IOS leider nicht vorhanden. Mein Server hängt an Port fa0/1 .. sendet auf die Multicast Adresse 239.255.12.42 .. empfangen sollen nur die Stationen, die es auch anfordern über die IP Meine Konfiguration: version 12.2 no service pad service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname boic2 ! no aaa new-model ip subnet-zero ! ip multicast-routing distributed ip igmp snooping vlan 1 immediate-leave ! ! no file verify auto spanning-tree mode pvst spanning-tree extend system-id ! vlan internal allocation policy ascending ! ! iinterface FastEthernet0/1 switchport mode access spanning-tree portfast ! interface FastEthernet0/2 switchport mode access spanning-tree portfast ! interface FastEthernet0/3 switchport mode access spanning-tree portfast ! interface FastEthernet0/4 switchport mode access spanning-tree portfast ! interface FastEthernet0/5 switchport mode access spanning-tree portfast ! interface FastEthernet0/6 switchport mode access spanning-tree portfast ! interface FastEthernet0/7 switchport mode access spanning-tree portfast ! interface FastEthernet0/8 switchport mode access spanning-tree portfast ! interface FastEthernet0/9 switchport mode access spanning-tree portfast ! interface FastEthernet0/10 switchport mode access spanning-tree portfast ! interface FastEthernet0/11 switchport mode access spanning-tree portfast ! interface FastEthernet0/12 switchport mode access spanning-tree portfast ! interface Vlan1 no ip address ip pim version 1 ip pim sparse-dense-mode ! ip classless ip http server ip http secure-server ! ! control-plane ! ! line con 0 line vty 0 4 no login line vty 5 15 no login ! end Zitieren Link zu diesem Kommentar
fu123 10 Geschrieben 26. Oktober 2006 Melden Teilen Geschrieben 26. Oktober 2006 Hi, du hast das auf dem Vlan 1 enabled. Also sendet er an alle Ports im Vlan. :) Fu Zitieren Link zu diesem Kommentar
adowoMAC 10 Geschrieben 26. Oktober 2006 Autor Melden Teilen Geschrieben 26. Oktober 2006 Jo nun läufts. Habe ein neues VLAN erstellt, einige Ports reingehauen und nun klappt das auch wenn ich dieses entsprechende VLAN eine Gruppe Joinen lasse. Danke! Zitieren Link zu diesem Kommentar
fu123 10 Geschrieben 26. Oktober 2006 Melden Teilen Geschrieben 26. Oktober 2006 Was mir aufgefallen ist, du hattest keine IP auf dem Vlan. Ohne wird es wahrscheinlich auch gar nicht funktionieren, oder? Du hast bestimmt deswegen kein "join-group" konfigurieren können. Multicast Traffic baut immer auf dem dem darunter liegenden Routing Protokoll auf. Sonst wäre es einfach broadcast. Aber das würde dann auch nicht über Subnetgrenzen hinwegkommen. Das "join-group" simuliert einen Host auf dem Vlan z.B. der einen igmp join request gesendet hat. Daraufhin bekommt er den Multicast Feed. Es sollten nicht alle den bekommen. Das kann eigentlich auch nicht sein. Wie hast du das denn festgestellt? Ich frag mich gerade, ob es daran liegt, das das Vlan keine IP Addresse hat, aber noch der Cisco Doku, sollte immer eine vergeben werden. Dann wäre das eine unübliche Konfiguration. Fu Zitieren Link zu diesem Kommentar
adowoMAC 10 Geschrieben 26. Oktober 2006 Autor Melden Teilen Geschrieben 26. Oktober 2006 Ja du hast Recht. Mit der vergebenen IP klappt es. Habe zwei verschiedene Dokumente von Cisco, in denen es einmal mit und einmal ohne IP gemacht wird. Der einzige Unterschied ist zwischen diesen Verfahren die Version des IOS. Da ich ein sehr neues IOS habe geht es nur mit. Früher konnte der Router/Switch es (scheinbar) auch ohne. Hendrik Zitieren Link zu diesem Kommentar
fu123 10 Geschrieben 27. Oktober 2006 Melden Teilen Geschrieben 27. Oktober 2006 Hi, ok. Das ist dann eventuell etwas wie flooding. Normalerweise verwaltet der Switch selber eine Tabelle mit Multicast Gruppen. Das macht er über "ip igmp snooping", schaut sozusagen in jedes Packet rein und merkt sich die Gruppenzugehörigkeit. Damit er nicht an alle Ports flooded. Snooping lässt sich auch pro Vlan oder insgesamt abschalten "no ip igmp snooping". Dann flooded er auf alle Ports oder man kann statisch mappen, jede Multicast Gruppe als MAC "01-00-5e-..." auf einen Port. Fu Zitieren Link zu diesem Kommentar
adowoMAC 10 Geschrieben 27. Oktober 2006 Autor Melden Teilen Geschrieben 27. Oktober 2006 Jo, also IGMP Snooping läuft nun wirklich gut bei mir. Habe es auch schon mit mehreren VLANs probiert .. das klappt echt gut. In Verbindung mit private-vlans kann man da echt sichere Multicast-Domänen aufbauen. Hendrik Zitieren Link zu diesem Kommentar
daking 10 Geschrieben 27. Oktober 2006 Melden Teilen Geschrieben 27. Oktober 2006 Hallo, dense mode is shit! Ciao Zitieren Link zu diesem Kommentar
fu123 10 Geschrieben 27. Oktober 2006 Melden Teilen Geschrieben 27. Oktober 2006 dense mode is shit! Also so wird es nie was zum Moderator! :) Fu Zitieren Link zu diesem Kommentar
daking 10 Geschrieben 27. Oktober 2006 Melden Teilen Geschrieben 27. Oktober 2006 Hola, na ja könntest du recht haben.. aber ohne umts karte auch nicht (:-). (next week) Vielleicht um noch ein wenig fachlich zu bleiben ein paar LAB Anregungen für die nächsten Steps: Vorraussetzung: Dense mode kann für Router Performance Tests oder (wirklich) kleine MCast Netze verwendet werden. Das Join/Prune verhalten von PIM Sparse Mode erzeugt alle 3 Minuten ein flooding des Multicasttraffics durch das gesamte Netzwerk (von der Sources zu allen Routern). Alle M-Router, die keine Empfänger kennen müssen nun dem ersten Router der die Source lokal kennt sagen, dass hier kein MCAST Traffic nötig ist (Pruning). Bei großen Netzen wird da eine lange Zeit geflooded (Alle 3 Minuten Probleme). Mit IPv6 wird es Dense Mode nicht mehr geben (auch kein aktueller Linux PIM Deamon unterstützt das). Gehen wir nun davon aus, dass das geplante Multicast Netzwerk folgende Eigenschaften haben soll: - kein Flooding = kein Dense + igmp snooping aktiv ==> Sparse Mode - Sparse Mode benötigt einen RP (Rendezvous Point) - falls ein dynamisch gelernter RP ausfällt ==> Sparse Mode - Es sollen redundante RPs existieren. - Die Umschaltzeit soll kleiner 100ms sein! - Nur bestimmter MCAST Gruppen sollen geroutet werden. - Auf Layer 2 nur eindeutige MCAST Gruppen (only 23 Bit) - mit und ohne bidirektionalen PIM --> don't forget the RPF!! Ciao Zitieren Link zu diesem Kommentar
fu123 10 Geschrieben 28. Oktober 2006 Melden Teilen Geschrieben 28. Oktober 2006 Hi daking, vielen Dank für deine Erläuterungen. Er hat aber auch sparse-dense-mode benutzt. Der Modus kann ja nach Bedarf zwischen sparse und dense umschalten. Aber für seinen einen Switch eh nicht so interessant. Dense (=> dicht) für wenige hosts und eine hohe Rate der Verteilung und Sparse (=> spärlich), bei gezielterer Verteilung. Multicast mit Auto-RP kann man auch mit sparse-dense-mode konfigurieren. Eine festlegung des RP ist dann nicht nötig. Mit sparse-mode muss man zumindest ein "ip pim rp listener" konfigurieren. Oder BSR nehmen. Das schwierige im Verständnis ist oft die Aufbau und die Verteilung der Tree's. Im Gegensatz zu Routingprotokollen macht Mcast immer einen RPF (Reverse Path Forward) Check um zu überprüfen, das es den Stream nun auf keinen Fall wieder zum Source zurücksendet. Da wo der Check fehlschlägt und es z.B. nicht eindeutig ob, wenn das Routing einen anderen Weg zurück vorschlägt, als das Packet gekommen ist, kann eine statische mroute notwendig sein. Das ist allerding finde ich oft, recht verwirrend. Also mroute ansehen und schauen ob ein Path zum Source dabei ist. Wobei ja dann auch wieder der RP Soure für Streams ist. Ich versuche z.B. gerade in einem Auto-RP Szenario herauszufinden, warum ein bestimmter Router nix bekommt, obwohl er zu einer Gruppe gehört und auch keinen RPF fehler meldet. Ich sucher gerade noch nach guten Möglichkeiten das richtig debuggen zu können. Fu Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.