ip multicast survival guide part 1cisco-users.org/zips/20160302_dfwcug ip multicast... · 2016. 3....

IP Multicast Survival Guide I-2nd Edition-rev4.pptx

IP Multicast Survival Guide Part 1

Second Edition

Beau WilliamsonCCIE 1356 R/S Emeritus

CiscoLive Distinguished Speakeraka “Multicast Survivorman”

Twitter: @Mr_Multicast

2IP Multicast Survival Guide I-2nd Edition-rev4.pptx

Rules of Engagement“Silence . . . I kill you!”

– I mean your Cell Phones and Laptops that is.– Violators must buy Beer for everyone in the room!

Ask questions at any time.– 10,000 Bonus Points awarded for Good Questions– 20,000 Bonus Points awarded for Great Questions– 30,000 Bonus Point deduction for “intentionally” stumping presenter

• Remember: I haven’t touched this stuff in years so I’m a bit rusty.


To give you some basic IP Multicast survival tools that will help you understand the concepts, mechanics and protocols used in IP Multicast and to go alone and unafraid into the CCIE Lab Wilderness1.

1You still may be asked to perform unnatural network acts in your CCIE lab.

Survival Guide Goal


AgendaWhy Multicast?Multicast FundamentalsPIM ProtocolsPIM VariantsRP choicesConfiguration Notes

Geekometer


Why Multicast?


Server

Router

Unicast

Server

Router

Multicast

Unicast vs. Multicast

Number of streams!


Example: Audio StreamingAll clients listening to the same 8 Kbps audio

• Enhanced Efficiency: Controls network traffic and reduces server and CPU loads

• Optimized Performance: Eliminates traffic redundancy• Distributed Applications: Makes multipoint applications possible

00.20.40.60.8

TrafficMbps

1 20 40 60 80 100# Clients

MulticastUnicast

Multicast Advantages


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

• 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) may 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 Is UDP Based!!!

Multicast Disadvantages


Multicast Fundamentals



Multicast Myth Busters

“Multicast is complicated, scary and hard to understand!”


IP Multicast Group Concept

2. If you send to a group address, all members receive it

1. You must be a “member” of a group to receive its data

3. You do not have to be a member of a group to send to a group

“Non” GroupMember

B

E

A D

C

GroupMember 2

Group Member 1

Group Member 3

Receiver Receiver

Sender & Receiver

Sender


Multicast Addressing IPv4 Header

Options Padding

Time to Live Protocol Header Checksum

Identification Flags Fragment Offset

Version IHL Type of Service Total Length

Source Address

Destination AddressDestination

Source

224.0.0.0 - 239.255.255.255 (Class D) Multicast Group Address RangeDestination

1.0.0.0 - 223.255.255.255 (Class A, B, C)Source

Multicast Addressing


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 Routers

Other 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

GLOP (honest, it’s not an acronym)– 233.0.0.0 - 233.255.255.255– Provides /24 group prefix per ASN


32 Bits28 Bits

25 Bits 23 Bits48 Bits

01-00-5e-7f-00-01

1110

5 BitsLost


IP Multicast MAC Address Mapping

239.255.0.1


224.1.1.1224.129.1.1225.1.1.1225.129.1.1

.

.

.238.1.1.1238.129.1.1239.1.1.1239.129.1.1

0x0100.5E01.0101

1 - Multicast MAC Address

32 - IP Multicast Addresses


Be Aware of the 32:1 Address Overlap

IP Multicast MAC Address Mapping


How are Multicast Flows Identified Every Multicast Flow can be identified by two components:

– Source IP Address• The address of the Sender

– Multicast Group Address• 224/4 (Class D) IP Address

Example(2.2.2.2, 232.1.1.1), 3w1d/00:02:40, flags: sIncoming interface: Ethernet 0/0, RPF nbr 207.109.83.33Outgoing interface list:Ethernet 1/0, Forward/Sparse, 3w1d/00:02:40Ethernet 2/0, Forward/Sparse, 2w0d/00:02:33

How do Hosts Signal to Routers which flow they want?– IPv4: IGMP– IPv6: MLD

Multicast Flow from Source 2.2.2.2 to Group 232.1.1.1


Host-Router Signaling: IGMP IGMP Version 3 is current version

– RFC3376 Oct 2002 (Over 10 years old)

