Hallo, so habe jetzt auch mal die Liste subscriped ;) Hier auch gleich mal die erste Frage: Wie ist der stand der Dinge? Ich habe hier am Montag bis 3 Uhr morgens mit carsten Otto gesessen und die Firewall vom Kullen für Multicast aufgemacht und xorp intalliert. Leider mußte wir festellen das alle Wohnheime das selbe Problem haben. Der Stream bricht immer nach 4 bis 5 Minuten ab ohne das man auch nur den Hauch einer Meldung im xorp bekommt. Es scheint so als würde der Cisco Router/Switch die Packete nach 4 bis 5 min nicht mehr schicken. Gruß Alexander PS: Die Leute sind hier ganz heiß daraf weil die Kabelqulität in den Wohnheimen so schlecht ist. Per Unicast wird der ansturm kaum zu bewältigen sein. ;) -- Alexander Grümmer Netzwerk-AG Kullenhof
Hier auch gleich mal die erste Frage: Wie ist der stand der Dinge?
Das Problem ist bei allen, die es probiert haben mit xorp das gleiche. Ausnahme ist lediglich das Halifax und zweitweise klappte es auch beim Sammy mal, ohne dass es jedoch reproduzierbar wäre. Wir haben allerdings einen Anhaltspunkt bzw. sogar möglichen Workaround gefunden: Wenn man vom Xorp Router IGMP Reports für die im LAN abonnierten Multicast-Gruppen an den Cisco schickt, öffnet dieser den Port (für die angegebenen Gruppen) wieder. Weitere Fakten: - Wenn der Empfang nicht (mehr) klappt, gehen Streams aber definitiv vom Halifax raus an den Cisco - Der Cisco blockiert auf unseren Ports nicht generell Multicast, sondern speziell die Gruppen. IGMP Reports müssen dann für jede Gruppe geschickt werden, die im LAN geguckt wird. Vermuten könnte man also einen Bug in der Cisco-Software. Soweit ich es recherchiert und verstanden habe hier nochmal die Hintergründe, wie es eigentlich funktionieren sollte: IGMP: Laut Spec dient dieses Protokoll dazu, dass _Clients_ ihrem DR (Designated Router, bei uns der xorp-Rechner) das Abo einer Gruppe mitteilen. Der DR schickt regelmässig Queries raus um festzustellen, ob noch Interesse an der Gruppe besteht. Geantwortet wird darauf mit einem Report. PIM: Darüber verständigen sich die PIM-SM Router untereinander. D.h. xorp schickt regelmässig PIM Join Nachrichten an den Cisco-Router (,welcher ein vollständiger PIM-SM Router ist) und somit sollte der Cisco Multicast Gruppen forwarden, solange regelmässig PIM-Join Nachrichten und kein PIM-Prune eintriffen. Bridged-Wohnheime: Für diese Wohnheime (z.B. Kawo2) ist der Cisco-Wohnheime wahrscheinlich der DR. Ich vermute, dass er hier anhand der IGMP Reports (IGMP Traffic wird vermutlich von Switches und Bridge dort durchgelassen) der Cisco entscheidet, ob er Gruppen forwarded auf diesen Port oder nicht. Das Verhalten ist im Prinzip sowas wie IGMP Snooping. Die Alternative wäre halt, dass der Cisco einfach alle Gruppen durchlässt und dann auf den Switches im Wohnheim mit IGMP Snooping gefiltert wird. Das wäre aber natürlich etwas ineffektiv. PIM-Kommunikation zw. xorp und Cisco: sieht einwandfrei aus IGMP-Kommunikation zw. xorp und Cisco: Der Cisco schickt regelmässig IGMP Queries raus. Xorp (oder eher wahrscheinlich der Linux Kernel selber) antwortet mit IGM Reports für die Gruppen PIM-ROUTERS.MCAST.NET und ALL-ROUTER.MCAST.NET. Das ist insofern richtig, dass der xorp-Rechner _selber_ Kunde dieser Gruppen ist (für die netzinterne Kommunikation). Für die Multicast-Gruppen die im LAN dahinter als Streams abonniert sind generiert xorp keine IGMP Reports, was meiner Meinung nach richtig ist. Fazit: Es könnte sein, dass hier entweder ein Bug in der Cisco-Software vorhanden ist oder es von Cisco gewollt ist insofern, dass sie zur Kommunikation zwischen Cisco PIM-enabled Routern explizit auch IGMP Nachrichten benutzen für alle abonnierten Gruppen. Vielleicht auch ein Bug, weil wir (wie oben beschrieben) den Cisco "gemischt" betreiben: Für die Bridged Wohnheime ist er DR, für die xorp Wohnheime hängt aber der DR dahinter. (*) Unklar ist, warum es im Halifax klappt, denn dort sieht die IGMP Kommunikation zwischen Router und Cisco genauso aus wie bei uns. Denkbar ist ein Seiteneffekt durch den Betrieb des RP im Halifax. Möglich ist aber auch, dass ich hier ganz an der falschen Stelle grabe und das alles nur Zufälle sind :) Vorschlag: Mit Cisco mal abklären, welches bzgl. der IGMP Kommunikation das von ihnen erwartete Verhalten ist. (* siehe oben) Dieses Setup sollte man dabei vielleicht auch mal gegenüber Cisco erwähnen. (In Ihrer Doku steht allerdings auch, dass über IGMP _Clients_ mit dem Router kommunizeren. IGMP für PIM-Router to PIM-Router Kommunikation wird dort nicht angesprochen. Es wäre ja auch "doppelt gemoppelt". Die PIM-Joins reichen ja als Information.) Gruß, Daniel
Daniel Sievers wrote:
Wir haben allerdings einen Anhaltspunkt bzw. sogar möglichen Workaround gefunden:
Es scheint aber, dass sich hier ein Workaround nicht besonders leicht realisieren lässt. Das Problem ist, dass die IGMP Reports das LAN nicht verlassen (sollen), weil - sie eine TTL von 1 haben - es keine explizite Route gibt (Zieladresse der Reports ist die Multicast Gruppenadresse). Xorp forwarded sie glaube ich auch mit einer höheren TTL nicht. Eine Route selber einzutragen verträgt sich evtl. mit xorp nicht. Es müsste dann auch eine source-based Route (dafür braucht man iproute2 und "tc") sein, denn eine einfache Route, mit der man Multicast-Gruppen auf das externe Interface schickt, würde natürlich der Idee widersprechen, dass man auch Streams von aussen nach innen empfängt :) Desweiteren habe ich ohne Erfolg mit dem ROUTE netfilter Patch gespielt (buggy, kaputt?). Die xorp IGMP Abo-Status Infos auszulesen geht auch nicht so ohne weiteres. (xorpsh lässt sich nicht von der Kommandozeile zur Ausgabe der gewünschten Infos bringen) Sonst hätte man das regelmässig machen und dann IGMP Reports generieren können. Am xorp Code selber rumbasteln hab ich jetzt nicht soo Lust :) Vielleicht gibt es andere Ideen?
@Jens: Bzgl. PIM to PIM Kommunikation ist mir grad doch noch eine Sache aufgefallen, wo Du mal reinschaun könntest: Xorp schickt seine PIM-Join Nachrichten an 224.0.0.13 (PIM-ROUTERS.MCAST.NET) was sich von Namen her auch korrekt anhört. Kann man sich da vielleicht irgendwie anzeigen lassen (debug?), dass er die auch korrekt behandelt? Vielleicht ist er ja nicht in der Gruppe....
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Sievers wrote:
@Jens:
Bzgl. PIM to PIM Kommunikation ist mir grad doch noch eine Sache aufgefallen, wo Du mal reinschaun könntest:
Xorp schickt seine PIM-Join Nachrichten an 224.0.0.13 (PIM-ROUTERS.MCAST.NET) was sich von Namen her auch korrekt anhört.
Kann man sich da vielleicht irgendwie anzeigen lassen (debug?), dass er die auch korrekt behandelt? Vielleicht ist er ja nicht in der Gruppe....
Ist was schwierig, ich habe keinen Snifferport dort. Mir fällt aber was anderes auf: Wenn ich nur Cisco's im Spiel habe, sieht meine PIM Neighbour Table so aus (Beispiel: Informatik): c6k-as55>sho ip pim neighb PIM Neighbor Table Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 137.226.139.41 Vlan117 04:22:40/00:01:16 v2 1 / S 137.226.35.66 Vlan564 7w0d/00:01:36 v2 1 / DR S 137.226.34.210 Vlan562 7w0d/00:01:41 v2 1 / DR S Auf c3750-sw23-wohnheime mit Euren Xorps siehts anders aus: c3750-sw23-wohnheime>sho ip pim neighb PIM Neighbor Table Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 137.226.119.114 Vlan639 1d14h/00:01:24 v2 1 / DR 137.226.37.178 Vlan732 18:06:01/00:01:40 v2 1 / DR 137.226.39.129 Vlan849 4d19h/00:01:37 v2 1 / S Eure Geräte haben kein "S" gesetzt. "S" steht für: "state refresh capable" Klingt ziemlich nach dem Problem. - -- 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 iQEVAwUBQ5bgTBsVN+J7zzuXAQI7WQgAjC3twsCFZIXlduPi9cXOyvuFXZ6ff48I jOyvZYcpCPig9drw3OkwpFEdQGRtdMHIR2Sxp3z99mzMjB6mFWlrAvY/xHeVuBTm Ggj18Zd7GCZuOvSEvW1MOzKajKkiXBHJK0Ouj7eFBvctSSqJqAv+Z86iUNnjVN/w lo5kdSJGk4zQHmkJrnXrsEm3/dXmveUaHgcx/fdqWvMVBiWi7e6tmtZQGupJfPLd HnovypKptHKtCo10Ivlzw/LhYOGLT1Ksb51zeBpPeX+mFMVZgT3jbqD8TxSLLiyV 5ql6Eldzv6l9lS5vlh2JeQMq3O0Ab+BhcwdfWBpAMYhJ3jXkLN9/Vg== =6zrz -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jens Hektor wrote:
Daniel Sievers wrote:
Kann man sich da vielleicht irgendwie anzeigen lassen (debug?), dass er die auch korrekt behandelt? Vielleicht ist er ja nicht in der Gruppe....
Ist was schwierig, ich habe keinen Snifferport dort.
Die einzigen Joins/Prunes die ich im Backbone sehe, kommen aus dem Halifax. - -- 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 iQEVAwUBQ5bniRsVN+J7zzuXAQLaDQf/RodTa74r2DwtRkdjzOiffYmn/J5In5GZ KRRM7gsCzD+IMGt1qmPFNECC4wbsFspDy/J9SupvzseCRhGSdqY2tTp+I93nAxgu uYa96pkHe6A3Mv5o80q4n9eHyVspAaT/AKXfnPg8LHJwduJiUDPdL3RjczdPBGX3 7J/7ayjcAFSFBatL5rES3eeCvdX5f+pITp8vSFNXtqptBJZSxjbfQUkCUzgbpvPW Xrly1bYa1W4n2GZeBFGdtFVB6X0938PL989YNx98+nB3Zx1ZWN3mr5V2HEyRyVAU EX1vvz33iIHbzjY4EiKDhk5ySW17iBxbaQqevQek5VimLWzfqfU4nw== =El5S -----END PGP SIGNATURE-----
On Wed, Dec 07, 2005 at 02:14:52PM +0100, Jens Hektor wrote:
Eure Geräte haben kein "S" gesetzt. "S" steht für: "state refresh capable"
http://www.cisco.com/warp/public/105/57.html S - State refresh capable (applies only for dense mode) XORP kann nur PIM-SM... -- Carsten Otto c-otto@gmx.de www.c-otto.de
On Wed, Dec 07, 2005 at 03:04:02PM +0100, Carsten Otto wrote:
S - State refresh capable (applies only for dense mode) XORP kann nur PIM-SM...
carsten_@ip1-254.halifax.RWTH-Aachen.DE> show pim neighbors Interface DRpriority NeighborAddr V Mode Holdtime Timeout eth1 1 137.226.119.113 2 Sparse 105 86 Der Wohnheimsrouter wird also mit PIM-SM erkannt, das ist OK denke ich. -- Carsten Otto c-otto@gmx.de www.c-otto.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carsten Otto wrote:
On Wed, Dec 07, 2005 at 03:04:02PM +0100, Carsten Otto wrote:
S - State refresh capable (applies only for dense mode) XORP kann nur PIM-SM...
OK, cisco kennt einen "sparse-dense-mode" (wasimmerdasis), der auch immer empfohlen wird. Ich habe jetzt mal explizit auf "sparse-mode" geschaltet.
carsten_@ip1-254.halifax.RWTH-Aachen.DE> show pim neighbors Interface DRpriority NeighborAddr V Mode Holdtime Timeout eth1 1 137.226.119.113 2 Sparse 105 86
Der Wohnheimsrouter wird also mit PIM-SM erkannt, das ist OK denke ich.
Sollte ok sein. - -- 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 iQEVAwUBQ5bwQhsVN+J7zzuXAQJYwQf/dRHTE9Lv07Trl9ej4ZQINeN3XwhPmz2C yoDJd1wRHiU9cubrN07CWFErK9w80YuA9f/lOz0T4ANjI5lNTSt7FHRHgj5riYVu rWLLyP4h3MenB7n64ZCVyXb0XPv2mjCpVWC4CQbEtAtym0YhoU35DBeoksPwo4BA j+BDNTI5XNzEscpERnkZz8CkR/ccG7r/GwXwG0oN93JpXNXh7ux1uRBiTuv9L498 OldBeq2Ysbd90g1YussplojgN06BtCQ9ToHzvEDGMH9FDi5tkFSULwFzxD3a1ie4 wKMjPWwUJHY8DaFHGJAY+xpWjee3HZOUmFjDOIQP5hpYpg6pETByfA== =v9Bh -----END PGP SIGNATURE-----
Wenn ich nur Cisco's im Spiel habe, sieht meine PIM Neighbour Table so aus (Beispiel: Informatik):
Vorschlag um die IGMP Theorie mit einem Schlag zu bekräftigen oder zu entkräftigen: Dazu müsste allerdings jmd. in der Informatik oder so einen Stream abonnieren aus dem Halifax.
show ip igmp groups und nach der abonnierten Multicast-Gruppe suchen, die der Client schaut.
Der zeigt per IGMP abonnierte Gruppen an und auch von wem die reported wurden (LastReporter!). Das dürfte sehr hilfreich sein. Man kann dann sofort sehen ob ein Cisco dem andern Cisco per IGMP Gruppenmitgliedschaft mitteilt.
On Wed, Dec 07, 2005 at 12:13:27PM +0100, Daniel Sievers wrote:
IGMP: Laut Spec dient dieses Protokoll dazu, dass _Clients_ ihrem DR PIM: Darüber verständigen sich die PIM-SM Router untereinander. D.h.
Richtig - denke ich.
Bridged-Wohnheime: Für diese Wohnheime (z.B. Kawo2) ist der Cisco-Wohnheime wahrscheinlich der DR. Ich vermute, dass er hier anhand der IGMP Reports (IGMP Traffic wird vermutlich von Switches und Bridge dort durchgelassen) der Cisco entscheidet, ob er Gruppen forwarded auf diesen Port oder nicht. Das Verhalten ist im Prinzip sowas wie IGMP Snooping. Die Alternative wäre halt, dass der Cisco einfach alle Gruppen durchlässt und dann auf den Switches im Wohnheim mit IGMP Snooping gefiltert wird. Das wäre aber natürlich etwas ineffektiv.
Und mit bald >500 MBit auch nicht wirklich elegant.
IGMP-Kommunikation zw. xorp und Cisco: Der Cisco schickt regelmässig IGMP Queries raus. Xorp (oder eher wahrscheinlich der Linux Kernel selber) antwortet mit IGM Reports für die Gruppen PIM-ROUTERS.MCAST.NET und ALL-ROUTER.MCAST.NET. Das ist insofern richtig, dass der xorp-Rechner _selber_ Kunde dieser Gruppen ist (für die netzinterne Kommunikation). Für die Multicast-Gruppen die im LAN dahinter als Streams abonniert sind generiert xorp keine IGMP Reports, was meiner Meinung nach richtig ist.
Ist auch hier so.
Fazit: Es könnte sein, dass hier entweder ein Bug in der Cisco-Software vorhanden ist oder es von Cisco gewollt ist insofern, dass sie zur Kommunikation zwischen Cisco PIM-enabled Routern explizit auch IGMP Nachrichten benutzen für alle abonnierten Gruppen.
Ist hier nicht nötig...
Vielleicht auch ein Bug, weil wir (wie oben beschrieben) den Cisco "gemischt" betreiben: Für die Bridged Wohnheime ist er DR, für die xorp Wohnheime hängt aber der DR dahinter. (*)
Wer die Protokolle sauber umsetzt, sollte damit kein Problem haben.
Unklar ist, warum es im Halifax klappt, denn dort sieht die IGMP Kommunikation zwischen Router und Cisco genauso aus wie bei uns. Denkbar ist ein Seiteneffekt durch den Betrieb des RP im Halifax.
Das haben wir getestet (oder war das im Kullen?). Eventuell hilft es, nicht nur RP zu sein, sondern auch Daten an diese Gruppe zu senden (VLC kann das).
Möglich ist aber auch, dass ich hier ganz an der falschen Stelle grabe und das alles nur Zufälle sind :)
Die Wahrscheinlichkeit ist nicht gering...
Mit Cisco mal abklären, welches bzgl. der IGMP Kommunikation das von ihnen erwartete Verhalten ist. (* siehe oben) Dieses Setup sollte man dabei vielleicht auch mal gegenüber Cisco erwähnen.
Vernünftig.
(In Ihrer Doku steht allerdings auch, dass über IGMP _Clients_ mit dem Router kommunizeren. IGMP für PIM-Router to PIM-Router Kommunikation wird dort nicht angesprochen. Es wäre ja auch "doppelt gemoppelt". Die PIM-Joins reichen ja als Information.)
Doku != Gerät :) -- Carsten Otto c-otto@gmx.de www.c-otto.de
Halo zusammen, Daniel Sievers wrote:
Für die Multicast-Gruppen die im LAN dahinter als Streams abonniert sind generiert xorp keine IGMP Reports, was meiner Meinung nach richtig ist.
(In Ihrer Doku steht allerdings auch, dass über IGMP _Clients_ mit dem Router kommunizeren. IGMP für PIM-Router to PIM-Router Kommunikation wird dort nicht angesprochen. Es wäre ja auch "doppelt gemoppelt". Die PIM-Joins reichen ja als Information.)
Für mich ist das unvereinbar damit das Switche zwischen den PIM-Routern IGMP einsetzten. Ich weiß ja nicht wie euere Anbindung an den Wohnheimsrouter ist. Aber ich hab keine Ahnung wie der Türmeswitch die PIM-joins oder die abonierten Gruppen verteilen soll ? (Außer IGMP abschalten und Brodcasten) Jens Hektor wrote:
Wäre es nicht auf dauer sinvoll ein Gerät zwischen den Türmen zu haben, welches PIM beherrscht ?
Das das Ding nicht routet, braucht es kein dort kein PIM. Das müssen die routenden Firewalls der Türme und Konsorten erledigen.
Kann niemand so eine anständige Doku mit grundlegensten Infos empfehlen ? Schönen Gruß Sebastian
Für mich ist das unvereinbar damit das Switche zwischen den PIM-Routern IGMP einsetzten. Ich weiß ja nicht wie euere Anbindung an den Wohnheimsrouter ist. Aber ich hab keine Ahnung wie der Türmeswitch die PIM-joins oder die abonierten Gruppen verteilen soll ? (Außer IGMP abschalten und Brodcasten)
Guter Einwand. Müsste sich dann ja jeder PIM-Router intelligent drum kümmern und evtl. IGMP sprechen zu seinen Nachbarn. Habe die Frage mit diesem Beispiel mal an den Entwickler von xorp weitergeleitet (Pavel).
So habe nach langem Suchen nun auch ein evtl. passendes Dokument bei Cisco gefunden :) @Jens: "Catalyst 3750 12.2(25) SED", passt das irgendwie halbwegs? http://www.cisco.com/en/US/products/hw/switches/ps5023/products_configuratio... Zwischen Multicast-Routern wird kein IGMP gesprochen. IGMP Snooping beinhaltet automatisch PIM-Snooping. Es gibt 2 Snooping Modes: ip igmp snooping vlan vlan-id mrouter learn {cgmp | pim-dvmrp} •cgmp—Listen for CGMP packets. This method is useful for reducing control traffic. •pim-dvmrp—Snoop on IGMP queries and PIM-DVMRP packets. This is the default. <- Das haben wir nehme ich an Unsere xorp Router-Ports müssten dann das aktiviert haben: ip igmp snooping vlan <vlan-id> mrouter interface <interface-id> --------- Was mich aber nun stört ist, dass anscheinend der Cisco bei uns auch _Querier_ spielt auf unserem VLAN Port, weil "•When administratively enabled, the IGMP snooping querier moves to the nonquerier state if it detects the presence of a multicast router in the network. •When it is administratively enabled, the IGMP snooping querier moves to the operationally disabled state under these conditions: –IGMP snooping is disabled in the VLAN. –PIM is enabled on the SVI of the corresponding VLAN." @Jens: was sagt "show ip igmp snooping vlan 641"?
@Jens: Was sagt "show mvr"? D.h. ist Multicast VLAN Registration (MVR) aktiviert? Das könnte Probleme machen mit dem xorp.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Sievers wrote:
@Jens: Was sagt "show mvr"? D.h. ist Multicast VLAN Registration (MVR) aktiviert?
Disabled. - -- 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 iQEVAwUBQ5cBKxsVN+J7zzuXAQI65Af/frc+2SToJZnQ9TQtAnOaWx0prlOUVHuL SIiQkRSd1kNuNHqHsEIoSg3yx/wKD264Rerb3pydNpytUSZi83zBDpIdstlGx358 I4iU8tAfOfsQ/zH341WIG0VmU62NKtF8cuVkxE1N06f9HJZrxSq2Wk7JwxQm/gf1 ZjbSMIaFSBF+AgFTcvtV6EtekIJKjLkFhcNhlOvRqj2ZGtQTCF0Gsf/YHNIpkAqc dbcQB0gIxpiL+W7tdf2bqekVNurNzIbvAMo6Qjkuqgh8UVSVcyvYHNeTOhTehkAo F/k5sJe9ZPtVFzNdG+AkqltL5382s+kFJ1FNb0vuzS/3VrYCFOS5Mw== =InAH -----END PGP SIGNATURE-----
ok ein allerletzter Versuch, dann geb ichs auf und beschliesse dass es nen Cisco Bug ist :) no ip igmp snooping vlan 641 explicit-tracking (aber eigentlich sollte das eh nur für igmpv3 relevant sein) show ip igmp snooping vlan 641 mrouter interface <interface-id> das ist enabled nehme ich an?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel Sievers wrote:
@Jens: "Catalyst 3750 12.2(25) SED", passt das irgendwie halbwegs?
Perfekt.
•pim-dvmrp—Snoop on IGMP queries and PIM-DVMRP packets. This is the default. <- Das haben wir nehme ich an
Stimmt.
@Jens: was sagt "show ip igmp snooping vlan 641"?
c3750-sw23-wohnheime>show ip igmp snooping vlan 641 Global IGMP Snooping configuration: - ----------------------------------- IGMP snooping : Enabled IGMPv3 snooping (minimal) : Enabled Report suppression : Enabled TCN solicit query : Disabled TCN flood query count : 2 Last Member Query Interval : 1000 Vlan 641: - -------- IGMP snooping : Enabled IGMPv2 immediate leave : Disabled Explicit host tracking : Enabled Multicast router learning mode : pim-dvmrp Last Member Query Interval : 1000 CGMP interoperability mode : IGMP_ONLY - -- 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 iQEVAwUBQ5cAjRsVN+J7zzuXAQIFqwf+N6hB6FXPcwWbet1AdF3PXWiJvbv2TjF2 Wo2+efpKE3FSwRjfQUQvADYEFpJ+slHVUlEnAnz9wKGHrbYW5L2P/5ZQEgDAxMRV qCBRgTd6WmgsCAWDGh45Pij3cbESKuzt5ImDNz56gKFjgTa1sRyvLlOnm7Myd4kW 5WkUM3Mw6N7ktEsw1lFPydaSRsEdra64rg2xibpAL5ziA39OkRiPnZ+Ybx8JALGx EjoQ2uCKadJtBhDCfCcPy4zFtIwfLVRN6YofFsAQy8aWec4P/3gcn/pAWk239I4r fxa4+uwpPIOS36109kOA6bncPYHfnhoGYsb8C/odWmu9z6x/pT1rQw== =h9cQ -----END PGP SIGNATURE-----
Nach wie vor verstehe ich aber nicht wieso der Cisco uns dann queried. Man könnte auch mal "no ip igmp snooping querier" explizit probieren Es kann sein, dass es dann aber für die bridged Wohnheime nicht mehr geht. Die müssten dann u.U. einen ihrer LAN Switches zum Querier machen.
"•When administratively enabled, the IGMP snooping querier moves to the nonquerier state if it detects the presence of a multicast router in the network.
•When it is administratively enabled, the IGMP snooping querier moves to the operationally disabled state under these conditions:
–IGMP snooping is disabled in the VLAN.
–PIM is enabled on the SVI of the corresponding VLAN."
Daniel Sievers schrieb am Wednesday, 7. December 2005 16:54:
Nach wie vor verstehe ich aber nicht wieso der Cisco uns dann queried.
Man könnte auch mal "no ip igmp snooping querier" explizit probieren
Es kann sein, dass es dann aber für die bridged Wohnheime nicht mehr geht. Die müssten dann u.U. einen ihrer LAN Switches zum Querier machen.
Der Lan Switch sollte wenn er richtiges igmp spricht automatisch zum Querier werden, sobald der cisco wohnheime es fuer das Subnetz nicht sein will. Prinzipiell will jeder Switch der kann Querier sein. Aber wenn ein Switch einen ip niedrigeren Switch hoert, der Querier sein will, so hoert der ip höhere auf Querier zu sein und gibt dem ip nidrigeren Vorrang. Gruesse Sammy
participants (6)
-
Alexander Grümmer -
Carsten Otto -
Daniel Sievers -
Jens Hektor -
Sami Okasha -
Sebastian Hoogen