BRKIPM-2261

© 2009 Cisco Systems, Inc. All rights reserved. Cisco PublicBRKIPM-2261 1

Deploying IP Multicast

BRKIPM-2261

2© 2009 Cisco Systems, Inc. All rights reserved. Cisco PublicBRKIPM-2261

Housekeeping

� We value your feedback- don't forget to complete your online session evaluations after each session & complete the Overall Conference Evaluation which will be available online from Thursday

� Visit the World of Solutions

� Please remember this is a 'non-smoking' venue!

� Please switch off your mobile phones

� Please make use of the recycling bins provided

� Please remember to wear your badge at all times including the Party


Session Goals

� Provide important guidance on what to consider when you deploy IP Multicast in your Enterprise network.

� Provide information on how to avoid common deployment problems and issues.

333

Session Non Goals

� Provide a “One-Size-Fits-All”configuration that meets all your Enterprise Multicast needs.


Agenda

� Which PIM Mode ?

� General Configuration Notes

� RP Engineering

� Controlling Groups, Sources & Receivers

� Market Data Feed Forwarding

� High Availability Notes

� Controlling App Traffic - QoS, Scoping

� Receiver Tracking


Things to Consider


Application Details can kill you!

� Get to know your Multicast Applications

You must develop an even closer relationship with your users

What multicast applications will they deploy?

What are the multicast applications’ characteristics?

One-to-Many or Many-to-Many?

How many and what Group addresses are used?

Are the Group addresses “hard-coded” � or can they be configured?

What is the “Scope” of the application?

Link-Local, Building, Campus, Region, Enterprise-wide?

What are the QOS and Bandwidth requirements?


Which PIM Mode?


PIM Mode Categories

� Sparse Mode (PIM-SM)

Original (Classic)

Supports both Shared and Source Trees

� Source Specific Multicast (PIM-SSM)

aka Single Source Multicast

Supports only Source Trees

No need for RP’s, RP Failover, etc.

� Bidirectional PIM (PIM-Bidir)

Supports only Shared Trees


PIM Sparse Mode (PIM-SM)

� Classic (original) PIMv2 Sparse Mode

Originally defined in RFC 2117, revised in RFC 2362

Standards Track PIMv2 specification is RFC 4601

� Requires a Rendezvous Point (RP)

RP and Shared Tree used for Source Discovery

Need some form of RP Failover mechanism

Shared to Source Tree switchover complexities

� Generally works well for most typical multicast applications


Source-Specific Multicast (SSM)

� Well suited for One-to-Many Model.

Examples: IPTV, Digital Signage

� Hosts responsible for learning (S,G) information.

Host uses IGMPv3 to join specific (S,G) instead of (*,G).

� Last-hop router sends (S,G) join toward source

No RPs or Shared Trees.

Eliminates possibility of Capt. Midnight Content Jammers.

Only specified (S,G) flow is delivered to host.

Data and Control Planes are decoupled

� Simplifies address allocation.

Different content sources can use same group without fear of interfering with each other.


Bidirectional PIM (Bidir)

� Many-to-Many State problemExamples: HPC, Message Bus, Distributed Processing Apps

Large numbers of sources creates huge (S,G) state problem.

Router performance can begin to suffer

� Bidir PIM: Uses a Bidirectional Shared Trees.

Only (*,G) state is used. No (S,G) state.

Source traffic flows up the Shared Tree to RP and then to receivers.

Note: Source traffic flows to RP even if there are no receivers.


Which PIM Mode

� Use SSM

For One-to-Many applications

Eliminates need for RP Engineering.

Greatly simplifies network.


� Use Bidir

For Many-to-Many | Few applications

Drastically reduces total (S,G) state in network.


� Use PIM-SM

For all other general purpose applications


Some Generic Configuration Notes


PIM Configuration Steps

� Enable Multicast Routing on every router

� Configure every interface for PIM

� Configure the RP for PIM-SM or PIM-Bidir

Statically

Using Auto-RP or BSR

Configure certain routers as Candidate RP(s)

All other routers automatically learn elected RP

Anycast RP for PIM-SM

Note: Anycast RP requires MSDP

Phantom RP for PIM-Bidir


no ip pim sparse-mode ip pim sparse-mode

Configure PIM on Every Interface

100 Mbps 10 Mbps

source

receiver

NetworkEngineer

XX

RPF to disabled linkRPF to disabled linkPIM Join never sent !!!PIM Join never sent !!!

Classic Partial Multicast Cloud MistakeClassic Partial Multicast Cloud Mistake

100 Mbps line has best metric to source

We’ll just use the backup 10 Mbps

for the IPmc trafficand not the

100 Mbps.

10.1.1.1

e0 e1


no ip pim sparse-mode ip pim sparse-mode


100 Mbps 10 Mbps

source

receiver

NetworkEngineer

Classic Partial Multicast Cloud MistakeClassic Partial Multicast Cloud Mistake

100 Mbps line has best metric to source

We’ll just use the backup 10 Mbps

for the IPmc trafficand not the

100 Mbps.

10.1.1.1

