A Brief About Multicast

Introduction

In a nutshell, multicast is a way of efficiently sending traffic from one source to multiple destination without burdening neither the source by having multiple separate streams to the destinations nor duplicating the traffic on the network thus over utilising the links.

A simple example for that is broadcasting a video stream to 100 users; let’s imagine this is a HD video stream using 4 Megabits/s of data. If the server needs to send a video stream for each single user, that means 400 Megabits/s only for those 100 users, not very efficient eh? With multicast, the server can only stream the video once and the network can duplicate the stream on-demand for people who want to watch it

But in order to do that, destination based routing as we know it wouldn’t do the trick, so there was multicast routing. For many people multicast routing is a hell of a topic, even for me I tend to sometimes get confused when troubleshooting a multicast problem. But practice makes perfect!

One of the basic concepts of multicast is that the Multicast sources don’t send traffic to a particular receiver but instead it sends it to a Multicast group. A multicast group is essentially an IP address that has a special meaning for the router in between the source and the receiver that when it receives traffic on this group, it immediately understand that some other interfaces towards the receivers might be interested in listening to the traffic from that group, so it replicates the traffic according to the number of the interested interfaces and forwards it to them. If a certain interface didn’t show up interest in listening to that group, no traffic will be sent to it, hence the efficiency of multicast.

1. Source sends the traffic out to destination address which will be ‘group addresses.
2. Interested receivers join the group address by signaling routers on LAN.
3. Routers communicate with each other to build up a loop free tree from Source to the destination(s).
4. Receivers that are not interested in a certain multicast traffic (Not joining the group address) will never receive the traffic.

Multicast Address Allocation

In order for multicast to work, two protocols are needed to make it happen

IPv4 Class-D range was allocated for multicast traffic purposes

The range start from 224.0.0.0 to 239.255.255.255

1-     Link Local Addresses: 224.0.0.0/24
Primarily this is used by many known protocols, there are many examples like:

224.0.0.1 All any node on the subnet
224.0.0.2 All routers on this subnet
224.0.0.13 All PIM routers
224.0.1.39 Cisco-RP-Announce
224.0.1.40 Cisco-RP-Discovery
224.0.0.5 All OSPF routers
224.0.0.6 OSPF designated routers
224.0.0.9 RIPv2 routers
224.0.0.10 EIGRP routers

2-     Source Specific Multicast (SSM) Addresses: 232.0.0.0 through 232.255.255.255
 the main purpose of SSM is that the client has the ability to request to join a certain group FROM a certain source.

3-     Administratively Scoped Multicast Addresses: 239.0.0.0 – 239.255.255.255
just like 192.168.0.0/24 is a private subnet for unicast traffic, the administratively scoped multicast address range can be considered as the private range for multicast traffic.

Multicast Protocols

In order for multicast to work, two protocols are needed to make it happen

1-   IGMP – Internet Gateway Messaging Protocol

This protocol is used between the receiver and the router or switch it is connected to, in order to request to join or leave a specific multicast group

IGMPv1

Now considered as a legacy protocol and it’s hardly ever used in any modern network

Uses two types of message

1-     Host membership Report
A Report message is sent when an application on client machine or the receiver is requesting to join a multicast group

2-     Host membership Query

Query is used by router to check if members of the group still exist and interested to get the traffic from the multicast group. If no receivers exist then the router will turn off the feed on the LAN. The Query is sent to all multicast hosts address of 224.0.0.1

Note: Supports group specific joins which are (*,G)   means that it does not care who the source is – just interested in the destination group address.

IGMPv2

IGMPv2 is backward compatible with IGMPv1

Enhancements of IGMPv2 over IGMPv1

1. The timers values are configurable to speed up the query and response times.

2. If multiple routers exist on the same LAN then one of the routers is elected which is known as the Querier.

3. Unlike IGMPv1 where the query was sent to all multicast hosts address, in IGMPv2 group specific queries can be sent on the LAN by the routers to each multicast group address separately.

