I’ve always wanted to find a quick way to test a multicast deployment in a Cisco environment. Many of us are already familiar with simply pinging a multicast address from an interface, and going to another router and issuing the ip igmp join-group command.
I’ve came across a new way to test that I’ve missed over the years but has apparently been around. This tool is the Multicast Routing Monitor. It has a fairly straight forward configuration and will at least give you some view into your multicast domain and it’s functionality.
The diagram we are working with is below. All routers have a loopback on them number X.X.X.X/32 where X is the routers number. In our tests we will be sourcing multicast from the loopback and the receiver will also be a loopback. In this case R5 exists as the MRM manager. That is, the device that will be doing the monitoring and starting/stoping the test. I used an additional out of band device to show that this test can be performing using a router that is NOT part of the multicast routing domain. (Please note, R5 has no multicast configuration on it what-so-ever)
To start out you need to have your multicast routing domain set up. This included turning on multicast routing, setting your desired PIM mode and associated RP’s if necessary. The next few steps are rather simple.
We will be using R1 as the sender in our MRM tests. We will be using the loopback 0 interface specifically for this. The configuration ip mrm test-sender will go under the loopback 0 interface.
interface Loopback0 ip address 184.108.40.206 255.255.255.255 ip pim sparse-dense-mode ip mrm test-sender end
Next we will do a very similar configuration on R4s loopback 0 as the receiver. The command is ip mrm test-receiver.
interface Loopback0 ip address 220.127.116.11 255.255.255.255 ip pim sparse-dense-mode ip mrm test-receiver end
Now we will utilize R5 as the MRM Manager. This is where the test and it’s sender and receiver list itself is defined, started, stopped, and where the status report will be visible. We will start out by creating two access-lists. One for the senders, and one for the receivers. I will utilize access-lists 1 and 2 respectively.
access-list 1 permit 18.104.22.168 access-list 2 permit 22.214.171.124
Now that we have our access-lists defined we can setup the initial test. I will utilize defaults and will not change the beacon intervals, hold times, or the UDP ports used. In this configuration we define the MRM manager name and it’s sender and receiver list. The senders command allows options to utilize all multicast-enabled interfaces, or all multicast test-send enabled interfaces. We are simply going to leave this at it’s default however. Our receivers configuration indicates the list of receivers, as well as the list of senders to be monitored. Per the Cisco configuration guide both the senders configuration as well as the receivers configuration statement including the senders list are used. We also define the managers interface for monitoring as well as the multicast group that will be used.
ip mrm manager MCAST manager Loopback0 group 126.96.36.199 senders 1 receivers 2 sender-list 1
At this point we are ready to test our multicast deployment. Simply issuing the mrm NAME start command will begin the monitoring and testing.
R5#mrm MCAST start R5# *Mar 1 03:21:33.219: IP MRM test 'MCAST' starts ...... R5# *Mar 1 03:21:36.219: IP MRM status report -- Test:MCAST Receiver:188.8.131.52 *Mar 1 03:21:36.219: Sender:184.108.40.206 Pkt Loss:1(4%) Ehsr:19 R5# *Mar 1 03:21:39.715: IP MRM status report -- Test:MCAST Receiver:220.127.116.11 *Mar 1 03:21:39.719: Sender:18.104.22.168 Pkt Dup:1(0%) Ehsr:41 *Mar 1 03:21:40.599: IP MRM status report -- Test:MCAST Receiver:22.214.171.124 *Mar 1 03:21:40.599: Sender:126.96.36.199 Pkt Dup:2(0%) Ehsr:46 R5# *Mar 1 03:21:42.659: IP MRM status report -- Test:MCAST Receiver:188.8.131.52 *Mar 1 03:21:42.663: Sender:184.108.40.206 Pkt Dup:1(0%) Ehsr:56 R5# *Mar 1 03:21:46.307: IP MRM status report -- Test:MCAST Receiver:220.127.116.11 *Mar 1 03:21:46.307: Sender:18.104.22.168 Pkt Dup:2(0%) Ehsr:77 *Mar 1 03:21:47.275: IP MRM status report -- Test:MCAST Receiver:22.214.171.124 *Mar 1 03:21:47.275: Sender:126.96.36.199 Pkt Dup:1(0%) Ehsr:82 R5#mrm MCAST st *Mar 1 03:21:48.235: IP MRM status report -- Test:MCAST Receiver:188.8.131.52 *Mar 1 03:21:48.239: Sender:184.108.40.206 Pkt Dup:2(0%) Ehsr:87 R5# *Mar 1 03:21:49.303: IP MRM status report -- Test:MCAST Receiver:220.127.116.11 *Mar 1 03:21:49.303: Sender:18.104.22.168 Pkt Dup:1(0%) Ehsr:92
To stop the test you simply run the mrm NAME stop command.
If we note the highly lines the first one shows us a lost packet. Correlated with that lost packet is a %. In this case 4 percent. This is rather typical to ping operations on Cisco devices where we lose the first packet sent. If we notice the next highlighted line it indicates that two duplicate packets (Dup:#) were noticed. This number does not show up in the % field.
We will now issue the command to look at the finished status report on R5.
R5#show ip mrm status-report IP MRM status report cache: Timestamp Manager Test Sender Test Receiver Pkt Loss/Dup (%) Ehsr *Mar 1 03:21:36 22.214.171.124 126.96.36.199 188.8.131.52 1 (4%) 19 *Mar 1 03:21:39 184.108.40.206 220.127.116.11 18.104.22.168 1 (0%) 41 *Mar 1 03:21:40 22.214.171.124 126.96.36.199 188.8.131.52 2 (0%) 46 *Mar 1 03:21:42 184.108.40.206 220.127.116.11 18.104.22.168 1 (0%) 56 *Mar 1 03:21:46 22.214.171.124 126.96.36.199 188.8.131.52 2 (0%) 77 *Mar 1 03:21:47 184.108.40.206 220.127.116.11 18.104.22.168 1 (0%) 82 *Mar 1 03:21:48 22.214.171.124 126.96.36.199 188.8.131.52 2 (0%) 87 *Mar 1 03:21:49 184.108.40.206 220.127.116.11 18.104.22.168 1 (0%) 92
If you notice the status-report output is nearly identical to the log messages we receive while the test is running. Lines 7 and 9 indicate our lost packet (noted in the % column) as well as duplicate packets (not counting towards the % field).
There you have it. A quick and easy test for multicast. I would recommend digging into deeper options for more specific tests. However, this is another tool you can use in the case you don’t have access to both the sending and receiving ends of the network to send pings and join the correct igmp group.