e0 e1

ip mroute 10.1.1.0 255.255.255.0 e1


� Static mroutes can be used to force multicast traffi c over particular paths

� This approach creates:High maintenance / High cost of ownership

Error-prone enviroment that leads to unintended results

� Don’t try to micro-manange your network !

� Its usually not worth the effort



Intermittent Source Applications

� Definition:

Applications with sources that temporarily stop sending for > 3 minutes.

� Impact:

(S,G) state times out within the network.

Initial packets often lost during SPT switchover.


Solutions to Intermittent Sources

� PIM-Bidir or PIM-SSM

� No data driven events

� Periodic keepalives or heartbeats

� S,G Expiry timer

ip pim sparse sg-expiry-timer <secs>

Available 12.2(18)SXE5, 12.2(18)SXF4, 12.2(35)SE


RP Engineering


Static RP’s

� Hard-coded RP address

When used, must be configured on every router

All routers must have the same RP address (per group)

Anycast RP must be used for Redunancy

� Configurationip pim rp-address <address> [group-list <acl>] [override]

[bidir]

Optional group list specifies group range

Default: Range = 224.0.0.0/4

Override keyword “overrides” Auto-RP information

Default: Auto-RP and BSR learned info takes precedence

Bidir keyword specifies this group range as PIM-Bidir


Auto-RP


Why use Auto-RP ?� Auto-RP is a dynamic method for the network to learn RP

to Group mapping information

This helps when:

� RP address and group ranges change often

� Your network has 100s or 1000s of routers and you want to simplify the config

� There are several RPs for different applications

� RPs maintained by different administrative groups


Auto-RP Overview

Announce Announce

Ann

ounc

eA

nnou

nce

Announce Announce

Ann

ounc

eA

nnou

nce

Announce

RP-Announcements multicast to theCisco Announce (224.0.1.39) group

AA

CC DDC-RP

1.1.1.1C-RP

2.2.2.2

BB

MA MA


CC DDC-RP

1.1.1.1C-RP

2.2.2.2

Auto-RP Overview

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 Configuration – Candidate RPs

� Candidate RPs

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>

Configured via global config commandip pim send-rp-announce <intfc> scope <ttl> [group-list acl]

[interval <sec>] [bidir]


Auto-RP Configuration – Mapping Agents

� Mapping agents

Receive RP-Announcements

Stored in Group-to-RP Mapping Cache with holdtimes

Elects highest C-RP IP address as RP for group range

Multicast RP-Discovery messages

Sent to Cisco-Discovery (224.0.1.40) group

Sent every rp-discovery-interval (default: 60 secs)

Both rp-announce-interval and rp-discovery-interval must be set to lower convergence times

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

[interval <sec>]

Source address of packets set by <interface>

If not specified, source address = output interface address

Results in the appearance of multiple MA’s. (one/interface)

rp-discovery-interval was hidden option until recently


Auto-RP Configuration - Auto-RP Listener

� Use global commandip pim autorp listener � Recommended

Added support for Auto-RP Environments.

Modifies interface behavior.

Forces interfaces to alwaysalways use DM for Auto-RP groups.

Only needed if Auto-RP is to be used.

Available 12.3(4)T, 12.2(28)S, 12.1(13)E7

� Use with interface commandip pim sparse-mode � Recommended

Prevents DM Flooding.

� Only reason to use sparse-dense is for DM groups


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.

Possibly a result of network congestion.

� Group is switched over to Dense mode.

*,G mroute entry changes to Dense modeFlags of S,G entries change from JT to TS,G PIM Joins are no longer sentState times out on upstream router – traffic flow stopsAll existing PIMAll existing PIM --SM SM SPTSPT’’ss are dropped!are dropped!

Dense mode flooding begins if interfaces configured with ip pim sparse-dense-mode


Avoiding DM Fallback in Auto-RP/BSR

� Use RP-of-last-resort

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

Example

ip pim rp-address <local_loopback> 10

access-list 10 deny 224.0.1.39access-list 10 deny 224.0.1.40access-list 10 permit any

� Needed Prior to IOS 12.3(4)T, 12.2(33)SXH


Avoiding DM Fallback Automatically

� New IOS global commandno ip pim dm-fallback

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

All SPT’s remain active.

Behavior is enabled by default if all interfaces are in sparse mode

� Available 12.3(4)T, 12.2(33)SXH


Auto-RP Summary

� Use Auto-RP Listener with Sparse Mode interfaces

With newer code you automatically get No Dense Mode Fallback

� With older code that doesn’t have: no ip pim dm-fallback

Use RP of Last Resort to prevent loss of active S,G entries in case of RP failure

� With ancient code that doesn’t have AutoRP Listener

Use sparse-dense interfaces

Use RP of Last Resort

Or Upgrade ;-)


Anycast RPs


Anycast RP Overview

MSDPMSDP

RecRecRecRec RecRecRecRec

SrcSrc SrcSrc

SA SAAA

RP1

10.1.1.1BB

RP2

10.1.1.1

XX


Anycast RP Overview

RecRecRecRec RecRecRecRec

