Im not particularly confident with multicast as its something I have not ye had to configure professionally, so these notes are a bit scatty as I try to get grips with some of it.

Finding the RP using Boost Strap Router (BSR) -
If multiple BSR configured routers exist in a network an election will take place and the one with the highest priority will win then the highest IP address used as a tie breaker. The winner is elected the preferred BSR, this is performed by each router advertising itself until a “better” BSR is discovered. Another election will also take place if a BSR does not receive a BSR message within 150 seconds. The preferred BSR will forward messages but BSRs which were not selected as the preferred BSR will monitor BSR messages but not originate them.

The BSR will be advertised in a BSR bootstrap messages which is forwarded out of all non-RPF interfaces by every router to the all PIM routers multicast group 224.0.0.13 with a TTL of 1, each router in turn resets the TTL to 1, thereby the messages should be received by every router on the network. This alleviates the chicken and egg issue with Auto RP in PIM-SM. Once candidate RPs are aware of the BSR they will announce themselves to the BSR via unicast, and then BSR will advertise this information of all the RPs bootstrap message to all PIM routers, it is then up to each router to decide which RP to use.

To configure BSR, first setup one or more candidate BSRs with the command;

Router(config)#ip pim bsr-candidate {interface} [Hash Mask 0-32] [Priority 0-255]

As with Auto RP you will also need to configure candidate RPs with the command

Router(config)#ip pim rp-candidate [interface] [group-list] [interval] [priority]

Anycast RP with Multicast Source Discovery Protocol (MSDP) – This approach to assisting routers finding the RP is not an independent protocol and can be used with, Auto RP or BSR. Anycast RP Its a relatively simple, firstly Anycast RP need to be configured, this is where multiple mapping Agents or BSRs in the network uses the same IP address. Eg if 3 Auto RP mapping agents were configured with the address 10.0.0.1 and this was advertised into the IGP each router would take the shortest path to get to its nearest Auto RP mapping agent as determined by the IGP. This has the nice benefits of failover in the time it takes for the IGP to reconverge and load balancing.

But there is a problem with Anycast RP a source may register with one RP and its receivers may join a separate RP, so MSDP was developed to allow RPs to exchange information about active sources with each other. MSDP routers are configured as peers and communicate with each other when a source sends a SA message for a multicast group, thereby every MSDP peer will becomes aware of the sources for each multicast group in other areas of the network where they are not the nearest RP. In case of failure the IGP will handle putting the receivers in contact with another Auto RP mapping agent or BSR in the convergence time for the IGP.

Please report any glaring mistakes in the above if you spot any, cheers!

Multicast traffic in PIM-SM gets sent to the RP and receivers request the traffic from the RP as such multicast networks operating in PIM-SM require an Rendezvous Point (RP) to operate. Section 2.4 of RFC2362 discusses how after a certain number of packets the shared tree using an RP can stop being used and a shortest path tree originating from the source router should be used, the RFC does not explicitly state the exactly when the switchover from a shared tree to a shortest path tree should take place. The time when the switchover takes place can be modified with this command;

Router(config)#ip pim spt-threshold ?
<0-4294967>  Traffic rate in kilobits per second
infinity     Never switch to source-tree

Manual selection of the RP – Manually selecting the RP is a drag as it does not scale to large networks as selecting the RP for each multicast group will be tedious and it is difficult to have any real redundancy if a manually selected RP happened to fail. Manual selection of an RP is configured with the following command;

Router(config)#ip pim rp-address ?
A.B.C.D  IP address of Rendezvous-point for group

Auto RP – One solution to this issue is automatically selecting the RP in a multicast tree using a Cisco proprietary protocol called Auto RP.

When using Auto RP an RP will send out an RP-Announce message every minute to the address 224.0.1.39 saying something like “Hey mapping agent(s), I’m 10.0.0.1, use me as the RP for all the multicast group 239.0.0.50!”. A Router(s) which is configured as the mapping-agent (often the same router) collates call of the RP information and sends out messages to the multicast group 224.0.1.40 stating which RPs should be used for which multicast groups. All routers using Auto RP and PIM-SM listen to 224.0.1.40 and use the information to find RPs.

If there are multiple RPs for a multicast group the RP will tiebreak with the highest RP address winning.

A router can be configured to send RP-Announce messages with the following commands;

Router(config)#access-list 10 permit 239.0.0.0 0.255.255.255
Router(config)#ip pim send-rp-announce loopback 0 scope 32 group-list 10

And a mapping agent configured with the command;

Router(config)#ip pim send-rp-announce loopback 0 scope 32

Simple!

There is a chicken and egg scenario with using PIM-SM with Auto RP where the Auto RP messages are sent to the multicast groups 224.0.1.39 and 224.0.1.40 but if a router does not know where to send the join messages for that group it cant participate. This is one of the reasons why the PIM the variation sparse-dense mode was developed to allow the routers to operate in dense mode until they learn the RP mappings of where to get the RP-Discovery or RP-Announce message.

Sparse-Dense mode is configured with the command;

Router(config-if)#ip pim sparse-dense-mode

Posts will be made tomorrow on finding the RP using BSR and Anycast RP with Multicast Source Discovery Protocol (MSDP)

The address range of 233.0.0.0/8 is reserved for GLOP addressing, it was originally defined in RFC 2770 (superseded by RFC 3180) the RFC authors David Meyer & Peter Lothberg unfortunately didn’t define what GLOP stands for.

The cool thing about GLOP addressing is that every ASN has its own defined range for multicast. The first octet is always 224, and the 2nd and 3rd octets should be be the uniquely assigned ASN, and the final octet is locally administered. Therefore every ASN is provided with a pool of 256 addresses which they can use for internet multicast.

The restrictions of GLOP addressing only works with 2 byte ASNs, each ASN only has a pool of 256, also not having an acroynm or meaning for GLOP will bug me so im bound to be up all night thinking of acronyms of GLOP.