From: Scott Vermillion (scott_ccie_list@it-ag.com)
Date: Wed Nov 07 2007 - 15:40:05 ART
Hey William,
Yeah, I actually do recall running into that sort of issue when making my
way through the mcast section of IEWB#1. At the time, I just kept reissuing
the command on the switch (I never had the labs up for any amount of time
anyway). Then, coincidentally, I tried to use this command in a similar
fashion to how it's used in the workbook in a real-world scenario and got
unexpected results. I'm not entirely clear that IE is using it correctly.
One option to try is the 'ip igmp static-group' command on the router (R6)
attaching to SW2 instead. If you needed to ping the router interface at the
mcast address (I don't recall that being a requirement), you could
alternatively do the 'ip igmp join-group' command on the router vs. the
switch. If I've got it all straight in my head now, either one will force
the router to pass the traffic on to SW2. The latter option will cause IOS
to process the traffic in addition to forwarding it, which allows for the
ping reply. Here's the snippet from the DocCD Command Ref on the
static-group command:
"When you configure the ip igmp static-group command, packets to the group
are fast-switched out the interface, provided that packets were received on
the correct reverse path forwarding (RPF) interface.
Configuring the ip igmp static-group command is unlike configuring the ip
igmp join-group command, which allows the router to join the multicast
group. This configuration of the ip igmp static-group command would cause
the upstream routers to maintain the multicast routing table information for
that group, which would ensure that all the paths to that multicast group
are active.
If you configure the ip igmp join-group command for the same group address
as the ip igmp static-group command, the ip igmp join-group command takes
precedence, and the group behaves like a locally joined group."
Give that a try and let us know if it gives a more predictable result. My
real-world scenario is no longer active and I used a different work-around
than this on the fly, so I can't vouch for it 100%, but it reads as being
pretty straight-forward...
Regards,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Murphy, William
Sent: Wednesday, November 07, 2007 9:05 AM
To: ccielab@groupstudy.com
Subject: Catalyst IGMP Reports Not Being Sent?
I was working on the IEWB-RS-VOL1-Multicast PIM NMBA example last night
and noticed that the SW2 was only sending an IGMP report when the igmp
join-group command was issued, so the group would get pruned back after
a few minutes. It appears that since the switch has a routed interface
that is doing the join and it also has L2 interfaces that are used to
connect other routers that are also doing multicast, things get a little
confused. The show igmp snooping mrouter command showed that SW2
thought the multicast router was on a port other than the routed
interface where I did the join. I disabled igmp snooping thinking this
would solve the problem but it didn't. Has anybody come across this
issue and if so how did you solve it? PIM NMBA mode worked fine and I
learned a lot from the lab but the group (232.1.1.1) would not stay up
indefinitely... Thanks...
This archive was generated by hypermail 2.1.4 : Sat Dec 01 2007 - 06:37:28 ART