Re: Multicast Graft and Prune Override

Hi Carlos,

Thanks for the info. One more thing who send this graft message and for
what reason they use this GRAFT message?

On Mon, Nov 21, 2011 at 11:41 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:

> The problem is not determining the destination ADDRESS of the GRAFT, but
> the INTERFACE you use to send it. You need to send it on RPF(S), but if
> you don't know S, then there's no way to know RPF(S).
> (And don't you dare think of flooding it :)
>
> GRAFT is part of PIM-DM. Hosts have no business in this mantra.
>
> -Carlos
>
> CCIE KID @ 21/11/2011 14:55 -0300 dixit:
>
>> Hi Carlos,
>>
>> U got my question right. What is the destination IP address for Graft
>> message. I thought it is 224.0.0.2 --All ROuters address and i didnt
>> thought about the Server Source address .. So when Flooding happens, the
>> FHR router will flood it to all hosts and hosts catch hold of that flood
>> and then they can send a IGMP join towards FHR right. Instead of that why
>> does it send GRAFT message?
>> And wat is the use of Graft message?
>>
>> On Mon, Nov 21, 2011 at 11:16 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar<mailto:
>> tron_at_huapi.ba.ar>> wrote:
>>
>> Kid,
>> you asked why is there flooding if you could use GRAFT instead.
>> (at least that was my interpretation of your Q1).
>>
>> My answer is that for you to be able to send a GRAFT, you need to
>> know where to send it to, but you learn that because of flooding.
>> If there were no flooding, the router would never learn the sources
>> of different groups, so you would not know where to GRAFT to.
>>
>> BTW, the "client" message is GRAFT, no GRAFT ACK. GRAFT ACK is sent
>> back to acknowledge reception by the upstream router.
>>
>> -Carlos
>>
>> CCIE KID @ 21/11/2011 14:32 -0300 dixit:
>>
>> hi carlos,
>>
>> not able to get u man in the first answer. Wat is the use of
>> graft and graft ack message. could u elaborate man
>>
>> On Mon, Nov 21, 2011 at 7:34 PM, Carlos G Mendioroz
>> <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>
>> <mailto:tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>> wrote:
>>
>> Kid,
>>
>> 1) you don't know S before you ever receive a mcast packet.
>> So you
>> can not tell who to send a graft (no RPF interface).
>>
>> 2) sounds good to me. Two receivers on the same segment and one
>> decides to PRUNE makes the other shout (JOIN) not to be
>> forgotten :)
>>
>> -Carlos
>>
>> CCIE KID @ 21/11/2011 08:21 -0300 dixit:
>>
>> Hi fellas,
>>
>> I was reading my Multicast theory and i have few doubts
>> with the
>> Dense
>> mode.
>>
>> 1)There is a Graft Ack message sent by the client to rejoin
>> a
>> particular
>> group , ( becasue already he is a member and then pruned and
>> then again
>> joining ) , . At this point the First hop router should send
>> just a Graft
>> Ack message to rejoin the group. If there is Graft
>> concept. Why
>> there is
>> the concept of Flooding n Pruning for every 3 minutes??
>>
>> Because Graft Ack just solves the purpose of joining again
>> instead of
>> waiting for 3 minutes for the FHR to send the feed again.
>> Can some explain me the use of Graft message and Graft Ack
>> in
>> Multicast
>>
>>
>> 2)Regarding Prune Override .. If there are more than two
>> routers
>> say R1 and
>> R2 in a LAN domain. R3 is used as as the FHR towards the
>> RP Now
>> if a host
>> connected to R1 is sending a IGMP Leave message and now
>> R1 sends
>> a Group
>> specific query and if there is no host which replies to this
>> query, now
>> then R1 will send a PIM prune message to 224.0.0.2 and now
>> R2
>> receives it
>> and now it see that there is a host which is actively
>> participating in that
>> group and it sends a Prune override to R3 and now R3
>> still sends
>> traffic on
>> the link.
>>
>> Correct me if i am wrong in the above statement. Can some
>> one
>> explain my
>> understanding is correct or not.
>>
>> R3------------------| Sw1 |---------------R1--------Host 1
>> |
>> |
>> |
>> R2
>> |
>> |
>> |
>> Host 2
>> This is my scenario
>>
>>
>> With Warmest Regards,
>>
>> CCIE KID
>> CCIE#29992 (Security)
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> ______________________________**
>> ______________________________**___________________
>>
>>
>> Subscription information may be found at:
>> http://www.groupstudy.com/____**list/CCIELab.html<http://www.groupstudy.com/____list/CCIELab.html>
>> <http://www.groupstudy.com/__**list/CCIELab.html<http://www.groupstudy.com/__list/CCIELab.html>
>> >
>>
>> <http://www.groupstudy.com/__**list/CCIELab.html<http://www.groupstudy.com/__list/CCIELab.html>
>> <http://www.groupstudy.com/**list/CCIELab.html<http://www.groupstudy.com/list/CCIELab.html>
>> >>
>>
>>
>>
>>
>>
>>
>>
>>
>> -- Carlos G Mendioroz <tron_at_huapi.ba.ar
>> <mailto:tron_at_huapi.ba.ar> <mailto:tron_at_huapi.ba.ar
>>
>> <mailto:tron_at_huapi.ba.ar>>>
>>
>> LW7 EQI Argentina
>>
>>
>>
>>
>> -- With Warmest Regards,
>>
>> CCIE KID
>> CCIE#29992 (Security)
>>
>>
>>
>> -- Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar
>> >>
>> LW7 EQI Argentina
>>
>>
>>
>>
>> --
>> With Warmest Regards,
>>
>> CCIE KID
>> CCIE#29992 (Security)
>>
>>
>>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>

-- 
With Warmest Regards,
CCIE KID
CCIE#29992 (Security)
Blogs and organic groups at http://www.ccie.net