SrcSrcSrcSrc

AA

RP1

10.1.1.1BB

RP2

10.1.1.1

XX


Anycast RP Configuration

Interface loopback 0ip address 10.0.0.1 255.255.255.255ip pim sparse-mode

Interface loopback 1ip address 10.0.0.2 255.255.255.255!ip msdp peer 10.0.0.3 connect-source loopback 1ip msdp originator-id loopback 1

Interface loopback 0ip address 10.0.0.1 255.255.255.255ip pim sparse-mode

Interface loopback 1ip address 10.0.0.3 255.255.255.255!ip msdp peer 10.0.0.2 connect-source loopback 1ip msdp originator-id loopback 1

MSDPMSDPBB

RP2

AA

RP1

CC DD

ip pim rp-address 10.0.0.1 ip pim rp-address 10.0.0.1


Combining Auto-RP and Anycast-RP

�Anycast-RP and Auto-RP may be combined.

Provides advantages of both methods

Rapid RP failover of Anycast RP

No DM Fallback

Configuration flexibility of Auto-RP

Ability to effectively disable undesired groups


Anycast RP with Auto-RP Configuration

Interface loopback 0ip address 10.0.0.1 255.255.255.255

Interface loopback 1ip address 10.0.0.2 255.255.255.255!ip pim send-rp-announce loopback 0 scope 32ip pim send-rp-discovery loopback 1 scope 32!ip msdp peer 10.0.0.3 connect-source loopback 1ip msdp originator-id loopback 1

Interface loopback 0ip address 10.0.0.1 255.255.255.255

Interface loopback 1ip address 10.0.0.3 255.255.255.255!ip pim send-rp-announce loopback 0 scope 32ip pim send-rp-discovery loopback 1 scope 32!ip msdp peer 10.0.0.2 connect-source loopback 1ip msdp originator-id loopback 1

MSDPMSDPBB

RP2

AA

RP1

ip multicast-routing

CC

ip multicast-routing

DD


Phantom BiDir RPs


RPRP

Receiver 2

E1 (DF) E1 (DF) E1 (DF) E1 (DF)

E1 (DF) E1 (DF)

E0 (DF)

Bidir PIM – Phantom RP

CC

E0 E0 E0 E0

E0 E0

Source Receiver 1

Question: Does a Bidir RP even have to physically e xist?Answer: No. It can just be a phantom address.

FF

DD

EE

AA BB


ip multicast-routing!interface Loopback0ip address 1.1.1.1 255.255.255.252ip pim sparse-modeip ospf network point-to-point!interface Ethernet0/0ip address 10.1.1.1 255.255.255.0ip pim sparse-mode!interface Ethernet1/0ip address 10.1.2.1 255.255.255.0ip pim sparse-mode!router ospf 11network 1.1.1.0 0.0.0.3 area 0network 10.1.1.0 0.0.0.255 area 0network 10.1.2.0 0.0.0.255 area 0!ip pim bidir-enableip pim rp-address 1.1.1.2 bidir

Phantom RP on Point-to-Point Core

RP: 1.1.1.2

ip multicast-routing!interface Loopback0ip address 1.1.1.1 255.255.255.248ip pim sparse-modeip ospf network point-to-point!interface Ethernet0/0ip address 10.1.1.2 255.255.255.0ip pim sparse-mode!interface Ethernet1/0ip address 10.1.2.2 255.255.255.0ip pim sparse-mode!router ospf 11network 1.1.1.0 0.0.0.7 area 0network 10.1.1.0 0.0.0.255 area 0network 10.1.2.0 0.0.0.255 area 0!ip pim bidir-enableip pim rp-address 1.1.1.2 bidir

SSPP30 Bit Mask 29 Bit Mask

OSPF requiresP2P interfaces


� In example below, Phantom RP address of 1.1.1.2 is being advertised through Auto-RP. The source of the Mapping packets are the address on Loopback1

� Previously, Auto-RP could only advertise IP address on interface (e.g. loopback) as RP

� New option has been added – now we can advertise any address on a directly connected subnet

ip pim send-rp-announce 1.1.1.2 scope 32 bidir

ip pim send-rp-discovery Loopback1 scope 32

interface Loopback0

ip address 1.1.1.1 255.255.255.252

ip pim sparse-mode

ip pim send-rp-announce <[int] | [ip-address]> scope [group-list] [bidir]

� Available 12.4(7)T, 12.2(18)SXF4

Phantom RP with Auto-RP


Controlling Groups, Senders and Receivers


Disabling Multicast Groups – Local Loopback

� Local Loopback RP Method

Concept:

Only Auto-RP/BSR learned groups are authorized.

All other groups are considered unauthorized.

Implementation:

On each router, define local Loopback as RP for all groups.

ip pim rp-address <local_loopback> 10

access-list 10 deny 224.0.1.39access-list 10 deny 224.0.1.40access-list 10 permit any

Use Auto-RP/BSR to override this and enable authorized groups.


Disabling Multicast Groups – Local Loopback

� Local Loopback RP Method

Operation:

