Multicast Brkipm 1261 PDF

#CLUS
Introduction to IP
Multicast
BRKIPM-1261
Beau Williamson
CCIE R/S #1346 Emeritus
CiscoLive Distinguished Speaker
Twitter: @Mr_Multicast
#CLUS
Session Goals • To provide you with an
Agenda understanding of the concepts,
mechanics and protocols used
to build IP multicast networks.
• To enable you to ask the right
questions, and make the
correct architectural decisions
in deploying and maintaining an
IP Multicast enabled network.
• To prove that Multicast doesn’t
have to be:
• Hard
• Scary
#CLUS BRKRST-2095 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Agenda • Multicast Fundamentals
• Source-Specific Multicast Geekometer
(SSM)
• Bidirectional Multicast (Bidir)
• Any-Source Multicast (ASM)
• ASM Redundant RP Choices
• Multicast at Layer 2
• Multicast over MPLS – mLDP
• Bit-Indexed Explicit Replication
– BIER
• Inter-domain IP Multicast
• IPv6 Multicast
Cisco Webex Teams
Questions?
Use Cisco Webex Teams (formerly Cisco Spark)
to chat with the speaker after the session
How
1 Find this session in the Cisco Events App
2 Click “Join the Discussion”
3 Install Webex Teams or go directly to the team space
4 Enter messages/questions in the team space
Webex Teams will be moderated cs.co/ciscolivebot#BRKRST-2095

by the speaker until June 18, 2018.
#CLUS © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 5
Multicast Fundamentals
6
Why Multicast
Unicast vs. Multicast Scaling
Unicast
Server
Router
Number of Streams
Multicast
Server
Router
Multicast Uses
• Any applications with multiple • Server/Website replication
receivers • Reducing network/resource
• One-to-many or many-to-many overhead
• Live video distribution • More than multiple point-to-point
• Collaborative groupware flows
• Periodic data delivery—“push” • Resource discovery

technology • Distributed interactive
• Stock quotes, sports scores, simulation (DIS)
magazines, newspapers, adverts • War games
• Inter Data Center L2 Underlay • Virtual reality
• VXLAN, etc. for BUM
Multicast Considerations
Multicast Is UDP-Based
• Best effort delivery: Drops are to be expected; multicast applications should not expect
reliable delivery of data and should be designed accordingly; reliable multicast is still an
area for much research; expect to see more developments in this area; PGM, FEC, QoS
• No congestion avoidance: Lack of TCP windowing and “slow-start” mechanisms can
result in network congestion; if possible, multicast applications should attempt to detect
and avoid congestion conditions
• Duplicates: Some multicast protocol mechanisms (e.g., asserts, registers, and SPT
transitions) result in the occasional generation of duplicate packets; multicast
applications should be designed to expect occasional duplicate packets
• Out of order delivery: Some protocol mechanisms may also result in out of order
delivery of packets
Multicast Myth Busters
“Multicast is complicated, scary and hard to

understand!”
Unicast vs. Multicast Addressing
12.1.1.1
11.1.1.1
src addr:
10.1.1.1 A unique packet
addressed to each 13.1.1.1
destination IP Address.
Multicast
Group
Address
src addr: e.g. 224.1.1.1
Same packet
10.1.1.1 addressed to “Group”
destination address...
Unicast vs. Multicast Addressing
12.1.1.1
11.1.1.1
src addr:
10.1.1.1 A unique packet
addressed to each 13.1.1.1
destination IP
Address.
Multicast
Group
Address
src addr: e.g. 224.1.1.1
..replicated at
10.1.1.1 each node along
the tree.
Multicast Addressing
IPv4 Header
Version IHL Type of Service Total Length
Identification Flags Fragment Offset
Time to Live Protocol Header Checksum
Source
Source Source Always
Addressthe unique unicast origin address of
1.0.0.0 - 232.255.255.255 (Class A, B, C) the packet – same as unicast
Destination
Destination Destination Address
224.0.0.0 - 239.255.255.255 (Class D) Multicast Group Address Range
Options Padding
Class D Group addresses – 224/4
• Multicast Group addresses are NOT in the unicast route table.
• A separate multicast route table is maintained for active multicast
trees.
• Multicast trees are initiated by receivers signaling their request to
join a group.
• Sources do not need to join, they just send!
• Multicast routing protocols build the trees:
• Hop-by-hop, from the receivers (tree leaves) to the source (tree root).
• Tree path follows the unicast route table backward to the source using
source address.
• i.e. Multicast relies on a dependable unicast infrastructure!
Multicast Addressing—224/4
• Reserved link-local addresses
• 224.0.0.0–224.0.0.255
• Transmitted with TTL = 1
• Examples
• 224.0.0.1 All systems on this subnet
• 224.0.0.2 All routers on this subnet
• 224.0.0.5 OSPF routers
• 224.0.0.13 PIMv2 routers
• 224.0.0.22 IGMPv3
• Other IANA reserved addresses
• 224.0.1.0–224.0.1.255
• Not local in scope (transmitted with TTL > 1)
• Examples
• 224.0.1.1 NTP (Network Time Protocol)
• 224.0.1.32 Mtrace routers
• 224.0.1.78 Tibco Multicast1
Multicast Addressing—224/4
• Administratively scoped addresses
• 239.0.0.0–239.255.255.255
• Private address space
• Similar to RFC1918 unicast addresses
• Not used for global Internet traffic—scoped traffic
• SSM (Source Specific Multicast) range

• 232.0.0.0–232.255.255.255
• Primarily targeted for Internet-style broadcast
IP Multicast MAC Address Mapping
32 Bits
1110 28 Bits
239.255.0.1
5 Bits
Lost
01-00-5e-7f-00-01
25 Bits 23 Bits
48 Bits
IP Multicast MAC Address Mapping
Be Aware of the 32:1 Address Overlap
32–IP Multicast Addresses
224.1.1.1
224.129.1.1
225.1.1.1 1–Multicast MAC Address
225.129.1.1
.
. 0x0100.5E01.0101
.
238.1.1.1
238.129.1.1
239.1.1.1
239.129.1.1
How are Multicast Flows Identified
• Every Multicast Flow can be identified by two components:
• Source IP Address
• The address of the Sender
Multicast Flow from Source 2.2.2.2 to
• Multicast Group Address Group 232.1.1.1
• 224/4 (Class D) IP Address
• Example
(2.2.2.2, 232.1.1.1), 3w1d/00:02:40, flags: s
Incoming interface: Ethernet 0/0, RPF nbr 207.109.83.33
Outgoing interface list:
Ethernet 1/0, Forward/Sparse, 3w1d/00:02:40
• How do Hosts Signal to Routers which flow they want?
• IPv4: IGMP
• IPv6: MLD
Host-Router Signaling: IGMP
• IGMP Version 3 is current version
• RFC3376 Oct 2002 (Over 10 years old!)
• Uses 224.0.0.22 (IGMPv3 routers) Link-Local Multicast Address
• All IGMP hosts send Membership Reports to this address
• All IGMP routers listen to this address
• Hosts do not listen or respond to this address (unlike previous IGMP
versions)
• Membership Reports
• Sent by Hosts
• Contain list of Multicast (Source, Group) pairs to Include/Exclude
(Join/Leave)
• Membership Queries
• Sent by Routers to refresh/maintain list of Multicast traffic to deliver.
IGMPv3
7
– Membership
15 31
Report Packet Format
Type = 0x22 Reserved Checksum 7 15 31
Record Type Aux Data Len # of Sources (N)
Reserved # of Group Records (M)
Multicast Group Address
Group Record [1]
Source Address [1]
Source Address [2]
Group Record [2] .
.
.
. Source Address [N]
.
Auxiliary Data
Group Record [M]
Record Type
Include, Exclude, Chg-to-Include,
# of Group Records (M) Chg-to-Exclude, Allow New Srcs,
Number of Group Records in Report Block Old Srcs
Group Records 1 - M
Group address plus list of zero or # of Sources (N)
more sources to Include/Exclude Number of Sources in Record
(See Group Record format) Source Address 1- N
Address of Source
IGMPv3 – Query Packet Format
Type = 0x11
IGMP Query 7 15 31
Max. Resp. Time Type = 0x11

