Showing Multicast Status

Problem

You want to view the current status of multicast protocols on your router.

Solution

There are several useful commands for checking the status of multicast configuration and protocols. You can see what multicast routes pass through a router with the EXEC command:

Router#show ip mroute

There are two useful variants of this command. The first reports on forwarding statistics for each multicast group:

Router#show ip mroute count

And the second reports only on the groups that are currently active:

Router#show ip mroute active

You can look at statistics on group membership using the command:

Router#show ip igmp groups

Use the interface keyword to look at the IGMP information in more detail:

Router#show ip igmp interface

There are four useful commands for viewing PIM information. The first shows information about PIM neighbor relationships:

Router#show ip pim neighbor

The second command shows information about the PIM configuration on different interfaces:

Router#show ip pim interface

This command shows information about PIM-SM Rendezvous Points (RP):

Router#show ip pim rp

And, finally, if you are using the Bootstrap Router (PIM Version 2) technique for distributing RP information, you will want to use this command:

Router#show ip pim bsr-router
PIMv2 Bootstrap information
This system is the Bootstrap Router (BSR)
 BSR address: 172.17.254.5 (?)
 Uptime: 00:06:37, BSR Priority: 0, Hash mask length: 1
 Next bootstrap message in 00:00:22

Next Cand_RP_advertisement in 00:00:15
 RP: 172.17.254.5(Loopback0)
Router#

There are several commands that allow you to look at MSDP functions:

Router#show ip msdp count

Router#show ip msdp peer 192.168.201.15

Router#show ip msdp summary

You can look at details of the Reverse Path Forwarding trees by using two useful commands, show ip rpf and mstat:

Router#show ip rpf 192.168.3.2

Router#mstat 192.168.3.2 239.5.5.55

 

Discussion

The show ip mroute command gives information on multicast routing. It shows which interfaces the router will use to forward packets belonging to different groups, and it also shows where the sources or Rendezvous Points for these groups are:

Router#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.1.40), 03:29:10/00:00:00, RP 0.0.0.0, flags: DJCL
 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:
 Ethernet1, Forward/Sparse-Dense, 03:29:10/00:00:00

(*, 239.5.5.55), 5d06h/00:02:59, RP 0.0.0.0, flags: DJC
 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:
 Ethernet0, Forward/Sparse-Dense, 00:04:23/00:00:00
 Ethernet1, Forward/Sparse-Dense, 03:29:08/00:00:00

(192.168.5.2/32, 239.5.5.55), 00:00:50/00:02:09, flags: CT
 Incoming interface: Ethernet1, RPF nbr 0.0.0.0
 Outgoing interface list:
 Ethernet0, Forward/Sparse-Dense, 00:00:50/00:00:00

In this example, the router belongs to multicast trees for two groups, 224.0.1.40 and 239.5.5.55. The first of these groups is what Cisco routers use for the Auto-RP procedure to locate a Rendezvous Point. In this case, there is no source for this group, but there is a member on the segment Ethernet1. This group member is another router that is also looking for the RP.

The second group has two entries. The first is the general (*,G) entry. The second is a specific (S,G) entry that shows the only known source for this multicast group, 192. 168.5.2. This specific entry indicates that this source is on the interface Ethernet1, and that there are members on interface Ethernet0.

The flags at the end of each group entry give useful information about the forwarding. Both of the general (*,G) enTRies include the flags, "D" and "J", which indicate that the router is using Dense-mode forwarding, and that it has joined a Shortest Path Tree. This is important because it says that although this router is configured for Sparse-Dense mode forwarding, it has not yet found an RP, so it is using Dense-mode forwarding.

The "C" flag, which you can see in all of the multicast routing entries, is for connected networks. This is most useful in the last entry because it shows that the multicast source, 192.168.5.2, is on a directly connected network segment. Since both the source and all of the group members are on interfaces on the same router, there is no need for it to try to join a tree connecting it to other routers.