Each router serves as RP for unauthorized groups.

Collapses PIM-SM domain of unauthorized groups down to the local router.

Unauthorized group traffic cannot flow beyond local router.

But it can still flow between Senders & Receivers directly connected to the router.

Effectively “discourages” deployment of unknown, unauthorized multicast applications.


Disabling Multicast Groups – New Method

� New Global Command Extension

ipip multicastmulticast--routingrouting [group[group--range <range <aclacl>]>]

Router drops all Control packets (PIM, IGMP) for denied groups.

Router drops all Data packets for denied groups.

No IGMP or PIM state created for denied groups.

Same behavior as placing a multicast boundary on every interface

� Available in 12.2(33)SXI


� In example below, 239/8 is allowed for multicast. All other groups will be disabled

� There is no direct way to turn off Auto-RP from creating state and accepting reports

� The group-range command could be used to disable Auto-RP

� In this example, state will never be created for 224.0.1.[39|40] but all other 224/4 groups will operate

ip multicast group-range 1

access-list 1 permit 239.0.0.0 0.255.255.255

ip multicast group-range 1

access-list 1 deny 224.0.1.39 0.0.0.0

access-list 1 deny 224.0.1.40 0.0.0.0

access-list 1 permit any any

Disabling Auto-RP with group-range


Controlling Senders

� Global commandip pim accept-register [list <acl>] | [route-map <map>]

Used on RP to filter incoming Register messages

Filter on Source address alone (Simple ACL)

Filter on (S, G) pair (Extended ACL)

� Helps prevents unwanted sources from sending

First hop router blocks traffic from reaching net

Note: Traffic can still flow under certain situations


Controlling Senders

RPRP configured to only accept Registers from specific source.

Receiver Receiver

192.16.2.1

192.16.1.1

(S, G) Register-Stop (unicast)

(S, G) Register (unicast)

ip pim accept-register list 10

access-list 10 permit 192.16.1.1


Market Data Feed Forwarding


Brokerage

ContentProvider

ContentProvider

ContentProvider

FinancialServiceProvider

Brokerage Brokerage

Market Data Distribution - Interface


Provisioning Options

• Static Forwarding

• Static Service Levels – Cable Model

• Dynamic Forwarding

• Hybrid Design


• Customers and providers prefer lowest common denominator – least coordination

Providers are under contract to deliver stream

Each side wants to limit organizational liability a nd coordination – KISS

Ideal Scenario: Provider and Customer have separate multicast domains

Therefore: Traffic is statically nailed upNo PIM NeighborsNo DR on edgeNo PIM JoinsNo shared RPNo MSDP

Traditional MD Interface Requirements


Market DataSource Network

Customer

224.0.2.64

DestinationSource

10.2.2.2

e0

e1

• MD feed is statically nailed up

interface Ethernet0ip address 10.1.2.1 255.255.255.0ip pim sparse-mode ip igmp static-group 224.0.2.64


Virtual RP

• Customer Edge router advertises RP address from upstream interface

• Every router in customer network needs to know about the RP

interface Ethernet1ip address 10.1.2.2 255.255.255.0ip pim sparse-mode

ip pim rp-address 10.1.1.1

ip route 10.1.1.1 255.255.255.255 10.1.2.5

router ospf 11network 10.1.0.0 0.0.255.255 area 0redistribute static subnets



ip route 10.1.1.1 255.255.255.255 10.1.2.5

router ospf 11network 10.1.0.0 0.0.255.255 area 0redistribute static subnets

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

MD Distribution – Virtual RP



Customer

224.0.2.64

DestinationSource

10.2.2.2

e0

e1




RP

• Customer Edge router is RP – so that it will accept a non-connected source

• Every router in customer network needs to be know about the RP


interface Loopback0ip address 10.1.1.1 255.255.255.255ip pim sparse-mode






MD Distribution – Edge router is RP



Customer

224.0.2.64

DestinationSource

10.2.2.2

e0

e1




RP

• Customer Edge router is RP – so that it will accept a non-connected source

• Every router in customer network needs to be know about the RP








This method will NOT work with future versions of IOS

MD Distribution – Edge router is RP



Customer

224.0.2.64

DestinationSource

10.2.2.2

e0

e1

RP

• Customer Edge router has dense-mode on IIF and proxy registers to RP

• RP is configured inside customer network

interface Ethernet1ip address 10.1.2.2 255.255.255.0ip pim dense-mode proxy-register list 100

access-list 100 permit ip any any


interface Ethernet1ip address 10.1.2.2 255.255.255.0ip pim dense-mode proxy-register list 100

access-list 100 permit ip any any









MD Distribution –Edge router proxy registers to RP



Customer

224.0.2.64

DestinationSource

10.2.2.2

e0

e1

RP

• Customer Edge router is RP and MSDP peer of main customer RP

interface Ethernet1ip address 10.1.2.2 255.255.255.0ip pim dense-mode

interface Loopback0ip address 10.1.1.1 255.255.255.255



ip msdp peer 10.1.3.1 connect-source Loopback1ip msdp originator-id Loopback1






