Cisco Networkers

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

(*, G) Join

Shared Tree

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

PIM-SM Sender Registration

Receiver

(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

(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

Winner

Receiver

Assert Loser Prunes Interface

Source

Multicast Packets

Receiver

Winner

Receiver

Assert Winner Fails

Source

Multicast Packets

ReceiverX

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

Source

RPF Interface

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

rcvrNetworkEngineer

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

Announce

RP-Announcements multicast to theCisco Announce (224.0.1.39) group

CC DDC-RP1.1.1.1

C-RP2.2.2.2

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

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

C-RP C-RP

BSR—From 10,000 feet

C-RP Advertise

(unicast)

C-RP Advertisement

(unicast)

BSRBSR

PIMv2 Sparse Mode

C-RP C-RP

BSR—From 10,000 feet

BSR MsgsBSR Msgs

BSR Msgs Flooded Hop-by-Hop

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

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

10.1.1.1BB

10.1.1.1

RecRecRecRec RecRecRecRec

SrcSrcSrcSrc

10.1.1.1BB

10.1.1.1

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

PIM Sparse Mode

RP/Mapping AgentC D

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

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

Solution 1: IGMPv1-v2 Snooping

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

Host 1

Host 2

Host 3

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

Host 1

Host 2

Host 3

Host 4

Router A

CAMCAMTableTable

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

Entry Added

Typical L2 Switch—1st Join

Host 1

Host 2

Host 3

Host 4

LAN Switch (IGMP Snooping Enabled)

2nd Join2nd Join

Router AIGMP Report

224.1.2.3

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

CAMCAMTableTable

Typical L2 Switch—

Host 1

Host 2

Host 3

Host 4

LAN Switch (IGMP Snooping Enabled)

2nd Join2nd Join

Router A

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

Port Added

CAMCAMTableTable

Typical L2 Switch—

CPUCPU

Host 1(MPEG Server)

Host 2

Host 3

Host 4

Switching EngineSwitching Engine

LAN Switch

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

Host 1

Host 2

Host 3

Host 4

CAMCAMTableTable

CPUCPU

LAN Switch

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

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

CAMCAMTableTable

L3 Aware Switch

Port Added

2nd Join2nd Join

2 3 4 5

CPUCPU

Router A

CAMCAMTableTable

1.5MbpsMPEG Video

Ahhh, That’smore like it!

L3 Aware Switch

CGMPCommands

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

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

(a) (b)

1/1 1/1

CGMP Basics

Host 2

Host 3

Host 4

CAMCAMTableTable

Simple LAN Switch

Host 10080.c7a2.1093

Router A

MAC Address Ports

1st Join1st Join

Host 2

Host 3

Host 4

CAMCAMTableTable

Simple LAN Switch

Host 10080.c7a2.1093

Router A

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

MAC Address Ports

1st Join1st Join

Host 2

Host 3

Host 4

CAMCAMTableTable

Simple LAN Switch

Host 10080.c7a2.1093

Router A

0100.5e01.0203 1,2

Entry Added

MAC Address Ports

1st Join1st Join

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

CGMP2nd Join2nd Join

2 3 4 5

CAMCAMTableTable

Simple LAN Switch

Router A

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

2 3 4 5

CAMCAMTableTable

Simple LAN Switch

Router A

Port Added

2 3 4 5

Simple LAN Switch

Router A

Host 2 Host 3Host 1(MPEG Server)

Host 4

1.5MbpsMPEG Video

CAMCAMTableTable

No Load on SwitchNo Load on Switch

• 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

UnnecessaryMulticastTraffic !!!

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

CAMCAMTableTable

RGMP Switch

AA BB CC DD

Initially, multicast forwarding to routers is disabled

1 2 3 4

MAC Address Ports 0100.5exx.xxxx 0

CAMCAMTableTable

RGMP Switch

RGMP JoinRGMP Join0100.5e01.01010100.5e01.0101

MAC Address Ports

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

CAMCAMTableTable

RGMP Switch

RGMP JoinRGMP Join0100.5e01.01010100.5e01.0101

MAC Address Ports

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

CAMCAMTableTable

RGMP Switch

MAC Address Ports

Multicast is constrained to routers B and D

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

Shared Tree

Sender/ReceiverReceiver

Bidirectional PIM—Overview

Receiver

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

R2R2R1R1

Join to DF

Shared Tree

N3N3 N4N4

R2R2R1R1

DFN2N2

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

Shared Tree

N3N3 N4N4

R2R2R1R1

DFN2N2

Shared Tree

N3N3 N4N4

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

R2R2R1R1

DFN2N2

N3N3 N4N4

Downstream routers with receivers Join towards theDF

Downstream traffic is forwarded through the DF

R2R2R1R1

DFN2N2

N3N3 N4N4

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

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

• 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

Initial Election

N3N3 N4N4

DF Offer 6

DF Preemption

N1N1 N2N2

New candidate sends improved Offer

Candidate

N3N3 N4N4

DF Backoff 6

DF Preemption

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

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

N3N3 N4N4

Offer 8

Restarted

PIM Neighbor Startup

N1N1 N2N2

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

N3N3 N4N4

Offer ∞

DF Loses Path to the RP

N1N1 N2N2

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

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:cs-ipmulticast@cisco.com

Customer Support Mailing List:tac@cisco.com

More Information

RTFB = “Read the Fine Book”

Deploying ScalableIP Multicast

Session RST-220

Please Complete Your Evaluation Form

Session RST-220

Cisco Networkers

Documents

CCNA Prep - IP Subnetting from Networkers

What Great Networkers Know

Korisnicki vodic za Cisco Unified CallManager Assistant ... · Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post–Routing, Pre–Routing, ProConnect, RateMUX,

Cisco - Global Home Page · inspiration] Irnúnl coil Dear Strategic Business Partner: We would like to welcome you to Cisco Networkers 2010, Panama City, Panama. The most recognized

Cisco Networkers 2007-Advanced Campus QoS Design

Habits of Highly Effective Networkers

Networkers magazine pdf

IBROS ECOMENDADOS PARA NETWORKERS

Secrets of Master Networkers Manual - Boldheart · The Secrets of Master Networkers: How to keep your practice consistently FULL just with networking! The Secrets of Master Networkers:

BRKAGG-2017 4-4.ppt [Read-Only] - City Colleges of …faculty.ccc.edu/mmoizuddin/CISCO LIVE 2008/AGG/BRKAGG...Continue your Networkers at Cisco Live learning experience with further

Ccna PrepCenter - IP Subnetting from Networkers

FEX -PPT By NETWORKERS HOME

Networkers prosperity

Ccna security prep from networkers

Designing and Troubleshooting OSPFNetworksledvina/vyuka/PDS/PDS_2005/14_OSPF.pdf · Designing and Troubleshooting OSPF Networks November 1997, Paris Networkers 97 1 Cisco Systems

VDC by NETWORKERS HOME

Networkers Online 2004 - Cisco€¦ · - 4 - Session Network Technology Technical Level Session Title Speaker(s) SEC-3011 Virtual Private Networks 3 Troubleshooting Cisco VPN 3000

Social Networkers U.S

PYTHON DÀNH CHO NETWORKERS

Successful Networkers Secrets Revealed