Max. Resp.
Checksum
Max. time to send a response Code
if < 128, Time in 1/10 secs
if > 128, FP value (12.8 - 3174.4 secs) Group Address
Group Address:
Multicast Group Address S QRV QQIC Number of Sources (N)
(0.0.0.0 for General Queries)
S Flag Source Address [1]
Suppresses processing by routers
QRV (Querier Robustness Value) Source Address [2]
Affects timers and # of retries
QQIC (Querier’s Query Interval) .
.
Same format as Max. Resp. Time
.
Number of Sources (N)
(Non-zero for Group-and-Source Query) Source Address [N]
Source Address
Address of Source
IGMPv3 – Joining Group “G” Source “S”
192.168.102.10 192.168.102.11 192.168.102.12
H1 H2 Type: Allow New (5) H3

Group: 232.1.1.1
Source: {2.2.2.2}
Report
(224.0.0.22)
show ip igmp groups 232.1.1.1 detail
Flags: L - Local, U - User, SG - Static Group, VG - Virtual Group,

SS - Static Source, VS - Virtual Source,
Ac - Group accounted towards access control limit
Interface: GigabitEthernet3/3
Group: 232.1.1.1
Flags: SSM
Uptime: 00:01:14
Group mode: INCLUDE
Last reporter: 192.168.102.11
Member
Group source list: (C - Cisco Src Report, U - URD, R - Remote, S - Static,
V - Virtual, M - SSM Mapping, L - Local, Hn Group: 232.1.1.1
Source: 2.2.2.2
Ac - Channel accounted towards access control limit)
Source Address Uptime v3 Exp CSR Exp Fwd Flags (Destination IP Address)
2.2.2.2 00:01:14 00:02:08 stopped Yes R
IGMPv3 – Maintaining State
192.168.102.10 192.168.102.11 192.168.102.12
H1 Type: Include (1) H2 Type: Include (1) H3 Type: Include (1)

Group: 232.1.1.1 Group: 232.1.1.1 Group: 232.1.1.1
Source: {2.2.2.2} Source: {2.2.2.2} Source: {2.2.2.2}
Report Report Report
(224.0.0.22) (224.0.0.22) (224.0.0.22)
(224.0.0.1)
Query
Group: 0.0.0.0
Source: {}
• Router sends periodic General Queries to All Hosts
• General Query: Group=0, #Srcs=0
• All IGMP members respond Hn
Member
Group: 232.1.1.1
• Reports can contain multiple Group State records Source: 2.2.2.2
(Destination IP Address)
IGMPv3 – Leaving Group “G” Source “S”
192.168.102.10 192.168.102.11 192.168.102.12
2
H1 1 H2 H3
Type: Block Old (6)
Group: 232.1.1.1
Source: {2.2.2.2}
Report
(224.0.0.22)
(232.1.1.1)
Query
3
Group: 232.1.1.1
1. H2 leaves Group-Source Source: {2.2.2.2}
2. Sends “Block Old” Membership Report

3. Router sends Group-Source Query
• Group-Source Query: Group=G, #Srcs=N Hn
Member
Group: 232.1.1.1
Source: 2.2.2.2
192.168.102.10 192.168.102.11 192.168.102.12
H1 H2 H3
Type: Include
Group: 232.1.1.1
Source: {2.2.2.2} 4
Report
(224.0.0.22)
5
1. H2 leaves Group-Source
3. Router sends Group-Source Query
4. A remaining member host sends report Hn
Member
Group: 232.1.1.1
5. Group-Source flow remains active Source: 2.2.2.2
192.168.102.10 192.168.102.11 192.168.102.12
H1 H2 6 H3 Type: Block Old (6)

Group: 232.1.1.1
Source: {2.2.2.2}
Report 7
(224.0.0.22)
(232.1.1.1)
Query
8
Group: 232.1.1.1
Source: {2.2.2.2}
Router sends Group-Source Query
Member
8. Hn Group: 232.1.1.1
Source: 2.2.2.2
192.168.102.10 192.168.102.11 192.168.102.12
H1 H2 H3
Router sends Group-Source specific query
Member
8. Hn Group: 232.1.1.1
Source: 2.2.2.2
9. State times out. Group-Source flow pruned. (Destination IP Address)
Unicast vs. Multicast Routing/Forwarding
Unicast Routing/Forwarding
• Destination IP address directly indicates where to forward packet
• Unicast Routing protocols build a table of
destination/interface/next-hop triples
• Unicast Forwarding is hop-by-hop simply based on these entries
• Unicast routing table determines interface and next-hop router to forward
packet
Multicast Routing & Forwarding
• Destination Group address doesn’t directly indicate where to forward packet.
• Forwarding State must be created to build trees to describe forwarding path.
• Multicast Routing is Backwards from Unicast Routing
• Multicast Routing builds a tree backwards from the receivers to the source.
• Concerned with “Where the packet will come from?”
• More specifically, “What’s the route back to the Source?”
• Trees are built via connection requests (Joins) “sent” toward the source.
• Joins follow the unicast routing table backwards toward the source.
• Joins create Multicast tree/forwarding state in the routers along the tree.
• Trees are rebuilt dynamically in case of network topology changes.
• Only when a tree is completely built from receiver backwards to the source can source
traffic flow down the tree to the receivers.
• Say that over and over to yourself when working with Multicast!
• All of this can easily lead to “thinking with your Unicast Lizard Brain!”
• If you ever get confused by Multicast, just remember to . . .
“Stand on your head!”
Source-Specific
Multicast (SSM)
32
Source Specific Multicast (SSM) Concepts
• Assumes one-to-many model
• Most Internet multicast fits this model
• IP/TV also fits this model
• Hosts responsible for source discovery
• Typically via some out-of-band mechanism
• Web page, Content Server, etc.
• Hosts join a specific source within a group
• Content identified by specific (S,G)
• Dissimilar content sources can use same group “G” without fear of
interfering with each other
• Last-hop router sends (S,G) join toward source
• Only specified (S,G) flow is delivered to host
Multicast Tree Building
• Multicast packet’s source address is checked against the unicast routing table
• Determines interface & next-hop multicast router in the direction of the source
• This is where the Joins are to be sent
• This interface becomes the “Incoming” interface
• Often referred to as the “RPF” (Reverse Path Forwarding) interface
• A router forwards a multicast datagram only if received on the Incoming/RPF interface
• A bit of History
• The term “RPF” is actually a left-over from early Dense mode Multicast days
• Multicast traffic was flooded everywhere (i.e. no explicit Join signaling to build trees)
• Traffic was only accepted on the “RPF” interface to avoid loops
• We still tend to use the term to indicate the calculation of the Incoming interface.
Traffic to
232.1.1.1
Source
2.2.2.2
Receiver
Multicast Traffic
Traffic to
232.1.1.1
Source
2.2.2.2
IGMP “Join”
(2.2.2.2, 232.1.1.1)
Receiver
Forwarding State
Multicast Traffic
Mroute Entry
Traffic to
232.1.1.1
Source
2.2.2.2
PIM Join
(2.2.2.2, 232.1.1.1)
Receiver
Forwarding State Mroute Entry
Multicast Traffic
Mroute Entry
Traffic to
232.1.1.1
PIM Join
(2.2.2.2, 232.1.1.1)
Source
2.2.2.2
Mroute Entry
Receiver
Multicast Traffic
Mroute Entry
Traffic to
232.1.1.1
Source
2.2.2.2
Mroute Entry
Receiver
Multicast Traffic
Mroute Entry
Traffic to
232.1.1.1
IGMP “Join”
(2.2.2.2, 232.1.1.1)
Source Receiver
2.2.2.2
Mroute Entry
Mroute Entry
Receiver
Multicast Traffic
Mroute Entry
Traffic to
232.1.1.1
PIM Join
(2.2.2.2, 232.1.1.1)
Source Receiver
2.2.2.2
Mroute Entry
Mroute Entry
Receiver
Multicast Traffic
Mroute Entry
Traffic to
232.1.1.1
Source Receiver
2.2.2.2
Mroute Entry
Mroute Entry
Receiver
Multicast Traffic
Mroute Entry
Mroute Entry
Traffic to show ip mroute 232.1.1.1