RP









MD Distribution –Edge router is RP and MSDP peer



Customer

224.0.2.64

DestinationSource

10.2.2.2

e0

e1

RP

• Customer Edge router is RP and MSDP peer of main customer RP











RP









Dense mode is required on the IIF so that the A flag will be set and MSDP will forward an SA

MD Distribution –Edge router is RP and MSDP peer


Static Forwarding – Cable Model

Basic Service

ip access-list standard basic-service

permit 239.192.1.0 0.0.0.255 ! Basic service channe ls

Premium Service

ip access-list standard premium-service


permit 239.192.2.0 0.0.0.255 ! Premium service chan nels

Premium Plus Service

ip access-list standard premium-plus-service


permit 239.192.2.0 0.0.0.255 ! Premium service chan nels

permit 239.192.3.0 0.0.0.255 ! Premium Plus service channels

Adapt cable model of provisioning for Market Data


class-map type multicast-flowsmarket-data group 224.0.2.64 to 224.0.2.80

interface Vlan6ip igmp static-group class-map market-data

interface Vlan6ip igmp static-group 224.0.2.64ip igmp static-group 224.0.2.65ip igmp static-group 224.0.2.66...ip igmp static-group 224.0.2.80

Subscribing dozens or hundreds of groups can be cumbersome with the static-group command:

The static group range command simplifies the config:

Available in 12.2(18)SXF5

Static Forwarding – group range command


• Provider and customer have separate multicast domai ns

Each is free to use any forwarding modele.g. PIM-SM, PIM-SSM, PIM-Bidir, PIM-DM

Each is responsible for their portion of the delive ry model – clear demarcation

Simple, straight-forward

Has traditionally been first choice for FSP

Main DisadvantageCustomer is not able to control subscriptions and bandwidth usage of last mile dynamically.

As data rates climb this is more of a issue.

Advantages of Static Forwarding


Dynamic Forwarding

Rising data rates and 24 hour trading are driving t herequirement for dynamic subscriptions.

Methods:

• IGMP Membership Reports

• PIM Joins - *,G for PIM-SM and PIM-Bidir

• PIM Joins - S,G for PIM-SSM


Dynamic Service – Static Subscriptions with IGMP

Customers want ability to nail up service

Existing Issues

• ip igmp join-group <group>Sends an IGMP report out the interfaceTraffic gets punted to CPU

• ip igmp static-group <group>Adds interface to OILDoes not send IGMP report out the interface

Workarounds

• Separate router - Put IGMP join group on a dedicated router

Need Better Solution

• ip igmp join-group <group> passive - under considerationIGMP report will be sent but traffic will not be pu nted to CPUIGMP host code on router will respond to queriesL flag will not be set ?



Customer

224.0.31.20

DestinationSource

10.2.2.2

e0

e1

• Assumes that hosts sit on edge of customer network or breaks multicast delivery model

• Stretches the original design and purpose of IGMP

• CME is doing this today in USA• We can make this work dynamically today with a

cumbersome combination of:

ip igmp helperip igmp proxy-serviceip igmp mroute-proxy

• Industry may want to recommend this model going forward

IGMP

IGMP

PIM

MD Distribution – Provider wants IGMP Report



e0

IGMP

IGMP

• igmp proxy service and helper are configured on loopbackinterface Loopback1

ip address 10.3.3.3 255.255.255.0ip pim sparse-mode ip igmp helper-address 10.4.4.4ip igmp proxy-serviceip igmp access-group filter-igmp-helperip igmp query-interval 9

interface Loopback1ip address 10.3.3.3 255.255.255.0ip pim sparse-mode ip igmp helper-address 10.4.4.4ip igmp proxy-serviceip igmp access-group filter-igmp-helperip igmp query-interval 9

• Downstream interface is configured with igmp mroute-proxy

• Every router in customer network needs to be know about the virtual RP

interface Ethernet0ip address 10.2.2.2 255.255.255.0ip pim sparse-modeip igmp mroute-proxy Loopback1

interface Ethernet0ip address 10.2.2.2 255.255.255.0ip pim sparse-modeip igmp mroute-proxy Loopback1

ip pim rp-address 20.20.20.20ip route 20.20.20.20 255.255.255.255 10.4.4.4

ip pim rp-address 20.20.20.20ip route 20.20.20.20 255.255.255.255 10.4.4.4

e1

Customer

e0loopback1

PIM

10.4.4.0/24

MD Distribution – igmp mroute-proxy



e0

IGMP

2. PIM *,G Join message filters up towards virtual RP

1. Host sends IGMP report and creates mroute state

(*, 239.254.1.0), 00:00:01/00:02:55, RP 20.20.20.20, flags: SCIncoming interface: FastEthernet1/15, RPF nbr 10.2.2.2, RPF-MFDOutgoing interface list:Vlan194, Forward/Sparse, 00:00:01/00:02:55, H

(*, 239.254.1.0), 00:00:01/00:02:55, RP 20.20.20.20, flags: SCIncoming interface: FastEthernet1/15, RPF nbr 10.2.2.2, RPF-MFDOutgoing interface list:Vlan194, Forward/Sparse, 00:00:01/00:02:55, H

