Just what is multicast? How do you set up your network to handle multicast? And how do you troubleshoot it if it fails? Let's start from the beginning.
Typical IP packet forwarding is considered "unicast" - a communication is broken up into IP packets and sent from a single source address to a single destination address where the payload is extracted from its network headers and reassembled. This works well for most communication where an endpoint - laptop, tablet, phone - needs to exchange data with another endpoint. You could be working on a file in a data store, or sending an email via a messaging server. You may even be on a video call connected to a conference bridge. In each of these applications, your machine is typically only communicating with one other endpoint at a time.
A different class of application might need to send the exact same data from one source to multiple receivers. Examples of this might be:
The common characteristic here is that identical copies of data from a single source need to be delivered to multiple endpoints.
You could use broadcast traffic to deliver this data, flooding data to every endpoint in the network. However, if you sent these data streams to all ports in the network, your resources would soon become overwhelmed. And it is potentially insecure too, as data would be delivered to endpoints that don't need it. A more selective mechanism to take a packet in a data stream, replicate it, and send it out to multiple receivers is needed.
With multicast delivery, endpoints (receivers) subscribe to a data stream being sent out by a source. The network nodes use protocols such as Internet Group Messaging Protocol (IGMP) and Protocol Independent Multicast (PIM) to manage forwarding and routing. This then ensures that they deliver streams to only the receivers who request access.
In order to prevent traffic getting into loops and unnecessarily consuming bandwidth, network nodes form up a distribution tree for multicast traffic. Multicast sources are tracked by network nodes listening out for streams. The network then adds receivers into the distribution tree when they request to join a multicast group.
The network identifies multicast streams as using Class D IPv4 addresses - between 224.0.0.0 and 239.255.255.255 - referred to as multicast groups. Routing logic for multicast traffic works almost in reverse to normal unicast routing: each router maintains a path back towards the source for each group.
Nodes typically send out an IGMP notification if they want to join a group (ie receive a particular multicast stream). The local network listens for the notification to identify that it has a receiver for the group, and notifies the wider multicast network that it needs to be part of the distribution tree for that group. In order to achieve that, routers exchange multicast routing protocol messages - the most common protocol being PIM.
Network engineers typically find multicast very difficult to troubleshoot. The logic appears "backwards" as the multicast routing is concerned with ensuring a path is built from receiver to sender. It's difficult to adjust the mindset required without regular exposure to it.
As a result, there is a bit of an air of mystery to the multicast troubleshooting process. Routing tables look "alien". It is difficult to track down all receivers for a multicast stream without logging in to every node in the network, checking for potential receivers, making sure routes are in place for all possible senders and assembling a distribution tree (usually on paper) to make sure there is continuity from all senders to all receivers.
Our development team have built comprehensive support into the platform to help you get to grips with multicast traffic.
First things first, IP Fabric queries switches and routers in the network to establish exactly where receivers are in the network using IGMP and IGMP Snooping information - presented in tables:
We can also track the sources:
We can visualise the PIM adjacencies which are formed between network nodes to share multicast routing information:
And we can visualise the multicast distribution tree from sender to all the receivers:
Most multicast issues tend to be down to configuration and the completeness of the distribution tree as a result - you can see how IP Fabric allows you to confirm that visually.
If all appears to be configured correctly but traffic is still not landing at certain receivers, there may be another element at play - reverse path forwarding (RPF) checks. Routers ensure that there is a valid path back towards the source of a multicast stream. When the unicast routing is aligned with the multicast distribution tree, there are no loops and traffic will flow as expected.
This can be tough to track down as - again - you would typically have to walk the entire tree to find where this is occurring. Unless you have IP Fabric that is! With our intent verification, we can overlay RPF error checking onto the topology and show exactly where there are failures:
If you have found this article helpful, please follow our company’s LinkedIn or Blog, where more content will be emerging. If you would like to test our solution to see for yourself how IP Fabric can help you manage your network more effectively, please contact us through www.ipfabric.io.
Just what is multicast? How do you set up your network to handle multicast? And how do you troubleshoot it if it fails? Let's start from the beginning.
Typical IP packet forwarding is considered "unicast" - a communication is broken up into IP packets and sent from a single source address to a single destination address where the payload is extracted from its network headers and reassembled. This works well for most communication where an endpoint - laptop, tablet, phone - needs to exchange data with another endpoint. You could be working on a file in a data store, or sending an email via a messaging server. You may even be on a video call connected to a conference bridge. In each of these applications, your machine is typically only communicating with one other endpoint at a time.
A different class of application might need to send the exact same data from one source to multiple receivers. Examples of this might be:
The common characteristic here is that identical copies of data from a single source need to be delivered to multiple endpoints.
You could use broadcast traffic to deliver this data, flooding data to every endpoint in the network. However, if you sent these data streams to all ports in the network, your resources would soon become overwhelmed. And it is potentially insecure too, as data would be delivered to endpoints that don't need it. A more selective mechanism to take a packet in a data stream, replicate it, and send it out to multiple receivers is needed.
With multicast delivery, endpoints (receivers) subscribe to a data stream being sent out by a source. The network nodes use protocols such as Internet Group Messaging Protocol (IGMP) and Protocol Independent Multicast (PIM) to manage forwarding and routing. This then ensures that they deliver streams to only the receivers who request access.
In order to prevent traffic getting into loops and unnecessarily consuming bandwidth, network nodes form up a distribution tree for multicast traffic. Multicast sources are tracked by network nodes listening out for streams. The network then adds receivers into the distribution tree when they request to join a multicast group.
The network identifies multicast streams as using Class D IPv4 addresses - between 224.0.0.0 and 239.255.255.255 - referred to as multicast groups. Routing logic for multicast traffic works almost in reverse to normal unicast routing: each router maintains a path back towards the source for each group.
Nodes typically send out an IGMP notification if they want to join a group (ie receive a particular multicast stream). The local network listens for the notification to identify that it has a receiver for the group, and notifies the wider multicast network that it needs to be part of the distribution tree for that group. In order to achieve that, routers exchange multicast routing protocol messages - the most common protocol being PIM.
Network engineers typically find multicast very difficult to troubleshoot. The logic appears "backwards" as the multicast routing is concerned with ensuring a path is built from receiver to sender. It's difficult to adjust the mindset required without regular exposure to it.
As a result, there is a bit of an air of mystery to the multicast troubleshooting process. Routing tables look "alien". It is difficult to track down all receivers for a multicast stream without logging in to every node in the network, checking for potential receivers, making sure routes are in place for all possible senders and assembling a distribution tree (usually on paper) to make sure there is continuity from all senders to all receivers.
Our development team have built comprehensive support into the platform to help you get to grips with multicast traffic.
First things first, IP Fabric queries switches and routers in the network to establish exactly where receivers are in the network using IGMP and IGMP Snooping information - presented in tables:
We can also track the sources:
We can visualise the PIM adjacencies which are formed between network nodes to share multicast routing information:
And we can visualise the multicast distribution tree from sender to all the receivers:
Most multicast issues tend to be down to configuration and the completeness of the distribution tree as a result - you can see how IP Fabric allows you to confirm that visually.
If all appears to be configured correctly but traffic is still not landing at certain receivers, there may be another element at play - reverse path forwarding (RPF) checks. Routers ensure that there is a valid path back towards the source of a multicast stream. When the unicast routing is aligned with the multicast distribution tree, there are no loops and traffic will flow as expected.
This can be tough to track down as - again - you would typically have to walk the entire tree to find where this is occurring. Unless you have IP Fabric that is! With our intent verification, we can overlay RPF error checking onto the topology and show exactly where there are failures:
If you have found this article helpful, please follow our company’s LinkedIn or Blog, where more content will be emerging. If you would like to test our solution to see for yourself how IP Fabric can help you manage your network more effectively, please contact us through www.ipfabric.io.
