From: Scott Morris (swm@emanon.com)
Date: Fri Dec 26 2003 - 00:46:45 GMT-3
BSR works on a hop-by-hop basis. The 224.0.0.13 is a local-link
multicast group, so it really has nothing to do with either PIM mode.
(think of it like how OSPF works "magically" but only on local links)
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
CISSP, JNCIS, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
Notations:
Per RFC 2362:
To obtain the RP information, all routers within a PIM domain collect
Bootstrap messages. Bootstrap messages are sent hop-by-hop within the
domain; the domain's bootstrap router (BSR) is responsible for
originating the Bootstrap messages. Bootstrap messages are used to
carry out a dynamic BSR election when needed and to distribute RP
information in steady state.
A domain in this context is a contiguous set of routers that all
implement PIM and are configured to operate within a common boundary
defined by PIM Multicast Border Routers (PMBRs). PMBRs connect each
PIM domain to the rest of the internet.
Routers use a set of available RPs (called the RP-Set) distributed in
Bootstrap messages to get the proper Group to RP mapping. The
following paragraphs summarize the mechanism; details of the
mechanism may be found in Sections 3.6 and Appendix 6.2. A (small)
set of routers, within a domain, are configured as candidate BSRs
and, through a simple election mechanism, a single BSR is selected
for that domain. A set of routers within a domain are also configured
as candidate RPs (C-RPs); typically these will be the same routers
that are configured as C-BSRs. Candidate RPs periodically unicast
Candidate-RP-Advertisement messages (C-RP-Advs) to the BSR of that
domain. C-RP-Advs include the address of the advertising C-RP, as
well as an optional group address and a mask length field, indicating
the group prefix(es) for which the candidacy is advertised. The BSR
then includes a set of these Candidate-RPs (the RP-Set), along with
the corresponding group prefixes, in Bootstrap messages it
periodically originates. Bootstrap messages are distributed hop-by-
hop throughout the domain.
Routers receive and store Bootstrap messages originated by the BSR.
When a DR gets a membership indication from IGMP for (or a data
packet from) a directly connected host, for a group for which it has
no entry, the DR uses a hash function to map the group address to one
of the C-RPs whose Group-prefix includes the group (see Section 3.7).
The DR then sends a Join/Prune message towards (or unicasts Registers
to) that RP.
The Bootstrap message indicates liveness of the RPs included therein.
If an RP is included in the message, then it is tagged as `up' at the
routers; while RPs not included in the message are removed from the
list of RPs over which the hash algorithm acts. Each router continues
to use the contents of the most recently received Bootstrap message
until it receives a new Bootstrap message.
If a PIM domain partitions, each area separated from the old BSR will
elect its own BSR, which will distribute an RP-Set containing RPs
that are reachable within that partition. When the partition heals,
another election will occur automatically and only one of the BSRs
will continue to send out Bootstrap messages. As is expected at the
time of a partition or healing, some disruption in packet delivery
may occur. This time will be on the order of the region's round-trip
time and the bootstrap router timeout value.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Pun, Alec CL
Sent: Thursday, December 25, 2003 10:38 PM
To: Ozgur Guler (Garanti Teknoloji); ccielab@groupstudy.com
Subject: RE: PIMv2 BSR
Ozgur,
I've tried BSR and it works in sparse-mode-only. But BSR messages do
not use 224.0.1.40 and 39 like auto-rp. It should be using 224.0.0.13.
My question is if no dense mode is configured, how can this multicast
group get flooded and mrouteed to all routers ??
BTW, from DocCD, it said :
Sparse mode and dense mode are properties of a group, as opposed to an
interface.
How can we make a group to act as dense or sparse mode ? It seems the
configuration only exists on a per-interface basis.
thanks
alec
-----Original Message-----
From: Ozgur Guler (Garanti Teknoloji) [mailto:OzgurG@garanti.com.tr]
Sent: Friday, December 26, 2003 2:19 AM
To: Pun, Alec CL; ccielab@groupstudy.com
Subject: RE: PIMv2 BSR
bsr like auto-rp is to distribute rp info, so it is for sparse-mode.
multicast traffic for groups 224.0.1.40 and 224.0.1.39 are flooded in
dense mode so again no default rp config needed, like in sparse-dense
mode.
Ozgur
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Pun, Alec CL
Sent: Thursday, December 25, 2003 7:17 PM
To: ccielab@groupstudy.com
Subject: PIMv2 BSR
Does BSR work in sparse-mode-only ? Do the BSR messages (224.0.0.13)
get flooded to all C-RP by dense-mode, which is similar to Auto-rp ?
thanks
alec
This archive was generated by hypermail 2.1.4 : Sat Jan 03 2004 - 08:25:45 GMT-3