Using MRM to test Multicast

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.

R1

R1

1

2

3

4

5

interfaceLoopback0

ip address1.1.1.1255.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

R4

1

2

3

4

5

interfaceLoopback0

ip address4.4.4.4255.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

1

2

access-list1permit1.1.1.1

access-list2permit4.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

R5

1

2

3

4

ip mrm manager MCAST

manager Loopback0 group239.42.42.42

senders1

receivers2sender-list1

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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

R5#mrm MCAST start

R5#

*Mar103:21:33.219:IP MRM test'MCAST'starts......

R5#

*Mar103:21:36.219:IP MRM status report--Test:MCAST Receiver:4.4.4.4

*Mar103:21:36.219:Sender:1.1.1.25Pkt Loss:1(4%)Ehsr:19

R5#

*Mar103:21:39.715:IP MRM status report--Test:MCAST Receiver:4.4.4.4

*Mar103:21:39.719:Sender:1.1.1.25Pkt Dup:1(0%)Ehsr:41

*Mar103:21:40.599:IP MRM status report--Test:MCAST Receiver:4.4.4.4

*Mar103:21:40.599:Sender:1.1.1.25Pkt Dup:2(0%)Ehsr:46

R5#

*Mar103:21:42.659:IP MRM status report--Test:MCAST Receiver:4.4.4.4

*Mar103:21:42.663:Sender:1.1.1.25Pkt Dup:1(0%)Ehsr:56

R5#

*Mar103:21:46.307:IP MRM status report--Test:MCAST Receiver:4.4.4.4

*Mar103:21:46.307:Sender:1.1.1.25Pkt Dup:2(0%)Ehsr:77

*Mar103:21:47.275:IP MRM status report--Test:MCAST Receiver:4.4.4.4

*Mar103:21:47.275:Sender:1.1.1.25Pkt Dup:1(0%)Ehsr:82

R5#mrm MCAST st

*Mar103:21:48.235:IP MRM status report--Test:MCAST Receiver:4.4.4.4

*Mar103:21:48.239:Sender:1.1.1.25Pkt Dup:2(0%)Ehsr:87

R5#

*Mar103:21:49.303:IP MRM status report--Test:MCAST Receiver:4.4.4.4

*Mar103:21:49.303:Sender:1.1.1.25Pkt 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

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

R5#show ip mrm status-report

IP MRM status report cache:

Timestamp

Manager Test Sender Test Receiver Pkt Loss/Dup(%)Ehsr

*Mar103:21:36

5.5.5.51.1.1.254.4.4.41(4%)19

*Mar103:21:39

5.5.5.51.1.1.254.4.4.41(0%)41

*Mar103:21:40

5.5.5.51.1.1.254.4.4.42(0%)46

*Mar103:21:42

5.5.5.51.1.1.254.4.4.41(0%)56

*Mar103:21:46

5.5.5.51.1.1.254.4.4.42(0%)77

*Mar103:21:47

5.5.5.51.1.1.254.4.4.41(0%)82

*Mar103:21:48

5.5.5.51.1.1.254.4.4.42(0%)87

*Mar103:21:49

5.5.5.51.1.1.254.4.4.41(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.

Matt Ouellette is a certified information technology professional residing in Southwest Michigan. His technology findings and advice can be found on his PacketPilot blog. Mr. Ouellette spent 4 years as an I.T. Technician before stepping into a Network Engineer role at Bronson Health Group. Since completing his Associates Degree in Network Administration Matt has taken a head on approach to career enrichment through obtaining credentials such as CCNP, CCNA Voice, MCSA: Server 2008, and VCP5. This passion for continued learning allows him to deliver up to date quality technical solutions.

Matt Ouellette

Matt Ouellette is a certified information technology professional residing in Southwest Michigan. His technology findings and advice can be found on his PacketPilot blog. Mr. Ouellette spent 4 years as an I.T. Technician before stepping into a Network Engineer role at Bronson Health Group. Since completing his Associates Degree in Network Administration Matt has taken a head on approach to career enrichment through obtaining credentials such as CCNP, CCNA Voice, MCSA: Server 2008, and VCP5. This passion for continued learning allows him to deliver up to date quality technical solutions.

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