e1

Customer

e0loopback1

PIM

10.4.4.0/24

3. PIM *,G Join message is received on e0 interface and mroute state is created. The igmp mroute-proxy command on interface causes special internal flag to be added to mroute

4. The first PIM *,G Join on e0 triggers an unsolicited IGMP report to be generated on the loopback1 interface

MD Distribution – igmp mroute-proxy detail



e0

IGMP

IGMPe1

Customer

e0loopback1

PIM

10.4.4.0/24

5. The igmp helper command directs the IGMP report out the e1 interface

6. When the periodic IGMP query is run on loopback1 the igmp proxy-service command initiates a walk through the mroute table looking for the mroute-proxy flag. An IGMP report is generated for each mroute with the mroute-proxy flag set.

As long as the mroute is kept alive with PIM joins the IGMP reports will be forwarded.

IGMP reports are dynamic – they are only sent when there is interest in the customer domain. However, the edge router does not respond to queries from provider router.

Two problems:• 7 times more IGMP messages than needed• Cumbersome config

MD Distribution – igmp mroute-proxy detail


Dynamic Service – Dynamic Subscriptions with IGMP

Better Solution: IGMP Host Proxy

Global command:

ip igmp host-proxy <group acl>Functionality:

1. When mroute state is created for any group defined b y <acl>

The mroute-proxy flag will be set

An IGMP report is generated for the mroute and set o ut the IIF of the mroute

2. When an IGMP Query is received for a group defined by <acl>

If mroute state exists, generate IGMP report

3. When a PIM Prune is received for a group defined by <acl>

An IGMP leave message is generated

4. All modes of PIM should be supported – PIM-SM, PIM-B idir and PIM-SSM. The groups must be defined on the router and the be havior will work appropriately. This solution should be compliant wi th RFC4605 and EDCS-623893.

ComingSoon



Customer

224.0.2.64

DestinationSource

10.2.2.2

e0

e1

• Provider accepts PIM join

– Sparse Mode

Provider must supply RP addrRequires PIM Neighbor relationshipNo RP on customer SideOne multicast domain

– Source Specific Multicast

Provider must supply S,G infoRequires PIM Neighbor relationship

• MSDPStandard Interdomain MulticastRequires peering relationship

RP

RP

RP

MD Distribution – Other options


Dynamic Forwarding - *,G PIM Joins

• Requires more coordination than static joins or IGM P

PIM NeighborsRP InfoMSDP ?

• Redundancy is up to server side

Standby server can monitor the stream and beginforwarding when traffic stops for a defined interva l


Dynamic Forwarding – S,G PIM Joins• Works in situations that are ideal for SSM

• No need to share RP info or use MSDP

Redundancy options:

Host side

Host can join both primary and secondary servers – for both A and B streams

Host will need to arbitrate between primary and sta ndby

Network/Server side

Anycast Source - Hosts only join one server and netwo rk tracksserver and forwards active stream


A set of 4 docs that cover all aspects of network a nd application design for Market Data distribution

� Market Data Network Architecture (MDNA)

� Trading Floor Architecture

� Design Best Practices for Latency Optimization

� IP Multicast Best Practices for Enterprise Customer s

http://www.cisco.com/go/financial

Market Data Design Whitepapers


High Availability Notes


A192.168.1.0/24.2 (DR) .1

B

• DR Failover is triggered by neighbor expiration tim e• Expiration Time sent in PIM query messages

Expiration time = 3 x <query-interval>Default <query-interval> = 30 secondsDR Failover = 90 seconds (worst case) by default

router-b#show ip pim neighbor PIM Neighbor TableNeighbor Interface Uptime/Expires Ver DRAddress Prio/Mode192.168.1.2 GigabitEthernet3/13 14w5d/00:01:32 v2 1 / DR B S

router-b#show ip pim neighbor PIM Neighbor TableNeighbor Interface Uptime/Expires Ver DRAddress Prio/Mode192.168.1.2 GigabitEthernet3/13 14w5d/00:01:32 v2 1 / DR B S

Corp. Intranet

• Use interface configuration command:ip pim query-interval <period> [msec]

• Setting period to 1 sec has a failover of 3 sec• 500 ms lowest recommended setting

PIM Query Interval Tuning


DataCenter

Trading RoomFloor

RPRP

cost 3

cost

1

cost 2 cost 2

cost

1

cost

1

cost

1

cost 3

cost 3

cost 2 cost 2

• A and B Traffic will take two different physical paths

• Edge routers on trading room floor have alternating DRs

• PIM Joins will be forwarded by the DR towards the RP or source

• Different link costs will create different forwarding state

Market Data Distribution – Path Diversity


Controlling Application Traffic with QoS and Scoping


� Video distribution often has well defined character istics

IPTV providers know how many channels they have and which groups they are using

Depending on Codec we can make assumptions about ex pected bandwidth

� Financial App traffic has different characteristics

Finance App data rate can surge on emotion of marke t

