Cisco Networkers

1RST-220 © 2001, Cisco Systems, Inc. All rights reserved.


Deploying ScalableIP Multicast

Session RST-220


GeekometerAgenda

•• IP Multicast ReviewIP Multicast Review

• Configuring IP Multicast

• Multicast Issues at Layer 2

• Multicast Scalability


Source

Initial Flooding

Receiver

Multicast Packets

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

PIM-DM Flood and Prune


Source

Pruning Unwanted Traffic

Receiver

Multicast Packets

Prune Messages



Results After Pruning

Source

Receiver

Multicast Packets

Flood and Prune processFlood and Prune processrepeats every 3 minutes!!!repeats every 3 minutes!!!

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



PIM-SM Shared Tree Join

Receiver

RP

(*, G) Join

Shared Tree

(*, G) State created onlyalong the Shared Tree.


PIM-SM Sender Registration

Receiver

RP

(S, G) Join

Source

Shared Tree

(S, G) Register (unicast)

Source Tree

(S, G) State created onlyalong the Source Tree.Traffic Flow



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

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

Additional (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 Tree.

Additional (S, G) State is created along 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


Agenda

• IP Multicast Review

•• Configuring IP MulticastConfiguring IP Multicast




PIM Configuration Steps

• Enable Multicast Routing on every every router

• Configure every every interface for PIM

• Configure the RP (if using PIM-SM)Anycast/Static RP addressing

RP address must be configured on every router

Note: Anycast RP requires MSDP

Using Auto-RP or BSR

Configure certain routers as Candidate RP(s)

All other routers automatically learn elected RP


Enabling Multicast on the Router

• Global Configuration Commandip multicast-routing

Enables IP multicast forwarding in the router

Configure on EVERY router in the network


Which Mode—Sparse or Dense

• Dense modeFlood and Prune behavior very inefficient

Can cause problems in certain network topologies

Creates (S, G) state in EVERY router

Even when there are no receivers for the traffic

Complex Assert mechanism

Mixed control and data planes

Results in (S, G) state in every router in the network

Can result in non-deterministic topological behaviors

No support for shared trees


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

XX



Source

RPF Interface

XX

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

New Traffic Flow

Multicast Route Loop ! !Multicast Route Loop ! !




• Sparse modeMust configure a Rendezvous Point (RP)

Statically (on every Router)

Using Auto-RP (Routers learn RP automatically)

Using BSR (Routers learn RP automatically)

Very efficient

Uses Explicit Join model

Traffic only flows to where it’s needed

Separated control and data planes

Router state only created along flow paths

Deterministic topological behavior

Scales better than dense mode

Works for bothboth sparsely or densely populated networks


CONCLUSIONCONCLUSIONVirtually all production networks should be configured to run in Sparse mode!



Enabling Multicast on an Interface

• Interface Configuration CommandsEnables 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.


Enabling Multicast on an Interface

• Multi-Layer Switching (MLS) Interface Configuration Commands

Permits multicast to be switched in hardware.

Catalyst 6500 MLS interface commandmls ip multicast


We’ll just use the spare 56K line

for the IP Multicasttraffic and not

the T1.

no ip pim dense-mode ip pim dense-mode

Configure PIM on Every Interface

T1/E1 56K/64K

src

rcvrNetworkEngineer

XX

RPF Failure!!!!!RPF Failure!!!!!

Classic Partial Multicast Cloud MistakeClassic Partial Multicast Cloud Mistake


Group Mode vs. Interface Mode

• Interface Mode controls Group Mode.“If I set all interfaces to ‘ip pim sparse-mode’, the router will always operate in Sparse mode and never fall back into Dense mode”

Bzzzztt!!! I’m sorry, but that’s the incorrect answer

Group mode is independent of interface mode

Interface mode only controls how the interface operates

Group mode is controlled by RP information!!!Group mode is controlled by RP information!!!

Common MisconceptionCommon Misconception



• Avoid Group/Interface mode mismatchesGroup and Interface mode should be the same

Otherwise you may get unwanted/unpredictable results

• Sparse-Dense interfaces alwaysalways match the Group mode

Should normally be used if running Auto-RP

Permits Auto-RP groups to automatically run in Dense mode

All other groups run in Sparse mode. (Assuming an RP is defined for all other groups)

Can also be used for Sparse-only or Dense-only networks



• Let Group mode control Interface modeUse ‘ip pim sparse-dense-mode’ command

Allows maximum flexibility

No need to ever change interface configuration

• Control Group mode with RP infoIf RP info exists, Group = Sparse

Therefore interface mode = Sparse for this group

If RP info does not exist, Group = Dense

Therefore interface mode = Dense for this group


To always guarantee Sparse mode operation (and avoid falling back to Dense mode), make sure that every router alwaysalways knows of an RP for every group.

Avoiding falling back to Dense Mode


Configuring Rendezvous Points

•• AutoAuto--RPRP

• Bootstrap Router (BSR)

• Static RP’s

• Anycast RP’s


Auto-RP Overview

• All routers automatically learn RP addressNo configuration necessary except on:

Candidate RPs

Mapping Agents

• Makes use of Multicast to distribute infoTwo specially IANA assigned Groups used

Cisco-Announce—224.0.1.39

Cisco-Discovery—224.0.1.40

These groups typically operate in Dense mode

• Permits backup RP’s to be configuredWarning: Can fall back into Dense mode if Warning: Can fall back into Dense mode if misconfiguredmisconfigured

• Can be used with Admin-Scoping


Auto-RP—From 10,000 Feet

Announce Announce

An

no

un

ceA

nn

ou

nce

Announce Announce

An

no

un

ceA

nn

ou

nce

Announce

RP-Announcements multicast to theCisco Announce (224.0.1.39) group

AA

CC DDC-RP1.1.1.1

C-RP2.2.2.2

BB

MA MA


CC DDC-RP1.1.1.1

C-RP2.2.2.2

Auto-RP—From 10,000 Feet

Discovery

RP-Discoveries multicast to theCisco Discovery (224.0.1.40) group

MA MADiscovery

Discovery

Dis

cove

ry

Dis

cove

ry

AA

Discovery

Discovery

Dis

cove

ry

Dis

cove

ry

BB


Auto-RP Fundamentals

• Candidate RPsConfigured via global config command

ip pim send-rp-announce <intfc> scope <ttl> [group-list acl]

Multicast RP-Announcement messages

Sent to Cisco-Announce (224.0.1.39) group

Sent every rp-announce-interval (default: 60 sec)

RP-Announcements contain:

Group Range (default = 224.0.0.0/4)

Candidate’s RP address

Holdtime = 3 x <rp-announce-interval>



• Mapping agents

Configured via global config commandip pim send-rp-discovery [<intfc>] scope <ttl>

Receive RP-Announcements

Select highest C-RP IP addr as RP for group range

Stored in Group-to-RP Mapping Cache with holdtimes

Multicast RP-Discovery messages

Sent to Cisco-Discovery (224.0.1.40) group

Sent every 60 seconds or when changes detected

RP-Discovery messages contain:

Contents of MA’s Group-to-RP Mapping Cache



• All Cisco routers

Join Cisco-Discovery (224.0.1.40) group

Automatic

No configuration necessary

Receive RP-Discovery messages

Stored in local Group-to-RP Mapping Cache

Information used to determine RP for group range



• Auto-RP

•• Bootstrap Router (BSR)Bootstrap Router (BSR)

• Static RP’s

• Anycast RP’s


BSR Overview

• A single Bootstrap Router (BSR) is electedMultiple Candidate BSR’s (C-BSR) can be configured

Provides backup in case currently elected BSR fails

C-RP’s send C-RP announcements to the BSR

C-RP announcements are sent via unicast

BSR stores ALL C-RP announcements in the “RP-set”

BSR periodically sends BSR messages to all routers

BSR Messages contain entire RP-set and IP address of BSR

Messages are flooded hop-by-hop throughout the network away from the BSR

All routers select the RP from the RP-set

All routers use the same selection algorithm; select same RP

• BSR cannot cannot be used with Admin-Scoping


PIMv2 Sparse Mode

PIMv2 Sparse Mode

C-RP C-RP

D

E

F

G

A

BSR—From 10,000 feet

C-RP Advertise

ment

(unicast)

C-RP Advertisement

(unicast)

B C

BSRBSR


PIMv2 Sparse Mode

PIMv2 Sparse Mode

C-RP C-RP

D

E

F

G

A

BSR—From 10,000 feet

BS

R M

sgs

BSR MsgsBSR Msgs

BS

R M

sgs

BSR Msgs Flooded Hop-by-Hop

B C

BSRBSR


BSR Fundamentals

• Candidate RPs

Configured via global config commandip pim rp-candidate <intfc> [group-list acl]

Unicast PIMv2 C-RP messages to BSR

Learns IP address of BSR from BSR messages

Sent every rp-announce-interval (default: 60 sec)

C-RP messages contain:

Group Range (default = 224.0.0.0/4)

Candidate’s RP address

Holdtime = 3 x <rp-announce-interval>


BSR Fundamentals

• Bootstrap router (BSR)Receive C-RP messages

Accepts and stores ALL C-RP messages

Stored in Group-to-RP Mapping Cache w/holdtimes

Originates BSR messages

Multicast to All-PIM-Routers (224.0.0.13) group

(Sent with a TTL = 1)

Sent out all interfaces. Propagate hop-by-hop

Sent every 60 seconds or when changes detected

BSR messages contain:

Contents of BSR’s Group-to-RP Mapping Cache

IP Address of active BSR


BSR Fundamentals

• Candidate bootstrap router (C-BSR)Configured via global config command

ip pim bsr-candidate <intfc> <hash-length> [priority <pri>]<intfc>

Determines IP address

<hash-length>

Sets RP selection hash mask length

<pri>

Sets the C-BSR priority (default = 0)

C-BSR with highest priority elected BSR

C-BSR IP address used as tie-breaker

(Highest IP address wins)

The active BSR may be preempted

New router w/higher BSR priority forces new election


BSR Fundamentals

• All PIMv2 routersReceive BSR messages

Stored in local Group-to-RP Mapping Cache

Information used to determine active BSR address

Selects RP using Hash algorithm

Selected from local Group-to-RP Mapping Cache

All routers select same RP using same algorithm

Permits RP-load balancing across group range


Auto-RP vs BSR

• Auto-RPEasy to configure

Supports Admin. Scoped Zones

Works in either PIMv1 or PIMv2 Cisco networks

Cisco proprietary

• BSREasy to configure

Does notnot support Admin. Scoped Zones

Non-proprietary (PIMv2 networks only)



• Auto-RP


•• Static RP’sStatic RP’s

• Anycast RP’s


Static RP’s

• Hard-coded RP addressWhen used, must be configured on every router

All routers must have the same RP address

RP fail-over not possible

Exception: If Anycast RPs are used. (More on that later.)

Group can never never fall back into Dense mode.

• Commandip pim rp-address <address> [group-list <acl>] [override]

Optional group list specifies group range

Default: Range = 224.0.0.0/4 (Includes Auto(Includes Auto--RP Groups!!!!)RP Groups!!!!)

Override keyword “overrides” Auto-RP information

Default: Auto-RP learned info takes precedence



• Auto-RP


• Static RP’s

•• Anycast RP’sAnycast RP’s


Avoiding DM Fallback

• Define an “RP-of-last-resort”Configure as a Static RP on every router

Will only be used if all Candidate-RP’s fall

Can be a dummy address

Recommendation: Use lowest priority C-RP address

Use ACL to avoid breaking Auto-RPip pim rp-address <RP-of-last-resort> 10access-list 10 deny 224.0.1.39

access-list 10 deny 224.0.1.40

access-list 10 permit any


Anycast RP—Overview

• Uses single statically defined RP addressTwo or more routers have same RP address

RP address defined as a Loopback Interface

Loopback address advertised as a Host route

Senders and Receivers Join/Register with closest RP

Closest RP determined from the unicast routing table

Can never never fall back to Dense mode

Because RP is statically defined

• MSDP session(s) run between all RPsInforms RPs of sources in other parts of network

RPs join SPT to active sources as necessary



MSDPMSDP

RecRecRecRec RecRecRecRec

SrcSrc SrcSrc

SA SAAA

RP1

10.1.1.1BB

RP2

10.1.1.1

XX



RecRecRecRec RecRecRecRec

SrcSrcSrcSrc

AA

RP1

10.1.1.1BB

RP2

10.1.1.1

XX


Anycast RP Configuration

ip pim rp-address 10.1.1.1 ip pim rp-address 10.1.1.1

Interface loopback 0ip address 10.1.1.1 255.255.255.255


!ip msdp peer 10.0.0.1 connect-source loopback 1ip msdp originator-id loopback 1



!ip msdp peer 10.0.0.2 connect-source loopback 1ip msdp originator-id loopback 1

MSDPMSDPBB

RP2

AA

RP1

XX YY


PIM Sparse Mode

PIM Sparse Mode

RP/Mapping AgentC D

A B

On every router: ip multicast-routingip pim rp-address <rtr-B> group-list 10access-list 10 deny 224.0.1.39access-list 10 deny 224.0.1.40access-list 10 permit all

On every interface: ip pim sparse-dense-mode

On routers B and C: ip pim send-rp-announce loopback0 scope <ttl>ip pim send-rp-discovery loopback0 scope <ttl>

RP/Mapping Agent

Beginner’s Guide to IP Multicast


Agenda



•• Multicast Issues at Layer 2Multicast Issues at Layer 2



Multicast M

PIM

Problem: Layer 2 Flooding of Multicast Frames

L2 MulticastFrame Switching

• Typical L2 switches treat multicast traffic as unknown or broadcast and must “flood” the frame to every port

• 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


IGMP

Solution 1: IGMPv1-v2 Snooping

IGMP

L2 Multicast Frame Switching

• Switches become “IGMP” aware• IGMP packets intercepted by the NMP or by special

hardware ASICsRequires special hardware to maintain throughput

• Switch must examine contents of IGMP messages to determine which ports want what traffic

IGMP membership reportsIGMP leave messages

• Impact on low-end Layer-2 switches:Must process ALL Layer 2 multicast packetsAdmin. load increases with multicast traffic loadGenerally results in switch MeltdownMeltdown!!!

PIM


2

0

Host 1

3

Host 2

4

Host 3

5

Host 4

Switching EngineSwitching EngineCPUCPU

LAN Switch (IGMP Snooping Enabled)1

IGMP Report224.1.2.3

Router A

CAMCAMTableTable

MAC Address Ports

Typical L2 Switch—1st Join


2

0

Host 1

3

Host 2

4

Host 3

5

Host 4



Router A

CAMCAMTableTable

MAC Address Ports 0100.5e01.0203 0,1,2

Entry Added

Typical L2 Switch—1st Join


2

0

Host 1

3

Host 2

4

Host 3

5

Host 4


LAN Switch (IGMP Snooping Enabled)

2nd Join2nd Join

1

Router AIGMP Report

224.1.2.3

MAC Address Ports 0100.5e01.0203 0,1,2

CAMCAMTableTable

Typical L2 Switch—


2

0

Host 1

3

Host 2

4

Host 3

5

Host 4


LAN Switch (IGMP Snooping Enabled)

2nd Join2nd Join

1

Router A

,5MAC Address Ports 0100.5e01.0203 0,1,2

Port Added

CAMCAMTableTable

Typical L2 Switch—


CPUCPU

2

0

Host 1(MPEG Server)

3

Host 2

4

Host 3

5

Host 4

Switching EngineSwitching Engine

LAN Switch

1

Router A

1.5MbpsMPEG Video

CPUCPUCPU

1.5Mbps !!! Choke, Gasp,

Wheeze!!

Typical L2 SwitchMeltdown!Meltdown!Meltdown!

(IGMP Snooping Enabled)

CAMCAMTableTable

MAC Address Ports 0100.5e01.0203 0,1,2,5


2

0

Host 1

3

Host 2

4

Host 3

5

Host 4

CAMCAMTableTable

CPUCPU

LAN Switch

1

Router A

MAC Address L3 Ports 0100.5exx.xxxx IGMP 0

IGMP Processing Entry

L3 Aware Switch

Switching Engine (w/L3 ASICs)Switching Engine (w/L3 ASICs)

(IGMP Snooping Enabled)


2 3 4 5

Host 1 Host 2 Host 3 Host 4

CPUCPU


Router A

1st Join1st Join

0

CAMCAMTableTable



MAC Address L3 Ports

0100.5e01.0203 !IGMP 1,20100.5exx.xxxx IGMP 0

L3 Aware Switch


2 3 4 5


CPUCPU


Router A

0

CAMCAMTableTable



L3 Aware Switch



,5

Port Added

2nd Join2nd Join


2 3 4 5


CPUCPU


Router A

0

CAMCAMTableTable




1.5MbpsMPEG Video

Ahhh, That’smore like it!

L3 Aware Switch

,5


CGMPCommands

IGMP

Solution 2: CGMP—Cisco Group Multicast Protocol


• Runs on both the switches and the router

• Router sends CGMP multicast packets to the switches at a well known multicast MAC address:

0100.0cdd.dddd

• CGMP packet contains :Type field—Join or Leave

MAC address of the IGMP client

Multicast address of the group

• Switch uses CGMP packet info to add or remove a Layer-2 entry for a particular multicast MAC address

PIM


IGMP Report

Dst MAC = 0100.5e01.0203Src MAC = 0080.c7a2.1093Dst IP = 224.1.2.3Src IP = 192.1.1.1IGMP Group = 224.1.2.3 5/1

CGMP Join

USA = 0080.c7a2.1093GDA = 0100.5e01.0203

5/1

(a) (b)

1/1 1/1

CGMP Basics


1

2

0

3

Host 2

4

Host 3

5

Host 4

CAMCAMTableTable


Simple LAN Switch

Host 10080.c7a2.1093


CGMP

Router A

MAC Address Ports

1st Join1st Join


1

2 3

Host 2

4

Host 3

5

Host 4

CAMCAMTableTable


Simple LAN Switch

Host 10080.c7a2.1093

Router A

CGMP JoinUSA 0080.c7a2.1093GDA 0100.5e01.0204

MAC Address Ports

CGMP

0

1st Join1st Join


1

2 3

Host 2

4

Host 3

5

Host 4

CAMCAMTableTable


Simple LAN Switch

Host 10080.c7a2.1093

Router A

0100.5e01.0203 1,2

Entry Added

MAC Address Ports

CGMP

0

1st Join1st Join


1

2 3 4 5

CAMCAMTableTable


Simple LAN Switch

Router A

Host 2 Host 3Host 1 Host 40080.c7b3.2174


0100.5e01.0203 1,2MAC Address Ports

0

CGMP2nd Join2nd Join


1

2 3 4 5

CAMCAMTableTable


Simple LAN Switch

Router A


0

CGMP JoinUSA 0080.c7b3.2174GDA 0100.5e01.0204




1

2 3 4 5

CAMCAMTableTable


Simple LAN Switch

Router A


0


,5

Port Added



1

2 3 4 5


Simple LAN Switch

Router A

0

CGMP

Host 2 Host 3Host 1(MPEG Server)

Host 4

1.5MbpsMPEG Video

CAMCAMTableTable


No Load on SwitchNo Load on Switch

,5



• Impact of IGMPv3 on IGMP SnoopingIGMPv3 Reports sent to separate group (224.0.0.22)

Switches listen to just this group.

Only IGMP traffic—no data traffic.

Substantially reduces load on switch CPU

Permits low-end switches to implement IGMPv3 Snooping

No Report Suppression in IGMPv3

Enables individual member tracking

IGMPv3 supports Source-specific Includes/Excludes

Permits (S,G) state to be maintained by switch

Currently not implemented by any switches

May be necessary for full IGMPv3 functionality


Summary—Frame Switches

• IGMP snoopingSwitches with Layer 3 aware Hardware/ASICs

High-throughput performance maintained

Increases cost of switches

Switches without Layer 3 aware Hardware/ASICs

Suffer serious performance degradation or even MeltdownMeltdown!

Shouldn’t be a problem when IGMPv3 is implemented

• CGMPRequires Cisco routers and switches

Can be implemented in low-cost switches


Catalyst 5000Catalyst 5000

75007500

ReceiverGroup 2

ReceiverGroup 1

25002500

T1 WAN

Video Server

1.5MBMPEGVideo

Streams

UnnecessaryMulticastTraffic !!!


Holy Multicast, Batman!!3MB of unwanted data!(Choke, gasp, wheeze!)

75007500 75007500

Router A

Router B Router C

Router D

Design Issue—Core Switch



25002500

T1 WAN

Router-D

Move WAN Router to Another VLAN SegmentInside of Catalyst 5000Catalyst 5000Catalyst 5000

75007500

ReceiverGroup 2

ReceiverGroup 1

Video Server

1.5MBMPEGVideo

Streams


75007500 75007500

Router A

Router B Router C



• ProblemRouters send PIM Join/Prunes at Layer 3

IGMP Join/Leaves not sent by routers

Other routers on VLAN can override Prune

Switches operate at Layer 2

Use IGMP Snooping to constrain multicast

Must assume routers want all multicast traffic

Need new Layer 2 Join/Prune mechanism

Permits routers to send Join/Prunes to switch

• Solution: (RGMP)Router Group Management Protocol


Router Group Management Protocol

• Runs on Core Routers and SwitchesRouters

Identify themselves via RGMP Hello/Bye msg.

Send special Layer 2 (*,G) Join/Prune messages

Switches

Do not forward multicast traffic to router ports until specifically requested

• Limitations:Only works with PIM-SM/PIM-SSM

No Hosts permitted on VLAN

Routers cannot detect sources since multicast flooding to routers is off by default


0

CAMCAMTableTable


RGMP Switch

RGMP

AA BB CC DD

Initially, multicast forwarding to routers is disabled

1 2 3 4

MAC Address Ports 0100.5exx.xxxx 0


1

0

2 3 4

CAMCAMTableTable


RGMP Switch

RGMP JoinRGMP Join0100.5e01.01010100.5e01.0101

MAC Address Ports

RGMP

AA CC

1st Router receives a PIM (*,G) Join from downstream

PIM (*, 224.1.1.1) Join

DDBB0100.5exx.xxxx 00100.5e01.0101 20100.5exx.xxxx 0

Entry Added


1

0

2 3 4

CAMCAMTableTable


RGMP Switch

RGMP JoinRGMP Join0100.5e01.01010100.5e01.0101

MAC Address Ports

RGMP

AA BB CC

2nd Router receives a PIM (*,G) Join from downstream

PIM (*, 224.1.1.1) Join

DD,40100.5e01.0101 20100.5exx.xxxx 0

Port Added


1

0

2 3 4

CAMCAMTableTable


RGMP Switch

MAC Address Ports

RGMP

AA CC

Multicast is constrained to routers B and D

DD

Source

BB0100.5e01.0101 2,40100.5exx.xxxx 0


Agenda




•• Multicast ScalabilityMulticast Scalability


Multicast Application Categories

• One-to-Many ApplicationsVideo, TV, Radio, Concerts, Stock Ticker, etc.

• Few-to-Few ApplicationsSmall (<10 member) Video/Audio Conferences

• Few-to-Many ApplicationsTIBCO RV Servers (Publishing)

• Many-to-Many ApplicationsStock Trading Floors, Gaming

• Many-to-Few ApplicationsTIBCO RV Clients (Subscriptions)


Multicast Application CategoriesPIM-SM (S, G) State

• One-to-Many Applications

Single (S,G) entry

• Few-to-Few Applications

Few (<10 typical) (S,G) entries

• Few-to-Many Applications

Few (<10 typical) (S,G) entries

• Many-to-Many Applications

Unlimited (S,G) entries

• Many-to-Few Applications

Unlimited (S,G) entries


Multicast State Maintenance

• CPU load factorsMust send/receive Registers

Must send periodic Joins/Prunes

Must perform RPF recalculation every 5 seconds

Watch the total number of mroute table entries

Unicast route table size impacts RPF recalculation

• Memory load factors(*, G) entry ~ 380 bytes + OIL size

(S, G) entry ~ 220 bytes + OIL size

Outgoing interface list (OIL) size

Each oil entry ~ 150 bytes


Many-to-Any State Problem

• Creates huge amounts of (S,G) state

State maintenance workloads skyrocket

High OIL fanouts make the problem worse

Router performance begins to suffer

• Using Shared-Trees only

Provides some (S,G) state reduction

Results in (S,G) state only along SPT to RP

Frequently still too much (S,G) state

Need a solution that only uses (*,G) state


Reducing (S,G) State

• Use Shared-Trees only

Set SPT-Threshold to Infinity

• Connect sources directly to RP

(S,G) state created onlyonly at the RP

Not always practical


Eliminating (S,G) StateSolution 1

• Register-Encapsulate all data to RPEasy to implement

RP never bothers to send a Register-Stop

Effectively IP-IP tunneling traffic to RP

Still results in (S,G) state in:

The RP

The first-hop routers

Each packet must be de-encapsulated

Process-switched

Only feasible if data rates are very low


Eliminating (S,G) StateSolution 2

• Bidirectional Shared-TreesAllows data to flow up the Shared Tree

Source traffic follows Shared Tree to get to the RP and all other receivers on the Shared Tree

Cannot use current (*,G) RPF rules

Care must be taken to avoid multicast loops

Requires a Designated Forwarder (DF)

Responsible for forwarding traffic up Shared Tree

DF’s will accept data on the interfaces in their OIL

Then send it out all other interfaces (Including the IIF)


Bidirectional (Bidir) PIM

• Idea: Use the same tree for traffic from sources towards RP and from RP to receivers

• 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

Flows down the Shared Tree to reach all other receivers


Bidirectional PIM—Overview

Receiver

RP

Shared Tree

Sender/ReceiverReceiver


Bidirectional PIM—Overview

Receiver

RP

Shared Tree

Source Traffic

Source Traffic forwardedbidirectionally using (*,G) state.

Sender/ReceiverReceiver


PIM Modifications for Bidir Operation

• Designated Forwarders (DF)

On each link the router with the best path to the RP is elected to be the DF

Note: Designated Routers (DR) are not used for bidir groups

The DF is responsible for forwarding traffic upstream towards the RP

No special treatment is required for local sources


Join to DF

Forwarding / Tree Building

Downstream routers with receivers Join towards the DF

DFN2N2

RPRP

R2R2R1R1

Join to DF

Shared Tree

N3N3 N4N4

N1N1


R2R2R1R1

DFN2N2

Join


DF adds link to (*,G) olist and Joins towards the RP

Shared Tree

N3N3 N4N4

RPRP

N1N1



R2R2R1R1

DFN2N2


Shared Tree

N3N3 N4N4

RPRP

N1N1


Shared Tree is now built




The DF forwards all traffic from the link upstream towards the RP. At the same time, traffic flows down the tree

S1S1

R2R2R1R1

DFN2N2

N3N3 N4N4

RPRP

N1N1

Downstream routers with receivers Join towards theDF




Downstream traffic is forwarded through the DF

S2S2


R2R2R1R1

DFN2N2

RPRP

S1S1

N3N3 N4N4

N1N1

Downstream routers with receivers Join towards theDF



The DF forwards all traffic from the link upstream towards the RP. At the same time, traffic flows down the tree


Designated Forwarder Election

• Performed as soon as a bidir RP is learned via Auto-RP or BSR

• Elects the router on the link with the best path to the RP

• Ensures all routers on link have a consistent view of the winner identity and metrics

• Uses assert-like metric comparison rules to pick best path


DF Election Messages

•• Offer:Offer: Used to advertise local metrics to reach the RP

•• Winner:Winner: Used by a DF announcing or re-asserting its status

•• BackoffBackoff:: Used by a DF to acknowledge receipt of a better Offer

•• Pass:Pass: Used by an acting DF to pass the DF responsibility to a better candidate


Initial Election

N1N1 N2N2

N3N3 N4N4

Offer 10

• On RP discovery send Offer with metric to RP RPRP


N1N1 N2N2

N3N3 N4N4

Offer 10

We are better

Initial Election

• On RP discovery send Offer with metric to RP RPRP

• Neighbors compare with own metric and send Offer only if better

Offer 8


N1N1 N2N2

N3N3 N4N4

We loseWe are better

RPRP

Offer 10Offer 8

• On RP discovery send Offer with metric to RP


Initial Election


We Win!

• After repeating 3 uncontested Offers, send a Winner and assume DF role

N1N1 N2N2

N3N3 N4N4

Winner 8

RPRP

• On RP discovery send Offer with metric to RP


Initial Election


We Win!

• Winner message informs the other routers who is DF

N1N1 N2N2

N3N3 N4N4

Winner 8

DF is N1

DF is N1DF is N1

RPRP

Initial Election


N3N3 N4N4

DF Offer 6

DF Preemption

N1N1 N2N2

RPRP

New candidate sends improved Offer

Candidate


N2N2

N3N3 N4N4

DF Backoff 6

DF Preemption

RPRP

N1N1

DF responds with Backoffinstructing candidate to wait


Candidate


Before backoff period expires, old DF stops forwarding and sends Pass

N3N3 N4N4

Pass N2

DF Preemption

N1N1 N2N2

RPRPDF responds with Backoffinstructing candidate to wait


Candidate



N3N3 N4N4

Pass N2

DF Preemption

N1N1 N2N2



On receipt candidate becomes DF

Candidate

DF



N3N3 N4N4

Pass N2

DF is N2DF is N2

DF Preemption

N1N1 N2N2



On receipt candidate becomes DF

Other routers hear Pass, learn N2 is now DF

DF


N3N3 N4N4

Offer 8

Restarted

DF

PIM Neighbor Startup

N1N1 N2N2

RPRP

Router N1 restarts and has no knowledge of DF

On RP discovery it sends an Offer


Router N1 restarts and has no knowledge of DF

N3N3 N4N4

Winner 6 DF

PIM Neighbor Startup

On RP discovery it sends an Offer

Acting DF responds with Winner or Backoff depending on metric comparison

N1N1 N2N2

RPRP


DF

N3N3 N4N4

Offer ∞

DF Loses Path to the RP

N1N1 N2N2

RPRP

Stops acting as the DF

Sends Offer with infinite metric to trigger new DF election

Current DF loses only path to the RP


N3N3 N4N4

DF Winner 8

DF Loses Path to the RP

Other candidates respond with real Offers and eventually best candidate takes over with a Winner message

Stops acting as the DF

Sends Offer with infinite metric to trigger new DF election

N1N1 N2N2

RPRP

Current DF loses only path to the RP


DF Failures

• Detecting DF Failures

Downstream Routers

RP RPF info no longer points to DF

Non-Downstream Routers

PIM Neighbor timeout of DF

• Router response to a DF Failure

Routers resend their Offer messages

Triggers new DF election


ip pim send-rp-announce Loopback0 scope 10 group-list 45 bidirip pim send-rp-announce Loopback1 scope 10 group-list 46! Two loopbacks needed due to a nature of ACLs (permit, deny)ip pim send-rp-discovery scope 10

access-list 45 permit 224.0.0.0 0.255.255.255access-list 45 permit 227.0.0.0 0.255.255.255! 224/8 and 227/8 will be PIM Bidir groupsaccess-list 45 deny 225.0.0.0 0.255.255.255! 225/8 will be a PIM Dense Mode group

access-list 46 permit 226.0.0.0 0.255.255.255! 226/8 will be a PIM Sparse Mode group

Configuring Bidir PIM(Auto-RP Example)

• Define Candidate RP and groups / modes it is willing to serve


Bidir PIM—Summary

• Drastically reduces network mroute state

Eliminates ALL (S,G) state in the network

SPT’s between sources to RP eliminated

Source traffic flows both up and down Shared Tree

Allows Many-to-Any applications to scale

Permits virtually an unlimited number of sources


• White Papers

• Web and Mailers

• Cisco Press

CCO Multicast page:http://www.cisco.com/go/ipmulticast

Questions:[email protected]

Customer Support Mailing List:[email protected]

More Information

RTFB = “Read the Fine Book”


Deploying ScalableIP Multicast

Session RST-220


Please Complete Your Evaluation Form

Session RST-220


Documents

Cisco Networkers