Why does this Topology not look like it was made in MS Paint? Because I am using CML to lab!
After trying to NAT, NAT, and then NAT traffic in and out of GNS3 to generate Multicast traffic into my previous Topology the time I spent troubleshooting the lab outweighed the study time – So CML it is!
Before I dive into labbing in CML though I wanted to separate the next level of Multicast concepts into a non-configuration / labbing article, as its enough information that it seemed to deserve its own dedicated page for just the theory of how everything works together to make Multicast Routing happen.
A review of IGMP, brief PIM review (more below), and Source-Tree vs Shared-Tree Multicast Routing
IGMP (Internet Group Management Protocol) is used by Host devices to tell their Edge Device like a Router that they would like to Join / Leave / Filter Multicast traffic that it (the Router) receives, while PIM (Protocol Independent Multicast) is how Routers exchange Multicast traffic across network devices.
A few nuts and bolts at a very high level view with these PIM and IGMP:
- PIM is Protocol “Independent” meaning it does not rely on a Routing Protocol to route traffic
- PIM is sub-divided into two well known modes: PIM Sparse-Mode and Dense-Mode
- IGMP is only used by Hosts, and PIM is then used to pass Multicast message traffic
- IGMPv2 introduced the “Leave” message to IGMPv1, and is currently the default IGMP mode
- IGMPv3 uses SSM (Source Specific Multicast) to Filter Multicast Traffic by Source (S, G)
- (S, G) = (Sender IP, Group Multicast Address)
The (S, G) concept originates from how the host announces how it wants to “Join” a Multicast Group to its upstream routers, where if it just wants to receive any traffic being streamed to 224.2.2.11 regardless of the source, it appears both in documentation and (*, G) because its only specifying the Multicast Group.
IGMPv2 can only send (*, G) Join requests, whereas IGMPv3 can utilize SSM Filtering (Source Specific Multicast) where it will include a source IP Address, which can be very confusing to even try to explain without pictures so I reverted back to using MS Paint to illustrate this concept.
When a Host uses IGMPv3 and SSM to define a Source IP (non-Multicast addy) and a Multicast Group:
The “G” will always be a Multicast Group or Class D address (as far as I currently know), while the Source address will be the regular Source address of the Router sending it, so with (S, G) not only must the Multicast Group be correct to receive the stream at all, but also the Source IP Address!
If a Host uses IGMPv2 and just sends a “Join” request to receive streams from 224.2.2.11:
To note – IGMPv3 can also send out (*, G) the same as IGMPv2 if it doesn’t use SSM, I am just overly demonstrating the difference between the versions here for the sake of really hammering it home.
Once these requests hit R3 from Desktop-0, PIM is used between routers to exchange messages to create the desired path for the Multicast Traffic to take to reach Desktop-0 with its desired Netflix movie.
With the easy stuff covered, lets get into how Multicast works at a glance – Distribution Trees!
There is first are two different “Distribution Tree” Types used by Multicast to determine traffic flow:
- Shared Tree – This uses a predetermined “Root” device which is called a “Rendezvous Point” or “RP” in Multicast Terminology, of which Multicast Traffic originate from or go through to reach the destination Host that wants to receive the Multicast Stream, this tree type is terribly inefficient as will be shown
- Source Tree / Shortest Path Tree – This allows the “Root” of the Multicast Network to be whichever Router the Multicast Traffic is originating from, using IP Route Tables to determine the best path to a Host requesting to “Join” that Multicast Group, and does not use a Rendezvous Point / RP
In my Topology I named one of the Routers “RV-Router” meaning that is the Shared Tree “Root” for the Topology because I want to eat up as much bandwidth as possible, and here is why that is:
Now further down the Multicast rabbit hole, Shared Tree / PIM works together to perform a Multicast Discovery, so its not entirely terrible, but we certainly don’t use it for all Multicast traffic!
As seen the RV-Router must be the Root or Source of the Multicast Traffic for any Multicast Streams it is configured to be part of, which as can be seen from R2 -> R1 -> RV -> R3 is not ideal.
Then there is Source Tree / Shortest Path Tree (SPT) that allows for… the Shortest Path to be used:
With Source Tree / Shortest Path Tree, there is no “Rendezvous Point” or “RP” to make traffic circle the network to reach its Destination, saving huge amounts of Bandwidth, however Source Tree does not make a very ideal Multicast Discovery mechanism because it does not crawl through the entire network!
Speaking of Multicast Network Discovery, lets look at PIM Dense-Mode and Sparse-Mode
Despite what my diagrams might lead you to believe, Multicast Traffic is not just colors drawn all over a Topology, it is unique Traffic in the way that it has to find a balance between Unicast and Broadcast!
I bring up that middle ground between Unicast and Broadcast, because Multicast can look a lot like a Broadcast of traffic during it discovery process, with PIM quietly exchanging messages between Multicast Neighbor Routers to pass Multicast Traffic to its destination using different PIM and SSM Mechanisms.
First thing First – PIM or Protocol Independent Multicast means the Multicast Traffic doesn’t rely on any specific IP Protocol to move Data, it will use absolutely any route configuration to move traffic including:
- A dynamic route
- A default route
- A policy route
- A route map
- Two papers clips and a piece of scotch tape!
While other mechanisms like Source Tree and SSM will use the IP Route Table to find the Shortest Path between the source and destination for Multicast traffic, PIM depends on those mechanisms to make the best forwarding decisions (or terrible decisions like with Shared Tree) to decide how traffic is forwarded.
However PIM itself is chatter between two Multicast Neighbors, a lot like MPLS only knows of its MPLS Neighbor Labels to forward traffic through the “Label Switched Path” – PIM is the same basic idea!
An overview of PIM Dense-Mode operation
Keith Barker coined a great term for PIM Dense-Mode in how it operates simply as “Forward First, Prune Later” in how PIM Dense-Mode enabled Multicast Router that is streaming Multicast Traffic will forward it to all of its neighbors and they will forward it to all of their neighbors until it saturates the network like a Broadcast of Traffic – Then the Multicast Neighbors will tell their Multicast Neighbors via PIM with a “Prune” message in response to the traffic to indicate they do not want to receive the stream.
This continues with each new burst of Multicast Traffic, PIM Dense-Mode routers assume that the whole world wants to receive their Multicast Traffic stream, unless specifically told no via “Prune” reply:
This process continues over and over for every Multicast Stream that originates from any Multicast Router, and the others have to use PIM to send “Prune” messages to stop the noise constantly, so PIM Dense-Mode is rarely used in modern networks unless for very specific / special case uses.
And then there is PIM Sparse-Mode, Shared Tree, and SSM to tie all of this together!
PIM Sparse-Mode uses the “Rendezvous Point” or “RP” from Shared Tree to either manually elect a Root / RP Router that Multicast Routers will report up to, whether it is to send a “Join” request or to send a Multicast Stream up to the RP Router, as it will know which Multicast Routers sent a PIM “Join” request and will then forward the traffic down to the destination.
After a few PIM Sparse-Mode messages from Multicast Neighbors, we have the initial stream flowing:
Desktop-0 tells R3 that it wants to receive Multicast Traffic from ANY Source to Multicast Group 224.2.2.11, R3 passes that up to the RP Router via a PIM “Join” request, so the RP now knows if it gets Multicast Group Traffic for 224.2.2.11 it needs to send it down to R3.
Desktop-2 sends Multicast Group Traffic to 224.2.2.11 via IGMP, which R1 detects did NOT originate from the RP Router, making R1 now a “First Hop Router” for this Multicast Stream and it informs the RP via PIM that it has this Multicast Group stream available for Group Members that want to receive it.
The RP Router now has the Join Request, the Multicast Stream notification, and forwards the traffic!
Then PIM Sparse-Mode uses the Source IP of the Stream to create a Shortest Path Tree!
Once R3 has the Source IP of the Multicast Group traffic, it will create a Shortest Path Tree to the Source of the traffic, and will eventually send PIM “Prune” replies between R1 and R3 to the RP once they cut over to talk more directly to each other and no longer need a Rendezvous Point:
This actually reminds me a lot of DMVPN going from “Phase 1” where mGRE Tunnels are all connected back to a common NHRP Server to communicate, to it transitioning into “Phase 2” where the mGRE DMVPN Routers begin communicating directly with each other, its a very cool process to understand.
Then IGMPv3 SSM comes in and completely crushes both these methods with (S, G)!
SSM actually entirely cuts out the need for the PIM Sparse-Mode discovery by IGMPv3 telling its edge Router that it wants x Group from x Source only (S, G), and SSM will actually build a Short Path Tree immediately rather than having to go through a discovery and cut over process.
Though the cut over process is cool to walk through step by step, and see the technology evolve into deeper and deeper efficiency until in this instance SSM steps onto the scene and destroys them both 🙂
With that I will conclude the theory and fundamentals of Multicast, and next dive into labbing!
I have gotten CML operational on my laptop and learned how to make a small Topology, and I absolutely cannot wait to start digging into the nice assortment of technology to lab R/S, Automation, or both:
I definitely want to dig back into some high level R/S topics, I will finally have an ASA appliance NOT in production I can go nuts labbing on and actually learn what breaks things and what doesn’t, and tons of Cisco Next-Gen Platforms that are just begging to be Automated!!! 🙂
Until Next Time, Keep it Multicasty!!! 🙂
The DEVNET GRIND! 