Conflicting Cisco Recommendations for Multicast PIM modes??
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...
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."
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.
Re: Conflicting Cisco Recommendations for Multicast PIM modes??
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).
Hi everyone, I would like to thank you in advance for any help you can provide a newcomer like myself!
Im studying the 100-105 book by Odom and am currently on the topic of Port security. I purchased a used 2960 and I'm trying to follow a...
While deploying a number of 18xx/2802/3802 model access points (APs), which run AP-COS as their operating platform. It can be observed on some occasions that while many of their access points were able to join the fabric WLC withou...
I am going to design and build an LAN network under a tunnel underground with long distance between the switches.
I will have 2 Catalyst switches and 8 Industrial IE3000, and they will be connected with fiber.
For now I am planning on use Layer-2 s...