232.1.1.1 (2.2.2.2, 232.1.1.1), 3w1d/00:02:40, flags: s
Source Receiver
2.2.2.2
Mroute Entry
Mroute Entry
Receiver
Forwarding State
Multicast Traffic
Mroute Entry
Mroute Entry
Traffic to show ip mroute 232.1.1.1

232.1.1.1 (2.2.2.2, 232.1.1.1), 3w1d/00:02:40, flags: s
Source Receiver
2.2.2.2
Receiver
Forwarding State
Multicast Traffic
This type of Multicast has a special name: Source Specific Multicast (SSM)
RPF Calculation
• Based on source address SRC 10.1.1.1
• Best path to source found in unicast

A
route table
Determines where to send join
Join
• C
• Joins continue towards source to build B
multicast tree Join D
• Multicast data flows down tree E0 E1

E
E2
Unicast Route Table
Network Interface R1
10.1.0.0/24 E0
RPF Calculation
• Based on source address SRC 10.1.1.1
• Best path to source found in unicast

A
route table Join
• Determines where to send join C
• Joins continue towards source to build B Join
multicast tree D
R2
• Multicast data flows down tree E0 E1

E
E2
R1
RPF Calculation
• What if we have equal-cost paths? SRC 10.1.1.1
• We can’t use both

A
• Tie-breaker
• Use highest next-hop IP address B C
D E
1.1.1.1 Join 1.1.2.1
E0 E1
F
Unicast Route Table E2
Network Intfc Nxt-Hop
10.1.0.0/24 E0 1.1.1.1 R1
10.1.0.0/24 E1 1.1.2.1
Multicast State
Multicast route entries are in (S,G) form.
rtr-a#show ip mroute 232.1.1.1
(2.2.2.2, 232.1.1.1), 3w1d/00:02:40, flags: s
Incoming interface points upstream
toward the root of the tree (i.e. Source)
OIL entries are refreshed by downstream Outgoing interface list (OIL) is where receivers
receivers roughly every 3 minutes or the have joined downstream and where packets
entry times out. [i.e. Soft State] will be replicated and forwarded downstream.
Multicast State
(2.2.2.2, 232.1.1.1), 3w1d/00:02:40, flags: s
rtr-b#show ip route 232.1.1.109

% Network not in table
Multicast Group addresses

are NEVER in the unicast
route table.
Multicast State
(2.2.2.2, 232.1.1.1), 3w1d/00:02:40, flags: s
POP QUIZ QUESTION #1!!

How is the Incoming Interface and
RPF Neighbor determined?
ANSWER:
The best route to the Source IP Address
is looked up in the route table and the RPF
Neighbor is the next upstream PIM neighbor.
Multicast State
(2.2.2.2, 232.1.1.1), 3w1d/00:02:40, flags: s
POP QUIZ QUESTION #2!!

What causes interfaces to be added
to the Outgoing Interface List?
ANSWER:
IGMP “Joins” or PIM Joins that are

received on that interface.
Basic SSM only Multicast Configuration
Assumes only 1:Many Multicast
• Enable Multicast Routing on every router
ip multicast routing
• Configure every interface for Multicast
• IOS-XR – On by default
When ip multicast routing is configured
•
• IOS – ip pim sparse mode
• Configure SSM for all Multicast groups

ip pim ssm range 10
access-list 10 permit 224.0.0.0 15.255.255.255
• Use DNS SSM-Mapping for non-IGMPv3 compatible apps on edge
interfaces
ip igmp ssm-map enable
• Static config-based SSM Mapping is also possible
SSM Mapping – DNS Example
DNS Record Format:
3.2.1.232 IN A 172.23.20.70
Reverse DNS
lookup for
PIM (S,G) join
group G
PIM (S,G) join DNS response:

Group G -> Source
S
IGMPv2 join
Set Top
Box (STB)
• Key Point
• If you ever get confused by Multicast . . .
. . . just remember to “Stand on your head”.
(Because Multicast is an Upside-down world where we are

interested in where the packet came from, not its
destination address.)
Multicast Myth Busters
“Multicast is complicated, scary and hard to

understand!”
See there . . .
. . . that wasn’t so hard, was it?
But wait, my network has Many:Many

Multicast applications!
How do I support them?
Bidirectional Multicast
i.e. Bidir PIM
58
Bidirectional (BiDir) PIM Concepts
Idea:
• Use a common “Shared” Tree to connect all Sources and
Receivers.
• Root this “Shared” Tree at a point in the network called the
Rendezvous Point (RP)
• Traffic flows up the tree from Sources to the RP and then down the
tree to Receivers
• Data traveling from Source toward RP is moving UPSTREAM
• Data traveling from RP toward Receivers is moving DOWNSTREAM
Bidirectional (BiDir) PIM Concepts
Implementation Details:
• Designated Forwarders (DF)
• One DF per link
• Router with best path to the RP is elected DF
• Election mechanism insures all routers on link agree on who is DF
• Prevents route loops from forming
• BiDir (*,G) forwarding rules:

• DF is the only router that picks-up upstream traveling packets off the link
to forward towards the RP
• This is like a constrained L3 Spanning-Tree for the Group
• Constrained because it only “spans” to Sources and Receivers for the
Group
How do hosts Join a
Shared Tree using
IGMPv3?
61
IGMPv3 – Joining a Shared Tree for All Sources
192.168.102.10 192.168.102.11 192.168.102.12
H1 H2 Type: Exclude (2) H3

