If this compilation seems a bit random then please note that this has been written as a summary/compilation during my time of study. It’s primary use is not to be a “bible book” but a means of remembering things I’ve read.

If this proves useful to anyone or to me later on in life then that’s a nice bonus. If this page, or any others in this section, contains any errors then please let me know what the correct syntax/wording is and I’ll make changes whenever I have time available.

R&S written Blueprint items:

• Distribution trees
• PIM-SM mechanics
• Rendezvous Points (RP)
• Reverse Path Forwarding (RFP)

—

Generic overview

Multicast forwarding

RPM: Reverse-Path Multicasting

Reverse-Path refers to not sending/flooding a packet back out the interface on which it was received

SPT: Shortest-Path Tree (=source-based distribution tree)

RPM history

• Flooding; mitigate loops by keeping a log of last seen Mcast packets
• RPB: Reverse-Path Broadcasting; flood only packets which are received on the interface with the shortest path to the Mcast source. Source port = “parent” link, other interfaces = “child” links
• TRPB: Truncated Reverse-Path Broadcasting: IGMP group membership information is used to make forwarding decisions
• RPM: Creates a delivery tree which includes, Subnetworks /w group members & routers and subnetworks along the shortest path from Source to each of the subnetworks /w group members

RPM (used by DVMRP, PIM-DM & MOSPF)

• Source based tree
• Supports Pruning & Grafting
• Implicit Join (occasional broadcasting of each active group: Dense-Mode)
  
• All routers in the network must be capable of sending Prune messages (for each group)

Pruning: Only when no downstream routers or hosts (group members) are known by a router.

RFP

• RPF: Reverse-Path Forwarding (Check)
• The first thing a router must do upon receipt of a Mcast packet is determine that it arrived on the “correct” inbound interface
• Loop prevention
• DVMRP: uses its own routing table for RFP
• PIM & CBT use the unicast routing table for RFP (default)
• PIM & CBT can also use DVMRP or MBGP routing tables or static multicast routes for RFP
• MOSPF does not use RFP because it computes both forward and reverse SPF source-routed trees

*** Dense-Mode protocols

Typically domains that are suited to Dense-Mode protocols have rather plentiful amounts of bandwidth (LAN/MAN)

• (S,G) based (per area) Source-based trees

DVMRP (v1 = RFC1075, RFC of DVMRPv3 = draft?)