4. When a client leaves the multicast address, the client has an option to send out an explicit leave message to the router on the LAN. If there are no other hosts want that multicast traffic then router can stop forwarding multicast traffic on the LAN segment.

IGMPv3

One of the Major benefits of IGMPv3 is the capability of Source Specific Multicast or SSM. SSM allows the receiver to explicitly ask for a specific feed from a specific source. This enhances security and also improves how planning of multicast capacity in many network scenarios since it uses only the shortest path tree from the source to the receiver

2-   PIM – Protocol Independent Multicast

This protocol messages is only communicated between the multicast routers to exchange information that will later build a loop free tree from the multicast source to the receiver. Hence the name “independent”, PIM relies on other protocols (OSPF, EIGRP etc.) to make sure that the topology is loop free.

A-    PIM Modes

1-     PIM Dense Mode

PIM Dense Mode operates on the principle of flood-and-prune, where the multicast traffic from the source is flooded to all network nodes using, even though none of them asked for it, and then branches of multicast tree that doesn’t want the traffic will prune it. This mechanism can have disastrous effects on large networks that can literally bring it down in seconds if large amounts of traffic are being forwarded.  

Dense mode uses 224.0.0.13 to discover neighbors on enables interfaces and then it floods the multicast traffic to all interfaces except the one it received the traffic from. Since this is non-deterministic, dense mode uses the shortest path trees to deliver traffic from the source to receivers.

Dense Mode Multicast Flooding
1. The Source of multicast traffic sends the traffic to the group address.
2. Router receiving the feed (packets) inserts an (S,G) entry into the multicast routing table where S = Source of the Feed and G= Group address.
3. The router also creates a (*,G) entry into the multicast routing table, stating that it is processing traffic for this group address.
4. Router also inserts into the routing table the Outgoing Interface List which lists all the PIM interfaces connecting to other PIM Routers
5. Outgoing Interface list is also referred to as OIL, and the multicast packet received from the source is replicated to all interfaces in OIL. OIL interfaces are always forwarding traffic towards the receivers, if the next hop in OIL is Null, then there are no receivers on those interfaces.
6. Next hop routers perform the same steps and the final result is the shortest path Tree from the source to the receivers for that multicast group.

PIM Dense Mode Pruning
Prune messages are always sent in response to the multicast feed received from upstream router. Prune messages are never unsolicited.
Prune messages are sent by the router to its upstream router to tell it to stop sending the traffic for a particular (S,G)
Prune messages occur when
1. No downstream neighbor or receivers for that group exist anymore
2. If all downstream neighbors have sent a prune message for that group
3. If the multicast feed fails an RPF check.

Prune Override

In a LAN environment if one downstream neighbor sends a prune message, the prune message will go to upstream router and also to other PIM neighbors on the LAN, since the prune message is multicast on 224.0.0.13. If any other PIM neighbor that is still interested in receiving the multicast feed can send a prune override messages and that upstream router will not prune the feed. Once the prune occurs, the traffic flow will stop and the (S,G) entry remains in the multicast routing table until the timer for the (S,G) entry expires then it is flushed out of the multicast routing table. Even after the prune occurs the traffic for the group is flooded periodically at a set interval.

Multicast Routing table is maintained by using a set of messages – Graft, Assert and State Refresh messages

·         Graft: when a router receives an IGMP message from a receiver that wants to join a specific group, it sends graft message to its upstream router telling it to that it needs to get traffic from that group so that it can forward it to the receiver

·         Assert: to avoid traffic duplication and forwarding loops on a LAN segment with two or more routers, the assert message is used to elect only one router to handle the multicast traffic.

The router with the shortest path (lowest IGP metric) to the source wins the election, if they have the same metric then the router with the lowest IP address wins.