Financial Apps (inside Brokerage) are better contro lled and understood than MD feeds

� Challenge: Apps are distributed – many servers sendi ng in uncoordinated fashion

Application Traffic – Approach


Application Traffic – Network approach

• Addressing plan that sets aside ranges for differen t BW limits

• Multicast boundary command to limit high BW streams

• QoS can use both DSCP and Mcast Address for policing , queuing

• Microflow policing to limit streams of certain apps (6500/7600)

• mCAC - limit the number of flows a branch can subscri be

Microflow policing and mCAC assume that BW requiremen ts for certain applications are known and fairly static.

WRED does not differentiate between TCP and UDP tra ffic. This also affects VoIP traffic.


Application Traffic – Addressing Plan

A multicast addressing plan is crucial for deployin g global applications. It will help with:

Example Address plan by bandwidth:1 Mbps streams – 239.1. 1.0/24

2 Mbps streams – 239.1. 2.0/24

4 Mbps streams – 239.1. 4.0/24

• Troubleshooting

• QoS Policies

• Scoping


Site A Site BS1

S0S0

S0

Border B Border C

239.1.4.0/24 239.1.4.0.0/24

239.1.4.0/24

MulticastBoundaries

MulticastBoundaries

Border A

Corp HQ

Multicast boundaries block high BW traffic from going to remote sites

Deploying Multicast Boundaries


Site A Site BS1

S0S0

S0

Border B Border C

239.1.4.0/24 239.1.4.0.0/24

239.1.4.0/24

Border A

Corp HQ

Multicast boundaries block high BW traffic from going to remote sites

! Access list on all routersaccess-list 10 deny 239.1.4.0 0.0.0.255access-list 10 permit any

interface Serial0ip multicast boundary 10



Deploying Multicast Boundaries


� QoS protection necessary for remote users and WAN aggregation

� Apps can be classified by group (239.1.QOS.x )

� Protect latency sensitive Finance Apps with LLQ

� Use MQC to allocate bandwidth to Finance Apps

CoreData Center

WAN Aggregation

access-list 101 permit ip any 239.1.1.0 0.0.0.63

class-map match-all finance-appsmatch access-group 101

policy-map app-llqclass finance-apps

prority 1024class default

fair-queue

interface serial 0service-policy output app-llq

QoS with Multicast


6500/7600 QoS Types of Policers - Aggregate

The effect of the Aggregate is that all traffic com ing into the ports associated with the aggregate are policed down the stated rate

AggregatePolicer

IngressTraffic

EgressTraffic

Total amount of output traffic is limited to the rate specified in the Aggregate


6500/7600 QoS Types of Policers - Microflow

The effect of the Microflow is that all flows coming into the ports associated with the Microflow policer are policed down the state d rate

MicroflowPolicer

IngressTraffic

EgressTraffic

Each flow is limited to the rate specified in the Microflow

NOTE: A flow is defined by the Flow Mask in use by the system

NOTE: A flow is defined by the Flow Mask in use by the system


mls qos


class-map match-all mcast-flowsmatch access-group 101

policy-map police-mcast-flowsclass mcast-flows

police flow mask dest-only 1000000 31250 conform-action transmit exceed-action drop

interface Vlan302service-policy input police-mcast-flows

All traffic sent to 239.1.1.0 All traffic sent to 239.1.1.1All traffic sent to 239.1.1.2 All traffic sent to 239.1.1.3All traffic sent to 239.1.1.4 All traffic sent to 239.1.1.5All traffic sent to 239.1.1.6All traffic sent to 239.1.1.7

rate limited to 1 Mbpsrate limited to 1 Mbpsrate limited to 1 Mbpsrate limited to 1 Mbpsrate limited to 1 Mbpsrate limited to 1 Mbpsrate limited to 1 Mbpsrate limited to 1 Mbps

Maximum of 8 Mbps traffic forwarded

Microflow policing with multicast


mls qos


class-map match-all mcast-flowsmatch access-group 101

policy-map police-mcast-flowsclass mcast-flows

police flow mask dest-only 1000000 31250 conform-action transmit exceed-action drop

interface Vlan302service-policy input police-mcast-flows

Micro-flow policers can only be applied to ingress traffic

NOTE:Maximum of 63 microflow policers on Sup720– 63 different policing rates

Only two flow masks are supported per system

Microflow policing with multicast (cont)


ip access-list standard one-mb-streamspermit 239.1.1.0 0.0.0.255

ip access-list standard two-mb-streamspermit 239.1.2.0 0.0.0.255

ip access-list standard four-mb-streamspermit 239.1.4.0 0.0.0.255

ip multicast limit cost one-mb-streams 1ip multicast limit cost two-mb-streams 2ip multicast limit cost four-mb-streams 4

Define the group ranges:

Set the costs:

20 groups X 1 Mbps =6 groups X 2 Mbps =2 groups X 4 Mbps =

20 Mbps12 Mbps8 Mbps

40 Mbps

Work out the allocation:

40 MbpsTotal

1 Mbps

1 Mbps1 Mbps