The other interesting flag in this example is the "L" flag, which indicates that the router itself is a member of this group. This is true for the 224.0.1.40 group, because the router is hoping to discover the RP by listening to this group.

With the count keyword, this command gives statistics on multicast usage:

Router#show ip mroute count
IP Multicast Statistics
3 routes using 1776 bytes of memory
2 groups, 0.5 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 224.0.1.40, Source count: 0, Group pkt count: 0

Group: 239.5.5.55, Source count: 1, Group pkt count: 1
 Source: 192.168.5.2/32, Forwarding: 1/0/100/0, Other: 1/0/0

The entry for 239.5.5.55 shows that there is only one source. It also shows that there has only been one packet associated with this group for all sources. The detail below this line breaks out the packet statistics for each source. The fields work as follows:

 Source: 192.168.5.2/32, Forwarding: 1/0/100/0, Other: 1/0/0

There are four fields separated by slashes following the word "Forwarding." These represent the total number of packets that have been forwarded, the current forwarding rate in packets per second, followed by the average packet size, and, finally, the forwarding rate in kilobits per second. The three fields after the word "Other" are the total number of packets received, followed by the number of packets that had to be dropped for Reverse Path Forwarding failures, and the number of drops for all other reasons. Note that the total number of forwarded packets, from the first number after Fowarding, plus the last two fields after Other, should add up to the first field after Other. These last two fields simply give an indication of when packets are dropped and why.

The active keyword shows only those sources that are currently sending multicast traffic at a rate greater than 4 Kbps:

Router#show ip mroute active
Active IP Multicast Sources - sending >= 4 kbps

Group: 239.5.5.55, (?)
 Source: 192.168.5.2 (?)
 Rate: 6 pps/41 kbps(1sec), 14 kbps(last 15 secs), 1 kbps(life avg)
 Source: 192.168.254.5 (?)
 Rate: 2 pps/24 kbps(1sec), 12 kbps(last 15 secs), 1 kbps(life avg)
Router#

This command can be deceptive because many multicast applications operate significantly slower than the minimum 4-Kbps rate. The sources for those slower applications do not appear. However, this can be useful for higher bandwidth multimedia type applications. The output shows the rates in both packets per second (pps) and kilobits per second (Kbps) averaged over the last second, as well as the rates in Kbps for the last 15 seconds and averaged over the entire life of this source.

In this particular case, there are actually three sources for this multicast application, but one is below the threshold. You can see them all by using the following command:

Router#show ip mroute 239.5.5.55 count
IP Multicast Statistics
12 routes using 4908 bytes of memory
5 groups, 1.40 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 239.5.5.55, Source count: 3, Group pkt count: 2319
 RP-tree: Forwarding: 0/0/0/0, Other: 0/0/0
 Source: 192.168.3.2/32, Forwarding: 65/0/76/0, Other: 65/0/0
 Source: 192.168.5.2/32, Forwarding: 1127/0/564/0, Other: 1128/1/0
 Source: 192.168.254.5/32, Forwarding: 1127/0/564/0, Other: 1127/0/0
Router#

To look at multicast group membership on the router, use the command:

Router# show ip igmp groups
Group Address Interface Uptime Expires Last Reporter
224.0.1.39 TokenRing0 01:17:44 00:02:59 192.168.3.2
224.0.1.40 Ethernet1 16:02:35 never 192.168.5.1
239.5.5.55 Ethernet0 00:22:07 00:02:50 192.168.1.104
239.5.5.55 TokenRing0 16:02:26 00:02:53 192.168.3.2
224.0.1.1 TokenRing0 16:02:26 00:02:51 192.168.3.2
Router#

This tells you where there are members for each of the active groups. The Last Reporter column tells you the last known group member for this group. The router will periodically query the segment to make sure that there are still active members. The Uptime column indicates how long this group has had members on this segment, and the Expires column shows when this group will be removed if there are no further membership reports. Note that one of the entries, 224.0.1.40, will never expire. This is because the router itself is a member of this group, as it is used for the Auto-RP process.

