Conflicting Cisco Recommendations for Multicast PIM modes??

Unanswered Question
Oct 8th, 2008
User Badges:

Hi,


Read the two Cisco statements below and give me your opinion on which road to go down for a large scale multicast deployment utilizing MPLS VPN's(possible end-use use cases unknown because it is a provider environment...


Exhibit A:

From current Cisco TAC multicast training lab...


"Deploying IP multicast with PIM Dense Mode is not scalable enough for the production networks due to inherent features of the dense mode multicast protocols. Instead the PIM Sparse Mode is used in production IP multicast enabled networks.


This protocol is scalable and very appropriate for implementation in modern networks. Most current networks, whether enterprise or service provider networks, build their multicast solution on a sparse model of IP multicast."


Exhibit B:

From a currently published Cisco article...


"Cisco recommends using the Protocol Independent Module (PIM). Enabling PIM on an interface also enables IGMP operation on that interface. An interface can be configured to be in PIM dense mode, PIM sparse mode, or PIM sparse-dense mode. The mode determines how the router populates its multicast routing table and how the router forwards multicast packets it receives from its directly connected LANs ...Cisco recommends configuring an interface for sparse-dense mode."


...I have also read Cisco recommendations for PIM-SSM in MPLS VPN provider networks, because PIM Bidir (Sparse-Dense) isn't supported on all equipment. In my case, it is a 6509/3750 infrastructure.




  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3.5 (2 ratings)
Loading.
paul.matthews Wed, 10/08/2008 - 12:17
User Badges:
  • Silver, 250 points or more

Sparse mode and sparse-dense mode are not that conflicting. In sparse-dense all user traffic will be handled as sparse mode, with dense mode only used to negotiate/communicate the RP.


SSM is only of use if clients are using IGMPv3.


My preference - sparse mode, static "anycast" RPs using MSDP to share information.


Nice and deterministic.

Giuseppe Larosa Wed, 10/08/2008 - 12:32
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Mike,

no real conflict here

sparse-dense-mode and sparse-mode.

The first will treat multicast groups not mapped to an RP as dense mode and all groups mapped to an RP as sparse.

This config helps to solve the problem of signaling startup with old AutoRP:

AutoRP use addresses 224.0.1.39 and 224.0.1.40 to advertise the existance of RPs but before RPs are known how can be correctly propagated the info of groups 224.0.1.39 and 224.0.1.40 ?

So sparse-dense-mode provides a way to solve this.

If your network support PIM version2 you can use the bootstrap protocol that uses PIM messages sent to 224.0.0.13 for advertising RPs and doesn't have this problem.

The best solution is a form of anycast RP that provides redundancy: in a big network using Bootstrap in a small network with static mapping to the anycast RP address


Be aware that you can have different multicast groups ranges treated as PIM SM, PIM SSM and so on as you need.


Hope to help

Giuseppe

netwalkr1 Wed, 10/08/2008 - 15:56
User Badges:

I hope this helps.


Sparse Versus Dense Mode

Recall that PIM Dense Mode is used (in principle) when the multicast is desired in most locations. Thus initial multicast packets are flooded everywhere, with pruning cutting off traffic to locations that do not need the multicast feed. Until recently, PIM Dense Mode suffered from periodic re-flooding every 3 minutes, but in 12.1(5)T, the PIM Dense Mode State Refresh feature alleviated this. With this feature, PIM Dense Mode is arguably suitable for simple implementation of multicast. Especially where the additional control of PIM Sparse Mode is not needed, and where occasional "accidental" flooding would not be very harmful.


PIM Sparse Mode uses an explicit request approach, where a router has to ask for the multicast feed with a PIM Join message. PIM Sparse Mode is indicated when you need more precise control, especially when you have large volumes of IP multicast traffic compared to your bandwidth. PIM Sparse Mode scales rather well, because packets only go where they are needed, and because it creates state in routers only as needed. Because of this, it has been written up as an Internet Experimental Protocol. See http://www.ietf.org/rfc/rfc2362.txt .


The price we pay for this extra control is mild extra complexity. PIM Sparse Mode uses a special router called a Rendezvous Point (RP) to connect the flow source or multicast tree to the router next to the wannabe receiver. The RP is typically used only temporarily, as we'll see below.


There can be different RP's for different multicast groups, which is one way to spread the load. There is usually one RP per multicast gropu. Redundancy of RP's is an advanced topic, and requires a little deeper expertise. One way to do this is with the MSDP protocol (possible later article in the series).


Recall that a PIM Join message is sent towards a Source (or for PIM-SM, possibly towards an RP), based on unicast routing. The Join message says in effect "we need a copy of the multicasts over here". It connects the sender of the Join and intervening routers to any existing multicast tree, all the way back to the target of the Join if necessary. A Prune message says in effect "we no longer need this over here". A router receiving a Prune sees whether it has any other interfaces requiring the multicast flow, and if not, sends its own Prune message. One advanced technique is to arrange a separate and perhaps different copy of the unicast routing information just for multicast purposes. This allows "steering" of the Join messages. MultiProtocol BGP, MBGP, for multicast, is one way to do this (possible later article in the series).


Source: http://www.netcraftsmen.net/welcher/papers/multicast03.html


Just for reference, we use PIM-Spare/MSDP for our large scale multicast subscribers (IPTV).


http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/anycast.html

Actions

This Discussion