• Distance Vector Multicast Routing Protocol
• Broadcast-and-Prune tree-building protocol (Dense Mode)
• Originally derived from RIP (now closer to RPM) Route updates are sent every 60 sec, a hop count of 32 = infinity
• Uses Probe messages to find neighbours, via 224.0.0.4 (All-DVMRP-Routers)
• Not fully supported by Cisco
• Cost & TTL (IP TTL must be higher than the configured interface TTL
• TTL defines the scope. Default values are:
• TTL: 0 – same host
• TTL: 1 – same subnet
• TTL: 15 – same site
• TTL: 63 – same region
• TTL: 127 – worldwide
• TTL: 191 – worldwide; limited bandwidth
• TTL: 255 – unrestricted in scope
• A better means of scoping is defined by means of Mcast address usage (administrative scoping: 239/8)

–

• Distance-vector: slow convergence & max hop count of 15
• Off-tree routers still need to support DVMRP (resource consumption)
• 1st packet for any (S,G) pair is flooded throughout the network
• Resulting in (leaf) routers responding with Prune messages
• Redundant source paths: If metric is equal then the router with the lower IP on its downstream interface (child link) will become the dominant router for this source

–

• (Unicast) Routing table: Contains source prefixes, their gateways (both unicast), Metric, Status and TTL [RPB/source tree] Used for RPF check
• “Routing table TTL”: Number of seconds remaining before an entry is removed from the routing table. Not the interface TTL or IP TTL
• Forwarding table: Contains GDA, it’s source prefix, parent interface (InIntf) and child interfaces (OutIntf) [Group membership]

GDA = Group Destination Address

PIM-DM (RFCs 2362, 3446, and 3973 (PIMv2). Used to be Cisco proprietary)

• Protocol Independent Multicast – Dense Mode
• Independent from any unicast routing protocol mechanisms (unlike DVMRP). PIM uses an existing unicast routing protocol to do RFP check (any unicast protocol will do)
• Based on RPM algorithm
• Forwards Mcast without assigning parent/child status, until a Prune message is received (duplicate packets may temporarily exist)
• Forms adjacencies with neighbours
• PIMv2 Hello interval: 30 sec (default)
• PIMv2 Hello IP: Protocol 103 & address 224.0.0.13 (All-PIM-Routers)
• PIM messages are only sent out of interfaces that have PIM neighbours attached (except Hellos…)

–

• Hello message: Forms neighbour adjacencies between PIM routers and used to elect a PIM DR on a multi-access network, contain a hold time of 3x Hello interval (default = 90 sec)
• (explicit) Prune message (Mcasted on broadcast links), used to get removed from the (S,G) SPT. note that other routers will have to send a PIM Join message (Prune Override) to remain attached to the distribution tree
• State Refresh: Sent by a downstream router to reset an upstream routers Prune timer, its (S,G) specific
• Assert message: Used on a multi-access network to determine which router may forward Mcast packets onto a LAN, is (S,G) specific
  • Lowest admin distance of route’s routing protocol wins
  • Lowest advertised routing protocol metric
  • Highest LAN IP address
• Prune Override (Join) message: Prevent being pruned off an (S,G) SPT, by sending a Join, when another router prunes itself (on a multi-access network) [RFC3973]
• Graft message: Used to reattach a pruned branch to the delivery tree
• Graft-Ack message: Reply of an RPF neighbour to a Graft message
• PIMv1: Uses PIM Query messages instead of Hello messages
• PIMv1: Is encapsulated in IP with protocol number 2 and uses 224.0.0.2 as a destination address

–

• Designated Router (DR): The PIM-DM or PIM-SM router with the highest IP address becomes DR
• PIM DR is used for IGMPv1 which does not have any means of selecting a Querier. The DR will then function as the IGMP Querier
• PIM DR is not used in combination with IGMPv2

The PIM DR and the “Assert process winner” may be two different routers on the same LAN. The PIM DR sends IGMP Queries, while the Assert process winner is responsible for forwarding Mcasts onto the LAN. The possibility of this happening is reasonable as the DR election is by highest IP and the Assert process goes by the lowest IP.

PIM-DM config:

(config)# ip multicast-routing
(config-if)# ip pim dense-mode (on all interfaces)
MOSPF (RFC1584)

• Multicast extensions to OSPF (Open Shortest Path First)
• Built on top of OSPFv2
• Does not support tunnels
• Not supported by Cisco
• (S,G) based (per area) Source-based trees
• Explicit Join (no flooding but tree is built on-demand)
• Uses IGMP to monitor Mcast group membership
• MOSPF advertises its Mcast capabilities by means of an (Multicast-Capable) MC-bit in the Options field of its LSAs

–

• Intra-area routing: Source and destinations reside in the same area
• Local group database: lists directly attached groups
• IGMP Queries are the responsibility of the OSPF DR
• Both the DR and BDR listen to IGMP Membership Reports
• On a LAN the DR must be an MOSPF router
• the DR sources Group-Membership LSAs (type 6), these are flooded into the backbone (no further)
• Datagram’s Shortest-Path tree: The tree (S,G) is built on demand upon receipt of the first Mcast packet (for a particular S,G pair)
• MOSPF link-state database: Contains source subnetworks (normal OSPF database plus Group-Membership LSAs)
• All routers calculate the same tree
• Flooding of any Mcast packets is not required, but (all area routers) storing MOSPF LSAs is
• Forwarding cache is built from the MOSPF database and the Local group database. It contains the GDA, USA, up and down-stream interfaces & TTL (This is the hop count)
• The forwarding cache is updated when there is a topology change or when there is a change in the Group-Membership LSAs
• Forward costs are used for intra-area Mcast (the unicast route is followed)

–

• Inter-area routing: Source resides in a different area than some of its destination group members
• Interarea Multicast Forwarder (MABR): Is responsible for the forwarding of group membership information and Mcast datagrams between areas
• MABRs advertise their attached group membership info into the backbone area (0), non-backbone areas do not receive any group membership info (They interconnect the various (S,G) source-based trees)
• Wildcard Multicast Receiver (WCMR): Is an MABR that receives(?) Mcast packets
• If group membership of an area or other AS is unknown their MA(S)BRs are added to the tree as WCMRs
• Interarea Datagram’s Shortest-Path tree: A single tree is not possible as SPF is run individually for each area. Nor do MABRs advertise all Mcast information. Topological estimates are made through the use of wild-card receivers and OSPF Summary-Link LSAs
• Reverse costs are used for inter-area Mcast (RPF forwarding, due to Summary-LSAs and AS-External LSAs only advertising costs in reverse direction)

–

• Inter-AS routing:
• Inter-AS Multicast forwarders: ASBR (Multicast Border Router; MBR)
• An MBR is a WCMR(eceiver) for all attached areas
• Assumes an inter-AS Mcast routing protocol which does RFP is in place

*** Sparse Mode protocols

CBT: Core-Based Trees

• Shared Tree
• Protocol independant (like PIM) Uses the existing unicast routing table to build the Shared Tree (does not mean that Mcast and Unicast use the same path)

PIM-SM

• Protocol Independent Multicast – Sparse Mode
• Forwarding state is not built on-demand
• No flooding of Mcast packets, pruned interfaces status is default
• Join messages need to be sent repeatedly to remain joined to the tree
• Same as PIM-DM in the following aspects:
  • PIM Neighbour discovery through exchange of Hello messages
  • Recalculation of the RPF interface when the unicast routing table changes
  • Election of a DR on a multi-access network. The DR performs all IGMP processes when IGMPv1 is in use on the network
  • The use of Prune Overrides on multi-access networks
  • Use of Assert messages to elect a designated forwarder on a multi-access network. The winner of the Assert process is responsible for forwarding unicasts onto that subnet

A Source sends its Mcast packets to the Rendezvous Point (RP). The RP forwards all packets down the shared tree (which was pre-built)

Anyone can send to traffic to the Group via the RP [hence (*.G)], without risking loops.

• The Source’s router must be registered with the RP
• Registration is only accepted if the RP knows of any group members (otherwise there’s no tree to forward anything on)
• The RP sends a Register-Stop if there’s no RPT available, the router trying to register starts a 1 min Register-suppression timer
• Register(-Stop) messages to and from the RP are unicast
• Register messages inform the RP of a Source for a specific Group [the RP does have a (S,G) pair]
• Register messages sent to the RP contain the Multicast packets from the Source until the registration process is completed, thus forwarding is possible before registration is complete
• The RP will forward the encapsulated Mcast packet if it knows any group members to forward it to
• Register-suppression timer: Will prevent a router from swamping an RP with Register messages. 5 sec before the time runs out the router will send another Register message with the Null-Register bit (flag) set (without the Mcast packet as payload)
• Either the RP sends another Register-Stop message or nothing is sent causing the timer to run out
• Once an RP has accepted a Registration it sends a PIM-SM Join message to the ‘sender (router) of the Registration message’
• All routers up to the ‘sender of the Registration message’, including the RP, are added to the SPT. Now the source can send Mcast packets down the tree
• The source router will remain to send Register messages until the RP sends a Register-Stop message (registration is now complete)
• SPT is only used between the source and the RP, RPT is used from the RP to group members (hosts)
• Source to RP = (S,G)
• RP to group members = (*,G)

–

• Shared tree (*,G) [Root-Path Tree (RPT)]
• A router joins a tree when it receives a Join message on an interface other then the upstream port to the RP (lookup RP address in unicast routing table). Or when it receives an IGMP Join message from a locally connected host
• If there are multiple sources for the same group, traffic from all sources would first travel to the RP (via various SPTs) and then travel down the shared-RPT to all group members

–

• RPT to SPT switchover: Cisco routers switch over after receiving the 1st Mcast packet via RPT
• Once a router has received a packet via RPT it knows the source and can Join the SPT
• When a router has successfully joined the SPT it should send a PIM-SM Prune message to the RP. The Prune message refers to the (S,G) SPT and contains the RPT-bit (which informs the RP that the router has switched from RPT to SPT)

PIM-SM config:

(config)# ip multicast-routing
(config-if)# ip pim sparse-mode (on all interfaces)

(config)# ip pim rp-address
Best practice: Use a loopback IP address for the RP

(config)# ip pim spt-threshold
Specifies at which bandwidth a router should switch from RPT to SPT (only locally significant)

Locating RPs

• Static config on each router
• Auto-RP (Cisco proprietary), designate an RP and advertise its IP address to all routers
• BootStrap Router (BSR) protocol, designate an RP and advertise its IP address to all routers

–

Auto-RP: Useful in large networks with many PIM-SM routers and many RPs (Static config becomes unmanageable). Changing an RP (after failure or normally) is extremely cumbersome and service affecting

1. RP announce messages: Sent to 224.0.1.39 every 60 sec. The RP-Announce message also allows the router to advertise the Mcast groups for which it is the RP
2. Mapping agent: Usually the same router as the RP, learns all the RPs and the Mcast groups each one supports. Mcasts RP-Discovery message identifying the RP for each range of Mcast group addresses, to 224.0.1.40. It informs all routers about which RPs to use

• Mapping agent selects the RP with the highest IP as the RP for a group
• Mapping agents can be redundant themselves (define more than one)
• Auto-RP requires PIM sparse-dense mode (Cisco implementation): Use PIM DM to find the RP, switch to PIM SM once the RP is known

BSR: a PIMv2 solution

• Uses 224.0.0.13 (All-PIM-Routers)
• Floods group-to-RP mapping information
• PIM-SM routers then find the best RP
• No need for anything like “PIM sparse-dense mode”

Anycast RP with Multicast Source Discovery Protocol (MSDP):

• Without: Only one active RP per group
• With: Load sharing by having multiple active RPs per group
• Each RP uses the same IP address
• Routers see all RPs as a single RP
• IGP routing is used to get to the closest RP
• Can use Static RP, Auto-RP and BSR
• Only setup capable of load sharing
• Fault recovery is (relatively?) fast

Redundant RPs

• Anycast RP, using Mcast Source Discovery Protocol (MSDP)
• BootStrap Router (BSR)

Bidirectional-PIM

• Like normal PIM-SM, but:

1. Source routers do not register with the RP but send packets up the tree to the RP (multicast packets)
2. RP doesn’t join the SPT for a source nor do leaf routers

*** Router config/show specifics

(10.31.140.18/32, 230.31.0.2), 00:00:33/00:01:56, flags: CT
_Incoming interface: E0, RPF nbr 10.31.141.66
_Outgoing interface list:
__FastEthernet1/3, Forward/Dense, 00:00:33/00:00:00
__Serial0/0, Prune/Dense, 00:00:18/00:02:42

• (S,G), up-time/expiry-time,
• Flags:
  • D = Dense
  • S = Sparse
  • C = Connected (has IGMP hosts connected)
  • L = local
  • P = Pruned
  • R = RP-bit set (S,G) entry is pointing towards the RP
  • F = Register flag
  • T = Forward along the SPT
  • J = Join SPT
• RPF neighbour is upstream to the source
• Egress interface: F1/3, has been forwarding for 33 sec (can not time-out when in Dense-Mode)
• Egress interface: S0/0, was pruned 18 sec ago, in 162 sec. The interface will go back to ‘Forward’ (Prune timer) unless a State Refresh message is received (PIMv2)

(*, 230.31.0.2), 00:00:33/00:01:56, RP 10.31.140.5, flags: SC
_Incoming interface: E0, RPF nbr 10.31.141.66
_Outgoing interface list:
__FastEthernet1/3, Forward/Sparse, 00:00:33/00:02:27

• (*,G), up-time/expiry-time, RP-id,
• Flags: (see Dense mode above)
• RPF neighbour is upstream to the RP
• Egress interface: F1/3, has been forwarding for 33 sec, and will time-out in 147 sec unless another IGMP Join message is received

PIM-SM-DM

• PIM sparse-dense mode

(S,G): Refers to a particular SPT, or to an individual router’s part of a particular SPT, where S is the Source’s IP address and G is the Group address. It’s written as (10.31.140.17, 230.31.0.1)
Group

(*,G): For each (S,G) entry, a Cisco router creates a (*,G) entry as a parent entry (design efficiency). The (*,G) entry is not used for forwarding Mcast traffic for a group that uses PIM-DM