With the interface keyword, the show ip igmp command gives details on how IGMP is implemented on this particular interface. It tells you information about IGMP query periods and what router is the PIM Designated Router (DR) for the segment. In the following example, this router is the DR for the segment. When there is more than one router on a segment, one of them must claim the role of DR or every multicast packet will appear twice. So this is a useful way of figuring out which router is DR:

Router# show ip igmp interface Ethernet0
Ethernet0 is up, line protocol is up
 Internet address is 192.168.1.201/24
 IGMP is enabled on interface
 Current IGMP version is 2
 CGMP is disabled on interface
 IGMP query interval is 60 seconds
 IGMP querier timeout is 120 seconds
 IGMP max query response time is 10 seconds
 Inbound IGMP access group is not set
 IGMP activity: 2 joins, 0 leaves
 Multicast routing is enabled on interface
 Multicast TTL threshold is 15
 Multicast designated router (DR) is 192.168.1.201 (this system)
 IGMP querying router is 192.168.1.201 (this system)
 No multicast groups joined

Another useful piece of information in this example is the Multicast TTL threshold indicator. A TTL threshold of 15 has been set on this interface to prevent local multicast traffic from reaching this segment. One of the most common problems with multicast networks comes from incorrectly setting multicast TTL thresholds. This can either allow multicast traffic to leak out of the appropriate network region or cause a router to drop it prematurely.

You can look at a router's PIM neighbor table as follows, for IOS Version 11.x:

Router#show ip pim neighbor
PIM Neighbor Table
Neighbor Address Interface Uptime Expires Mode
192.168.5.2 Ethernet1 16:22:46 00:01:23 Sparse-Dense (DR)
192.168.3.2 TokenRing0 16:22:16 00:01:05 Sparse-Dense (DR)
Router#

This shows not only what the PIM neighbor routers are, but also what PIM mode they are using (Sparse-Dense for both of the routers in this example), how long the neighbor relationship has existed, and when the router will delete this neighbor from its table if it doesn't hear from it again. The very last field in both lines indicates that this router is the DR for both of these network segments. If you look at the same information on either of these neighbor routers, you will see that neither of them have this DR indication.

The format of this output changed slightly between IOS Versions 11.x and 12.x. It now includes PIM version information:

Router#show ip pim neighbor
PIM Neighbor Table
Neighbor Address Interface Uptime Expires Ver Mode
192.168.5.1 Ethernet0 16:33:41 00:01:02 v1 Dense
192.168.254.6 Serial0 16:34:23 00:01:38 v2
Router#

As you can see, one of the neighbors is using PIM Version 1. This actually highlights the interoperability of the different PIM versions. You can easily build a hybrid network using both old and new routers.

The show ip pim interface command looks like this:

Router#show ip pim interface

Address Interface Version/Mode Nbr Query DR
 Count Intvl
192.168.5.2 Ethernet0 v2/Sparse-Dense 1 30 192.168.5.2
192.168.254.5 Serial0 v2/Sparse-Dense 1 30 0.0.0.0
Router#

Notice that there are slight differences between the output of this command and the previous one. In particular, the interface command indicates that the Ethernet0 port is configured for PIM Version 2 (the default), using Sparse-Dense mode. However, the previous neighbor command shows that this port is actually using Dense mode and PIM Version 1 for compatibility with the older router.

When using PIM-SM, you can see information about the RPs using this command:

Router#show ip pim rp
Group: 239.255.255.250, RP: 192.168.3.2, v2, v1, uptime 00:00:43, expires 00:02:16
Group: 239.5.5.55, RP: 192.168.3.2, v2, v1, uptime 00:00:42, expires 00:02:17
Group: 224.0.1.1, RP: 192.168.3.2, v2, v1, uptime 00:00:42, expires 00:02:17
Router#

