Point of clarification.
Wouldn't it be PIM that is requiring the RPF check and not the IGMP join-group? Let's say you have gateway (GW1) with an Ethernet interface on the same broadcast domain as another gateway (GW2) that is correctly routing the multicast group traffic onto that broadcast domain, and you have GW1 subscribe to the multicast traffic via the "ip igmp join-group" command. Would GW1 require that its interface be PIM enabled before it would be able to receive the multicast traffic, or would enabling "ip igmp join-group" be sufficient to get the multicast traffic into the IOS software? If "ip igmp join-group" is sufficient without enabling PIM on the interface, would GW1 even perform RPF checks? TIA, Brian From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Morris Sent: Sunday, April 06, 2008 2:05 PM To: 'Dale Kling'; [email protected] Subject: Re: [OSL | CCIE_RS] RPF not working? It depends. ;) Namely, it depends on what you are RPFing for and what the router is RPFing for. In a (*,G) group, the RPF check is actually against the RP address and NOT the multicast source. In a (S,G) group, the RPF check is against the actual source. So that may affect what you think should be a failure where the router thinks life is good. HTH, Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE-M #153, JNCIS-ER, CISSP, et al. CCSI/JNCI-M/JNCI-ER VP - Technical Training - IPexpert, Inc. IPexpert Sr. Technical Instructor [EMAIL PROTECTED] Telephone: +1.810.326.1444 Fax: +1.810.454.0130 http://www.ipexpert.com _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dale Kling Sent: Sunday, April 06, 2008 1:47 PM To: [email protected] Subject: [OSL | CCIE_RS] RPF not working? Hi everyone, I have a question that kind of puzzles me and I hope it's a fundamental gap I'm missing that can quickly answer this. I have a client router receiving multicast traffic destined for its ethernet interface with an "igmp join-group" command on it. Thing is the multicast traffic is not incoming on its RPF interface, yet it's still working. I've done an extended ping on the source to verify I'm choosing the source address. I'm running sparse mode and I can see the mpacket count increase normally on the RP-tree for that (*,G) entry on the client. I do a debug ip mpacket on the client router to verify the source is not coming in on it's RPF interface. Shouldn't this be failing and dropping? thanks, Dale
