You want to view the current status of multicast protocols on your router.
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
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 following 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 RPs:
Router#show ip pim rp
And, 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 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
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 RPs 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 an RP. 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 indicates 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 been only 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, the average packet size, and 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 packets forwarded, from the first number after "Forwarding," 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 4Kbps:
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 4Kbps 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 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 following 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; 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 a 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 the 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 this traffic 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. In Version 12.x, it 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#
Note 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 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, <Peer>: <# SA learned>
192.168.199.15: 0
192.168.201.15: 0
SA State per ASN Counters, <asn>: <# 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. However, the interface leading to this source must be configured for multicast forwarding:
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 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, showing 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#
Note 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.
Recipe 23.2; Recipe 23.3; Recipe 23.13
 |
|
|
| Top |