Note that you can have different RPs for different groups. So the output of this command shows the RP separately for each group. Of course, in this example there is only one RP for the entire network.

If you are using a BSR to distribute RP information, as in Recipe 23.2, you can look at the BSR status by using the bsr-router keyword:

Router#show ip pim bsr-router
PIMv2 Bootstrap information
This system is the Bootstrap Router (BSR)
 BSR address: 172.17.254.5 (?)
 Uptime: 00:06:37, BSR Priority: 0, Hash mask length: 1
 Next bootstrap message in 00:00:22

Next Cand_RP_advertisement in 00:00:15
 RP: 172.17.254.5(Loopback0)
Router#

In this example, the router itself claims to be the BSR for the network. This means simply that it is responsible for distributing RP information to the network. This command also shows what the next RP that this router intends to advertise will be, and when it will send out the next advertisement.

If you are running MSDP to distribute multicast source and RP information between networks, you will want to use the various show ip msdp commands. The count keyword allows you to see gross statistics for all of the configured MSDP peers:

Router#show ip msdp count
SA State per Peer Counters, : <# SA learned>
 192.168.199.15: 0
 192.168.201.15: 0

SA State per ASN Counters, : <# sources>/<# groups>
 Total entries: 0

In this case, the peers are configured, but no sources or groups have been learned.

You can look at one peer in more detail with the peer keyword:

Router#show ip msdp peer 192.168.201.15
MSDP Peer 192.168.201.15 (?), AS ?
Description:
 Connection status:
 State: Down, Resets: 0, Connection source: none configured
 Uptime(Downtime): 00:13:28, Messages sent/received: 0/0
 Output messages discarded: 0
 Connection and counters cleared 00:13:28 ago
 SA Filtering:
 Input (S,G) filter: none, route-map: none
 Input RP filter: none, route-map: none
 Output (S,G) filter: none, route-map: none
 Output RP filter: none, route-map: none
 SA-Requests:
 Input filter: none
 Sending SA-Requests to peer: disabled
 Peer ttl threshold: 0
 SAs learned from this peer: 0
 Input queue size: 0, Output queue size: 0

And the summary keyword shows general information about all of the MSDP peers:

Router#show ip msdp summary
MSDP Peer Status Summary
Peer Address AS State Uptime/ Reset SA Peer Name
 Downtime Count Count
192.168.199.15 65531 Down 00:15:41 0 0 ?
192.168.201.15 ? Down 00:15:30 0 0 ?
Router#

The last version shows a critical piece of information. These MSDP peers are currently unreachable, so no routing information is being exchanged. In this case, the peers have been down for over 15 minutes, allowing you to isolate exactly when the problem occurred.

The last two commands show details on the actual multicast trees. The first, show ip rpf, shows information about how the router would build an RPF tree for a specified source. Note that this does not actually require that this source must exist, or that it be currently sending multicast packets. It does require that the interface that leads to this source must be configured for multicast forwarding, however:

Router#show ip rpf 192.168.3.2
RPF information for ? (192.168.3.2)
 RPF interface: Ethernet0
 RPF neighbor: ? (192.168.5.1)
 RPF route/mask: 192.168.3.0/255.255.255.0
 RPF type: unicast
Router#

If there are two or more equal cost paths to the same destination, the router simply selects the one with the highest IP address:

Router#show ip route 192.168.4.29
Routing entry for 192.168.4.28/30
 Known via "eigrp 65530", distance 90, metric 297372416, type internal
 Redistributing via eigrp 65530
 Last update from 192.168.4.26 on Tunnel6, 00:07:25 ago
 Routing Descriptor Blocks:
 * 192.168.4.22, from 192.168.4.22, 00:07:25 ago, via Tunnel5
 Route metric is 297372416, traffic share count is 1
 Total delay is 505000 microseconds, minimum bandwidth is 9 Kbit
 Reliability 255/255, minimum MTU 1514 bytes
 Loading 1/255, Hops 1
 192.168.4.26, from 192.168.4.26, 00:07:25 ago, via Tunnel6
 Route metric is 297372416, traffic share count is 1
 Total delay is 505000 microseconds, minimum bandwidth is 9 Kbit
 Reliability 255/255, minimum MTU 1514 bytes
 Loading 1/255, Hops 1

