Using MRM to test Multicast

Reading Time: 4 minutes

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)

MRM Topology

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.

R1

interface Loopback0
 ip address 1.1.1.1 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.

R4

interface Loopback0
 ip address 4.4.4.4 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.

R5

access-list 1 permit 1.1.1.1
access-list 2 permit 4.4.4.4

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.

R5

ip mrm manager MCAST
 manager Loopback0 group 239.42.42.42
 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:4.4.4.4
*Mar  1 03:21:36.219:   Sender:1.1.1.25         Pkt Loss:1(4%)  Ehsr:19
R5#
*Mar  1 03:21:39.715: IP MRM status report -- Test:MCAST  Receiver:4.4.4.4
*Mar  1 03:21:39.719:   Sender:1.1.1.25         Pkt Dup:1(0%)  Ehsr:41
*Mar  1 03:21:40.599: IP MRM status report -- Test:MCAST  Receiver:4.4.4.4
*Mar  1 03:21:40.599:   Sender:1.1.1.25         Pkt Dup:2(0%)  Ehsr:46
R5#
*Mar  1 03:21:42.659: IP MRM status report -- Test:MCAST  Receiver:4.4.4.4
*Mar  1 03:21:42.663:   Sender:1.1.1.25         Pkt Dup:1(0%)  Ehsr:56
R5#
*Mar  1 03:21:46.307: IP MRM status report -- Test:MCAST  Receiver:4.4.4.4
*Mar  1 03:21:46.307:   Sender:1.1.1.25         Pkt Dup:2(0%)  Ehsr:77
*Mar  1 03:21:47.275: IP MRM status report -- Test:MCAST  Receiver:4.4.4.4
*Mar  1 03:21:47.275:   Sender:1.1.1.25         Pkt Dup:1(0%)  Ehsr:82
R5#mrm MCAST st   
*Mar  1 03:21:48.235: IP MRM status report -- Test:MCAST  Receiver:4.4.4.4
*Mar  1 03:21:48.239:   Sender:1.1.1.25         Pkt Dup:2(0%)  Ehsr:87
R5#
*Mar  1 03:21:49.303: IP MRM status report -- Test:MCAST  Receiver:4.4.4.4
*Mar  1 03:21:49.303:   Sender:1.1.1.25         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 
    5.5.5.5         1.1.1.25        4.4.4.4         1            (4%)     19
*Mar  1 03:21:39 
    5.5.5.5         1.1.1.25        4.4.4.4         1            (0%)     41
*Mar  1 03:21:40 
    5.5.5.5         1.1.1.25        4.4.4.4         2            (0%)     46
*Mar  1 03:21:42 
    5.5.5.5         1.1.1.25        4.4.4.4         1            (0%)     56
*Mar  1 03:21:46 
    5.5.5.5         1.1.1.25        4.4.4.4         2            (0%)     77
*Mar  1 03:21:47 
    5.5.5.5         1.1.1.25        4.4.4.4         1            (0%)     82
*Mar  1 03:21:48 
    5.5.5.5         1.1.1.25        4.4.4.4         2            (0%)     87
*Mar  1 03:21:49 
    5.5.5.5         1.1.1.25        4.4.4.4         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.

Share this article:

Permanent link to this article: https://www.packetpilot.com/using-mrm-to-test-multicast/