Uses 224.0.0.22 (All 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.

• General Queries• Group Specific Queries• Source-Group Specific Queries


IGMPv3 – Membership Report Packet Format

# of Group Records (M)Number of Group Records in Report

Group Records 1 - MGroup address plus list of zero or more sources to Include/Exclude(See Group Record format)

Record Type(1) Include, (2) Exclude, (3) Chg-to-Include, (4) Chg-to-Exclude, (5) Allow New Srcs, (6) Block Old Srcs

# of Sources (N)Number of Sources in Record

Source Address 1- NAddress of Source

7 15 31Reserved ChecksumType = 0x22

Reserved # of Group Records (M)

Group Record [1]

Group Record [2]

Group Record [M]

.

.

.

7 15 31Aux Data Len # of Sources (N)Record Type

Multicast Group Address

Source Address [1]Source Address [2]

.

.Source Address [N]

Auxiliary Data


IGMPv3 – Query Packet FormatType = 0x11

IGMP Query Max. Resp. Time

Max. time to send a responseif < 128, Time in 1/10 secsif > 128, FP value (12.8 - 3174.4 secs)

Group Address:Multicast Group Address(0.0.0.0 for General Queries)

S FlagSuppresses processing by routers

QRV (Querier Robustness Value)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 AddressAddress of Source

Group Address

7 15 31

Source Address [N]

.

.

.

Source Address [1]

Source Address [2]

Type = 0x11 Max. Resp. Code Checksum

QQIC Number of Sources (N)QRVS


IGMPv3 – Joining Group “G” Source “S”

Type: Include (1)Group: 232.1.1.1Source: {2.2.2.2}

Report(224.0.0.22)

192.168.102.10 192.168.102.11 192.168.102.12

H1 H2 H3H2

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/3Group: 232.1.1.1Flags: SSM Uptime: 00:01:14Group mode: INCLUDELast reporter: 192.168.102.11Group source list: (C - Cisco Src Report, U - URD, R - Remote, S - Static,

V - Virtual, M - SSM Mapping, L - Local,Ac - Channel accounted towards access control limit)

Source Address Uptime v3 Exp CSR Exp Fwd Flags2.2.2.2 00:01:14 00:02:08 stopped Yes R


IGMPv3 – Querier Election192.168.102.10 192.168.102.11 192.168.102.12

H1 H2 H3

192.168.102.254

(224.0.0.1)Query

Group: 0.0.0.0Source List: {}192.168.102.253

IGMPQuerier

IGMPNon-Querier

(224.0.0.1)Query

Group: 0.0.0.0Source List: {}

Initially all routers send out a query Router with lowest IP address “elected” querier Other routers become “non-queriers”


IGMPv3 – Maintaining State

Router sends periodic General Queries to All Hosts– General Query: Group=0, #Srcs=0

All IGMP members respond– Reports can contain multiple Group State records

(224.0.0.1)Query

Group: 0.0.0.0Source List: {}


Report(224.0.0.22)


Report(224.0.0.22)


Report(224.0.0.22)

H1 H2 H3

192.168.102.10 192.168.102.11 192.168.102.12

MemberGroup: 232.1.1.1Source: 2.2.2.2

Hn

(Destination IP Address)


IGMPv3 – Leaving Group “G” Source “S”

1. H2 leaves Group-Source2. Sends “Block Old” Membership Report3. Router sends Group-Source Query

– Group-Source Query: Group=G, #Srcs=N

Type: Block Old (6)Group: 232.1.1.1Source: {2.2.2.2}

Report(224.0.0.22)

H1 H2 H3H3

(232.1.1.1)Query

Group: 232.1.1.1Source List: {2.2.2.2}

1

3

2H2

192.168.102.10 192.168.102.11 192.168.102.12


Hn




1. H2 leaves Group-Source2. Sends “Block Old” Membership Report3. Router sends Group-Source Query4. A remaining member host sends report5. Group-Source flow remains active

Type: IncludeGroup: 232.1.1.1Source: {2.2.2.2}

Report(224.0.0.22)

H1 H2 H3H3

4

5

192.168.102.10 192.168.102.11 192.168.102.12


Hn



(232.1.1.1)Query

Group: 232.1.1.1Source: {2.2.2.2}

8

Type: Block Old (6)Group: 232.1.1.1Source: {2.2.2.2}

Report(224.0.0.22)


6. H3 leaves Group-Source7. Sends “Block Old” Membership Report8. Router sends Group-Source Query

H1 H2 H36

7

H3

192.168.102.10 192.168.102.11 192.168.102.12


Hn




6. H3 leaves Group-Source7. Sends Remove Membership Report8. Router sends Group-Source specific query9. State times out. Group-Source flow pruned.

H1 H2 H3

9

192.168.102.10 192.168.102.11 192.168.102.12


Hn



Unicast vs. Multicast Routing/Forwarding

Destination IP address directly indicates where to forward packetUnicast Routing protocols build a table of

destination/interface/next-hop triplesUnicast Forwarding is hop-by-hop simply based on these entries

–Unicast routing table determines interface and next-hop router to forward packet

Unicast Routing/Forwarding



Destination Group address doesn’t directly indicate where to forward packet. 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 called 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!

Multicast Routing & Forwarding



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!”


Multicast Tree Building1. Multicast source address is checked against the unicast routing table2. Determines interface & next-hop multicast router in the direction of the source

– Which is where the Joins are sent3. 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.



Source2.2.2.2

Receiver

Traffic to232.1.1.1



Source2.2.2.2

Receiver

Traffic to232.1.1.1

IGMP “Join”(2.2.2.2, 232.1.1.1)

Mroute Entry



Source2.2.2.2

Receiver

Traffic to232.1.1.1

PIM Join(2.2.2.2, 232.1.1.1)

Mroute Entry

Mroute Entry



Source2.2.2.2

Receiver

Traffic to232.1.1.1

PIM Join(2.2.2.2, 232.1.1.1)

Mroute Entry

Mroute Entry

Mroute Entry



Source2.2.2.2

Receiver

Traffic to232.1.1.1

Mroute Entry

Mroute Entry

Mroute Entry



Source2.2.2.2

Receiver

Traffic to232.1.1.1

Mroute Entry

Mroute Entry

Mroute Entry

Receiver

IGMP “Join”(2.2.2.2, 232.1.1.1)

Mroute Entry



Source2.2.2.2

Receiver

Traffic to232.1.1.1

Mroute Entry

Mroute Entry

Mroute Entry

Receiver

PIM Join(2.2.2.2, 232.1.1.1)

Mroute Entry



Source2.2.2.2

Receiver

Traffic to232.1.1.1

Mroute Entry

Mroute Entry

Mroute Entry

Receiver

Mroute Entry



Source2.2.2.2

Receiver

Traffic to232.1.1.1

Receiver

Mroute Entry

show ip mroute 232.1.1.1(2.2.2.2, 232.1.1.109), 3w1d/00:02:40, flags: sIncoming interface: Ethernet 0/0, RPF nbr 207.109.83.33Outgoing interface list:Ethernet 1/0, Forward/Sparse, 3w1d/00:02:40Ethernet 2/0, Forward/Sparse, 2w0d/00:02:33


Multicast Tree Building

Based on source addressBest path to source found in

unicast route tableDetermines where to send

joinJoins continue towards

source to build multicast treeMulticast data flows down

tree

RPF Calculation

R1

C

D

10.1.1.1

E1

E2Unicast Route Table

Network Interface10.1.0.0/24 E0

Join

Join

A

E0

E

SRC

B



Based on source addressBest path to source found in

unicast route tableDetermines where to send

joinJoins continue towards

source to build multicast treeMulticast data flows down

tree

RPF Calculation

R1

C

D

A

R2

10.1.1.1

E1E0

E2E

Join

Join

SRC

B



What if we have equal-cost paths?–We can’t use both

Tie-breaker–Use highest next-hop IP

address

RPF Calculation

R1

B C

D E

A

10.1.1.1

E1E0

E2Unicast Route TableNetwork Intfc Nxt-Hop10.1.0.0/24 E0 1.1.1.110.1.0.0/24 E1 1.1.2.1

1.1.2.11.1.1.1 Join

F

SRC


Multicast State

rtr-a#show ip mroute 232.1.1.1(2.2.2.2, 232.1.1.1), 3w1d/00:02:40, flags: sIncoming interface: Ethernet 0/0, RPF nbr 207.109.83.33Outgoing interface list:Ethernet 1/0, Forward/Sparse, 3w1d/00:02:40Ethernet 2/0, Forward/Sparse, 2w0d/00:02:33

Multicast route entries are in (S,G) form.

Incoming interface points upstreamtoward the root of the tree (i.e. Source)

Outgoing interface list is where receivers have joined downstream and where packetswill be replicated and forwarded downstream.

rtr-b#show ip route 232.1.1.109% Network not in table

Multicast Group addressesare NEVER in the unicast route table.



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?



What you have just seen is calledPIM Single Source Multicast

or PIM-SSM

Best used for all One-to-Many applications which covers most common Multicast applications


But my Application is not One-to-Many it’s Many-to-Many so I can’t use SSM!


Types of Multicast Trees


Receiver 3

Multicast Distribution Tree TypesShortest Path or Source Distribution Tree (used by SSM)

Notation: (S1, G)S = SourceG = Group

Receiver 1

Source 1

Receiver 2

Source 2B D FA

C E


Multicast Distribution TreesShortest Path or Source Distribution Tree (used by SSM)

Receiver 1

Source 1 Notation: (S2, G)S = SourceG = Group

Receiver 2

Source 2A B D F

C

These are the type of trees we’ve been talking about so far.

Receiver 3E


Multicast Distribution TreesShared Distribution Tree (Unidirectional)

Notation: (*, G)* = All SourcesG = Group

(RP) PIM Rendezvous PointShared Tree

Receiver 1

Source 1

Receiver 2

Source 2A B FD

C E

RP


Multicast Distribution TreesShared Distribution Tree (Unidirectional)


(RP) PIM Rendezvous Point

Source Tree(s)(used to get traffic to RP)

Receiver 1

Source 1

Receiver 2

Source 2F

C E

DARP

B

Shared Tree

(This is PIM-ASM. More on this later.)


Multicast Distribution TreesBidir Shared Distribution Tree


(RP) PIM Rendezvous Point

Shared Tree (Up)

Receiver 1

Source 1

Receiver 2

Source 2F

C E

DARP

B

Shared Tree (Down)


Bidirectional Multicasti.e. Bidir PIM


Bidirectional (BiDir) PIM Idea:

– Use Shared Tree to bring traffic up from sources to the RP and then down to receivers– Receivers IGMP Join “ALL” Sources in Group (*, G)

Benefits:– Less state in routers

• Only (*, G) state is used• Source traffic follows the Shared Tree

– Flows up the Shared Tree to reach the RP– Then flows down the Shared Tree to reach all receivers


PIM Modifications for BiDir Operation All trees rooted at a point in the network

– This point is called the Rendezvous Point or RP– Data traveling from source toward RP is moving UPSTREAM– Data traveling from RP toward receivers is moving DOWNSTREAM

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?


Router#sh ip igmp groups 239.1.2.21 detail


Interface: GigabitEthernet3/3Group: 239.1.2.21Flags:Uptime: 00:00:22Group mode: EXCLUDE (Expires: 00:02:49)Last reporter: 192.168.102.11Source list is empty

IGMPv3 – Joining a Shared Tree for All Sources (*,G)

Type: Exclude (2)Group: 239.1.2.21

Source List: {}Report

(224.0.0.22)

192.168.102.10 192.168.102.11 192.168.102.12

H1 H2 H3H2


Bidir Forwarding/Tree Building

E

A B CE1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

Receiver 1

F

D IGMP (*,G)Join

E0 (DF)

RP



Bidir State created in “D”

E

A B CE1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

Receiver 1

F

(*, 224.1.1.1), 00:00:04/00:00:00, RP 172.16.21.1, flags: BCBidir-Upstream: Ethernet0, RPF nbr 172.16.9.1Outgoing interface list:

Ethernet0, Bidir-Upstream/Sparse-Dense, 00:00:04/00:00:00Ethernet1, Forward/Sparse-Dense, 00:00:04/00:02:55

D

E0 (DF)

RP



Branch of Shared Tree Is Now Built Down to Receiver 1

E

A B CE1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

Receiver 1

PIM (*,G)Join

PIM (*,G)JoinE0 (DF)

D

RP

F



Bidir State in RPE

A B CE1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

Receiver 1

F

D

E0 (DF)

(*, 224.1.1.1), 00:32:20/00:02:59, RP 172.16.21.1, flags: BBidir-Upstream: Null, RPF nbr 0.0.0.0Outgoing interface list:

Ethernet0, Forward/Sparse-Dense, 00:00:04/00:02:55

RP



E

B CE1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

Receiver 1

F

D

(*, 224.1.1.1), 00:32:20/00:02:59, RP 172.16.21.1, flags: BPBidir-Upstream: Ethernet0, RPF nbr 172.16.7.1Outgoing interface list:

Ethernet0, Bidir-Upstream/Sparse-Dense, 00:32:20/00:00:00Source

Arriving Traffic from Source Causes Router “A” to Create (*, G) State

E0 (DF)

RP

A



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

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E0 (DF)

Receiver 1

A B CE1 (DF)

E0

E1 (DF)

E0

F

D

RP

(*, 224.1.1.1), 00:32:20/00:02:59, RP 172.16.21.1, flags: BPBidir-Upstream: Ethernet0, RPF nbr 172.16.7.1Outgoing interface list:

Ethernet0, Bidir-Upstream/Sparse-Dense, 00:32:20/00:00:00

E



RP already has (*, G) StateSource

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E0 (DF)

Receiver 1

E

A B CE1 (DF)

E0

E1 (DF)

E0

F

D

Bidir State in RP(*, 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.0Outgoing interface list:

Ethernet0, Forward/Sparse-Dense, 00:00:04/00:02:55

RP



Traffic flows up the Shared Tree . . .Source

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E1 (DF)

E0

E0 (DF)

Receiver 1

E

A B CE1 (DF)

E0

E1 (DF)

E0

F

D

RP

. . . and then back downthe Shared Tree


What Makes Multicast Complicated?


Biggest Multicast Complicating FactorNetwork-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 BiDir Multicast


Multicast Complicating FactorNetwork-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 just use of Bidir Multicast (Bidir) . . .– A bit more complicated than Source Specific Multicast but easier than ASM.


Joining Group with IGMPv2


Joining/Leaving with IGMPv2 Key Differences with IGMPv3

– Membership Reports (Joins) sent to Group being Joined• i.e. Destination IP Address = Group Address

– Not a separate IGMP Control Group (224.0.0.22)• Reports (Joins) are mixed in with Group Data flows• All members hear each other’s “Joins”.• Permits Report suppression techniques to be used.• One Report packet needed per Group to be Joined/Renewed

– Only Group Joins (*,G) possible• No Source Include/Exclude List in the “Joins”• Not compatible with SSM

– Unless you use special tricks like SSM Mapping

– Leaving is basically the same for both V2 and V3• Except V3 has (S,G) Source-Group Specific as well as Group Specific (*,G) Queries

– Used when Host leaves (S,G) in SSM


IGMPv2 – Joining a Group

Joining host sends Report to 232.1.1.1 to receive ALL sources for group– Note: Control (Report) and Data using same Group address

Type: 0x16 (IGMPV2 Report)Group: 232.1.1.1

(232.1.1.1)

192.168.102.10 192.168.102.11 192.168.102.12

H1 H2 H3H2


Router#show ip igmp groups 232.1.1.1 detail


Interface: GigabitEthernet3/3Group: 232.1.1.1Flags:Uptime: 00:00:22Group mode: EXCLUDE (Expires: 00:02:49)Last reporter: 192.168.102.11Source list is empty

IGMPv2 – Joining a Group192.168.102.10 192.168.102.11 192.168.102.12

H1 H2 H3H2


IGMPv2 – Maintaining a Group


(232.1.1.1)

192.168.102.10 192.168.102.11 192.168.102.12

H1 H2 H3H2 Type: 0x16 (IGMPV2 Report)Group: 232.1.1.1

(232.1.1.1)


(232.1.1.1)

Router sends periodic General Queries– General Query: Group Field = 0.0.0.0

One member per group per subnet reports first Other members hear first report and suppress theirs

(224.0.0.1)Query

Group: 0.0.0.0

X X


IGMPv2 – Leaving a Group

Type: 0x17 (IGMPV2 Leave)Group: 232.1.1.1

(232.1.1.1)

192.168.102.10 192.168.102.11 192.168.102.12

H1 H2 H3H2

(224.0.0.1)Query

Group: 232.1.1.1

Last host leaves group; sends Leave message Router sends Group specific query No report is received Group times out


Any-Source Multicasti.e. ASM PIM

(The original Sparse Mode PIM)


PIM-SM Shared Tree Join

Receiver

RP

(*, G) JoinShared Tree

(*, G) State Created OnlyAlong the Shared Tree


PIM-SM Sender Registration

Receiver

RP

(S, G) Join

Source

(S, G) Register (unicast)Source Tree

(S, G) State Created OnlyAlong the Source TreeTraffic Flow

Shared Tree



Receiver

RPSource

Shared TreeSource Tree RP Sends a Register-Stop Back

to the First-Hop Router to Stop the Register Process(S, G) Register-Stop (unicast)

Traffic Flow

(S, G) Register (unicast)

(S, G) Traffic Begins Arriving at the RP via the Source Tree



Receiver

RPSource

Shared TreeSource Tree

Traffic FlowSource Traffic Flows NativelyAlong SPT to RPFrom RP, Traffic Flows Downthe Shared Tree to Receivers


PIM-SM SPT Switchover

Receiver

RP

(S, G) Join

Source

Source TreeShared Tree

Last-Hop Router Joins the Source TreeAdditional (S, G) State Is Created Along New Part of the Source Tree

Traffic Flow



Receiver

RPSource


(S, G)RP-bit Prune

Traffic Begins Flowing Down the New Branch of the Source TreeAdditional (S, G) State Is Created Along the Shared Tree to Prune Off (S, G) Traffic

Traffic Flow



Receiver

RPSource


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

Traffic Flow



Receiver

RPSource


(S, G) Traffic Flow Is No Longer Needed by the RP so It Prunes the Flow of (S, G) Traffic

Traffic Flow

(S, G) Prune



Receiver

RPSource


(S, G) Traffic Flow Is Now Only Flowing to the Receiver via a Single Branch of the Source Tree

Traffic Flow


All of the PIM modes you have seen so far (SSM, Bidir & ASM) are variations of PIM

Sparse Mode.


But What about PIM Dense Mode???


PIM-DM Uses Flood and Prune model

– Floods network and prunes back based on multicast group membership

Data Driven Events– Forwarding state created by data arrival.– Assert mechanism used to prune off redundant flows.– Non-Deterministic Behavior

• Can lead to black-holes and route loops


PIM-DM Flood & Prune

Source

Initial Flooding

Receiver

Multicast Packets(S, G) State created inevery router in the network!



Source

Pruning unwanted traffic

Receiver

Multicast Packets

Prune Messages



Results after Pruning

Source

Receiver

Multicast Packets

Flood & Prune processrepeats every 3 minutes!!!

(S, G) State still exists inevery router in the network!


PIM-DM Assert Mechanism

E0

Incoming Multicast Packet(Successful RPF Check)

E0

S0S0

Routers receive packet on an interface in their “oilist”!!– Only one router should continue sending to avoid

duplicate packets.

1

2 Routers send “PIM Assert” messages– Compare distance and metric values– Router with best route to source wins– If metric & distance equal, highest IP adr wins– Losing router stops sending (prunes interface)

1Assert

Assert

22


Receiver

Initial Flow

Source

Multicast Packets

PIM-DM Assert Problem

Receiver

Duplicate Traffic


Receiver

Sending Asserts

Source

Multicast Packets


Receiver

Assert Messages

Loser

Winner


Receiver

Assert Loser Prunes Interface

Source

Multicast Packets


Receiver

Loser

Winner


Receiver

Assert Winner Fails

Source

Multicast Packets


ReceiverX

Loser

Winner

Traffic flow is cutoffuntil Prune times outon Assert Loser.


Source

Interface previously Prunedby Assert Process

Normal Steady-State Traffic Flow

RPF Interface

Potential PIM-DM Route Loop


Interface Fails

Source

This Router converges first

RPF Interface

X



Source

RPF Interface

XBut wait . . .This Router stillhasn’t converged yet

New Traffic Flow

Multicast Route Loop ! !



Click to edit source

“Fuggidaboudit!”“Fuggidaboudit!”Source: “The Wiseguys’s Guide to IP Multicast”, ©2005, T. Soprano

So what about PIM Dense Mode??


Protocol Summary

“Sparse Mode Good, Dense Mode Bad!”

Source: “The Caveman’s Guide to IP Multicast”, ©2000, R. Davis

CONCLUSION #1


Protocol Summary

“SSM and/or Bidir Sweet, ASM Nasty!”

Source: “Everyone that has ever had to deal with Network-based Source Discovery.

CONCLUSION #2


RP Configuration(For ASM & Bidir)


How Does the Network Learn RP Address? Static configuration

– Manually on every router in the PIM domain

AutoRP– Originally a Cisco® solution– Facilitated PIM-SM early transition

BSR– RFC 5059 – Bootstrap Router Mechanism for PIM

Anycast RP– Form of Static RP– Two routers share RP address– Requires MSDP


Static RPs• Hard-configured RP address

‒ When used, must be configured on every router‒ All routers must have the same RP address‒ RP failover not possible

• Exception: If Anycast RPs are used

• Commandip pim rp-address [group-list ] [override]

‒ Optional group list specifies group range• Default: range = 224.0.0.0/4 (includes auto-RP groups!)

‒ Override keyword “overrides” auto-RP information• Default: auto-RP learned info takes precedence


Auto-RP – From 10,000 Feet

Announce AnnounceAn

noun

ceAn

noun

ceAnnounce Announce

Anno

unce

Anno

unce

Announce

RP-Announcements Multicast to theCisco Announce (224.0.1.39) Group

A

C DC-RP

1.1.1.1C-RP

2.2.2.2

B

MA MA


A

C DC-RP

1.1.1.1C-RP

2.2.2.2

B

MA MA

Auto-RP – From 10,000 Feet

Discovery

RP-Discoveries Multicast to theCisco Discovery (224.0.1.40) Group


E

G

A

BSR – From 10,000 Feet

B C

C-BSR

F

C-BSR

D

C-BSR

BSR Election Process

BSR Msgs

BSR Msgs Flooded Hop-by-Hop



Highest Priority C-BSRIs Elected as BSR

BSR

E

A

B C

FD

G


BSR

C-RP


C-RP

E

A

B C

FD

G


A

C-RPC-RP


BSR Msgs

BSR Msgs Containing RP-SETFlooded Hop-by-Hop

BSR

E

B C

FD

G

A


Anycast RP (with MSDP) Overview

MSDP

RecRec RecRec

Src Src

SA SAA10.1.1.1B

RP2

10.1.1.1

X

1

RP1


Failover time based on Unicast

Convergence

Anycast RP (with MSDP) Overview

RecRec RecRec

SrcSrc

A10.1.1.1

B

RP2

10.1.1.1

1

XRP1


Configuration Notes


Group Mode vs. Interface Mode Group & Interface mode are independent.

– Interface Mode• Determines how the interface operates when sending/receiving multicast traffic.

– Group Mode• Determines whether the group is Sparse or Dense.• Based on knowledge of an RP for the Group or . . .• If SSM is configured for the Group


Configuring Interface Interface Mode Configuration Commands

– Enables multicast forwarding on the interface.– Controls the interface’s mode of operation.ip pim dense-mode

• Interface mode is set to Dense mode operation.ip pim sparse-mode

• Interface mode is set to Sparse mode operation.ip pim sparse-dense-mode

• Interface mode is determined by the Group mode.– If Group is Dense, interface operates in Dense mode.– If Group is Sparse, interface operates in Sparse mode.


Group Mode Group mode is controlled by local RP info

– Local RP Information• Stored in the Group-to-RP Mapping Cache• May be statically configured or learned via Auto-RP or BSR

– If RP info exists, Group = Sparse or Bidir• Depends on RP configuration

– If RP info does not exist, Group = Dense– Mode Changes are automatic.

• i.e. if RP info is lost, Group falls back to Dense!

Exception – SSM ip pim ssm {default | acl}

• Default is 232.0.0.0• Use acl to for other group ranges

– Overrides everything forcing groups into SSM mode


Dense Mode Fallback Caused by loss of local RP information in older IOS releases.

– Entry in Group-to-RP mapping cache times out. Can happen when:

– All C-RP’s fail.– Auto-RP/BSR mechanism fails.

• Generally a result of network congestion. Group is switched over to Dense mode.

– Dense mode state is created in the network.– Dense mode flooding begins if interfaces configured with

ip pim sparse-dense-mode.– All existing PIM-SM SPT’s are dropped!


Summary – PIM Configuration Steps Enable Multicast Routing on every router

ip multicast-routing

Configure every interface for PIM Sparse-Modeip pim sparse-mode

Configure the RP– Using Auto-RP or BSR (see next slides for details)

• Configure certain routers as Candidate RP(s)• All other routers automatically learn elected RP

– Static RP(s)ip pim rp-address [group-list ] [override]• RP addresses must be configured on every router

– Anycast RP(s) (see next slides for details)• Form of Static RP with two RP’s sharing same RP address• Requires MSDP to be run between the two Anycast RP’s


Configuring Auto-RP Candidate RPs

ip pim send-rp-announce scope [group-list ] [interval ] [ bidir ]• Primary address of is used as RP-address

– If goes down, C-RP messages are not sent (use Loopback)

Mapping Agentsip pim send-rp-discovery [] scope [interval ]• Configure as Loopback Interface.

– Same reason recommended for C-RP

Auto-RP Listenersip 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.


Configuring BSR – BSR Candidates Configured via global config command

ip pim bsr-candidate [accept-rp-candidate ]

BSR election:• C-BSR with highest becomes BSR • Tie-breaker: Highest-IP-Address• Preemption by better C-BSR at any time

Elected BSR– Receives Unicast messages from C-RPs

• Stores Group-to-RP mapping cache (with holdtime) for all C-RPs– Originates BSR Multicast messages (every 60 seconds)

• Contain ALL C-RP’s Group-to-RP Mapping Cache and IP Address of active BSR• All PIM routers receive, and independently elect same RP based on hash algorithm


Configuring BSR – Candidate RPs Configured via global config command

ip pim rp-candidate [group-list | bidir | interval | priority ]

– All parameters as in AutoRP C-RP – except

C-RP learns IP address of active BSR via BSR election/messages C-RP Unicasts C-RP message to BSR every

– C-RP messages contain:• Group Ranges (default = 224.0.0.0/4) from • Candidate’s RP address with + • Holdtime = 3 x


Configuring Anycast RP

MSDP(Established via TCP)

interface Loopback200description -> anycast RPip address 10.1.1.1 255.255.255.255ip pim sparse-mode

interface Loopback10ip address 10.10.10.10 255.255.255.255

ip msdp peer 20.20.20.20 connect-source Loopback10ip msdp originator-id Loopback10

ip pim rp-address 10.1.1.1

interface Loopback200description -> anycast RPip address 10.1.1.1 255.255.255.255ip pim sparse-dense-mode

interface Loopback10ip address 20.20.20.20 255.255.255.255

ip msdp peer 10.10.10.10 connect-source Loopback10ip msdp originator-id Loopback10

ip pim rp-address 10.1.1.1

B

RP2

10.1.1.1A

RP1

10.1.1.1


Avoiding DM Flooding with Auto-RP Use global command

ip pim autorp listener– Added support for Auto-RP Environments.

• Modifies interface behavior.– Forces interfaces to always use DM for Auto-RP groups.– Only needed if Auto-RP is to be used.– Sort of a global : ip pim sparse-mode except auto-rp-groups

» Except you still have to put ip pim sparse-mode on all intrfcs

Use with interface command.ip pim sparse-mode

• Prevents DM Flooding.• Does not prevent DM Fallback!• All existing SPT’s will be lost!!!


Avoiding DM Fallback in Auto-RP/BSR Prior to IOS 12.3(4)T, 12.2(28)S Use RP-of-last-resort

• Assign local Loopback as RP-of-last-resort on each router.• Example

ip pim rp-address 10access-list 10 deny 224.0.1.39access-list 10 deny 224.0.1.40access-list 10 permit any

– Must also use ip pim sparse-dense mode interface command to support Auto-RP.


Avoiding DM Fallback … Totally!! New IOS global command

no ip pim dm-fallback Recommended Totally prevents DM Fallback!!

– No DM Flooding since all state remains in SM

Default RP Address = 0.0.0.0 [nonexistent]– Used if all RP’s fail.

• Results in loss of Shared Tree.• All SPT’s remain active.

Added in 12.2(28)S


Summary Multicast is Connection Oriented

– Connections are unidirectional– No traffic will flow unless connection is established end-to-end

Multicast is upside down from Unicast– Connections (Joins) are initiated from Receiver to the Source– Remember to “Stand on your Head” when Troubleshooting

Enable Multicast everywhere within Multicast Domain.– On all routers & interfaces.

Use SSM or Bidir for simplicity– Avoid ASM at all costs!

• Sometimes “Stuff” Happens in Networks and you can’t avoid it.– Dense Mode – Fuggidaboudit!


• White Papers

• Web and Mailers

• Cisco Press

More Information

RTFB = “Read the Fine Book”


Multicast Bedtime Stories

IP Multicast �Survival Guide Part 1 �Second EditionRules of EngagementSurvival Guide GoalAgendaWhy Multicast?Unicast vs. MulticastMulticast AdvantagesMulticast DisadvantagesMulticast FundamentalsMulticast FundamentalsIP Multicast Group ConceptMulticast AddressingMulticast Addressing - 224/4Multicast Addressing - 224/4 Multicast AddressingMulticast AddressingHow are Multicast Flows IdentifiedHost-Router Signaling: IGMPIGMPv3 – Membership Report Packet FormatIGMPv3 – Query Packet FormatIGMPv3 – Joining Group “G” Source “S” IGMPv3 – Querier ElectionIGMPv3 – Maintaining StateIGMPv3 – Leaving Group “G” Source “S”IGMPv3 – Leaving Group “G” Source “S”IGMPv3 – Leaving Group “G” Source “S”IGMPv3 – Leaving Group “G” Source “S”Unicast vs. Multicast Routing/ForwardingUnicast vs. Multicast Routing/ForwardingUnicast vs. Multicast Routing/ForwardingMulticast Tree BuildingMulticast Routing & ForwardingMulticast Routing & ForwardingMulticast Routing & ForwardingMulticast Routing & ForwardingMulticast Routing & ForwardingMulticast Routing & ForwardingMulticast Routing & ForwardingMulticast Routing & ForwardingMulticast Routing & ForwardingMulticast Routing & ForwardingMulticast Tree BuildingMulticast Tree BuildingMulticast Tree BuildingMulticast StateMulticast Routing & ForwardingMulticast FundamentalsMulticast FundamentalsMulticast FundamentalsSlide Number 50Types of Multicast TreesMulticast Distribution Tree TypesMulticast Distribution TreesMulticast Distribution TreesMulticast Distribution TreesMulticast Distribution TreesBidirectional Multicast�i.e. Bidir PIMBidirectional (BiDir) PIMPIM Modifications for BiDir OperationHow do hosts Join a Shared Tree using IGMPv3?IGMPv3 – Joining a Shared Tree for All Sources (*,G)Bidir Forwarding/Tree BuildingBidir Forwarding/Tree BuildingBidir Forwarding/Tree BuildingBidir Forwarding/Tree BuildingBidir Forwarding/Tree BuildingBidir Forwarding/Tree BuildingBidir Forwarding/Tree BuildingBidir Forwarding/Tree BuildingWhat Makes Multicast Complicated?Biggest Multicast Complicating FactorMulticast Complicating FactorJoining Group with IGMPv2Joining/Leaving with IGMPv2IGMPv2 – Joining a GroupIGMPv2 – Joining a GroupIGMPv2 – Maintaining a GroupIGMPv2 – Leaving a GroupAny-Source Multicast�i.e. ASM PIM�(The original Sparse Mode PIM)PIM-SM Shared Tree JoinPIM-SM Sender RegistrationPIM-SM Sender RegistrationPIM-SM Sender RegistrationPIM-SM SPT SwitchoverPIM-SM SPT SwitchoverPIM-SM SPT SwitchoverPIM-SM SPT SwitchoverPIM-SM SPT SwitchoverSlide Number 89But What about PIM Dense Mode???PIM-DMPIM-DM Flood & PrunePIM-DM Flood & PrunePIM-DM Flood & PrunePIM-DM Assert MechanismPIM-DM Assert ProblemPIM-DM Assert ProblemPIM-DM Assert ProblemPIM-DM Assert ProblemPotential PIM-DM Route LoopPotential PIM-DM Route LoopPotential PIM-DM Route LoopSo what about PIM Dense Mode??Protocol SummaryProtocol SummaryRP Configuration�(For ASM & Bidir)How Does the Network Learn RP Address?Static RPsAuto-RP – From 10,000 FeetAuto-RP – From 10,000 FeetBSR – From 10,000 FeetBSR – From 10,000 FeetBSR – From 10,000 FeetBSR – From 10,000 FeetAnycast RP (with MSDP) OverviewAnycast RP (with MSDP) OverviewConfiguration NotesGroup Mode vs. Interface ModeConfiguring InterfaceGroup ModeDense Mode FallbackSummary – PIM Configuration StepsConfiguring Auto-RPConfiguring BSR – BSR CandidatesConfiguring BSR – Candidate RPsConfiguring Anycast RPAvoiding DM Flooding with Auto-RPAvoiding DM Fallback in Auto-RP/BSRAvoiding DM Fallback … Totally!!SummaryMore InformationMulticast Bedtime Stories

ip multicast survival guide part 1cisco-users.org/zips/20160302_dfwcug ip multicast... · 2016. 3....

Documents