Router#show ip rpf 192.168.4.29
RPF information for ? (192.168.4.29)
 RPF interface: Tunnel6
 RPF neighbor: ? (192.168.4.26)
 RPF route/mask: 192.168.4.28/255.255.255.252
 RPF type: unicast
Router#

This is helpful when debugging multicast routing issues because it tells you, for example, that this route uses the unicast routing table. If you had intended for this routing information to come from some other source such as DVMRP or MBGP, it tells you that there is probably an Administrative Distance problem. Here is how the output looks for another source that has a static multicast route:

Router#show ip rpf 192.168.55.5
RPF information for ? (192.168.55.5)
 RPF interface: Serial0
 RPF neighbor: ? (192.168.254.6)
 RPF route/mask: 192.168.55.5/255.255.255.0
 RPF type: static mroute
Router#

For tracing the multicast trees for real sources, you can use the mstat command to get much more detail:

Router>mstat 192.168.3.2 239.5.5.55
Type escape sequence to abort.
Mtrace from 192.168.3.2 to 192.168.5.2 via group 239.5.5.55
From source (?) to destination (?)
Waiting to accumulate statistics......
Results after 10 seconds:

 Source Response Dest Packet Statistics For Only For Traffic
192.168.3.2 192.168.5.2 All Multicast Traffic From 192.168.3.2
 | _ _/ rtt 7 ms Lost/Sent = Pct Rate To 239.5.5.55
 v / hop 7 ms --------------------- --------------------
192.168.3.1
192.168.5.1 ?
 | ^ ttl 0
 v | hop 0 ms -2/0 = --% 0 pps 0/0 = --% 0 pps
192.168.5.2 ?
 | \_ _ ttl 1
 v  hop 0 ms 0 0 pps 0 0 pps
192.168.5.2 192.168.5.2
 Receiver Query Source

Router>

This command tells the router to actually probe the RPF tree by using a similar technique to that used by the traceroute program. It presents the results starting at the top with the source and tracing down to the receiver, which is the router itself, at the bottom, and shows all of the intermediate router hops. There is a lot of useful information in this output. It tells you, for example, the minimum source TTL value required to reach each point in the network. And it also shows the multicast forwarding packet statistics at each hop for both this group and for all multicast traffic. You can use this to determine if you are losing multicast traffic due to congestion at some point in your network.

Here is another interesting mstat output in which the router discovers a TTL boundary:

Router#mstat 192.168.1.201 239.5.5.55
Type escape sequence to abort.
Mtrace from 192.168.1.201 to 192.168.254.5 via group 239.5.5.55
From source (?) to destination (?)
Waiting to accumulate statistics......
Results after 10 seconds:

 Source Response Dest Packet Statistics For Only For Traffic
0.0.0.0 192.168.254.5 All Multicast Traffic From 192.168.1.201
 | _ _/ rtt 3 ms Lost/Sent = Pct Rate To 239.5.5.55
 v / hop 3 ms --------------------- -----------------
0.0.0.0 
192.168.254.6 ? Hit scope boundary
 | ^ ttl 64 
 v | hop 0 ms -2/0 = --% 0 pps 0/0 = --% 0 pps
192.168.254.5 ? 
 | \_ _ ttl 65 
 v  hop 0 ms 0 0 pps 0 0 pps
192.168.254.5 192.168.254.5 
 Receiver Query Source

Router#

Notice that at the 192.168.254.6 hop, mstat discovers that there is a TTL boundary with a threshold value of 64. So you can see that the minimum TTL required to reach the final destination is 65. This is an extremely useful command for isolating multicast routing problems.