·         State Refresh: The PIM Dense Mode State Refresh feature is an extension of the PIM Version 2 multicast routing architecture. PIM dense mode builds source-based multicast distribution trees that operate on a flood and prune principle. Multicast packets from a source are flooded to all areas of a PIM dense mode network. PIM devices that receive multicast packets and have no directly connected multicast group members or PIM neighbors send a prune message back up to the source-based distribution tree toward the source of the packets. As a result, subsequent multicast packets are not flooded to pruned branches of the distribution tree. However, the pruned state in PIM dense mode times out approximately every 3 minutes and the entire PIM dense mode network is re-flooded with multicast packets and prune messages. This re-flooding of unwanted traffic throughout the PIM dense mode network consumes network bandwidth. The PIM Dense Mode State Refresh feature keeps the pruned state in PIM dense mode from timing out by periodically forwarding a control message down the source-based distribution tree. The control message refreshes the prune state on the outgoing interfaces of each device in the distribution tree.

2-     PIM Sparse Mode

Works on the Principle where you get no multicast traffic until you ask for it. In sparse mode, explicit join messages has to be received by a router in order to forward multicast traffic down to a certain branch of the tree. It is built on the concept of shared tree (it also uses shortest tree) where all routers in the network agrees on some form of a central point that decides how the multicast traffic will be forwarded throughout the network. This central point can be Bootstrap Router (BSR) or Rendezvous Point (RP) depending on the implementation. The main benefit of this is that the BSR or RP knows all the multicast sources and who’s asking for it, so there’s no need to flood all the network and then prune, traffic is only sent to the tree branch that asks for it.

On LAN Segments, a designated router is elected to communicate with the RP about the multicast sources. The election of the DR is based on higher priority, and the then the higher IP address if the priority is equal.

Only the first packets when forming the shared tree passes through the RP, then the traffic uses the shortest tree from the source to the receivers. This is very important since the RP can be overwhelmed if all the multicast traffic passes through it.

There are two messages used in the shared-tree model

·         Register Message

This message is used by the router connected to the multicast source to inform the RP or BSR that there’s a multicast source when a certain IP and it is streaming traffic to a certain group. When the RP gets the register message, RP inserts the (S,G) entry in the table and sends a register stop message back to the originating router.

·         Join message

This is a similar message to the Graft message mentioned earlier used when the last hop router that is connected to the receiver receives and IGMP message requesting to receive traffic from a group, the join message is sent towards the RP or BSR to inform them that multicast traffic is needed in this direction.

When the PIM join is generated up the reverse path towards the RP, all the routers in the path will install the (*,G) entry and forward the join hop-by-hop towards the RP, so at this point all the routers in the path toward the receiver and the RP have the (*,G) entry.

When the RP knows about both (S,G) and (*,G) then RP sends a PIM join message towards the source to the routers in the path. This Join message makes sure that all routers in the path add the RP to the OIL.     

Multicast Forwarding

Since the forwarding logic in unicast is very different from multicast, the operation of multicast forwarding is bounded by several rules

In unicast forwarding table, unicast traffic has only one source and one destination, the one destination makes it easy for the router to forward packets based on the destination route, even if there are ECMP. Multicast on the other hand faces the problem of having multiple destinations that need to receive this traffic, hence the OIL is generated to make sure that traffic is being replicated internally and sent of all OIL interfaces.

Another problem is the possibility of traffic being looped due to the flooding and replication process. This can be resolved by Reverse-Path Forwarding check which ensures that traffic doesn’t get looped due to the replication and flooding mentioned earlier.

RPF Check Process

Unicast routing table is checked for reverse path back to the source, which is the 3 steps listed below

1. Check the source IP address of the multicast packet received in the feed.

2. Check the interface on which it was received.

3. Check the unicast routing table (CEF table) to find out if the IGP uses this interface to reach the IP address of the source.

4. If the IGP uses this interface to reach the source then RPF check passes otherwise it’s a looped packet and RPF check fails and the packet is dropped.