Brkipm 1261

BRKIPM-1261-rev5
Introduction to IP
Multicast
Beau Williamson
CCIE R/S #1346 Emeritus
CiscoLive Distinguished Speaker
Twitter: @Mr_Multicast
BRKIPM-1261
Cisco Spark
Questions?
Use Cisco Spark to communicate
with the speaker after the session
How
1. Find this session in the Cisco Live Mobile App
2. Click “Join the Discussion”
3. Install Spark or go directly to the space
4. Enter messages/questions in the space
Cisco Spark spaces will be cs.co/clus17/#session ID

available until July 3, 2017. E.g: session ID = BRKCOL-1800
BRKIPM-1261 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public
Other IP Multicast Sessions @ CiscoLive
• BRKIPM-2264 – Troubleshooting Multicast
• Wednesday, Jun 28, 8:00 a.m. - 10:00 a.m. | Level 2, Mandalay Bay A
• BRKIPM-2249 – Segment Routing and Multicast

• Monday, Jun 26, 4:00 p.m. - 5:30 p.m. | Level 3, Palm D
• LABCCIE-3010 – CCIE SP - Multicast VPN

• M,Tu,W,Th, 10:00 a.m. - 10:45 a.m. | WISP 77
• LABMPL-2005 – Introduction to Multicast Label Distribution (mLDP)

• M,Tu,W,Th, 10:00 a.m. - 10:45 a.m. | WISP 78
• LTRMPL-3103 – Next Generation Multicast VPN

• Monday, Jun 26, 8:00 a.m. - 12:00 p.m. | MGM Grand, Level 1, Room 108
• BRKIPM-3017 – Advanced mVPN Deployment Models

• Tuesday, Jun 27, 4:00 p.m. - 5:30 p.m. | Level 3, South Seas
• BRKSPV-2919 – Video Transport Architectures

• Wednesday, Jun 28, 1:30 p.m. - 3:30 p.m. | Level 2, Reef B
BRKIPM-1261 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 4
Session Goals
• To provide you with an
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
BRKIPM-1261
Agenda
• Multicast Fundamentals Geekometer
• 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
BRKIPM-1261
Multicast Fundamentals
BRKIPM-1261 7
Why Multicast
Unicast vs. Multicast Scaling
Unicast
Server
Router
Number of Streams
Multicast
Server
Router
Multicast Uses
• Any applications with multiple receivers • Server/Website replication
• One-to-many or many-to-many
• Reducing network/resource
• Live video distribution overhead
• More than multiple point-to-point flows
• Collaborative groupware
• Resource discovery
• Periodic data delivery—“push” technology
• Stock quotes, sports scores, magazines, • Distributed interactive simulation
newspapers, adverts (DIS)
• 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
src addr: Address
10.1.1.1 e.g. 224.1.1.1
Same packet
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
src addr: Address
10.1.1.1 e.g. 224.1.1.1
..replicated at each
node along the
tree.
Multicast
MulticastAddressing
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
Multicast Addressing
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
225.129.1.1 1–Multicast MAC Address
.
.
.
238.1.1.1 0x0100.5E01.0101
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 – Membership Report Packet Format
7 15 31
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 Max. Resp.

Type = 0x11 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
Member
Last reporter: 192.168.102.11
Group source list: (C - Cisco Src Report, U - URD, R - Remote, S - Static, Hn Group: 232.1.1.1
Source: 2.2.2.2
V - Virtual, M - SSM Mapping, L - Local,
Ac - Channel accounted towards access control limit) (Destination IP Address)
Source Address Uptime v3 Exp CSR Exp Fwd Flags
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
Member
• All IGMP members respond Hn Group: 232.1.1.1
Source: 2.2.2.2
• Reports can contain multiple Group State records (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
Source: {2.2.2.2}
1. H2 leaves Group-Source
2. Sends “Block Old” Membership Report
3. Router sends Group-Source Query Member
Hn Group: 232.1.1.1
• Group-Source Query: Group=G, #Srcs=N Source: 2.2.2.2
(Destination IP Address)
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
3. Router sends Group-Source Query
4. A remaining member host sends report Hn
Member
Group: 232.1.1.1
Source: 2.2.2.2
5. Group-Source flow remains active
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}
8. Router sends Group-Source Query Member
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
7. Sends Remove Membership Report
8. Router sends Group-Source specific query Member
Hn Group: 232.1.1.1
9. State times out. Group-Source flow pruned. Source: 2.2.2.2
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)
BRKIPM-1261 33
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
1. Multicast packet’s source address is checked against the unicast routing table
2. Determines interface & next-hop multicast router in the direction of the source
• This is where the Joins are to be sent
3. 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 10.1.1.1
SRC
• Best path to source found in unicast route table

A
• Determines where to send join
Join
• Joins continue towards source to build multicast tree C
• Multicast data flows down tree B
Join D
E0 E1
E
E2
Unicast Route Table
Network Interface R1
10.1.0.0/24 E0
RPF Calculation
• Based on source address 10.1.1.1
SRC
• Best path to source found in unicast route table

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

