Re: PIM DR vs IGMP Querier

Hi,

Thank you all for looking at this.

This is getting more confusing, so let's try to clear things up.

When the senders are on a shared media and there is more than one multicast
capable router on the segment, the router that will register the source or
sources with the RP is the DR, which, by default is the router with the
highest IP address on the segment. There is no Assert procedure on the
segment where there are only senders located. Assert only takes place for
shared segments where there are receivers located -note there can be senders
as well.

Now, the confusion arises on shared segments where there are receivers. In a
previous mail you said:

"The one who receive IGMP messeges and send the join message towards RP
(signalling) is always the same router. "

Hosts signal IGMP messages asynchronously, and all multicast capable routers
on the segment process these messages and respond to these messages at the
beginning, thus IGMP Querier election process needs to take place as well as
PIM DR election process. However both election processes use different
criteria. IGMP Querier uses lowest IP address and PIM DR uses highest IP
address, this is why without any parameter modification (i.e. altering
priorities) the PIM DR and the IGMP Querier cannot be the same router.

Now, back to my original doubt, is it true that both the PIM DR and IGMP
Querier help receivers build RPT trees towards the RP? Or is it just the PIM
DR who can do this?
If both PIM DR and IGMP Querier can signal RPT Trees towards the RP and
these two are different routers, how is this ultimately handled? Will
multicast traffic from sources be initially sent to both the PIM DR and IGMP
Querier? Then both routers will forward this multicast traffic on to the
shared segment forcing assert procedure to take place and finally the assert
loser will prune its LAN interface from the OIL?

Is this the correct order of operations?

Thanks!
Jorge

On Sun, Jun 13, 2010 at 10:25 AM, <kebramccie_at_gmail.com> wrote:

> Outgoing interface list and incoming interface list I guess
> Sent from my BlackBerry wireless device from MTN
>
> -----Original Message-----
> From: F H <sol3a1_at_gmail.com>
> Sender: nobody_at_groupstudy.com
> Date: Sun, 13 Jun 2010 10:57:44
> To: Cisco certification<ccielab_at_groupstudy.com>
> Reply-To: F H <sol3a1_at_gmail.com>
> Subject: Re: PIM DR vs IGMP Querier
>
> Please forgive my ignorance, but what are the terms IIL and OIL?
>
>
> Thanks
>
> On Sun, Jun 13, 2010 at 10:21 AM, masroor ali <masror.ali_at_gmail.com>
> wrote:
>
> > As per my understanding about these terms, DR is the one who signals
> > towards
> > to RP so that RPT build (R2), and the assert forwarder would be R4 or R5.
> > because the traffic is moving from sender---> R4/R5--->RP---->R2---->G1,
> > and
> > the router who unicast the multicast traffic to RP is the assert
> forworder
> > (if AD is low,metric is low,or higest IP address in that segment),
> >
> > On Sun, Jun 13, 2010 at 6:47 PM, Muzammil Malick <malickmuz_at_gmail.com
> > >wrote:
> >
> > > Masroor.
> > >
> > > Would you also agree that R1 and R2 also send PIM Assert messages to
> each
> > > other to decide who is the Designated Forwarder TO the receiver?
> > >
> > >
> > > On 12 June 2010 12:32, 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
> > >>
> > >>
> _______________________________________________________________________
> > >> 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
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Mon Jun 14 2010 - 11:08:23 ART