Hi,
Thanks for commenting on my query, appreciate it.
I understand what you are saying; however my question is in regards of
the IGMP Querier, from what I've read so far, the IGMP Querier can
also signal the creation of the RPT for the receivers. Maybe I am
misunderstanding something here and this is not true and it is only
the DR the one in charge of signaling the RPT for the receivers, do
you know by any chance if, in fact, the IGMP Querier can signal the
creation of the RPT to the RP (this, of course, would be done using
PIM in the upstream connection to the RP)? Now, if this is actually
true and both the IGMP Querier and PIM DR can signal RPTs, who will be
signaling the creation of the RPT for a shared segment where the DR
and IGMP Querier are different routers?
Thanks again,
Jorge
On Sat, Jun 12, 2010 at 6:32 AM, masroor ali <masror.ali_at_gmail.com> wrote:
> Hi,
>
> G1(receiver)(Multicast group)
> |
> |
> ---------------------------------
> | |
> |(192.168.1.1) | f0/0 (OIL)
> R1 R2 (192.168.1.2)
> | | f0/1 (IIL)
> --------------------------------
> |
> |
> R3 (RP)
> |
> |
> ---------------------------------
> | |
> | |
> R4 R5
> | |
> --------------------------------
> |
> |
> source(S1)(sender)
>
>
> lets assume G1 is the IGMP group, who wants to receive the multicast
> traffic. G1 1st send the IGMP host membership to join the group(which is
> also called signaling).As there are multiple routers R1, R2 in the segment,
> DR election process occur, the heighest IP address router (R2) wins and
> create OIL(f0/0) . the DR (R2) send a join messege to RP, RP recieve the jon
> messege, in this way RPT occur.
> note that untill the multicast reciver G1 signal nothing would happen.
>
> This is one part of the story. ((G1) IGMP reciever ---------> RP)
>
> The second part remains to discuss. ((S1)source------------> RP)
>
> The first hop route (R4, R5) encapsulate the multicast traffic into register
> message and unicast to RP, here two routers are the first-hop routers, now
> the PIM-assert come into play and now 1st check the AD, then metric, then
> heighest router IP become the forwarder and unicast the encapsulated
> multicast traffic into the register message to RP. then RP de-encapsulate
> the register message and forward to reciever.
>
> note: The 1st hop router keep on encapsulating the packet unless the RP send
> a register-stop message.
>
>
>
> On Thu, Jun 10, 2010 at 10:33 PM, Jorge Cortes <jorge.cortes.cano_at_gmail.com>
> wrote:
>>
>> I apologize I hit send button before finishing with the email.
>>
>> Although both protocols are used for different purposes, it is my
>> understanding that both, PIM DR and IGMP Querier, can signal SPT Trees
>> on behalf of the multicast receivers on a shared medium when PIM SM
>> is in use. Is this
>> correct?
>>
>> If this is correct, the following question arises. Lets assume the
>> following scenario
>>
>>
>>
>> ------------------------------
>> | |
>> R1 R2
>> \ /
>> \ /
>> \ /
>> \ /
>> \ /
>> \ /
>> RP
>>
>> If all IGMP and PIM parameters are left to the default, one of this
>> routers will become the IGMP Querier, lets say R1, and the other one
>> will become the PIM DR, lets say R2, so both will signal the SPT Trees
>> for the groups on the shared segment. Since both routers signaled the
>> SPT Tree, then both routers will forward the same multicast data on
>> the segment and the assert procedure will take place. Assuming R2 has
>> a better metric to the source it will become the assert winner and R1
>> will prune its LAN interface from the OIL.
>>
>> Is this understanding correct?
>> Am I missing anything here?
>>
>> I appreciate your inputs.
>>
>> Thanks,
>> Jorge
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Regards,
> Masroor Ali
Blogs and organic groups at http://www.ccie.net
Received on Sat Jun 12 2010 - 23:01:31 ART
This archive was generated by hypermail 2.2.0 : Sun Aug 01 2010 - 09:11:37 ART