R2
D
E0 E1
E
E2
R1
RPF Calculation
• What if we have equal-cost paths? 10.1.1.1
SRC
• We can’t use both
• Tie-breaker A
• 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
BRKIPM-1261 59
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?
BRKIPM-1261 62
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

• 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?
BRKIPM-1261 74
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
BRKIPM-1261 77
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 the
(S, G) Join Receiver 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 Pruned

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

Traffic Flow Longer Needed by the RP so It
Shared Tree 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

• Configure address of ASM RP for all Multicast groups
ip pim rp-address <ip-address>
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.”
– PIM Frequently Forgotten Fact
But what about PIM Dense Mode??
“Fuggidaboudit!”
“Fuggidaboudit!”
Source: “Thesource
Click to edit 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
BRKIPM-1261 90
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
BRKIPM-1261 106
Auto-RP – From 10,000 Feet
Announce
Announce
MA MA
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 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
BRKIPM-1261 124
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
BRKIPM-1261 128
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
BRKIPM-1261 133
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 LSA
5 – B/32 BIER Domain 1 – E/32
LSA D/32 6 5 4 3 2 1
LSA LSA
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

0111 B 0011 C 0001 D
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

0111 B 0011 C 0001 D
AND D
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:0100
0011 C
B
Forwarding Packets

0111 B &0111 0011 C 0001 D
AND D
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 F
each neighbor.
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 B &0111 0011 C &0011 0001 D &0001
AND AND AND D
0100 E 0010 F
BFR-ID 1
0001 0001 0001 BS:0001
A B C
Forwarding table is copied in the packet for F
each neighbor.
E
BS:0100
0011 C
B
Forwarding Packets

0111 B 0011 C 0001 D
AND D
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:0100
0011 C
B
Forwarding Packets
Nbr Nbr Nbr

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

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
0111
Duplicate Packets!!
F
E
BFR-ID 2
Nbr BFR-ID 3 BS:0010
BS:0100
0011 C
AND
B
IPv6 Multicast
BRKIPM-1261 146
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-D)
Scope = 5 = site are unassigned but can be
8 = organization 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
BRKIPM-1261 156
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. A daily winner will
receive a $750 gift card.
• 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.
BRKIPM-1261 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public
Continue Your Education
• Demos in the Cisco campus
• Walk-in Self-Paced Labs
• Lunch & Learn
• Meet the Engineer 1:1 meetings
• Related sessions
Please join us for the Service Provider Innovation Talk featuring:
Yvette Kanouff | Senior Vice President and General Manager, SP Business
Joe Cozzolino | Senior Vice President, Cisco Services
Thursday, July 14th, 2016

11:30 am - 12:30pm, In the Oceanside A room
What to expect from this innovation talk

• Insights on market trends and forecasts
• Preview of key technologies and capabilities
• Innovative demonstrations of the latest and greatest products
• Better understanding of how Cisco can help you succeed
Register to attend the session live now or

watch the broadcast on cisco.com
BRKIPM-1261
Thank you
BRKIPM-1261

Brkipm 1261

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Brkipm 1261

Hochgeladen von

Copyright:

Verfügbare Formate

BRKIPM-1261-rev5

Cisco Spark spaces will be cs.co/clus17/#session ID

• BRKIPM-2249 – Segment Routing and Multicast

• LABCCIE-3010 – CCIE SP - Multicast VPN

• LABMPL-2005 – Introduction to Multicast Label Distribution (mLDP)

• LTRMPL-3103 – Next Generation Multicast VPN

• BRKIPM-3017 – Advanced mVPN Deployment Models

• BRKSPV-2919 – Video Transport Architectures

• Source-Specific Multicast (SSM)

Multicast Myth Busters

“Multicast is complicated, scary and hard

Identification Flags Fragment Offset

Time to Live Protocol Header Checksum

• Other IANA reserved addresses

• SSM (Source Specific Multicast) range

Be Aware of the 32:1 Address Overlap

32–IP Multicast Addresses

• How do Hosts Signal to Routers which flow they want?

Max. Resp. Time Max. Resp.

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)

H1 H2 6 H3 Type: Block Old (6)

“Stand on your head!”

• Hosts responsible for source discovery

• Hosts join a specific source within a group

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 route table

• Multicast data flows down tree B

• Best path to source found in unicast route table

• Joins continue towards source to build multicast tree C

• Multicast data flows down tree B Join

• Use highest next-hop IP address

rtr-a#show ip mroute 232.1.1.1

rtr-b#show ip route 232.1.1.109

Multicast Group addresses

rtr-a#show ip mroute 232.1.1.1

POP QUIZ QUESTION #1!!

rtr-a#show ip mroute 232.1.1.1

POP QUIZ QUESTION #2!!

IGMP “Joins” or PIM Joins that are

• Configure every interface for Multicast

DNS Record Format:

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 Myth Busters

“Multicast is complicated, scary and hard

. . . 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