Jump to content

Multicast auf Cisco 3750


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

Link zu diesem Kommentar
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

Link zu diesem Kommentar
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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...