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
