Re: Multicast RP - RPF concept

Correction of word-wrapped debug message from previous post:
*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 lookup failed for source or RP

On Tue, Jul 7, 2009 at 11:21 PM, Pavel Bykov <slidersv_at_gmail.com> wrote:

> 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/
>

-- 
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