Group: 239.1.2.21
Source List: {}
Report
(224.0.0.22)
Router#sh ip igmp groups 239.1.2.21 detail
Flags: L - Local, U - User, SG - Static Group, VG - Virtual Group,

SS - Static Source, VS - Virtual Source,
Ac - Group accounted towards access control limit
Interface: GigabitEthernet3/3
Group: 239.1.2.21
Flags:
Uptime: 00:00:22
Group mode: EXCLUDE (Expires: 00:02:49)
Last reporter: 192.168.102.11
Source list is empty
Bidir Forwarding/Tree Building
RP
E0 (DF)
E0 E0
E F
E1 (DF) E1 (DF)
E0 E0 E0 E0
A B C D IGMP (*,G)
E1 (DF) E1 (DF) E1 (DF) E1 (DF)
Join
Receiver 1
RP
E0 (DF)
E0 E0
E F
E1 (DF) E1 (DF)
E0 E0 E0 E0
A B C D
E1 (DF) E1 (DF) E1 (DF) E1 (DF)
(*, 224.1.1.1), 00:00:04/00:00:00, RP 172.16.21.1, flags: BC

Bidir-Upstream: Ethernet0, RPF nbr 172.16.9.1
Receiver 1
Ethernet0, Bidir-Upstream/Sparse-Dense, 00:00:04/00:00:00
Ethernet1, Forward/Sparse-Dense, 00:00:04/00:02:55
Bidir State created in “D”

RP
E0 (DF)
E0 E0
E F PIM (*,G)
E1 (DF) E1 (DF) Join
E0 E0 E0 E0
A B C D
E1 (DF) E1 (DF) E1 (DF) E1 (DF)
(*, 224.1.1.1), 00:00:04/00:00:00, RP 172.16.21.1, flags: BC

Receiver 1
Ethernet1, Forward/Sparse-Dense, 00:00:04/00:02:55
Bidir State created in “F”

RP
PIM (*,G)
E0 (DF) Join
E0 E0
E F
E1 (DF) E1 (DF)
E0 E0 E0 E0
A B C D
E1 (DF) E1 (DF) E1 (DF) E1 (DF)
(*, 224.1.1.1), 00:32:20/00:02:59, RP 172.16.21.1, flags: B

Bidir-Upstream: Null, RPF nbr 0.0.0.0
Ethernet0, Forward/Sparse-Dense, 00:00:04/00:02:55 Receiver 1
Branch of Shared Tree is now built from RP down to Receiver 1

RP
E0 (DF)
E0 E0
E F
E1 (DF) E1 (DF)
E0 E0 E0 E0
A B C D
E1 (DF) E1 (DF) E1 (DF) E1 (DF)
(*, 224.1.1.1), 00:32:20/00:02:59, RP 172.16.21.1, flags: BP

Outgoing interface list: Receiver 1
Source
Arriving Traffic from Source causes Router “A” to create (*, G) State
RP
E0 (DF)
E0 E0
E F
E1 (DF) E1 (DF)
E0 E0 E0 E0
A B C D
E1 (DF) E1 (DF) E1 (DF) E1 (DF)
(*, 224.1.1.1), 00:32:20/00:02:59, RP 172.16.21.1, flags: BP

Source Ethernet0, Bidir-Upstream/Sparse-Dense, 00:32:20/00:00:00
Receiver 1
Arriving Traffic Causes Router “E” to create (*, G) State
RP
E0 (DF)
E0 E0
Bidir State in RP
E (*, 224.1.1.1),F 00:32:20/00:02:59, RP 172.16.21.1, flags: B
E1 (DF) E1 (DF)
Bidir-Upstream: Null, RPF nbr 0.0.0.0
E0 E0 E0
Ethernet0, E0
Forward/Sparse-Dense, 00:00:04/00:02:55
A B C D
E1 (DF) E1 (DF) E1 (DF) E1 (DF)
Source Receiver 1
RP already has (*, G) State
RP
E0 (DF)
E0 E0
E F
E1 (DF) E1 (DF)
E0 E0 E0 E0
A B C D
E1 (DF) E1 (DF) E1 (DF) E1 (DF)
Source Receiver 1
Traffic flows up the Shared Tree . . .

. . . and then back down the Shared Tree
Basic Bidir only Multicast Configuration
• When ip multicast routing is configured
• Enable Bidir Multicast Routing on every router
ip pim bidir enable
• Configure address of Bidir RP for all Multicast groups
ip pim rp-address <ip-address> bidir
Bidir RP Redundancy using Phantom RP
Static route config option
Primary injecting RP Secondary injecting RP

Phantom RP
1.1.1.1
ip multicast-routing ip multicast-routing
interface Loopback0 interface Loopback0

ip address 11.0.0.1 255.255.255.255 ip address 11.0.0.2 255.255.255.255
ip pim sparse-mode ip pim sparse-mode
router ospf 11 router ospf 11

redistribute static subnets redistribute static subnets
ip route 1.1.1.1 255.255.255.255 Loopback0 ip route 1.1.1.0 255.255.255.254 Loopback0
ip pim bidir-enable ip pim bidir-enable

ip pim rp-address 1.1.1.1 bidir ip pim rp-address 1.1.1.1 bidir
What Makes Multicast
Complicated?
73
Biggest Multicast Complicating Factor
Network-Based Source Discovery
• Lazy One-to-Many Application Developers
• “Let’s just let the Network do all the work to keep track of Sources.”
• Uses old and outdated IGMPv2 methods to join (*,G) only.
• Really!!!! IGMPv3 has been out for 10+ years!!
• Even Apple OS supports IGMPv3
• Suffers from Capt. Midnight stream hijacking
• Complicates Multicast Address management/allocation
• Now you have to worry about what application uses what Multicast Address
• Ad-Hoc Multicast Applications
• No “good” way to know or predict who will become a source.
• Sometimes you just have to support Network-Based Source Discovery
• Requires complex Any-Source Multicast (ASM) & Rendezvous Point
Engineering/Mgmt
Or maybe just BiDir Multicast?
Multicast Complicating Factor
Network-Based Source Discovery
• Requires Any-Source Multicast (ASM)
• Much, much more complicated than SSM or Bidir
• Requires physical Rendezvous Point (RP) router(s) & RP Redundancy methods
• Uses Shortest-Path Trees (ala SSM) to first deliver traffic to RP
• Then uses a common “Shared Tree” rooted at RP to deliver all Multicast traffic
• Routers w/directly connected receivers then learn about new sources via
Shared Tree
• Then join Shortest-Path Tree to all the sources.
. . . or maybe just use Bidir Multicast (Bidir)

• A bit more complicated than Source Specific Multicast but easier than ASM.
Any-Source Multicast
i.e. ASM PIM
76
PIM-SM Shared Tree Join
RP
(*, G) State Created Only

(*, G) Join Along the Shared Tree
Shared Tree
Receiver
PIM-SM Sender Registration
RP
Source
(S, G) State Created Only

Traffic Flow Along the Source Tree
Shared Tree
Source Tree
(S, G) Register (unicast) Receiver
(S, G) Join
RP
Source
(S, G) Traffic Begins Arriving at

