Re: Multicast RP - RPF concept

I have just verified this in the lab. It's just a confusing (misleading)
debug message.

I replicated your setup R1--R2==R3, but two links were not important (one
with pim, the other without pim).
The important thing was route presence to RP on R2. As in your case, when
there was no route to RP, there was a failure message:

*Mar 1 00:18:50.351: IP(0): s=10.0.0.1 (FastEthernet2/0) d=224.20.20.20
id=9, ttl=254, prot=1, len=114(100), RPF

But once there was a route to RP on R2, then register was sent successfully:

*Mar 1 00:17:48.483: PIM(0): Check RP 3.3.3.3 into the (*, 224.20.20.20)
entry
*Mar 1 00:17:48.487: PIM(0): Send v2 Register to 3.3.3.3 for 10.0.0.1,
group 224.20.20.20
*Mar 1 00:17:48.487: IP(0): s=10.0.0.1 (FastEthernet2/0) d=224.20.20.20
id=8, ttl=254, prot=1, len=114(100), mroute olist null
*Mar 1 00:17:48.607: PIM(0): Received v2 Register-Stop on FastEthernet0/0
from 3.3.3.3
*Mar 1 00:17:48.611: PIM(0): for source 10.0.0.1, group 224.20.20.20
*Mar 1 00:17:48.611: PIM(0): Clear Registering flag to 3.3.3.3 for (
10.0.0.1/32, 224.20.20.20)

On Tue, Jul 7, 2009 at 6:46 PM, Ravi Singh <way2ccie_at_googlemail.com> wrote:

