There are two important protocols required to get your network to forward multicast packets: IGMP and PIM. In this article, I’ll show you how to configuring multicast protocols on your network and how to troubleshoot them.
Configuring multicast: PIM and IGMP
PIM (Protocol Independent Multicast) has two main versions called “dense-mode” and “sparse-mode.” There is also a “sparse-dense-mode,” which has features of both versions and is really just used to help to bootstrap a multicast network. Because this is a short blog article and not a book, we’ll focus on what we consider to be the best way to implement a multicast network, for both reliability and security. For this reason, we’ll only discuss “sparse-mode.”
PIM runs only on Layer 3 network devices like routers and firewalls. It never runs on end devices like servers and workstations or on Layer 2 devices like switches. Its function is to create loop-free multicast forwarding trees between network segments.
Configuring PIM-SM
Let’s just jump right into the configuration for a Cisco device and then discuss what’s going on:
RouterA#configure terminal Enter configuration commands, one per line. End with CNTL/Z. RouterA(config)#ip multicast-routing RouterA(config)#ip pim rp-address 192.168.100.5 RouterA(config)#interface Ethernet0/0 RouterA(config-if)#ip address 192.168.1.1 255.255.255.0 RouterA(config-if)#ip pim sparse-mode RouterA(config-if)#interface Ethernet0/1 RouterA(config-if)#ip address 192.168.2.1 255.255.255.0 RouterA(config-if)#ip pim sparse-mode RouterA(config-if)#end RouterA#
In this example, we’ve done three things: First, “the ip multicast-routing command” enables multicast routing, which is disabled by default because most networks don’t use it. On Cisco Nexus devices, you’ll need to enable the PIM feature with the command “feature pim” before any of the other commands become available.
Second, the above example defines a Rendezvous Point (RP). The RP is a router, somewhere in the network, that knows how to reach the multicast source device. In the example, a single RP is defined for all possible multicast data streams. This isn’t always practical. If you have to manage many multicast sources and groups, or if some of your multicast groups originate in external networks, it might be convenient to have different RPs for different groups. The syntax for configuring this depends on what type of device you’re using. On older Cisco IOS routers, the syntax specified a numbered ACL like this.
RouterA(config)#ip pim rp-address 192.168.100.5 55 RouterA(config)#ip pim rp-address 192.168.101.12 56 RouterA(config)#access-list 55 permit 224.0.100.0 0.0.0.255 RouterA(config)#access-list 56 permit 224.0.200.1
Here we’ve defined two different RPs using access lists. The first one will be used for everything in the 224.0.100.0-255 range and the second will be used only for 224.0.200.1.
On Nexus devices, the syntax uses prefix lists instead. Here’s an equivalent Nexus configuration:
RouterA(config)#ip pim rp-address 192.168.100.5 prefix-list RP-1-groups RouterA(config)#ip pim rp-address 192.168.101.12 prefix-list RP-2-groups RouterA(config)#ip prefix-list RP-1-groups permit 224.0.100.0/24 RouterA(config)#ip prefix-list RP-1-groups permit 224.0.200.1/32
In the Nexus configuration, you can also specify the groups directly on the RP configuration in simple examples like this. Note that the prefix list method is generally preferable because it provides more flexibility in specifying longer lists of groups.
RouterA(config)#ip pim rp-address 192.168.100.5 group-list 224.0.100.0/24 RouterA(config)#ip pim rp-address 192.168.101.12 group-list 224.0.200.1/32
In the above example, we’ve shown only one router at some random location in your network. This router is not the RP, and we’ve only configured two interfaces to take part in multicast. This router will only forward multicast packets between these two interfaces.
Configuring IGMP
In the introduction, I said the second important protocol is IGMP (Internet Group Membership Protocol). This is used by devices that want to receive a multicast data stream. Each multicast data stream is defined by the destination IP address in the packet, which is called the group IP. Receiver devices use IGMP to request the groups they want to receive.
When the router receives an IGMP “join” message from a receiver, it generally doesn’t know where the sender will be. That’s what the RP will do. But there’s a way that IGMP can also solve this problem.
There are two versions of IGMP in common use. Version 1, the original version, was replaced by version 2, which addresses some important shortcomings of version 1. So version 1 is really not recommended anymore. Version 3 includes a feature called SSM (Source-Specific Multicast). With SSM, the receiver device can request a multicast group and require that it only wants to receive that group from a particular source device.
If you’re using SSM, it’s important that the router knows it needs to use the requested source instead of consulting the RP for the multicast source.
IGMP version 2 is enabled by default as soon as you enable PIM on a router interface. If you want IGMP version 3, you need to explicitly configure it.
RouterA(config)#interface Ethernet0/0 RouterA(config-if)#ip igmp version 3
Note that you generally don’t want to configure this unless you’re using SSM. However, Version 3 is also backwards compatible to Version 2, so you don’t lose functionality by doing this.
Configuring the RP
Next let’s configure the RP, which will be another router. Generally, the RP will be a router either in the center of the network or near the sources. The RP is defined by an IP address. Since it must be reachable, the best practice is to make this a loopback interface rather than a physical interface.
Router-RP#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router-RP(config)#ip multicast-routing Router-RP(config)#interface Loopback0 Router-RP(config-if)#ip address 192.168.100.5 255.255.255.255 Router-RP(config-if)#ip pim sparse-mode Router-RP(config-if)#exit Router-RP(config)#interface Ethernet0/0 Router-RP(config-if)#ip address 192.168.2.10 255.255.255.0 Router-RP(config-if)#ip pim sparse-mode Router-RP(config-if)#exit Router-RP(config)#interface Ethernet0/1 Router-RP(config-if)#ip address 192.168.10.1 255.255.255.0 Router-RP(config-if)#ip pim sparse-mode Router-RP(config-if)#exit Router-RP(config)#ip pim rp-address 192.168.100.5 55 Router-RP(config)#access-list 55 permit 224.0.100.0 0.0.0.255 Router-RP(config)#end
This example is similar to the previous one. We’ve enabled multicast routing and configured some interfaces with “ip pim sparse-mode.” The extra piece is that we’ve also created a loopback interface, which will act as the RP address. Note that—because this will be our RP—it must also have PIM enabled.
Also, note that the example includes an “ip pim rp-address” command pointing to itself so this router knows that it’s the RP for the defined groups.
PIM must be enabled on every interface that’s involved in multicast forwarding. This includes an interface that has sources or consumers of multicast traffic as well as on all links between routers that will need to forward multicast traffic to one another.
Static and dynamic RPs
A lot of PIM configuration documents you’ll find on the internet are concerned with dynamic RP discovery. There are two protocols for doing this—BSR (Bootstrap Router) and Auto-RP. In both of these cases, multicast is used to discover and relay information about the RPs, which creates an immediate complication because multicast forwarding doesn’t work without an RP. So the network needs to “bootstrap” (hence the first protocol’s name) itself to find the RP.
Dynamic RPs solve the administrative problem of how to dynamically find, change, or reallocate RPs. But, in doing so, they create a serious security problem—any device on the network could masquerade as the RP and either disrupt multicast forwarding or inject bogus multicast packets. Also, the mechanisms for forwarding the multicast packets intended to advertise and discover the RP could be abused for other purposes. These complications can be resolved, but the solutions lead to more and more complicated network configurations.
The other problem that dynamic RPs solve is how to dynamically handle the failure of an RP in a production network. In the simplest case, where the RP is defined as a loopback interface on a single router, this is a real danger. But this can be resolved with static RPs using the “Anycast RP” method described in RFC 4610. In this method, the same loopback address is configured on two or more routers, any of which can act as the RP, and all of which advertise the address into a routing protocol.
In this way, the other routers in the network simply use the closest RP. There’s an additional complication with this scheme, as the routers sharing this common RP address must somehow share information about the locations of the multicast source devices. This is made possible using another protocol called MSDP (Multicast Source Discovery Protocol). A discussion of MSDP is beyond the scope of this article.
I believe that, in most networks, the administrative disadvantages of using static RPs are far less severe than the problems involved in securing the dynamic protocols against abuse. So I strongly recommend using static RPs (possibly with Anycast RP for resiliency) unless there’s some compelling reason such as frequent reallocation of RPs and group IPs.
Troubleshooting PIM and IGMP
Multicast requires that you think differently than you do when you’re troubleshooting normal unicast issues in your network. In particular, although PIM uses the same routing table as your unicast network does, multicast routes backward. All routes are considered not as the path towards the destination, but as the path back to the source. This is called reverse path forwarding.
Mroutes
The first thing to look at is the multicast route, or “route.”
RouterA#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P – Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.100.40), 02:15:11/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/0, Forward/Sparse-Dense, 02:15:11/00:00:00 (192.168.12.2/32, 224.0.100.40), 00:01:51/00:01:18, flags: CT Incoming interface: Ethernet0/1, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/0, Forward/Sparse-Dense, 00:01:51/00:00:00
This output shows a single multicast route. After the standard top part that defines what all of the flags mean, there are two blocks of information. The first one, for (*, 224.0.100.40), is called a “(*,G).” This block shows that there’s been a request (either by PIM or IGMP) for this group that was received on interface Ethernet0/0. If you have only a (*,G) entry, then the router isn’t delivering the multicast to the destination, but it’s received a request for it.
The second block is for the “(S,G),” which includes the source IP of the server that sends this multicast group. The packets from this source are received on interface Ethernet0/1 and they’re forwarded out through Ethernet0/0. So this entry satisfies the request of the previous block.
If you have the first but not the second, then there’s a problem with delivering multicast packets to this router. The first thing to look for is the unicast route to the source device. Each router requires that it will only forward multicast packets that it receives on the interface that points back toward the source indicated in the packet header—reverse path forwarding. If the unicast routing table includes a different interface as the path to the source, the router will drop the incoming multicast packet.
This strict RPF rule is required to ensure that there are no loops when forwarding multicast packets. You can check what the router thinks the RPF interface should be using this command:
RouterA# show ip rpf 192.168.12.2 RPF information for ? (192.168.12.2) RPF interface: Ethernet0/1 RPF neighbor: ? (192.168.2.10) RPF route/mask: 192.168.12.0/24 RPF type: unicast RPF recursion count: 0 Doing distance-preferred lookups across tables
This output shows what the router thinks the RPF tree for this source should look like. If it says instead something like “failed, no route exists,” then you know that there’s a mismatch. Perhaps the route is missing from the unicast table, or perhaps the interface specified in the unicast routing table doesn’t have PIM enabled.
If you see neither the first nor the second block of information in the mroute table, then the router isn’t receiving the request for this group. You should look at either the path to the receiver device or, if it’s on a locally connected segment, look at the PIM configuration or possibly an IGMP problem on the connected interface.
IGMP
The next thing to look at is IGMP.
RouterA# show ip igmp groups Group Address Interface Uptime Expires Last Reporter 224.0.100.40 Ethernet0/0 00:16:32 00:01:51 192.168.1.12 RouterA#
This output shows that at least one device on the segment directly connected through Ethernet0/0 has requested the group 224.0.100.40. It also tells us that the last such request was from the device with the address 192.168.1.12. It’s important to remember that this isn’t necessarily the only requester. In fact, it might not even be the real requester IP. In many network architectures, you could have an intermediate Layer 2 device that scoops up all of the IGMP requests and acts on their behalf. This device is called a querier.
The querier could be, for example, a Layer 2 switch that’s managing group membership for the segment. The querier can then make sure that it knows exactly which physical interface contains the real requesters, and it can reduce the IGMP traffic for the router by giving it only a single request for each group. Also, when the last device leaves the group, the querier can send a single “leave” message to tell the router to tear down this multicast tree.
PIM Neighbors
PIM operates between routers, hop by hop. So one of the important things to look at is the PIM neighbor table.
RouterA#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 192.168.2.10 Ethernet0/1 16:34:23 00:01:38 v2 RouterA#
This shows that our router has an active PIM neighbor connected through its Ethernet0/1 interface. If you’re having trouble with multicast forwarding, it’s useful to verify that all of your routers between the source and receiver are establishing PIM neighbor relationships with one another.
Your Guide to Selling Managed Network Services
Get templates for network assessment reports, presentations, pricing & more—designed just for MSPs.