Traffic Flow the RP via the Source Tree
Shared Tree
Source Tree RP Sends a Register-Stop Back
(S, G) Register (unicast) Receiver to the First-Hop Router to Stop
(S, G) Register-Stop (unicast) the Register Process
RP
Source
Source Traffic Flows Natively

Traffic Flow Along SPT to RP
Shared Tree From RP, Traffic Flows Down
Source Tree the Shared Tree to Receivers
Receiver
PIM-SM SPT Switchover
RP
Source
Last-Hop Router Joins the

Traffic Flow Source Tree
Shared Tree Additional (S, G) State Is
Source Tree Created Along New Part of
(S, G) Join Receiver the Source Tree
RP
Source
Traffic Begins Flowing

Traffic Flow Down the New Branch of
Shared Tree the Source Tree
Source Tree Additional (S, G) State Is Created
(S, G)RP-bit Prune Receiver Along the Shared Tree to Prune
Off (S, G) Traffic
RP
Source
(S, G) Traffic Flow Is Now

Traffic Flow Pruned Off of the Shared Tree
Shared Tree and Is Flowing to the Receiver
Source Tree via the Source Tree
Receiver
RP
Source
(S, G) Traffic Flow Is No

Traffic Flow Longer Needed by the RP so
Shared Tree It Prunes the Flow of (S, G)
Source Tree Traffic
(S, G) Prune Receiver
RP
Source
(S, G) Traffic Flow Is Now Only

Traffic Flow Flowing to the Receiver via a
Shared Tree Single Branch of the Source
Source Tree Tree
Receiver
Basic ASM-Only Multicast Configuration
• When ip multicast routing is configured
• Configure address of ASM RP for all Multicast groups
ip pim rp-address <ip-address>
PIM Frequently Forgotten Fact
The default behavior of PIM-SM (ASM) is that

routers with directly connected members will
join the shortest path tree as soon as they
detect a new multicast source.”
– aka “PIM FFF”
But what about PIM Dense Mode??
“Fuggidaboudit!”
Source: “The Wiseguys’s Guide to IP Multicast”, ©2005, T. Soprano
It does “Flood & Prune” without any Joins!

It can meltdown your network and blackhole your traffic!
Inter-domain IP
Multicast
89
MP-BGP Overview
MP-BGP: Multiprotocol BGP
• Originally defined in RFC 2858 (extensions to BGP)
• Can carry different types of routes
• Unicast
• Multicast
• Both routes carried in same BGP session

• Does not propagate multicast state info
• That’s PIM’s job
• Same path selection and validation rules
• AS-Path, LocalPref, MED…
MP-BGP Overview
• Separate BGP tables maintained
• Unicast prefixes for Unicast forwarding
• Unicast prefixes for Multicast RPF calculation
• AFI = 1, Sub-AFI = 1
• Contains Unicast prefixes for Unicast forwarding
• Populated with BGP Unicast NLRI
• AFI = 1, Sub-AFI = 2
• Contains Unicast prefixes for Multicast RPF calculation
• Populated with BGP Multicast NLRI
MBGP Overview
MBGP Allows Divergent Paths and Policies
• Same IP address holds dual significance
• Unicast Routing information
• Multicast RPF information
• For same IPv4 address two different NLRI with different next-hops
• Can therefore support both congruent and incongruent topologies
Inter-domain Multicast – Simple. Use SSM!
Domain E
MP-BGP Peering
Domain C Receiver
Receiver Learns
S and G Out of
Domain B Band, i.e.,
Webpage
Domain D
Source in 232/8
Source “S” Domain A
Inter-domain Multicast – Simple. Use SSM!
Domain E
MP-BGP Peering
Multicast Traffic
Domain C Receiver
Data flows natively

along the interdomain
Domain B source tree
Domain D
Source in 232/8
Source “S” Domain A
Inter-domain Bidir? – Not really
Historical Issues:
• Deciding who (what SP/ASN) owns RP was problematic.
• Some SP’s wanted their own RP.
• Other SP’s didn’t want RP’s in their network.
• No consensus was ever reached.
• Inter-domain Bidir never got off the ground.
• Don’t hold your breath looking for Inter-domain Bidir support from
Vendors/SPs
Inter-domain ASM
Issues
• Global Group Address Allocation/Management
• With ASM we have to make sure that we use unique Groups
• Otherwise we start mixing up the Multicast flows
• Solution(?): GLOP Addressing

• 233.0.0.0–233.255.255.255
• Put your ASN in the middle two Octets
• Provides /24 group prefix per ASN
Inter-domain ASM
Issues
• How do we do Inter-domain Source Discovery?
• Can we all agree on what domain “owns” the RP?
• And for which Global Multicast Group??
• GLOP Addressing?
• Why not have RP’s in each domain “share” Source information?
• Solution: Multicast Source Discovery Protocol (MSDP)
MSDP – Multicast Source Discovery Protocol
• RFC 3618 - Multicast Source Discovery Protocol (MSDP)
• PIM ASM only solution
• RPs knows about all Sources in their domain
• Sources cause a “PIM Register” to the RP
• RP tells RPs in other domains of it’s Sources
• Uses “MSDP SA” (Source Active) messages
• RPs know about existence of Receivers in their domain

• Receivers cause a “(*, G) Join” to the RP
• RP can join the Source tree in the peer domain
• Uses normal PIM “(S, G) Join”
MSDP Overview
MSDP Example
Domain E
MSDP Peers RP Join (*, 233.3.2.1)
Receiver
Domain C
RP
Domain B
RP
RP
ASN770 Domain D
GLOP: 233.3.2.0/24
RP
Domain A
MSDP Overview
MSDP Example
Domain E
MSDP Peers RP
Source Active SA SA
Receiver
Messages Domain C
RP
SA
Domain B SA
SA
RP
SA RP
SA ASN770 Domain D
SA Message SA Message
GLOP: 233.3.2.0/24
8.1.1.1, 233.3.2.1 RP 8.1.1.1, 233.3.2.1
Source Domain A
Register
8.1.1.1, 233.3.2.1
MSDP Overview
MSDP Example
Domain E
MSDP Peers RP
Receiver
Domain C
RP
Domain B
RP
RP
ASN770 Domain D
GLOP: 233.3.2.0/24
RP
Source Domain A
MSDP Overview
MSDP Example
Domain E
MSDP Peers RP
Multicast Traffic Receiver
Domain C
RP
Domain B
RP
RP
ASN770 Domain D
GLOP: 233.3.2.0/24
RP
Source Domain A
MSDP Overview
MSDP Example
Domain E
MSDP Peers RP
Domain C
RP
Domain B
RP
RP
ASN770 Domain D
GLOP: 233.3.2.0/24
RP
Source Domain A
MSDP Overview
MSDP Example
Domain E
MSDP Peers RP
Domain C
RP
Domain B
RP
RP
ASN770 Domain D
GLOP: 233.3.2.0/24
RP
Source Domain A
ASM Redundant RP
Choices
105
Auto-RP – From 10,000 Feet
MA MA
Announce
Announce
A B
Announce Announce Announce Announce

