Above is a Topology I created for Multicast Routing, however I’ve found in digging into Multicast that I will need to add some LAN segments to really demonstrate behaviors of different Multicast configuration, so this will cover the fundamentals of Multicast before hitting the lab to get our hands dirty!
Why we need Multicast Routing in our daily lives – We need our streaming services on-demand!
Netflix, VoIP, and MMO (Massively Multi-player Online) video games!
Multicast Routing allows the above few examples of streaming services to work without saturating the Internet or Company Networks with data packets, using IGMP (Internet Group Management Protocol) and PIM (Protocol Independent Multicast) to allow Hosts or End devices to listen to a particular Multicast Address streaming Data it wants to receive, and allowing Upstream devices such as Routers that originate this traffic to only send a single copy of the Data downstream devices to deliver the stream only to the Hosts listening to that Multicast Address / Stream, avoiding the need to have separate Data streams for each Host.
IGMP vs PIM will be discussed in detail later down the Multicast Routing discussion.
Where is Unicast Traffic is Host to Host (1:1) communication, and Broadcast Traffic to all Hosts (1:All), Multicast Traffic is considered 1:Many via Class D IPv4 Address space (224.0.0.0 – 239.255.255.255) as learned in the CCNA studies.
Going back to the Streaming Services such as Netflix for example, Internet Routers simply could not handle 10 million Unicast connections for subscribers to Netflix streaming different shows, and the solution to this is for Netflix to stream the data (or copy of the data packets once) to Downstream devices which then continue sending this data Downstream until it eventually is received by Hosts (residential devices / routers) that are in the IGMP Group listening to the stream.
The overhead from streaming media 1:1 would grind the Internet to a halt with modern streaming services such as MMO video games and Video streaming services – So Multicast to the rescue!
A quick review of some CCNA / CCNP Multicast Addresses, and some new ones coming up!
Below is non-conclusive list of well-known Multicast Addresses for Dynamic Routing Protocols, and some new addresses for topics that will be demonstrated going forward that allows Multicast Routing to work:
- 224.0.0.0/24 – Local Multicast Subnet / Control Block
- 224.0.0.1 – All hosts on local subnet
- 224.0.0.2 – All Multicast Routers
- 224.0.0.4 – DMVRP (Distance-Vector Multicast Routing Protocol) Routers
- 224.0.0.5 – All OSPF Routers
- 224.0.0.6 – All OSPF Dr Routers
- 224.0.0.9 – All RIPv2 Routers
- 224.0.0.10 – All EIGRP Routers
- 224.0.0.13 – All PIM Routers
- 224.0.1.0/24 – Internetwork Control Block
- 224.0.1.39 – Rendezvous Point (RP) Announce
- 224.0.1.40 – Rendezvous Point (RP) Discover
- 224.0.2.0/24 – Ad Hoc Multicast Block
- 239.0.0.0/8 – Admin Scoped Address Space
- 239.192.0.0 – 239.251.255.255 – Org-Local Scope
- 239.252.0.0 – 239.254.255.255 – Site-Local Scope
Reviewing IGMP (Internet Group Management Protocol) and its three different versions
Hosts use IGMP to announce their Multicast Group memberships to Routers, so that Routers are aware of which streams they must direct back to the Host, which can use 3 different IGMP Version #’s.
IGMPv1
RFC 1112 for IGMP or now IGMPv1 simply describes the messaging between Hosts and Routers to communicate via Multicast:
- Membership Query – Sent by Router to Hosts to check if they want to join Multicast Group
- Membership Report – Sent by Hosts to Routers in a network segment to join Multicast Group
The problem with IGMPv1 is in how a Host leaves a Multicast Group and the total time it takes to leave the group, as a Host will leave a membership group after 3 missed Membership Query messages, which are sent every 60 seconds meaning it takes 180 seconds or 3 minutes to leave an IGMPv1 group.
IGMPv2
IGMPv2 is the current working standard for IGMP, which expands upon its messages sent between Hosts and Routers to allow for a Host to send a “Leave” message to the Router rather than missing 3 queries.
Below are the 4 IGMPv2 Messages exchanged between Hosts and Routers:
- Membership Query – Sent by Router to Hosts to check if they want to join Multicast Group
- Version 2 Membership report – Sent by Hosts to other Multicast Group Members to join and remain in a Multicast Group within the same network segment (IP Address Control Block)
- Version 2 Leave group – Sent by Hosts to indicate they will leave the Multicast Group, if sent to the “All Routers” Multicast Address of 224.0.0.2, it triggers the Router to query other Group Members to verify if they are remaining Multicast Group Members
- Version 1 Membership report – For backwards compatibility with IGMPv1 members
Essentially this just speeds up the process of Hosts to leave a Multicast Group if the Membership is no longer needed to reduce bandwidth consumption, and in turn Multicast enabled Routers to check with other Hosts to verify they would like to remain within the Multicast Group.
IGMPv3
Being that this is still an emerging IGMP Version I won’t cover all the details in this basic overview of Multicast Routing, however the big leap IGMPv3 takes is providing the Hosts SSM (Source-Specific Multicast) which is a mechanism that allows Hosts to filter Multicast streams by the source of the stream.
IGMPv3 is backwards compatible with V2 and V1, but beyond that I won’t go into details as of yet.
Multicast Routing on Switches
By default, switches are going to be switches, meaning they will forward Multicast Traffic out all ports on the Network Segment (VLAN) it belongs to which allows for some protocols to mitigate traffic.
CGMP (Cisco Group Management Protocol) is a Switch Protocol that can be enabled on Layer 2 switches that allows the switch to talk to the IGMP Routers to gather MAC Addresses of Hosts that want to receive Multicast Traffic, which in turn allows the L2 Switch to only forward this out ports with Multicast Hosts.
CGMP Routers can also forward “Leave” messages to CGMP enabled switches, disabling Multicast on the Host Ports, which may cause inadvertent issues with Multicast Traffic – So if your Hosts suddenly begin having trouble receiving Multicast Traffic it may be due to a Leave message received by an IGMP Router.
^^^ That could be a very evasive issue if you don’t know this behavior, so very good to know!
IGMP Snooping is another L2 Switching mechanism to determine how to forward Multicast Traffic to Hosts on a LAN segment, however it is much less optimal than CGMP as it is a “middle man” for query and control messages between Hosts and IGMP Routers which adds to the CPU load on the switch.
RGMP (Router Group Management Protocol) is another kind of niche Multicast topic that I’d probably rather lab it to understand, however it is a mechanism for Router-Only Switched Ethernet segments, where control messages are relayed between a Switch that only has Routers plugged into it to determine which IGMP Router to forward Multicast Traffic to via Join and Leave messages received.
There is more Layer 2 Multicast / MAC Address mapping, but being this is a basics / overview look at Multicast I will not go into depth on that topic in this article!
I did want to note that Layer 2 Multicast Addressing does exist by combining MAC Addressing with the Multicast Addressing, however it is not a fundamentals topic, so I will cover that at a later time 🙂
I will halt this Multicast Intro here, and save running through Multicast Methods for labbing!
I did spin up a GNS3 Topology of Routers only to demonstrate how traffic would flow, but upon reading through different “Tree” types and methods of configuring Multicast, I am not sure exactly how “best path” is determined so I will be throwing some hosts / LAN segments into the Topology and demonstrate some different Multicast Routing methods in upcoming articles here to dig into the nuts and bolts.
Until next time! 🙂
The DEVNET GRIND! 