From: Andrew Lissitz \(alissitz\) (alissitz@cisco.com)
Date: Sun Oct 16 2005 - 17:04:17 GMT-3
So Chris, you have proven that even without sparse-dense mode
configured, these dense mode groups were flooded ... hummm ... the
autorp information was sent out of an interface that was not configured
to forward dense mode groups.
Lets step back a second here ...
For autorp, the mapping agent and RP need to be configured first. Every
other router automatically joins the discovery group 224.0.1.40 after
you configure any interface for pim. The routers will now listen to the
discovery group hoping to hear about a RP.
This is why your entire lab can learn about the RP after you configure
the RP to announce itself, and you have a mapping agent. Configure your
other routers for multicast and pim and watch them learn... Sparse mode
is much easier knowing a few of these rules.
In your lab Chris, you configured the RP and mapping agent on the same
router and then autorp did it's thing... it began to tell other routers.
As mentioned everything router will automatically list a *, 224.0.1.40
membership.
If a router sent this info out an interface without being configured to
... (autorp listener or sparse-dense mode) ... then ... do we have a
bug? I am not sure either... I will look into it and get back to you
all sometime this week.
Chris, can you provide version and show mroute ( mroute for curiosity)
info?
For those on this mailing list... please do not count on this behavior
and of course ... ask the proctor if you are given a question that seems
to be incomplete / incorrect.
Thanks all, and have a wonderful week ... tomorrow is Monday ... (sorry
for telling you)
________________________________
From: Chris Lewis [mailto:chrlewiscsco@yahoo.com]
Sent: Sunday, October 16, 2005 3:19 PM
To: swm@emanon.com; 'simon hart'; Andrew Lissitz (alissitz); 'Jian Gu';
'Ashok M A'
Cc: ccielab@groupstudy.com; 'C&S GroupStudy'
Subject: RE: IGMP join & PIM join
I don't think I said any random joins would happen :)
The debug clearly shows that enabling sparse mode on the interface will
make that interface send an IGMP report. Issuing a sho ip igmp group
224.0.1.40 on the sparse enabled routers shows the local interface has
joined.
I think it quite within the realms of proctor thinking that they could
ask for a router to obtain an RP address via auto-rp and forbid the use
of auto-rp listener and sparse-dense as described. It tests your
knowledge of what happens on a sparse enabled interface for both PIM and
IGMP.
Just my opinion
Chris
Scott Morris <swm@emanon.com> wrote:
So you have used R3 to send out reports of "Hey, I have this
multicast group". And R1 receives the initial report and even though it
has no dense-mode information, it's still a Cisco router and knows that
it likes that group. So it may get information in RESPONSE to the MA.
But left to its own devices it won't go randomly joining things.
I'm hoping that a lab won't get so anal into the intracacies of
IGMP group messaging (and what happens if a Cat becomes the querier?)
that it would make a difference. Go to R1, and if the theory is
correct, you should see that 224.0.1.40 has actually been joined via
igmp. (sh ip igmp group)
Scott
________________________________
From: Chris Lewis [mailto:chrlewiscsco@yahoo.com]
Sent: Sunday, October 16, 2005 11:16 AM
To: Scott Morris; 'simon hart'; 'Andrew Lissitz (alissitz)';
'Jian Gu'; 'Ashok M A'
Cc: ccielab@groupstudy.com; 'C&S GroupStudy'
Subject: RE: IGMP join & PIM join
Actually....I believe it is.....:)
Every multicast router has an interface that joins the group
224.0.1.40 and sends out an IGMP report as a host would, because it is a
host receiver for discovery packets.
Consider this simple setup
R1-S3/0----S1/0-R3-S3/0-------S2/0-R2
I am going to set this up in a weird way to illustrate a point.
The interfaces between R3 and R2 are set as dense only.
The interfaces between R1 and R3 are sparse only.
R2 is going to end up as the RP
There is no sparse-dense and no autorp listener configured.
I now configure the following on R2
ip pim send-rp-announce Loopback0 scope 15
ip pim send-rp-discovery Loopback0 scope 15
So, with no dense mode capability between R3 and R1, no autorp
listener and no static configuration, will R1 learn about the RP? This
is what R1 tells me
Router1#sho ip pim rp mapp
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 192.168.2.2 (?), v2v1
Info source: 192.168.2.2 (?), elected via Auto-RP
Uptime: 00:02:13, expires: 00:02:48
The loopback of R2 is 192.168.2.2, so it does learn over a
sparse only mode interface about the RP. Why is this? Well some debugs
of IGMP show what is happening.
R3
*Oct 16 14:38:38.203: IGMP(0): Send v2 Report for 224.0.1.40 on
Serial1/0
R1
*Oct 16 14:38:37.923: IGMP(0): Send v2 Report for 224.0.1.40 on
Serial3/0
R1 and R3 are sending out reports for 224.0.1.40 on their
sparse-enabled interfaces, there are no ip igmp join statements
anywhere. So R1 sends a report, R3 uses dense to learn about R2 as the
RP.
So imagine a CCIE scenario, no sparse-dense allowed, no autorp
listener allowed, and a router that needs to learn about the RP is no
directly connected to the RP, but auto-RP is required. You can use this
behavior to have a router generate an IGMP report over sparse, and other
routers use dense mode only to get to the RP.
These are the relevant config bits for anyone that wants to lab
this themselves, just add a unicast routing protocol of choice.
R1
!
ip multicast-routing
!
interface Serial3/0
ip address 172.16.31.1 255.255.255.252
ip pim sparse-mode
R3
!
ip multicast-routing
!
interface Serial1/0
ip address 172.16.31.2 255.255.255.252
ip pim sparse-mode
!
interface Serial3/0
ip address 172.16.32.3 255.255.255.0
ip pim dense-mode
R2
!
ip multicast-routing
!
interface Loopback0
ip address 192.168.2.2 255.255.255.0
ip pim sparse-mode
!
interface Serial2/0
ip address 172.16.32.2 255.255.255.0
ip pim dense-mode
!
ip pim send-rp-announce Loopback0 scope 15
ip pim send-rp-discovery Loopback0 scope 15
Chris
Scott Morris <swm@emanon.com> wrote:
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 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
>
>
>
>
>
This archive was generated by hypermail 2.1.4 : Sun Nov 06 2005 - 22:00:51 GMT-3