C D
C-RP C-RP
1.1.1.1 2.2.2.2
Announce
Announce
RP-Announcements Multicast to the
Cisco Announce (224.0.1.39) Group
Announce
Auto-RP – From 10,000 Feet
MA MA
A B
C D
C-RP C-RP
1.1.1.1 2.2.2.2
RP-Discoveries Multicast to the

Cisco Discovery (224.0.1.40) Group
Discovery
Auto-RP Configuration
Global Configuration Commands
• Candidate RPs
ip pim send-rp-announce <interface> scope <ttl> [group-list <acl>] [interval <rp-announce-interval>] [ bidir ]
• Primary address of <interface> is used as RP-address
• If <interface> goes down, C-RP messages are not sent (use Loopback)
• Mapping Agents
ip pim send-rp-discovery [<interface>] scope <ttl> [interval <interval>]
• Configure <interface> as Loopback Interface.
• Same reason recommended for C-RP
• Auto-RP Listeners
ip pim autorp listener
• Enable on all routers (even MA and C-RPs)
• Enables all routers to listen to (and forward) RP-Announce and RP-Discover messages
• Allowing us to move away from old IOS sparse-dense operation.
BSR – From 10,000 Feet
BSR Election Process
C-BSR
C-BSR C-BSR
A
D F
B C
BSR Msgs
E
BSR Msgs Flooded Hop-by-Hop
Highest Priority
C-BSR
Is Elected as G
BSR
BSR
A
D F
B C
BSR
A
D F
C-RP B C C-RP
BSR
A
D F
C-RP B C C-RP
BSR Msgs
E
BSR Msgs Containing RP-SET
Flooded Hop-by-Hop
BSR Configuration
Global Configuration Commands
• Candidate-BSR (C-BSR)
ip pim bsr-candidate <interface> <hash-length> <priority> [accept-rp-candidate <acl>]
• BSR election:
• C-BSR with highest <priority> becomes BSR
• Tie-breaker: Highest-IP-Address
• Preemption by better C-BSR at any time
• Candidate RP (C-RP)
ip pim rp-candidate <interface> [group-list <acl> | bidir | interval <rp-announce-interval> | priority <priority>]
• All parameters as in AutoRP C-RP – except <priority>
Anycast-RP w/MSDP: Intra-domain use of MSDP
• Anycast-RP w/MSDP
• Redundant RP technique for ASM which uses MSDP for RP
synchronization
• Uses single defined RP address
• Two or more routers have same RP address
• RP address defined as a loopback interface
• Loopback address advertised as a host route
• First/Last hop Routers Join/Register with closest RP
• Closest RP determined from the unicast routing table
• Because RP is statically defined
• MSDP session(s) run between all RPs
• Informs RPs of Sources in other parts of network
• RPs join SPT to active Sources as necessary
Anycast RP w/MSDP – Overview
Src Src
RP1 RP2
MSDP
X
A SA SA B
10.1.1.1 10.1.1.1
Rec Rec Rec Rec
Anycast RP w/MSDP – Overview
Src Src
RP1 RP2
X
A B
10.1.1.1 10.1.1.1
Rec Rec Rec Rec
Anycast RP w/MSDP – Basic Configuration
Src Src
RP1 RP2
MSDP
A (Established via TCP) B
10.1.1.1 10.1.1.1

description -> anycast RP description -> anycast RP
Rec Rec
ip address 10.1.1.1 255.255.255.255
ip pim sparse-mode
Rec
ip address 10.1.1.1 255.255.255.255
ip pim sparse-dense-mode
Rec
ip msdp peer 10.10.10.2 connect-source Loopback10 ip msdp peer 10.10.10.1 connect-source Loopback20
ip msdp originator-id Loopback2 ip msdp originator-id Loopback2
ip pim rp-address 10.1.1.1 ip pim rp-address 10.1.1.1
Anycast-RP w/PIM only
Goal: Anycast RP without using another protocol i.e. MSDP
• RFC4610 – Anycast-RP w/PIM only
• Redundant RP technique for ASM which uses PIM Registers for RP
synchronization
• Uses single defined RP address
• Two or more routers have same RP address
• RP address defined as a loopback interface
• Loopback address advertised as a host route
• First/Last hop Routers Join/Register with closest RP
• Closest RP determined from the unicast routing table
• Because RP is statically defined
• PIM Register messages exchanged between all RPs
• Informs RPs of Sources in other parts of network
• RPs join SPT to active Sources as necessary
Anycast RP w/PIM Registers – Overview
Src
RP1 PIM Anycast RP Neighbors RP2

A PIM Register PIM Register Stop B
10.1.1.1 10.1.1.1
Rec Rec Rec Rec
Src Src

X
A PIM Register Stop PIM Register B
10.1.1.1 10.1.1.1
Rec Rec Rec Rec
Src Src
RP1 RP2
X
A B
10.1.1.1 10.1.1.1
Rec Rec Rec Rec
Anycast RP w/PIM Registers – Basic
Configuration

A B
10.1.1.1 10.1.1.1

description -> anycast RP description -> anycast RP
ip pim sparse-mode ip pim sparse-mode

ip pim anycast-rp 10.1.1.1 10.10.10.1 ip pim anycast-rp 10.1.1.1 10.10.10.1

ip pim anycast-rp 10.1.1.1 10.10.10.2 ip pim anycast-rp 10.1.1.1 10.10.10.2
ip pim rp-address 10.1.1.1 ip pim rp-address 10.1.1.1
Multicast at Layer 2
123
L2 Multicast Frame Switching
Problem: Layer 2 Flooding of Multicast Frames
• Typical L2 switches treat multicast traffic as unknown or broadcast
and must “flood” the frame to every port
PIM
• Static entries can sometimes be set to specify which ports should
receive which group(s) of multicast traffic
• Dynamic configuration of these entries would cut down on user
administration
Multicast M
IGMP Snooping
• L2 switches now “listen to” and intercept IGMP & PIM packets
• Builds “multicast mac table”. Prevents flooding (like unicast)

• Mrouter Ports: Ports connected to a PIM Router
• Dynamically learned upon hearing IGMP Queries or PIM Hellos PIM
• Forward IGMP joins, leaves & mcast data to this port towards PIM router
Switch# show ip igmp snooping mrouter

Type: S - Static, D – Dynamic
Vlan Router-port Type Uptime Expires

143 Eth8/11 D 4w1d 00:04:59 e8/11
Po1
IGMP Snooping
• L2 switches now “listen to” and intercept IGMP & PIM packets
• Builds “multicast mac table”. Prevents flooding (like unicast)

