Re: Multicast RP - RPF concept

Hi Pavel,

You are correct , the message is indeed misleading !!! I now have my set up
working even with the message on R4 ..R4 sends the register through one link
which is not PIM enabled , but multicast flows through the other PIM
enabled interface which is fine since the RPF is not done on the register
message..but strangely the RPF failed message is still there..I always agree
when someone says that Multicast causes Headaches many times ;-)

Thanks for your help and time though ..

Regards,
Ravi

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

> Oh, and one more important thing.
> In the R1--R2==R3 setup, when pinging from R1 to whatever group, R1 never
> sends any register. It acts as a dumb sender (and as we know, multicast
> senders are "dumb" most of the time - i.e. just send the packet to the given
> multicast address, without any control messages)
>
> It's up to R2 to start up multicast intelligence.
> So in case you are doing any multicast testing, remember this and always
> have spare router/other device that will generate packets, so you'd have
> more correct simulation of the network behavior
>
>
>
> On Tue, Jul 7, 2009 at 11:22 PM, Pavel Bykov <slidersv_at_gmail.com> wrote:
>
>> 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/
>>
>
>
>
> --
> 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
Received on Wed Jul 08 2009 - 05:28:29 ART