1 Mbps1 Mbps

1 Mbps1 Mbps1 Mbps1 Mbps1 Mbps

4 Mbps

2 Mbps

2 Mbps

4 Mbps

2 Mbps

Available:12.4(15)T412.2(33)SXI12.2(33)SB

Multicast Call Admission Control (mCAC)


Site A

Corp HQ

s0

s0

40 MbpsTotal

1 Mbps

1 Mbps

1 Mbps

1 Mbps

1 Mbps

1 Mbps4 M

bps

2 Mbps

2 Mbps

interface s0ip multicast limit rpf one-mb-streams 20ip multicast limit rpf two-mb-streams 6ip multicast limit rpf four-mb-streams 2

ip multicast limit cost one-mb-streams 1ip multicast limit cost two-mb-streams 2ip multicast limit cost four-mb-streams 4

interface s0ip multicast limit out one-mb-streams 20ip multicast limit out two-mb-streams 6ip multicast limit out four-mb-streams 2

The number of streams at each data rate are limited by the allocation.

NOTE *,G and S,G will both be accounted

Deploying Multicast CAC


Application Traffic – Network approach

Summary

• Addressing plan

• Multicast boundary

• QoS – LLQ and Shaping

• Microflow policing (6500/7600)

• mCAC


Receiver Tracking


es1-7606-c3#show ip igmp snooping explicit-tracking vlan 301

Source/Group Interface Reporter Filter_mode

---------------------------------------------------------------------------

0.0.0.0/224.0.1.39 Vl301: 126.1.99.15 EXCLUDE

0.0.0.0/239.254.1.1 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.4 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.3 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.2 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.5 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.2 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.5 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.3 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.4 Vl301:Gi3/2 126.1.99.41 EXCLUDE

Displays receiver IP address and interface for IGMPv2 hosts

Available on 6500 in 12.2(33)SXH

NewIGMP Explicit Tracking




---------------------------------------------------------------------------

0.0.0.0/224.0.1.39 Vl301: 126.1.99.15 EXCLUDE

0.0.0.0/239.254.1.1 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.4 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.3 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.2 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.5 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.2 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.5 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.3 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.4 Vl301:Gi3/2 126.1.99.41 EXCLUDE

Displays receiver IP address and interface for IGMPv2 hosts


New

Host IP Addr

IGMP Explicit Tracking




---------------------------------------------------------------------------

0.0.0.0/224.0.1.39 Vl301: 126.1.99.15 EXCLUDE

0.0.0.0/239.254.1.1 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.4 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.3 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.2 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.5 Vl301:Gi3/1 126.1.99.36 EXCLUDE

0.0.0.0/239.254.1.2 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.5 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.3 Vl301:Gi3/2 126.1.99.41 EXCLUDE

0.0.0.0/239.254.1.4 Vl301:Gi3/2 126.1.99.41 EXCLUDE

New

VLAN 301 Physical Int / SwitchportDisplays receiver IP address and interface for IGMPv2 hostsIGMP Explicit Tracking



User Subscriber rates

es1-7606-c3#show ip igmp snooping subscriber-rate 126.1.99.37

0.0.0.0/239.254.1.2 Vl301:Gi3/1 126.1.99.37 996 pps/366 kbps (1 sec)

0.0.0.0/239.254.1.1 Vl301:Gi3/1 126.1.99.37 996 pps/366 kbps (1 sec)

0.0.0.0/239.254.1.5 Vl301:Gi3/1 126.1.99.37 1000 pps/368 kbps (1 sec)

0.0.0.0/239.254.1.4 Vl301:Gi3/1 126.1.99.37 1000 pps/368 kbps (1 sec)

0.0.0.0/239.254.1.3 Vl301:Gi3/1 126.1.99.37 1000 pps/368 kbps (1 sec)

--------------------------

Total = 4992 pps/1836 kbps (1 sec)

Displays total traffic subscribed from one user

Combines information from:show ip igmp snooping explicit-tracking vlan [vlan]show ip mroute [group] active

Available on 6500 in 12.2(33)SXI

New


Agenda

� Which PIM Mode ?

� General Configuration Notes

� RP Engineering

� Controlling Groups, Sources & Receivers

� Market Data Feed Forwarding

� High Availability Notes

� Controlling App Traffic – QoS, Scoping

� Receiver Tracking


Q and A


Meet The Expert

To make the most of your time at Cisco Networkers 2009, schedule a Face-to-Face Meeting with a top Cisco Expert.

Designed to provide a "big picture" perspective as well as "in-depth" technology discussions, these face-to-face meetings will provide fascinating dialogue and a wealth of valuable insights and ideas.

Visit the Meeting Centre reception desk located in the Meeting Centre in World of Solutions


Source: Cisco Press

Recommended ReadingBRKIPM-2261


Multicast at Networkers:

� BRKIPM-2261 Deploying IP Multicast

� BRKIPM-3010 Advances in Multicast

� BRKSEC-2015 Multicast Security

� BoF-01 - Multicast BoF

BRKIPM-2261

Documents

Transcript of BRKIPM-2261