From: Andrew Lissitz \(alissitz\) (alissitz@cisco.com)
Date: Sun Oct 16 2005 - 09:51:44 GMT-3
Hey All,
As Scott mentioned, the global command ip pim autorp listener was
created to allow an interface to operate in sparse mode only and still
receive dense mode groups .40 and .39 used for auto rp.
The pim commands configured on an interface, tells the interface how pim
should behave on an interface. If you have configured sparse mode only
for the interface, then this interface will do just that. It will not
flood auto rp throughout the network. Use the global command ip pim
autorp listener to over ride this for auto rp only.
As mentioned earlier in this email string, finding and registering with
the RP is required for sparse more. If your router can not find a RP,
then it will fall back to dense mode. If the interface is configured
for sparse-mode only, then it will not be able to send dense mode
traffic out of the interface.
A question for the group: in your networks, would you rather have
multicast traffic fail due to sparse mode only operation, or fall back
to dense mode when it needs to? Personally I would rather have
multicast completely fail and then attempt to fix the problem, however I
am not currently working for a financial or other company that uses
heavily multicast.
As with Scott, I have not see a router automatically try and join a
group... what group should it try to join, how would it know what
groups?
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Sunday, October 16, 2005 8:19 AM
To: 'simon hart'; Andrew Lissitz (alissitz); 'Jian Gu'; 'Ashok M A'
Cc: ccielab@groupstudy.com; 'C&S GroupStudy'
Subject: RE: IGMP join & PIM join
Actually that's not the case...
If you look at some of the detail in the messages that are going out,
you'll find that whenever you implement PIM on an interface, it sends
out PIM messages to discover any other PIM neighbors on that interface.
You'll do things like figure out who the PIM DR is for that interface.
It will send out IGMP messages to do the same thing, figure out who is
going to be in charge and be the querier. But I haven't ever seen it
use IGMP to try to join these groups unless you issue an "igmp
join-group" command on an interface. A router with "ip
multicast-routing" enabled is inherently able to do IGMP on multiaccess
interfaces, this doesn't mean it sends out an igmp join message though!
In dense mode (which is how AutoRP works by default) there is no joining
or leaving (granted, IGMP is a separate process), but internally on a
non-MA and non-RP, you won't even see the groups present in anything
until traffic
is seen being flooded around via dense mechanisms. Then you'll see
these
groups in the mroute cache. Up until that time, the router is
pleasantly ignorant and just sits there. No igmp joins for those
groups, no nothing.
The autorp listener is done to prevent future networking disasters.
Everyone agrees that dense mode kinda sucks. The problem with pim
sparse-dense is that it says we TRY to use sparse, but if we don't know
of an RP, can't reach it, or don't get a good answer then dense is fine.
So if we have any multicast traffic going on either before we know of
the RP or if the RP doesn't respond in a timely fashion, the PIM router
thinks dense mode is cool for ANY group. So we would have the potential
for many other dense groups working on the network than we may intend,
and there's no other way to filter.
So autorp listener was created so that we could put the routers in
sparse mode only, where if an RP isn't available then NOTHING goes
(viewed as a cleaner solution than flooding). Yet, the listener command
will override this for ONLY the AutoRP groups. That still puts a non-MA
and non-RP router into a listening mode though, where if any discovery
packets or announcements aren't forthcoming, there's no igmp joining
going on. At least that's the packet traces I've conducted in 12.2
devices.
I can't think of a good reason why that would change. *shrug*
HTH,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
simon hart
Sent: Sunday, October 16, 2005 4:02 AM
To: Andrew Lissitz (alissitz); Jian Gu; Ashok M A
Cc: ccielab@groupstudy.com; C&S GroupStudy
Subject: RE: IGMP join & PIM join
Hi all,
I think everyone has done an eloquent job in explaining the difference
between IGMP and PIM Joins, however I do not believe that this goes to
the heart of Ashok's question.
When a router's interface is enabled for either pim sparse or pim
sparse-dense mode (not sure about dense will have to lab it up). Then
that interface will immediately send out igmp joins to any listening
multicast router on that subnet, as well as sending out pim hello's.
Why does it send out IGMP joins. Well the router is in sparse mode and
therefore needs to know how to get to the Rendevouz point. The only way
it knows how to do this is to join the discovery and announcement groups
of 224.0.1.40 and 224.0.1.39, thus it will send out an IGMP join.
The router that recieves this IGMP join from its PIM neighbor will send
a PIM Join to the Rendevouz point so that the initiating router can
join the group.
Remember that if the router is not next to the discovery agent, then
everything breaks in sparse mode as the initiating router does not know
how to get to the RP - this is the catch 22 that pim sparse-dense mode
is trying to overcome as is autorp listener
Hope that helps
Simon
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Andrew Lissitz (alissitz)
Sent: 16 October 2005 05:11
To: Jian Gu; Ashok M A
Cc: ccielab@groupstudy.com; C&S GroupStudy
Subject: RE: IGMP join & PIM join
Hey Group,
Jian says it well, igmp join messages are spoken by hosts. PIM messages
are sent by the PIM protocol (I know that sounds simple ...) which is
typically run only by routers. PIM is a control plane protocol used by
routers to set up and control multicast traffic.
When you configure an interface for multicast, you must configure the
PIM protocol. This command enables the protocol on the interface as
well as tells PIM how to behave on that interface; sparse, sparse-dense,
and dense mode. PIM is not smart enough to know how to behave, you are
telling it to try and operate as configured. Notice I said try ... If
you configured sparse-dense mode, but your router can not find the RP
... What will happen?
It certainly will not be sparse mode, but will fall back to dense mode
...
Zzzis not good.
When a router receives a igmp join message on it's interface, it then
knows that it has a receiver requesting traffic for a group. What does
it do now with this knowledge? Well in the case of sparse mode, it
needs to tell the RP that it is interested in receiving traffic for this
group. It will do this by using the PIM protocol. In the case of dense
mode, it will be sure that it will NOT send a prune messages for the
requested group.
Ashok, I am not sure I answered your question. Are you also thinking of
config options, such as igmp join-group?
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Jian Gu
Sent: Saturday, October 15, 2005 3:18 PM
To: Ashok M A
Cc: ccielab@groupstudy.com
Subject: Re: IGMP join & PIM join
They are very different, IGMP joins are from end host to last hop
router, when last hop router receives a IGMP join, it will initiate a
PIM join upstream to RP and create (*,G) entry locally, PIM joins are
between routers.
On 10/14/05, Ashok M A <ashok_ccie@yahoo.co.in> wrote:
>
> Hi GS,
>
> This might be silly question; but i can't explanin this well.
>
> What is the differnece between IGMP join and PIM join messages?
>
> Confusion arises as IGMP will be automatically enabled by configuring
> PIM sparse or dense or sparse-dense mode over an interface.
>
> TIA,
> Ashok
>
>
>
>
> __________________________________________________________
> Yahoo! India Matrimony: Find your partner now. Go to
> http://yahoo.shaadi.com
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:51 GMT-3