CCIE R&S Written Exam Overview: Multicasting

*To be honest the video for this lesson was extremely painful. I have without a doubt identified my weakest area of the CCIE material. Just look at these notes… what a beast!! Ciscos recommend reading on Multicasting is this badboy:

I think for this particular topic I will really need to get into the book and then go back to the video. It surprised me how detailed this ‘overview’ really was.. The problem as well is I have never touched any kind of multicasting IPv4 network.. so to be an expert at this topic is currently way off!!


IP Multicast

Multicast Section Objectives

• Understand the components of…

– Multicast Addressing

– Multicast Control Plane

– Multicast Data Plane

IPv4 Multicast Addressing

• IPv4 multicast uses Class “D” Addresses

– (–

• Includes reserved ranges

– Link-local Addresses

• ( –

– Source Specific Multicast

• ( –

– Administratively Scoped

• ( –

Multicast Control Plane

• Multicast control plane used to determine

– Who is sending traffic and to what group(s)

– Who is receiving traffic and for what group(s)

– How traffic should be forwarded when it is received

• The Multicast “Tree”

• Control plane is built with a combination of

– Host to Router communication (IGMP)

– Router to Router communication (PIM and MSDP)

Multicast Data Plane

• Once the tree from sender to receiver(s) is built, traffic begins to flow

• Before forwarding, Data Plane checks occur

– Reverse Path Forwarding (RPF) check

• Was traffic received on the correct interface?

– Multicast Routing Table

• What interface(s) should I forward the packets out?

Control Plane – IGMP

• Internet Group Management Protocol

– Used for receiver to signal routers on the LAN that it wants traffic for a specific group

• IGMP host signals membership to router via Report

– IGMPv1/v2 supports only group specific joins

• (*,G) Report

– IGMPv3 supports group and source specific joins

• (S,G) Report

• IOS Router listens for IGMPv1/2 when PIM is enabled

Control Plane – PIM

• Protocol Independent Multicast

– Used for routers to signal each other how to build the Multicast Tree

• “Protocol Independent” because it does not advertise its own topology information

– Implies IGP already runs in the network to build a loop-free topology

• IOS runs PIMv2 by default

PIM Modes

• PIM modes control how the tree is built and who receives what traffic

• Dense Mode

– Considered implicit join

– All traffic unless you say you don’t want it

– Uses Flood & Prune behavior

• Sparse Mode

– Considered explicit join

– No traffic unless you ask for it

– Uses Rendezvous Point (RP) to process join requests

• Sparse Dense Mode

– Sparse for groups with an RP assigned

– Dense for all others

Control Plane – MSDP

• Multicast Source Discovery Protocol

– Used for RPs to signal each other about Multicast Senders

• Originally designed for Inter-AS Multicast

• Can be used for Intra-AS Anycast RP

Data Plane – RPF Check

• PIM does not exchange topology information

– How do we know the network is loop free?

• RPF check prevents loops in the Data Plane

• When packet is received…

– Check source IP address and incoming interface

– If incoming multicast interface == outgoing unicast interface back to source, RPF check passes

– If incoming multicast interface != outgoing unicast interface, RPF check fails and packet is dropped

Data Plane – Multicast Routing Table

• Using PIM, routers learn where sources and receivers exist

– Interface facing upstream towards source is the “incoming interface”

– Interface(s) facing downstream towards receivers make up the “outgoing interface list” or OIL

– Split-horizon like behavior stops an interface from being in OIL if it is already an incoming interface

• If RPF check passes…

– Prefer (S,G) over (*,G) in routing table

– Switch packets from incoming interface to all interfaces in the


PIM Dense Mode

• RFC 3973 “Protocol Independent Multicast – Dense Mode (PIM-DM)”

• Uses “push” model or “implicit join”

– Called flood and prune

– All traffic flooded throughout entire network

– Routers that have no receivers prune (unjoin) unused links

• Only suitable for small multicast implementations

– Doesn’t scale because of flooding and (S,G) state creation

PIM Dense Mode Operation

• Discover PIM neighbors

– (PIM) to find neighbors on attached links

• Flood all multicast traffic

• Prune unwanted traffic

• Multicast table maintenance

– Graft

– Assert

– State Refresh

PIM Dense Mode Flooding

• Router attached to LAN listens for senders

– Sender does not communicate multicast control plane

• Once traffic is received…

– Insert (*,G) and (S,G) into routing table

• Incoming interface is attached to sender

• OIL is all other PIM interfaces

– Flood traffic to OIL

• Next downstream router(s) continue the process

– Flooding results in a Shortest Path Tree (SPT)

PIM Dense Mode Pruning

• Prune used to tell upstream neighbor to stop sending traffic for (S,G)

• Prune occurs if

– Multicast feed fails RPF check

– No downstream neighbors or receivers

– Downstream neighbors have already sent prune

– LAN Prune Override exception

• Once prune occurs, traffic flow stops but (S,G) remains in table

– Even after prune, traffic is periodically re-flooded at a set interval

PIM Dense Mode Graft

• What happens if I have pruned an (S,G), but then I receive an IGMP join from receiver?

• Graft message used as dense mode “join” to un-prune (S,G) from upstream neighbor

– Graft continues up reverse path back towards Source until tree is rebuilt

– Used to speed up convergence and not wait for periodic flooding

PIM Dense Mode Assert

• Used to prune duplicate multicast feed transmissions

– Typically needed when multiple routers attach to the same multicast enabled LAN

• Triggered when (S,G) feed is receive in an interface already in the OIL

• Assert winner determined by

– Lowest metric to source

– Highest IP address if metric is equal

PIM Dense Mode State Refresh

• Normally once an (S,G) is pruned, traffic is reflooded about every 3 minutes

– Limits scalability of dense mode

• State refresh is a keepalive for prune state

– Originated by root of the SPT

– If downstream routers agree, traffic is not reflooded

– Still doesn’t fix (S,G) state information in the routing table

PIM Sparse Mode

• RFC 4601 “Protocol Independent Multicast – Sparse Mode (PIM-SM)”

• Uses “pull” model or “explicit join”

– Traffic is not flooded unless you ask for it

• Uses both Shared Trees (RPT) and Source Based Trees (SPT)

– Dense mode uses only source trees

– More scalable than dense mode and usually the better design choice

Shared vs. Source Trees

• Multicast tree determines how traffic is routed from sender to receivers

• Source based trees

– Uses shortest path from sender to receiver

– Dense mode or sparse mode

• Shared trees

– Uses shortest path from sender to Rendezvous Point (RP), then shortest path from RP to receiver

– Sparse mode only

– Used to eliminate flooding and pruning and make routing table more scalable

PIM Sparse Mode Operation

• Discover PIM neighbors & elect DR

• Discover RP

• Tell RP about sources

• Tell RP about receivers

• Build shared tree from sender to receivers through RP

• Join shortest path tree

• Leave shared tree

• Multicast table maintenance

RP Overview

• RP is used as a reference point for the root of the shared tree

• RP learns about sources through unicast PIM

Register messages

– Register tells the RP about an (S,G)

• RP learns about receivers through PIM Join messages

– Tells the RP to add an interface to the OIL for (*,G)

• RP is used to merge the two trees together

PIM Register Message

• As the root of all shared trees, the RP must know about all sources

• When the first-hop router connected to sender hears traffic, a unicast Register message is sent to the RP

– If multiple first-hop routers, only the DR registers

• If RP accepts this message, it acknowledges with Register Stop and inserts (S,G) into the table

• At this point only DR and RP know (S,G)

PIM Join Message

• As the root of all shared trees, the RP must also know about all receivers

• When a last-hop router receives an IGMP Report, a PIM Join is generated up the reverse path tree towards the RP

• All routers in the reverse path install (*,G) and forward the Join hop-by-hop to the RP

• At this point the RP and all downstream devices towards the receiver know (*,G)

Merging the Trees

• Once the RP knows about both sender and receiver…

– RP sends a PIM Join message up reverse path to source

• All routers in the reverse path from the RP to the source install (*,G) with OIL pointing towards RP

• Once (S,G) begins to flow, the tree is built end to end through the RP

Joining the SPT

• The shared tree is made up of two Shortest Path Trees

– SPT from receiver to RP

– SPT from RP to sender

• SPT from receiver to sender may not be the same as the shared tree

– Result is that Shared Tree is not optimal forwarding

• To fix this, last-hop router…

– Joins SPT to source with (S,G) Join

– Leaves the RPT by sending (*,G) Prune to RP

• Can be modified with ip pim spt-threshold {kbps | infinity} [group-list access-list]

Routing Table Maintenance

• Like PIM Dense Mode, PIM Sparse Mode uses State Refresh to ensure that feeds do not timeout

– (*,G) join sent to RP or up SPT to refresh the OIL

• Sparse Prune message can be used to speed up state information timeout if IGMP Leave is heard from end host

RPF Check and Sparse Mode

• RPF check is different in Sparse vs. Dense

• RP performs RPF on…

– Control Plane PIM Register from DR

– Data Plane packets from Source

• Receivers perform RPF check on…

– RP for (*,G) Shared Tree

– Source for (S,G) SPT

Changing the RPF

• RPF is based on unicast routing table

– Implies changing unicast routing affects multicast routing

• RPF can be modified

– Manually with ip mroute

– Dynamically with Multicast BGP

• RPF controls how tree must be built, not how it can be built

• RPF can be verified with…

– show ip rpf

– show ip mroute count

– debug ip mpacket

Learning the RP’s Address

• Without the RP…

– Sources can’t register

– Joins can’t be processed

• All routers must agree on the same RP address on a pergroup basis

– Registers and joins are rejected for invalid RPs

• RP address can be assigned

– Statically

– Dynamically

• Auto-RP



• Legacy Cisco proprietary method

• Uses two functional roles

– Candidate RP(s)

• Device(s) willing to be the RP

• Sends advertisement to MA via

– Mapping Agent

• Chooses the RP among candidates and relays this information to the rest of the PIM domain

• Sends advertisement to all routers via

Auto-RP Caveats

• Dynamically learned RP mappings are preferred over statically configured ones

• Auto-RP control plane messages are subject to RPF check

• To successfully advertise Auto-RP information

– Mapping Agent must listen for

– Everyone must listen for

• In PIM Sparse Mode

– Cannot join the Auto-RP groups without knowing where the RP is

– Cannot know where the RP is without joining the Auto-RP groups

– Recursive logic

Auto-RP Solutions

• Default RP assignment

– Assign a static RP for groups and

– Defeats the purpose of automatic assignment

• PIM Sparse-Dense Mode

– Dense for groups without an RP

– Sparse for all others

• Auto-RP Listener feature

– Dense for only

– Sparse for others

Bootstrap Router

• Standard per PIMv2

– Functionally similar to Auto-RP

• Defines two roles in BSR domain

– RP Candidate

• Analogous to Candidate RP in Auto-RP

• Uses unicast PIM to advertise itself to the Bootstrap Router

– Bootstrap Router (BSR)

• Analogous to Mapping Agent in Auto-RP

• Advertises RP information to other routers with multicast PIM on a hop-by-hop basis

Bidirectional PIM

• Traditional Sparse Mode forms two trees

– Unidirectional SPT from source to RP

– Unidirectional Shared tree from RP to receivers

• Results in (*,G) and (S,G) entries in control plane

– For many-to-many multicast applications, doesn’t scale well

• Bidirectional PIM solves this by only allowing the Shared Tree (*,G) and never a SPT (S,G)

Source Specific Multicast

• IGMPv2 and PIM Sparse mode use (*,G) Joins to discover sources

– This is why the RP is needed

• IGMPv3 and SSM change these rules

– Clients generate (S,G) IGMPv3 Joins

– Routers build SPT directly to S for G

• Removes the need for RP

– Since no RP, no Register messages

– Source discovery is out of band

• Typically uses address range


• RFC 3618 – Multicast Source Discovery Protocol

• Allows Service Provider to use their own internal RPs

– Don’t rely on internal routing of another AS

• MSDP used to communicate between RPs

– Who are the active multicast sources?

• Does not eliminate the need for PIM

How MSDP Works

• RPs in different ASes peer via MSDP

– TCP transport required

• When RP receives PIM Register for (S,G), it informs

MSDP peers using Source Active (SA) message

– Allows other ASes to know what senders there are

• If another RP receives (*,G) Join for G, (S,G) Join sent to S

– MSDP peers are used just for control, not necessarily data plane

Anycast RP

• Uses anycast load balancing to decentralize the placement of RPs

– PIM Register and Join messages go to the closest RP in the topology

– If one RP goes down, convergence is up to IGP

– As long as one anycast RP is up, network is functional

• Anycast RP Design Issues

– For anycast to work, all RPs must share the same information about senders and receivers

– What if PIM Register is sent to one anycast RP, and PIM Join is sent to another?

• Solution: MSDP

How Anycast RP Works

• Anycast RPs assign a duplicate Loopback address and advertise into IGP

• All routers point to anycast RP address

– Could be static or dynamic assignment

• Anycast RPs are MSDP peers using a unique address

– If three of more RPs, usually a mesh group

• When PIM Register is received, MSDP SA is sent to MSDP peers

– Results in synchronization of (S,G) information