> Hi Pavel,
>
> Good to see your answers back on the list after a while ..
>
> Anyways, actually I have a receiver and things do work out perfectly fine
> if I sort out the RPF failure issue...I will try the debugs tonight but what
> I am concerned with is the step no.6 in your last email which says
>
> 6. RPF to RP fails and you see the message...
>
> This means R4 is doing a RPF check for the RP address, which also means
> that this check is being performed without R4 actually receiving any traffic
> from the RP yet, contrary to the usual RPF mechanism when an RPF check is
> performed on the source of the multicast packet received..This is the only
> concept that I wish to verify ..
>
> Regards,
> Ravi
>
>
> On Tue, Jul 7, 2009 at 5:16 PM, Pavel Bykov <slidersv_at_gmail.com> wrote:
>
>> Well, there are more things to consider.
>> You don't have a receiver, do you? So the R6 is not going to build a
>> source tree. When there is no tree, there is nothing to forward. Hence there
>> is no native multicast flow from R6 to R5.
>>
>> I think what you see here, is byproduct of Cisco multicast implementation.
>> When a multicast packet is originated, it is sent out of all pim-enabled
>> interfaces at once (causes headaches many times). So here what is happening:
>>
>> 1. R6 pings the group
>> 2. R6 sends the packet out of all the interfaces
>> 3. R4 receives the packet and thinks that it's basically just a host
>> residing on the segment
>> 4. R4 tries to send REGISTER to RP
>> 5. R4 does not have a route to RP
>> 6. RPF to RP fails and you see the message.
>>
>> In your debugs, include "debug ip pim" to see how the tree is beeing
>> built. Also, try debug ip mpacket with no ip mroute-cache on interfaces.
>>
>>
>>
>> On Tue, Jul 7, 2009 at 5:45 PM, Ravi Singh <way2ccie_at_googlemail.com>wrote:
>>
>>> Guys,
>>>
>>> I must have messed with the wording to sound like asking about RPF check
>>> on a unicast packet , but thats definitely not what I meant..Here is the
>>> output of the test I carried.. Since I am pasting it out of the test I was
>>> doing the hostnames are different..In this case R6 is the source connected
>>> to R4 and R4 is connected to R5 through two links ...I am getting an RPF
>>> failed on R4 which is not the RP ..
>>>
>>> SHOW IP MROUTE BEFORE THE PING
>>> R6#sh ip mr 224.20.20.20
>>> Group 224.20.20.20 not found
>>>
>>>
>>> R4#sh ip mr 224.20.20.20
>>> Group 224.20.20.20 not found
>>>
>>> R5#sh ip mr 224.20.20.20
>>> <output ommitted >
>>>
>>> (*, 224.20.20.20), 06:37:30/00:03:29, RP 150.1.5.5, flags: S
>>> Incoming interface: Null, RPF nbr 0.0.0.0
>>> Outgoing interface list:
>>> FastEthernet0/0, Forward/Sparse, 05:44:48/00:03:29
>>> PING INITIATED FROM R6 and a debug on R4
>>>
>>> R6#ping 224.20.20.20
>>> Type escape sequence to abort.
>>> Sending 1, 100-byte ICMP Echos to 224.20.20.20, timeout is 2 seconds:
>>> .
>>> R6#
>>>
>>> R4#debug ip mpack deta
>>> IP multicast packets debugging is on (detailed)
>>> R4#
>>> *Jun 23 10:15:17.047: IP(0): MAC sa=000d.bc35.5f60 (FastEthernet0/1), IP
>>> last-hop=155.1.146.6
>>> *Jun 23 10:15:17.047: IP(0): IP tos=0x0, len=100, id=16, ttl=254, prot=1
>>> *Jun 23 10:15:17.047: IP(0): s=155.1.146.6 (FastEthernet0/1)
>>> d=224.20.20.20 id=16, ttl=254, prot=1, len=114(100), RPF lookup failed for
>>> source or RP
>>> R4#
>>> R4#un all
>>> All possible debugging has been turned off
>>> R4#sh ip rpf 150.1.5.5
>>> RPF information for ? (150.1.5.5) failed, no route exists
>>> R4#
>>> R4#sh ip rpf 155.1.146.6
>>> RPF information for ? (155.1.146.6)
>>> RPF interface: FastEthernet0/1
>>> RPF neighbor: ? (155.1.146.6) - directly connected
>>> RPF route/mask: 155.1.146.0/24
>>> RPF type: unicast (connected)
>>> RPF recursion count: 0
>>> Doing distance-preferred lookups across tables
>>> R4#
>>> As you can see R4 is not failing the RPF check for the source rather the
>>> RP IP address .. A debug ip packet detail on R4 and R5 also shows that there
>>> are actually no packets sent from R4 to R5 , and the RPF is not failing on
>>> the RP .. What I meant in my question was R4 (R2 originally in the question
>>> ) knows the RP address so when it receives a register message to be sent to
>>> the RP does it first do a RPF check for the RP address.. and if yes,, does
>>> it do that without actually receiving any packet from the RP unlike in other
>>> scenarios where an RPF check is performed only when a multicast packet is
>>> received..
>>>
>>> Hope this time the wording is clear ;-)
>>>
>>> Regards,
>>> Ravi
>>>
>>>
>>>
>>>
>>> On Tue, Jul 7, 2009 at 4:07 PM, Jared Scrivener <jscrivener_at_ipexpert.com
>>> > wrote:
>>>
>>>> This also explains the odd behavior seen occasionally when pinging a
>>>> multicast address where the first ping packet responds but the
>>>> subsequent
>>>> ones fail.
>>>>
>>>> Cheers,
>>>>
>>>> Jared Scrivener CCIE3 #16983 (R&S, Security, SP), CISSP
>>>> Sr. Technical Instructor - IPexpert, Inc.
>>>> URL: http://www.IPexpert.com <http://www.ipexpert.com/>
>>>> Telephone: +1.810.326.1444
>>>> Fax: +1.810.454.0130
>>>> Mailto: jscrivener_at_ipexpert.com
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>>>> Pavel Bykov
>>>> Sent: Tuesday, 7 July 2009 9:16 AM
>>>> To: Ravi Singh
>>>> Cc: Cisco certification
>>>> Subject: Re: Multicast RP - RPF concept
>>>>
>>>> As Lejoe pointed out, there are no checks on R2 since it's UNICAST, so
>>>> it
>>>> behaves as unicast in all manners. The problem in your case are two
>>>> links
>>>> towards R3. register would arrive at R3, R3 would decapsulate the
>>>> packet,
>>>> and then do the RPF - that's where RPF would fail, and that's where the
>>>> counters would increment.
>>>>
>>>> On Tue, Jul 7, 2009 at 1:15 PM, Ravi Singh <way2ccie_at_googlemail.com>
>>>> wrote:
>>>>
>>>> > Hi Group,
>>>> >
>>>> > Just trying to clarify a bit in the RPF check mechanism in PIM Sparse
>>>> > mode..Suppose 3 routers R1, R2 and R3 are connected linearly .. with
>>>> R1 as
>>>> > the source of the multicast and R3 as the RP.. Not concerned with the
>>>> > receivers in this example.. If R1 sends traffic towards the receiver
>>>> > (downstream R3) , the unicast register reaches R2 and R2 does a RPF
>>>> check
>>>> > on
>>>> > the source of the traffic i.e R1 as well as the RP i. R3 .. Now as I
>>>> have
>>>> > read it when a router receives a multicast packet it does a RPF check
>>>> on
>>>> > the
>>>> > source of the packet. But in this case the RP (i.e R3 ) has not yet
>>>> sent
>>>> > any
>>>> > traffic towards R2 so R2 has not received any packet from the RP..
>>>> Yet R2
>>>> > does a check on the RP address.. My question is have I understood this
>>>> > correctly that the RPF check for the RP address is done without
>>>> actually
>>>> > any
>>>> > multicast traffic being received from the RP ...while for other
>>>> scenarios
>>>> > the multicast packet has first to be received from a source and then
>>>> the
>>>> > RPF
>>>> > check is performed ..
>>>> >
>>>> > I have a scenario where R2 has two connections to R3 (RP ) and one of
>>>> the
>>>> > connections has PIM enabled while the RP is reachable through the
>>>> other
>>>> > connection ..Essentially, the RPF check on R2 fails for the RP and
>>>> when I
>>>> > debug the packets there is no packet which was sent to the RP .. the
>>>> check
>>>> > failed on R2 straightaway ...
>>>> >
>>>> > Hope I have put the question properly !!
>>>> >
>>>> > Regards,
>>>> > Ravi
>>>> >
>>>> >
>>>> > Blogs and organic groups at http://www.ccie.net
>>>> >
>>>> >
>>>> _______________________________________________________________________
>>>> > Subscription information may be found at:
>>>> > http://www.groupstudy.com/list/CCIELab.html
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>>> --
>>>> Pavel Bykov
>>>> ----------------
>>>> Don't forget to help stopping the braindumps, use of which reduces value
>>>> of
>>>> your certifications. Sign the petition at
>>>> http://www.stopbraindumps.com/
>>>>
>>>>
>>>> Blogs and organic groups at http://www.ccie.net
>>>>
>>>> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Pavel Bykov
>> ----------------
>> Don't forget to help stopping the braindumps, use of which reduces value
>> of your certifications. Sign the petition at
>> http://www.stopbraindumps.com/
>>
>
>

-- 
Pavel Bykov
----------------
Don't forget to help stopping the braindumps, use of which reduces value of
your certifications. Sign the petition at http://www.stopbraindumps.com/
Blogs and organic groups at http://www.ccie.net