From: Chris Lewis (chrlewiscsco@gmail.com)
Date: Mon May 08 2006 - 18:02:04 ART
Pierre, I think the problem is with your test methodology.
With PIM NBMA mode on R2, it will only send a copy of the multiast stream
to a PIM neighbor if it receives a register from a specific IP address. On
the ethernet connecting R1, R3 and R5 the DR will be the one responsible for
notifying upstream routers that a multicast stream has been requested.
Therefore in this setup only one router on the R1/R3/R5 segment will be
requesting the stream and R2 will therefore only send one stream. Whichever
you select as the DR out of R1 and R3 will the the one making the request
and hence the only one receiving the multicast stream. This leads to the
assert process being pointless.
If you setup a situation where both R1 and R3 are receiving the multicast
stream, the assert process will have an opportunity to work.
To test this you need to be sure the multicast stream is getting to both R1
and R3, then see which one is forwarding on to the R1/R3/R5 segment.
Chris
On 5/8/06, Pierre-Alex <paguanel@hotmail.com> wrote:
>
> Chris, thank you replying.
>
> On question 1, nothing else to add.
>
> On question 2, my statements are based on observation in a lab
> environment.
>
> bb1
> |
> R2
> / \
> / \
> R1 R3
> |-------|---------|
> R5
>
> Ospf area 0 is running between R2, R1 and R3 (frame-relay multipoint -
> configured with ip nbma)
> Ospf area 111 is running on the Ethernet segment between R2 and bb1
> Ospf area 13 is running on the Ethernet segment between R1, R5 and R3
>
> bb1 is the muticast source using extended ping to group 239.255.255.1. PIM
> or IGMP is not running on bb1
>
> R5 is the client. IGMP is running on its LAN interface and the group
> 239.255.255. has been joined. PIM is not running.
>
> I am running sparse mode on R2, R1 and R3
>
> R3 is the rp (I am using static rp here)
>
> IP address of R1 on the shared LAN is 10.123.123.1
>
> IP address of R3 is 10.123.123.3
>
> If I do not do anything, R3 is the forwarder on the LAN and also the DR.
>
> If I changed the dr-priority to make R1 the prefered router, then R1
> becomes the forwarder and the DR.
>
> I played with the ospf costs and made R1 have the worst metric to the RP.
> Made no difference:
>
> When I changed the DR priority, I could see the Assert mechanism
> negotiating. However the outcome of the negotiation had no bearing on
> who finally became the fowarder : i.e, although R1 lost because it had
> the worst metric, it still remained the forwarder because it had the
> highest dr-priority.
>
> Also I set the dr-priority to default on both R1 and R3, and set the
> metric to a worst value on R3. R3 still remained the fowarder and DR.
>
> Thus:
>
>
> A) The determinant seems thus to be the DR priority level or the IP
> address (highest)
> B) The assert mechanism does not seem to have any effect ( and use) in
> sparse mode
> C) Both DR and forwarder functions are merged.
>
>
> I have re-read the RFC and agree with you that this is contrary to what is
> said ...
>
> The only way I can resolve this is by saying that Cisco does not implement
> pure RFC as far as Assert mechanism is concerned in sparse mode.
>
> If you know a way to to split the functions between forwarder and DR, I am
> eager to learn.
>
> Kind Regards,
>
> Pierre
>
>
>
>
>
>
>
> ----- Original Message -----
> *From:* Chris Lewis <chrlewiscsco@gmail.com>
> *To:* Pierre-Alex <paguanel@hotmail.com>
> *Cc:* ccielab@groupstudy.com
> *Sent:* Monday, May 08, 2006 4:39 PM
> *Subject:* Re: Multicast Statements
>
>
> A good sumary Pierre,
>
> For question 1, there are some differences between IGMP version 1 and
> version 2 relevant to your statements. In version 1 the querier and DR are
> the same device, in version 2 the DR is the router with the highest IP
> address, whereas the querier is the one with the lowest address.
>
> For question 2, I am aware that PIM v2 uses the assert message to
> determine which of multiple possible forwarders of a multicast stream will
> be the one to forward packets on to a multi-access segment (to avoid
> duplication of a steam on to that segment). The lowest IGP cost to the
> source wins the assert mechanism, highest IP address is the tie breaker.
>
> I am not aware of a difference between Dense mode and sparse mode
> operation for the assert process. Could you give a link of some kind
> that suggests this? Possibly a reference to the Designated Forwarder, which
> is a PIM BiDir enhancement is mixed in here? RFC 2362 defines assert for
> sparse mode, so I think you should re-visit that. In sparse mode the DR is
> responsible for sending triggered Join/Prune and Register messages toward
> the RP, it is not involved in the process of selecting routers to be used
to
> forward multicast packets on to the multi-access segment.
>
> For 3, again the DR is not necessarily the forwarder for a multi-access
> segment.
>
> For more information on the BiDir enhancement for a DF, refer to
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration
_guide_chapter09186a00800ca796.html
>
>
> Specifically the following (noting that it is only relevant to BiDir, not
> sparse mode in general):
>
> DF Election
>
> In bidir-PIM, the packet forwarding rules have been improved over PIM-SM,
> allowing traffic to be passed up the shared tree toward the RP. To avoid
> multicast packet looping, bidir-PIM introduces a new mechanism called
> designated forwarder (DF) election, which establishes a loop-free SPT
rooted
> at the RP.
>
> On every network segment and point-to-point link, all PIM routers
> participate in a procedure called DF election. The procedure selects one
> router as the DF for every RP of bidirectional groups. This router is
> responsible for forwarding multicast packets received on that network
> upstream to the RP.
>
> The DF election is based on unicast routing metrics and uses the same
> tie-break rules employed by PIM assert processes. The router with the most
> preferred unicast routing metric to the RP becomes the DF. Use of this
> method ensures that only one copy of every packet will be sent to the RP,
> even if there are parallel equal cost paths to the RP.
>
> A DF is selected for every RP of bidirectional groups. As a result,
> multiple routers may be elected as DF on any network segment, one for each
> RP. In addition, any particular router may be elected as DF on more than
one
> interface.
> Chris
>
>
> On 5/7/06, Pierre-Alex <paguanel@hotmail.com> wrote:
> >
> > Can someone please review the following statements I am making?
> >
> > Some of them are not clearly stated in the RFCs or the Cisco Doc but
> > appear to
> > be verified while labing.
> >
> > Much thanks,
> >
> > Pierre
> >
> > ======
> >
> > 1. The router with the lowest ip address is the IGMP querrier.
> >
> > 2. In PIM Dense mode to determine who will be the forwarder on a shared
> > LAN,
> > pim asserts are used.
> >
> > In PIM Spare mode to determine who will be the forwarder on a shared
> > LAN,
> > a DR election is run :
> >
> > The designated router is the router with the highest IP address or the
> > router
> > configured with the highest "ip pim dr-priority" value
> >
> > NB: in PIM Dense mode there is still an election but it serves no
> > purpose
> > (except in IGMP v1 m to choose the IGMP Querier)
> >
> > There is no need for an assert mechanism in SPARSE mode since there is
> > already
> > a DR election.
> >
> > (not exactly what the RFC is saying:
> > http://www.zvon.org/tmRFC/RFC2362/Output/chapter2.html !!!!
> >
> >
> > 3. In sparse mode, the designated router (DR) sends SOURCE REGISTRATION
> >
> > messages to the rendezvous point (RP).
> >
> > The DR is also responsible for sending joins towards the RP.
> >
> > The DR is the fowarder on a shared LAN.
> >
> >
> >
> > ========
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Jun 01 2006 - 06:33:21 ART