• Mrouter Ports: Ports connected to a PIM Router
• Dynamically learned upon hearing IGMP Queries or PIM Hellos PIM
• Forward IGMP joins, leaves & mcast data to this port towards PIM router
• Member Ports: Ports that have received an IGMP join
• Vlan: Vlan in which the above Member Port belongs
• Multicast Group: Group the member port has joined.
e8/11
Switch# show ip igmp snooping groups
Type: S - Static, D - Dynamic, R - Router port
Vlan Group Address Ver Type Port list Po1
143 225.131.38.2 v2 D Po1
Multicast over MPLS
with mLDP
– The 60,000’ View
127
Multipoint Label Distribution Protocol – mLDP
Why mLDP?
• Customers running MPLS in their network want to run Multicast
natively over MPLS
• MPLS forwarding plane is shared between unicast and multicast
• i.e. unicast MPLS features are applied to multicast
• Separation of data plane and control plane has advantages
Terminology
• P2MP - Point to Multi-point
• Like a PIM SSM tree
• MP2MP – Multi-Point to Multi-Point
• Like a PIM Bidir tree
• MP LSP – Multi-Point LSP, either P2MP or MP2MP
• Label Mapping
• Like a PIM Join
• Label Withdraw
• Like a PIM Prune
Why mLDP?
• Simplification compared to PIM
• No shared tree / source tree switchover
• No (S,G,R) prune’s
• No DR election
• No PIM registers
• No Asserts
• No Periodic messaging
• No Auto-RP/BSR
Extensions to LDP
• mLDP is an extension to the IETF LDP RFC 3036.
• Procedures are documented in IETF RFC 6388
• Joined effort by multiple vendors and customers.
• mLDP reuses LDP protocol packets and neighbor adjacencies.
• mLDP is a client of the LDP infrastructure.
• mLDP allows the creation of P2MP and MP2MP LSPs
• We refer to these as Multipoint LSPs (MP LSPs).
BIER –
Bit-Indexed Explicit
Replication
132
BIER history
• A team was formed to investigate solutions for multicast in the
context of Segment Routing.
• Encoding a Sourced routed Multicast tree path using MPLS labels is
difficult.
• The packet header would get very large, and its very hard to parse
such header.
The BIER Epiphany
• Only encode the end-receivers in the packet header.
• Not the intermediate nodes.
• Assign end-receivers a Bit Position from a Bit String.
• The smallest identifier possible.
• Encode the Bit String in the packet header.
• Using some sort of encapsulation.
• Create a Bit Forwarding Table on all BIER nodes to allow multicast
packet forwarding using the Bit String in the packet.
• Derived from the RIB, SPF based.
• We call it, Bit Indexed Explicit Replication (BIER).
BIER – Basic Idea
A/32
B/32
BIER Domain
D/32
6 5 4 3 2 1
BitString/BFR-ID
C/32
F/32
E/32
1. Assign a unique Bit Position/BFR-ID1 from a BitString to each BFER2 in the
domain.
1Bit-Position = BIER Forwarding Router-ID
2BFER = Bit-Forwarding Egress Router
BIER – Basic Idea
A/32
B/32
LSA
6 - A/32
LSA
5 – B/32 BIER Domain LSA
1 – E/32
LSA D/32
LSA LSA 6 5 4 3 2 1
4 – C/32
3 – E/32 2 – D/32
BitString/BFR-ID
C/32
F/32
E/32
1. Assign a unique Bit Position/BFR-ID1 from a BitString to each BFER2 in the domain.
2. BFERs flood their BFR-Id/BFR Prefix to the Domain using the IGP (OSPF, ISIS)
BIER – Basic Idea
A/32
B/32
BitMask Nbr
0011 A
0100 B
1000 C
D/32
C/32
F/32
E/32
3. Each router in the BIER Domain builds Bit-Mask to BFR Prefix mapping table

BIER Bit-Mask Forwarding Table
BIER Bit-Mask Forwarding Table is based on shortest path to each BFR-ID
BM Nbr BM Nbr BM Nbr
D
0111 B 0011 C 0001 D
0100 E 0010 F
BFR-ID 1
BS:0001
A B C
F
E
BFR-ID 2
BM Nbr BFR-ID 3 BS:0010
BS:0100
0011 C
B
Forwarding Packets
D
0111 B 0011 C 0001 D
AND
0100 E 0010 F
BFR-ID 1
0001 BS:0001
A B C
Suppose A leans about D’s interest,

F
in the blue multicast flow. E
BFR-ID 2
(via BGP, SDN, STATIC, etc…) BS:0010
BM Nbr BFR-ID 3
BS:0100
0011 C
B
Forwarding Packets

&0111
D
0111 B 0011 C 0001 D
AND
0100 E 0010 F
BFR-ID 1
0001 0001 BS:0001
A B C
• Result from the bitwise AND (&) between
the Bit Mask in the packet and the
Forwarding table is copied in the packet
for each neighbor.
F
E
• This is the key mechanism to prevent BFR-ID 2
duplication. BM Nbr BFR-ID 3 BS:0010
BS:0100
0011 C
B
Forwarding Packets

&0111 &0011 &0001
D
0111 B 0011 C 0001 D
AND AND AND
0100 E 0010 F
BFR-ID 1
0001 0001 0001 BS:0001
A B C
for each neighbor.
F
E
BS:0100
0011 C
B
Forwarding Packets
D
0111 B 0011 C 0001 D
AND
0100 E 0010 F
BFR-ID 1
0111 BS:0001
A B C
Suppose A leans about D, E and F’s interest,

F
in the blue multicast flow. E
BFR-ID 2
(via BGP, SDN, STATIC, etc…) BS:0010
BM Nbr BFR-ID 3
BS:0100
0011 C
B
Forwarding Packets

&0111 &0011 &0001
D
0111 B 0011 C 0001 D
AND AND AND
0100 E &0100 0010 F &0010
BFR-ID 1
0111 0111 0011 BS:0001
A B C
for each neighbor.
F
E
BS:0100
0011 C
AND
B
Failure to reset bits when Forwarding Packets

0111 B &0111 0011 C &0011 0001 D &0001
AND AND AND D
0100 E &0100 0010 F &0010
BFR-ID 1
0111 0111 0111 BS:0001
A B C
Duplicate
0111
F
Packets!! E BFR-ID 2
BM Nbr BFR-ID 3 BS:0010
BS:0100
0011 C
AND B
IPv6 Multicast
145
IPv4 vs. IPv6 Multicast
IP Service IPv4 Solution IPv6 Solution
Address Range 32-Bit, Class D 128-Bit (112-Bit Group)
Protocol-Independent
Protocol-Independent
Routing All IGPs and BGP4+
All IGPs and GBP4+
with v6 Mcast SAFI
PIM-DM, PIM-SM:
Forwarding PIM-SM: ASM, SSM, BiDir
ASM, SSM, BiDir
Group Management IGMPv1, v2, v3 MLDv1, v2
Domain Control Boundary/Border Scope Identifier
MSDP Across Independent PIM Single RP Within Globally Shared

Interdomain Source Discovery
Domains Domains
IPv6 Multicast Addresses
per RFC 4291
128 bits
8 4 4
FF Flags Scope Group-ID
1111 1111 Flags T or Lifetime, 0 if Permanent, 1 if Temporary

P for Unicast-based Assignments
F F R P T Scope
Flags = R for Embedded RP
Others Are Undefined and Must Be Zero
8 bits 8 bits
1 = interface-local
2 = link 4
= admin-local Note: Other scopes (6, 7, 9-
Scope = 5 = site D) are unassigned but can
8 = organization be used
E = global
0, 3, F = reserved
IPv6 Layer 2 Multicast Addressing Mapping
RFC 2464 IPv6 Multicast Address
112 Bits
8 4 4 80 32
FF Flags Scope High-Order Low-Order
80 Bits Lost
• Similar to IPv4: 5 bits are lost
• (28 significant L3 multicast bits are mapped into 23 L2 MAC bits) 33-33-xx-xx-xx-xx
48 Bits
• More than 1 multicast address (in fact 2^80) will map to the Ethernet MAC Address
same MAC address.
• For example: FF02::1  33-33-00-00-00-01
FF3E::1  33-33-00-00-00-01
• Pick multicast group addresses that give distinct multicast MAC addresses
Unicast-based Multicast addresses
RFC 3306
8 4 4 8 8 64 32
FF Flags Scope Rsvd Plen Network-Prefix Group-ID
• RFC 3306 – Unicast-based Multicast Addresses

