From: Pierre-Alex (paguanel@hotmail.com)
Date: Mon May 08 2006 - 17:17:29 ART
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
To: Pierre-Alex
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