– Similar to IPv4 GLOP Addressing (233/8 + ASN = 256 group addresses)
– Solves IPv6 global address allocation problem.
– Flags = 00PT
P = 1, T = 1 => Unicast-based Multicast address
– Example
Content provider’s unicast prefix
1234:5678:9abc::/48
Multicast address
FF3E:0030:1234:5678:9abc::1 (hex “30” is 48 bits)
IPv6 Multicast Tree Building & Forwarding
• PIM-Sparse Mode (PIM-SM)
• RFC4601
• PIM Source Specific Mode (SSM)
• RFC3569 SSM overview (v6 SSM needs MLDv2)
• Unicast, prefix-based multicast addresses ff30::/12
• SSM range is ff3X::/96
• PIM Bi-Directional Mode (BiDir)
• RFC5015 – Bidirectional PIM (BIDIR-PIM)
RP Mapping Mechanisms for IPv6
• Static RP assignment
• BSR
• Embedded RP
• No Auto-RP!
• No current plans for Auto-RP at Cisco or IETF
• No Anycast RP w/MSDP!
• Because MSDP is not supported in IPv6
• No current plans for IPv6 MSDP at Cisco or IETF
Embedded RP Addressing
Multicast Address with Embedded RP address – RFC3956
8 4 4 4 4 8 64 32
FF Flags Scope Rsvd RPadr Plen Network-Prefix Group-ID
• Proposed new multicast address type
• Uses unicast-based multicast addresses (RFC 3306)
• RP address is embedded in multicast address
• Flag bits = 0RPT
• R = 1, P = 1, T = 1  Embedded RP address
• Network-Prefix::RPadr = RP address
• For each unicast prefix you own, you now also own:
• 16 RPs for each of the 16 multicast scopes (256 total) with 2^32 multicast groups assigned to
each RP (2^40 total)
Embedded RP Addressing – Example
Multicast Address with Embedded RP address
8 4 4 4 4 8 64 32
FF Flags Scope Rsvd RPadr Plen Network-Prefix Group-ID
FF76:0130:1234:5678:9abc::4321
1234:5678:9abc::1
Resulting RP address
Multicast Listener Discover—MLD
• MLD is equivalent to IGMP in IPv4
• MLD messages are transported over ICMPv6
• Version number confusion
• MLDv1 corresponds to IGMPv2
• RFC 2710
• MLDv2 corresponds to IGMPv3, needed for SSM
• RFC 3810
• MLD snooping
• RFC4541 – Considerations for IGMP & MLD Snooping Switches
Conclusion
155
Now You Know…
• Multicast Fundamentals
• Source-Specific Multicast (SSM)
• Bidirectional Multicast (Bidir)
• Any-Source Multicast (ASM)
• ASM Redundant RP Choices
• Multicast at Layer 2
• Multicast over MPLS – mLDP
• Bit-Indexed Explicit Replication – BIER
• Inter-domain IP Multicast
• IPv6 Multicast
Complete your online session evaluation
Give us your feedback to be entered

into a Daily Survey Drawing.
Complete your session surveys through
the Cisco Live mobile app or on
www.CiscoLive.com/us.
Don’t forget: Cisco Live sessions will be available for viewing
on demand after the event at www.CiscoLive.com/Online.
Continue
your Demos in
the Cisco
Walk-in
self-paced
Meet the
engineer
Related
sessions
education campus labs 1:1
meetings
Thank you
#CLUS
#CLUS

Multicast Brkipm 1261 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Multicast Brkipm 1261 PDF

Uploaded by

Copyright:

Available Formats

#CLUS

Webex Teams will be moderated cs.co/ciscolivebot#BRKRST-2095

• Periodic data delivery—“push” • Resource discovery

“Multicast is complicated, scary and hard to

Identification Flags Fragment Offset

Time to Live Protocol Header Checksum

• SSM (Source Specific Multicast) range

Max. Resp. Time Type = 0x11

H1 H2 Type: Allow New (5) H3

show ip igmp groups 232.1.1.1 detail

Flags: L - Local, U - User, SG - Static Group, VG - Virtual Group,

H1 Type: Include (1) H2 Type: Include (1) H3 Type: Include (1)

• Reports can contain multiple Group State records Source: 2.2.2.2

2. Sends “Block Old” Membership Report

5. Group-Source flow remains active Source: 2.2.2.2

H1 H2 6 H3 Type: Block Old (6)

“Stand on your head!”

Traffic to show ip mroute 232.1.1.1

Traffic to show ip mroute 232.1.1.1

• Best path to source found in unicast

• Joins continue towards source to build B

multicast tree Join D

• Multicast data flows down tree E0 E1

• Best path to source found in unicast

• Determines where to send join C

• Joins continue towards source to build B Join

• Multicast data flows down tree E0 E1

• We can’t use both

rtr-b#show ip route 232.1.1.109

Multicast Group addresses

POP QUIZ QUESTION #1!!

POP QUIZ QUESTION #2!!

IGMP “Joins” or PIM Joins that are

• Configure SSM for all Multicast groups

PIM (S,G) join DNS response:

• If you ever get confused by Multicast . . .

. . . just remember to “Stand on your head”.

(Because Multicast is an Upside-down world where we are

“Multicast is complicated, scary and hard to

. . . that wasn’t so hard, was it?

But wait, my network has Many:Many

How do I support them?

• BiDir (*,G) forwarding rules:

H1 H2 Type: Exclude (2) H3

Router#sh ip igmp groups 239.1.2.21 detail

Flags: L - Local, U - User, SG - Static Group, VG - Virtual Group,

(*, 224.1.1.1), 00:00:04/00:00:00, RP 172.16.21.1, flags: BC

Bidir State created in “D”

(*, 224.1.1.1), 00:00:04/00:00:00, RP 172.16.21.1, flags: BC

Bidir State created in “F”

(*, 224.1.1.1), 00:32:20/00:02:59, RP 172.16.21.1, flags: B

Branch of Shared Tree is now built from RP down to Receiver 1

(*, 224.1.1.1), 00:32:20/00:02:59, RP 172.16.21.1, flags: BP

(*, 224.1.1.1), 00:32:20/00:02:59, RP 172.16.21.1, flags: BP

Arriving Traffic Causes Router “E” to create (*, G) State

RP already has (*, G) State

Traffic flows up the Shared Tree . . .

Primary injecting RP Secondary injecting RP

interface Loopback0 interface Loopback0

router ospf 11 router ospf 11

ip route 1.1.1.1 255.255.255.255 Loopback0 ip route 1.1.1.0 255.255.255.254 Loopback0

ip pim bidir-enable ip pim bidir-enable

. . . or maybe just use Bidir Multicast (Bidir)