idnits 2.17.1 draft-ietf-mboned-mdh-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 30 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 248 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 492 instances of too long lines in the document, the longest one being 26 characters in excess of 72. == There are 52 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 97 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 17 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...), its areas...' == Line 13 has weird spacing: '... its worki...' == Line 17 has weird spacing: '... and may ...' == Line 18 has weird spacing: '...afts as refer...' == Line 21 has weird spacing: '... To learn...' == (243 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 1464, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1467, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1471, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1474, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1478, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1482, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2030 (ref. '1') (Obsoleted by RFC 4330) == Outdated reference: A later version (-14) exists of draft-ietf-idmr-igmp-mib-04 -- Unexpected draft version: The latest known version of draft-ietf-mmusic-sap is -00, but you're referring to -02. -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-14) exists of draft-ietf-idmr-multicast-routmib-04 == Outdated reference: A later version (-11) exists of draft-ietf-idmr-pim-mib-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-idmr-pim-mib (ref. '6') == Outdated reference: A later version (-11) exists of draft-ietf-idmr-dvmrp-mib-03 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-07) exists of draft-ietf-idmr-traceroute-ipm-01 -- Possible downref: Normative reference to a draft: ref. '8' -- Unexpected draft version: The latest known version of draft-ietf-mboned-sntp-heart is -00, but you're referring to -02. -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-02) exists of draft-ietf-mboned-pruning-01 -- Possible downref: Normative reference to a draft: ref. '11' Summary: 15 errors (**), 0 flaws (~~), 24 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONE Deployment Working Group Dave Thaler 3 INTERNET-DRAFT University of Michigan 4 Bernard Aboba 5 25 March 1997 Microsoft 7 Multicast Debugging Handbook 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 The distribution of this memo is unlimited. It is filed as , and expires September 1, 1997. Please send 28 comments to the authors. 30 2. Abstract 32 This document serves as a handbook for the debugging of multicast con- 33 nectivity problems. In addition to reviewing commonly encountered 34 problems, the draft summarizes publicly distributable multicast diag- 35 nostic tools, and provides examples of their use, along with pointers 36 to source and binary distributions. 38 3. Introduction 40 In order to deploy multicast on a large scale, it is necessary for 41 Network Operations Centers, support personnel and customers to be able 42 to diagnose problems. Over the years a number of tools have been 43 developed that can assist in the diagnostic process. This document 44 serves as a handbook for the debugging of multicast connectivity prob- 45 lems. In addition to reviewing commonly encountered problems, the 46 draft summarizes publicly distributable multicast diagnostic tools, 47 and provides examples of their use, along with pointers to source and 48 binary distributions. 50 4. Usage scenarios 52 Multicast diagnostic tools are typically employed in one of the fol- 53 lowing settings: 55 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 56 | | | 57 | Customer service or | SDR | 58 | support | mtrace | 59 | | RTPmon | 60 | | Dr. Watson | 61 | | | 62 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 63 | | | 64 | | SDR | 65 | | mrinfo | 66 | Network or system | netstat | 67 | administrator | mconfig | 68 | | mstat | 69 | | mtrace | 70 | | RTPmon | 71 | | tcpdump | 72 | | Dr. Watson | 73 | | Duppkts | 74 | | mrouted.dump, mrouted.cache | 75 | | | 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 | | | 78 | | SDR | 79 | | mrtree | 80 | | map-mbone | 81 | Network Operations | MVIEW | 82 | Center | Multicast heartbeat | 83 | | mwatch and mcollect | 84 | | asn | 85 | | asname | 86 | | | 87 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 4.1. Customer service and support 91 ISPs offering multicast services are likely to encounter the following 92 classes of customer questions: 94 Session announcement problems 95 Reception problems 96 Multicast router problems 98 Below we discuss how each of these types of problems may be diagnosed. 100 4.1.1. Session announcement problems 102 Session announcement questions are those which relate to the user's 103 session announcement software. Sample complaints include: 105 No conferences were visible in the session announcement tool 106 Conference X was not visible in the session announcement tool 107 I can see conferences when dialed into POPA, but not POPB 108 I can receive conferences listed in SDR, but sometimes when I join 109 conferences via a Web site, I cannot receive them. 111 Session announcement questions are typically investigated via the fol- 112 lowing procedure: 114 1. If only a specific session announcement is missing, check the ses- 115 sion announcement from somewhere where it is being received, and find 116 the group(s) and ports that the session utilizes, as well as the 117 source IP addresses. If the problem is with all session announce- 118 ments, find the information on any current session announcement which 119 should be seen by the user. 121 2. Find out the user's IP address, if known, and the POP dialed into 122 or router connected to. One way to determine the user's router given 123 their IP address is to mtrace or traceroute to their address. 125 3. Do an mtrace between the session announcement's origin and the 126 receiver on the sap.mcast.net group. If the mtrace succeeds, note any 127 hops showing loss. 129 4. If the mtrace never gets past the receiver itself, check the NASes 130 or routers with mstat -l to see if the relevant group has been joined. 131 If not, the problem is probably with the receiver's host. Ask the 132 user to check with Dr. Watson or a sniffer to see if the router is 133 sending IGMP membership queries, and if the host is responding with 134 membership reports and if so, what versions are being used. 136 5. If the sap.mcast.net group has been joined, but the mtrace failed, 137 the problem is likely a multicast routing problem (see section 4.1.3). 139 6. If the mtrace succeeded, and one hop shows 100% loss, compare the 140 output with the TTL of the session announcement. Users may download 141 session descriptions from Web sites that they may not be in the posi- 142 tion to receive, due to site or regional scoping. The loss may also 143 be the result of a scoped boundary separating the originator and the 144 receiver, which will also be indicated as such by mtrace. 146 7. Otherwise, if the mtrace succeeded, look for hops showing non-neg- 147 ligible loss. These typically denote points of congestion (see sec- 148 tion 4.3.1). Note that if rate-limiting is installed on these con- 149 gested links, session announcements are often lost since SAP traffic 150 is given lower priority. 152 8. If all else fails, request a network sniff from the user, and 153 check whether it shows traffic to sap.mcast.net, and if so, from what 154 sources, and what is being announced. 156 4.1.2. Reception problems 158 Reception questions are those where the user has successfully received 159 the session announcement, but was unable to receive one or more media 160 streams for the session joined. Sample complaints include: 162 I joined conference X, but nothing happened 163 I joined conference X, got video but no audio 164 I joined conference X, and got intermittent audio 165 I can't see source X, but source X can see me (or vice versa) 167 Reception questions are typically investigated via the following pro- 168 cedure: 170 1. Check the session announcement, find the group(s) and ports that 171 the session utilizes, as well as the source IP addresses. 173 2. Find out the user's IP address, if known, and the POP dialed into 174 or router connected to. One way to determine the user's router given 175 their IP address is to mtrace or traceroute to their address. 177 3. Check if the user is sending RTCP reports with RTPmon, and if so, 178 what the loss rate is. 180 4. Do an mtrace between the source and the receiver on the relevant 181 group. If the mtrace succeeds, note any hops showing loss. 183 5. If the mtrace never gets past the receiver itself, check the NASes 184 or routers with mstat -l to see if the relevant group has been joined. 185 If not, the problem is probably with the receiver's host. Check with 186 Dr. Watson to see if the router is sending IGMP membership queries, 187 and if the host is responding with membership reports and if so, what 188 versions are being used. 190 6. If the relevant group has been joined, but the mtrace failed, the 191 problem is likely a multicast routing problem (see section 4.1.3). 193 7. If the mtrace succeeded, and one hop shows 100% loss, compare the 194 output with the TTL of the session announcement. The user may not be 195 in a position to receive data from the source, due to site or regional 196 scoping. The loss may also be the result of a scoped boundary sepa- 197 rating the source and the receiver, which will also be indicated as 198 such by mtrace. 200 8. Otherwise, if the mtrace succeeded, look for hops showing non-neg- 201 ligible loss. These typically denote points of congestion (see sec- 202 tion 4.3.1). 204 9. If all else fails, request a network sniff from the user, and 205 check whether it shows traffic to the relevant group, and if so, from 206 what sources. 208 Other reception complaints include: 209 When I join my first conference, it works great. But then when I 210 quit that and join another one, it doesn't work anymore. 212 Why is my modem light is still flashing even after I've quit SDR 213 and VIC? 215 Such problems are often IGMP-related problems observed by a user con- 216 necting to the network using a host which is running a TCP/IP stack 217 implementing IGMP v1. Such users will experience long leave latencies, 218 with resulting poor reception and/or performance of other applica- 219 tions. Such problems can be distinguished from ordinary reception 220 problems in that they typically do not occur for the first session 221 joined, only for subsequent sessions. The solution consists of upgrad- 222 ing the user to an IGMP v2-capable stack. 224 IGMP-related questions are typically investigated by the following 225 procedure: 227 1. Obtain the vendor and version of the user's TCP/IP stack. Deter- 228 mine whether this stack is IGMP v2-enabled. 230 2. Ask the user to run Dr. Watson or a network sniffer and to indi- 231 cate whether IGMP queries are being seen, whether responses are being 232 sent, and if so, what version. 234 4.1.3. Multicast router problems 236 Multicast router questions are those which relate to the setup of a 237 multicast router. Sample complaints include: 239 I can get video and audio when online with ISDN, but not with a 240 modem, or vice versa. 242 I can't bring up a DVMRP tunnel to my site. Why not? 244 My router works great. Why can't I get multicast? 246 Why can't I source multicast? 248 Multicast routing questions are typically investigated via the follow- 249 ing procedure: 251 1. Ask the user what the router vendor is, and what software version 252 they have running. Attempt to verify this information using mrinfo or 253 mstat. 255 2. Check whether this vendor and version supports multicast routing, 256 and whether an upgrade to a later version is recommended. 258 3. Ask for a copy of the router configuration file. 260 4. Check whether the user has NAT enabled; this is incompatible with 261 most multicast routing protocols, and so should be switched off. 263 5. Find out the user's IP address(es), or if not known, the POP dialed 264 into or router connected to. 266 6. Check the loss rate and connectivity by doing an mtrace from vari- 267 ous sources to the user's IP address. 269 7. Check the user's router with mstat -l to see if it has joined any 270 multicast groups, and check upstream routers to see if they are sub- 271 scribed to any groups. 273 8. When all else fails, request a network sniff and examine it to 274 determine what multicast routing protocols are being run, if any. 276 4.2. Network Operations Center 278 A Network Operations Center (NOC) will typically receive a complaint 279 after it has been investigated by customer support and determined to 280 be a network-related issue. Although it is desirable for customer sup- 281 port to have performed the diagnostic tests described above, if this 282 has not been done, NOC personnel will need to perform the tests them- 283 selves to isolate the cause of the problem. If the proper systems have 284 been installed, in most cases, the NOC will already have been alerted 285 to the problem prior to receiving referrals from customer support. The 286 following diagnostic procedures are recommended: 288 1. Regularly generate summaries based on RTCP receiver and sender 289 reports, using RTP monitoring tools. Sample reports may include aver- 290 age loss rates experienced during sessions, or users whose loss rates 291 exceed a particular threshold. 293 2. Determine the source of the problems by doing mtraces between the 294 sources and the receivers. 296 3. On a network monitoring station, keep track of the functioning of 297 multicast-enabled hardware, either by doing periodic mtraces, or by 298 using a heartbeat monitor to receive SNMP traps from equipment losing 299 the heartbeat. 301 4. In order to keep track of group topologies, use mapping tools such 302 as map-mbone, MVIEW, or mrtree, along with autonomous system mapping 303 tools such as asn and asname. 305 4.3. Network or system administrator 307 The NOC will escalate network engineering problems to network engi- 308 neers and system administrators if their intervention is required. In 309 order to understand the origin of the problem and repair it, it is 310 necessary to diagnose the operations of individual systems and routers 311 using router and system diagnostics such as netstat, mrinfo, mstat, 312 mconfig, RTPmon, and mtrace, as well as network analysis tools such as 313 tcpdump or Dr. Watson. 315 In smaller installations the network engineer or system administrator 316 often doubles as customer support and network operations guru, in 317 which case problems may be escalated without any triage (our condo- 318 lences). 320 Typical classes of problems encountered by network engineers and sys- 321 tem administrators include: 323 Congestion and rate-limiting problems 324 Multicast routing problems 326 4.3.1. Congestion and rate limiting problems 328 Congestion and rate limiting problems result in high packet loss with 329 subsequent loss of session announcements and decrease in quality of 330 audio and video. These problems may be investigated via the following 331 procedure: 333 1. Use RTPmon to check for receivers experiencing packet loss. 335 2. Do an mtrace from the source to the receiver on the relevant group 336 in order to locate the problematic hops. 338 3. Do an mtrace in the opposite direction to help distinguish whether 339 the problem is with the router or the link at that hop. 341 4. If the reverse mtrace shows similar loss at an hop adjacent to the 342 lossy hop in the forward mtrace, odds are that the intermediate router 343 is overloaded. Use mrinfo to check the fanout on the router. Over- 344 loaded routers are often the result of having too many tunnels. 346 5. If the reverse mtrace shows no problems near that hop, indicating 347 that loss is one-way, then check the router on the upstream end of the 348 link with mstat -nv to see if it has a rate-limit set on the link, and 349 if the link traffic is near that limit. 351 6. If the reverse mtrace shows loss over the same link, the problem is 352 likely to be link congestion. Use mstat -nv to see how much bandwidth 353 is being used by multicast traffic. (If mstat fails, running an 354 mtrace with the -T option may help to confirm link congestion, 355 although the statistics can be misleading.) 357 7. If a congested link is suspected, but mstat failed, another indica- 358 tor can be obtained by doing an mtrace from the session announcer to 359 the destination on other groups joined by the receiver, such as the 360 SAP group, and comparing loss statistics. 362 8. Check for unicast packet loss over the link using ping. Multicast 363 (but not unicast) packet loss on a link with a rate limit is an indi- 364 cation that the link's multicast rate limit should be raised or elimi- 365 nated entirely. Packet loss on a link without rate limiting is an 366 indication of congestion. On such links it may be desirable to add a 367 rate limit. Since DVMRP prunes are currently not retransmitted by most 368 routers, prunes may be lost if no rate limit exists, which may further 369 worsen the congestion problem. 371 9. Use mstat -gR to see whether a single group is using an inordinate 372 amount of the link bandwidth. If so, use mstat to see whether a sin- 373 gle source to that group is using an inordinate amount of the link 374 bandwidth. If so, attempt to contact the source (contact information 375 may be available in the session announcement). 377 4.3.2. Multicast routing problems 379 Multicast routing problems include: 381 Duplicate packets 382 Injection of bogus routes (typically into DVMRP) 383 Redistribution of unicast routes (via BGP or an IGP) into DVMRP 384 Non-pruning routers 386 Duplicate packets are a symptom of routing loops. This problem may be 387 investigated via the following procedure: 389 1. Use a program such as Duppkts to detect duplicate packets. 391 2. Use a network monitor or RTPmon to find the sources and receivers 392 on the group. 394 3. Do an mtrace from the source(s) to the receivers in order to find 395 the loop. Duplicates will also show up in mtrace output as hops with 396 negative loss. 398 Bogus route injection problems may be investigated via the following 399 procedure: 401 1. Dump the DVMRP routing table. The routing table may be examined 402 remotely via mstat using the -r options, or locally (for mrouted) by 403 sending the USR1 signal to mrouted, generating the 404 /var/tmp/mrouted.dump file. 406 2. Check the table for bogus routes (known as "martians"). Bogus 407 routes include addresses reserved for use by private internets, as 408 described in [10]. These routes include 10/8, 172.16/12, or 409 192.168/16, or more specific routes within these regions. Injecting a 410 default route into the DVMRP backbone is also considered to be a bogus 411 route. 413 3. Locate the origin of the bogus routes by doing an mtrace to an IP 414 address in the bogus range. 416 Symptoms of unicast route redistribution are injection of a large num- 417 ber of unicast routes (25K+) into DVMRP. The problem may be investi- 418 gated via the following procedure: 420 1. Examine the routing table. The DVMRP routing table may be examined 421 remotely via mstat -r, or locally (for mrouted) by sending the USR1 422 signal to mrouted, generating the /var/tmp/mrouted.dump file. For 423 protocol independent multicast routing protocols (such as Sparse-Mode 424 PIM), examine the unicast routing table. 426 2. Check if a single site is the predominant route injector. This 427 site is likely to be the problem. One way to check this is to mtrace 428 to addresses in a number of "suspect" prefixes. 430 3. If your router supports it, set a route limit on the DVMRP tunnel 431 interface. A limit of 7000 routes is currently recommended. You may 432 also wish to set "route-hog notification" at 5000 routes. 434 Non-pruning DVMRP routers are those which maintain groups in the mul- 435 ticast routing table although there are no downstream subscribers. The 436 problem can be solved via the following procedure: 438 1. Check the router version number using mstat or mrinfo. As described 439 in [11], non-pruning routers include mrouted versions prior to 3, 440 Cisco Systems IOS prior to version 11.0(3), and Bay Networks implemen- 441 tations prior to 9.0. 443 2. Confirm lack of pruning as follows. First, dump the multicast for- 444 warding table. This can be done remotely with mstat -N, or locally 445 (for mrouted) by sending the USR2 signal to mrouted, generating the 446 /var/tmp/mrouted.cache file. 448 3. Check the forwarding table to see if an interface is in the outgo- 449 ing interface list for every entry in the multicast forwarding table. 450 If so, it is likely that a non-pruner lies downstream in that direc- 451 tion. 453 4. You can confirm the existence of a non-pruner by creating a tempo- 454 rary, unadvertised, session and sending (preferably with a low data 455 rate) data to that group. After a few moments, dump the forwarding 456 table again. If any interfaces appear in the outgoing interface list 457 of the entry for your test stream, then non-pruners lie in those 458 directions. 460 5. If a non-pruner exists downstream, use mrtree to follow the path of 461 the data downstream to the non-pruning router(s). 463 6. If your router supports it, enable the reject non-pruners option. 464 If not, and the unpruned interface is a tunnel, consider disabling the 465 tunnel. 467 5. Appendix - Multicast Diagnostic Tools 468 5.1. Types of tools 470 Multicast diagnostic tools typically fall into the following cate- 471 gories: 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | | | 475 | RTP monitoring tools | RTPmon | 476 | | Msessmon | 477 | | RTPquality | 478 | | RTPdump | 479 | | RTPcast/RTPlisten | 480 | | Duppkts | 481 | | | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | | | 484 | | mrinfo | 485 | Multicast router | netstat | 486 | diagnostics | mconfig | 487 | | mstat | 488 | | mrouted.dump, mrouted.cache | 489 | | | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | | | 492 | Multicast traceroute | mtrace | 493 | | | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | | | 496 | | mrtree | 497 | | map-mbone | 498 | MBONE mapping tools | asn | 499 | | asname | 500 | | mcollect & mwatch | 501 | | | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | | | 504 | NOC tools | MVIEW | 505 | | Multicast heartbeat | 506 | | | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | | | 509 | Network analysis | tcpdump | 510 | tools | Dr. Watson | 511 | | | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 RTP monitoring tools are used to monitor the transmission quality and 515 popularity of individual sessions. Multicast router diagnostics are 516 used to obtain information on the configuration and state of multicast 517 routers. MBONE mapping tools are used to map out the topology for a 518 particular group. These tools can show the topology at the level of 519 individual systems, or at the level of autonomous system connections. 520 Multicast traceroute tools are used to trace the path between a source 521 and destination. Network Operations Center tools are used to monitor 522 the state of network devices within an autonomous system. Network 523 analysis tools (such as tcpdump and Dr. Watson) are used to analyze 524 traffic on the network. 526 5.2. Facilities utilized 528 Multicast diagnostic tools typically rely on one or more of the fol- 529 lowing facilities: 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | | | 533 | RTCP source and | RTPmon | 534 | receiver reports | Msessmon | 535 | | RTPquality | 536 | | RTPdump | 537 | | RTPcast/RTPlisten | 538 | | Duppkts | 539 | | | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | | | 542 | | multicast heartbeat | 543 | SNMP MIBs | mconfig | 544 | | mstat | 545 | | MVIEW | 546 | | mrtree | 547 | | | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | | | 550 | IGMP trace facility | mtrace | 551 | | | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | | | 554 | | mrinfo | 555 | | mrtree | 556 | IGMP ASK_NEIGHBORS | map-mbone | 557 | message (DVMRP) | | 558 | | | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | | | 561 | Routing arbiter and | asn | 562 | WHOIS Databases | asname | 563 | | | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | | | 566 | Internal structures | tcpdump | 567 | | netstat | 568 | | mrouted.dump, mrouted.cache | 569 | | | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 Tools using RTCP reports analyze RTCP source and receiver reports, 573 providing information on packet loss, inter-arrival jitter, bandwidth 574 availability, or listenership. These tools therefore will only work 575 with RTP implementations which support RTCP reporting. Tools using 576 SNMP MIBs perform queries for variables in the IGMP, multicast rout- 577 ing, DVMRP, and PIM MIBs. As a result, these tools depend on implemen- 578 tation of the relevant SNMP MIBs in the network devices that are being 579 monitored. Tools based IGMP ASK_NEIGHBORS messages use these messages 580 to map portions of the MBONE, and thus will only work with routers 581 implementing DVMRP. Tools based on IGMP tracing perform a multicast 582 traceroute. These tools are typically only useful in cases where mul- 583 ticast routers along the path have a route back to the source. 585 Diagnostic tools may use more than one of these facilities. For exam- 586 ple, mstat makes use of SNMP MIBs, as well as the IGMP ASK_NEIGHBORS 587 facility. 589 5.3. RTP monitoring tools 591 This class of tools provides information required to monitor the per- 592 formance of RTP-based applications. 594 5.3.1. RTPmon 596 Authors 598 David Bacher, Andrew Swan, and Lawrence A. Rowe 599 {drbacher,aswan,rowe}@cs.berkeley.edu 600 Computer Science Division - EECS 601 University of California 602 Berkeley, CA 94720-1776 604 Description 606 RTPmon allows network administrators or support personnel to moni- 607 tor listenership as well as session quality experienced by sub- 608 scribers. The tool also facilitates tracing the cause of problems 609 resulting in quality degradation. To accomplish this task, RTPmon 610 summarizes and analyzes information provided by RTCP source and 611 receiver reports. 613 Receivers are displayed for a given sender in the form of a spread- 614 sheet, with cells being filled in with metrics such as packet loss 615 rate or jitter. Clicking on a cell displays a stripchart of statis- 616 tics on packet loss rate, smoothed packet loss rate and jitter. 617 From the stripchart it is possible to launch an mtrace between the 618 sender and the receiver, a convenient way of diagnosing network 619 problems along the multicast distribution path. Clicking on a 620 receiver or sender displays summary information. 622 For groups with large memberships, the display may be limited to 623 members surpassing a given threshold in packet loss rate or jitter. 624 Using RTPmon it is possible to sort receivers for a given sender 625 according to maximum or average loss. 627 Further information is available in the RTPmon man page. 629 Example 631 For examples and further information, see the rtpmon man page, or: 632 http://bmrc.berkeley.edu/~drbacher/projects/mm96-demo/ or 634 Facilities used 636 RTCP source and receiver reports 637 IGMP multicast trace (if installed) 639 Availability 641 RTPmon is available for UNIX and may be obtained from: 642 ftp://bmrc.berkeley.edu/pub/rtpmon/ 644 Bug reports and suggestions should be sent to: 645 rtpmon@bmrc.berkeley.edu. 647 5.3.2. RTPcast/RTPlisten, RTPquality, Duppkts, RTPdump, RTPtools, 648 Msessmon 650 Author 652 Description 654 RTPcast listens to RTCP receiver reports and forwards data to 655 another multicast group; RTPlisten then listens to that group. RTP- 656 dump listens for, and dumps RTP and RTCP packets. Duppkts listens 657 on a multicast group and port, and reports the number of packets 658 received and lost, as well as the number of duplicates. RTPquality 659 listens to RTCP receiver reports and writes data on packet loss, as 660 well as late and non-sequenced packets. RTPtools allows recording 661 and playback of RTP sessions. Msessmon provides a routemap of par- 662 ticipants in RTP conferences as well as stripcharts of statistics 663 on RTP packet loss and jitter. 665 Example 667 Information on these tools is available from: 668 http://sauce.mmlab.uninett.no/mice-nsc/tools.html 670 Facilities used 672 RTCP source and receiver reports 674 Availability 676 Binaries for RTPcast/RTPlisten are available from: 677 ftp://sauce.uio.no/mice-nsc/util/rtp 678 Source code for RTPquality is available from: 679 ftp://sauce.uio.no/mice-nsc/util/rtp/rtpqual.c 681 Source code for RTPdump is available at: 682 ftp://sauce.uio.no/mice-nsc/util/rtpdump-1.0.tar.gz 684 Source code for RTPtools is available at: 685 ftp://sauce.uio.no/mice-nsc/util/rtptools-1.6.tar.gz 687 Source and binaries for Msessmon is available at: 688 ftp://sauce.uio.no/mice-nsc/util/msessmon/ 690 5.4. Multicast router diagnostics 692 This class of tools facilitates monitoring and management of multicast 693 routers. 695 5.4.1. mrouted.dump, mrouted.cache 697 Author 699 Bill Fenner, fenner@parc.xerox.com 701 Description 703 Sending the USR1 signal to mrouted dumps the internal routing table 704 to /var/tmp/mrouted.dump; sending the USR2 signal dumps the for- 705 warding cache to /var/tmp/mrouted.cache. 707 Further information on mrouted and the mrouted.dump and 708 mrouted.cache file formats is available in the mrouted man page. 710 Example 712 % cat mrouted.dump 713 vifs_with_neighbors = 2 715 Virtual Interface Table 716 Vif Name Local-Address M Thr Rate Flags 717 0 ed0 128.31.107.1 subnet: 128.31.107/24 1 1 0 querier 718 peers: 128.31.107.249 (3.8) (0xe) 719 groups: 239.109.100.200 720 224.0.0.2 721 224.0.0.4 722 pkts in : 4075 723 pkts out: 0 725 1 ed0 128.31.107.1 tunnel: 204.67.107.11 1 32 500 726 peers: 204.67.107.11 (11.2) (0x1a) 727 pkts in : 0 728 pkts out: 2359 730 Multicast Routing Table (3801 entries) 731 Origin-Subnet From-Gateway Metric Tmr In-Vif Out-Vifs 732 207.10.165.51/32 128.31.107.249 10 20 0 1 733 207.10.165.50/32 128.31.107.249 10 20 0 1 734 206.172.195.32/32 128.31.107.249 9 20 0 1 735 172/8 128.31.107.249 10 20 0 1 736 ... 738 % cat mrouted.cache 739 Multicast Routing Cache Table (198 entries) 740 Origin Mcast-group CTmr Age Ptmr IVif Forwvifs 741 131.107.2.139/32 224.0.12.0 58s 7m - -1 742 >131.107.2.139 743 143.107.103.0/27 224.0.1.1 3m 2m 3m 0P 744 >143.107.103.5 745 128.232/16 224.0.1.1 4m 7m 4m 0P 746 >128.232.2.209 747 157.161/16 224.0.1.1 67s 6m - 0 1 748 >157.161.114.2 749 206.152.163/24 224.0.1.15 74s 7m - 0 1 750 >206.152.163.21 751 4.0.0.34/32 224.0.1.32 56s 4m 25s 0P 1p 752 >4.0.0.34 753 137.39.2.254/32 224.0.1.32 3m 5m - 0 1 754 >137.39.2.254 755 137.39.43.32/30 224.0.1.32 38s 5m - 0 1 756 >137.39.43.34 757 ... 759 Facilities used 761 Internal facilities (forwarding cache and routing table) 763 Availability 765 The SNMP-capable mrouted distribution is available at: 766 ftp://ftp.merit.edu/net-research/mbone/mirrors/mrouted/ 768 5.4.2. mrinfo 770 Author 772 Van Jacobson, van@ee.lbl.gov 774 Description 776 mrinfo displays information about a multicast router; to do this, 777 it uses the IGMP ASK_NEIGHBORS message to discover the router's 778 physical and virtual interfaces. Routers are also queried for their 779 version number, and if this query is successful, for their metrics, 780 thresholds, and flags. Results are printed in an indented list for- 781 mat similar to that for map-mbone. 783 Example 785 % mrinfo 192.80.214.199 786 192.80.214.199 (collegepk-mbone1.bbnplanet.net) [version 11.2,prune,mtrace,snmp]: 787 128.167.252.196 -> 0.0.0.0 (local) [1/0/pim/querier/leaf] 788 192.80.214.199 -> 0.0.0.0 (local) [1/0/pim/querier/leaf] 789 192.41.177.196 -> 0.0.0.0 (local) [1/0/pim/querier/down/leaf] 790 128.167.252.196 -> 128.167.254.165 (devo.sura.net) [1/32/tunnel/querier/down/leaf] 791 128.167.252.196 -> 131.119.0.197 (paloalto-mbone1.bbnplanet.net) 792 [1/64/tunnel/pim/querier] 793 128.167.252.196 -> 199.94.207.2 (cambridge1-mbone1.bbnplanet.net) 794 [1/32/tunnel/pim/querier] 795 128.167.252.196 -> 137.39.43.34 (MBONE1.UU.NET) [1/32/tunnel/querier] 796 128.167.252.196 -> 192.41.177.199 (wtn-ms2.bbnplanet.net) [1/16/tunnel/querier] 797 128.167.252.196 -> 128.244.93.3 (sage.jhuapl.edu) [1/32/tunnel/querier] 798 128.167.252.196 -> 192.221.34.22 (cdrn.bbnplanet.net) [1/32/tunnel/querier] 799 128.167.252.196 -> 128.167.1.197 (cpk-ms1.ser.bbnplanet.com) [1/16/tunnel/querier] 800 128.167.252.196 -> 134.205.93.150 (dilbert.sam.pentagon.mil) [1/32/tunnel/querier] 801 128.167.252.196 -> 192.221.48.234 (atlanta3-mbone1.bbnplanet.net) 802 [1/64/tunnel/pim/querier] 803 128.167.252.196 -> 204.167.201.38 (dallas2-mbone1.bbnplanet.net) 804 [1/64/tunnel/pim/querier] 805 128.167.252.196 -> 205.130.85.3 (philipii.nap.edu) [1/32/tunnel/querier/down/leaf] 806 128.167.252.196 -> 128.175.13.36 (pfet.nss.udel.edu) [1/32/tunnel/querier/down/leaf] 807 128.167.252.196 -> 192.41.177.197 (wtn-ms1.bbnplanet.net) [1/32/tunnel/querier] 808 128.167.252.196 -> 204.148.62.28 (mbone-e.ans.net) [1/32/tunnel/querier] 809 128.167.252.196 -> 205.128.246.2 (usnrctc.bbnplanet.net) [1/32/tunnel/pim/querier] 811 Facilities used 813 IGMP ASK_NEIGHBORS message (DVMRP) 815 Availability 817 mrinfo is available for UNIX and is included in the SNMP-capable 818 mrouted distribution, available at: 819 ftp://ftp.merit.edu/net-research/mbone/mirrors/mrouted/ 821 mrinfo is also available in the MVIEW distribution, available at: 822 ftp://ftp.merit.edu/net-research/mbone/mview/ 824 5.4.3. netstat 826 Author 828 Unknown 830 Description 832 On multicast-enabled systems, netstat is typically extended so as 833 to provide information on virtual interfaces and the multicast for- 834 warding cache (-g option), as well as multicast routing statistics 835 (-gs option), and igmp behavior (-s option). 837 Example 839 %netstat -g 841 Virtual Interface Table 842 Vif Thresh Rate Local-Address Remote-Address Pkts-In Pkts-Out 843 0 1 0 128.15.2.120 16323 385 844 1 32 512 128.15.2.120 202.34.126.2 2 0 846 Multicast Forwarding Cache 847 Origin Group Packets In-Vif Out-Vifs:Ttls 848 128.15.2.120 224.2.195.166 281 0 849 128.15.1.110 239.100.101.223 1660 0 850 128.15.1.135 238.27.27.1 1660 0 851 128.15.1.110 239.111.111.235 1660 0 852 ... 854 %netstat -gs 855 multicast forwarding: 856 182880 multicast forwarding cache lookups 857 8237 multicast forwarding cache misses 858 6736 upcalls to mrouted 859 193 upcall queue overflows 860 5567 upcalls dropped due to full socket buffer 861 177 cache cleanups 862 7234 datagrams with no route for origin 863 0 datagrams arrived with bad tunneling 864 0 datagrams could not be tunneled 865 954 datagrams arrived on wrong interface 866 0 datagrams selectively dropped 867 0 datagrams dropped due to queue overflow 868 0 datagrams dropped for being too large 870 %netstat -s 871 ip: 872 3807182 total packets received 873 0 bad header checksums 874 ... 875 icmp: 876 40 calls to icmp_error 877 0 errors not generated 'cuz old message was icmp 878 ... 879 igmp: 880 18504 messages received 881 0 messages received with too few bytes 882 48 messages received with bad checksum 883 2478 membership queries received 884 0 membership queries received with invalid field(s) 885 194 membership reports received 886 0 membership reports received with invalid field(s) 887 0 membership reports received for groups to which we belong 888 8510 membership reports sent 889 tcp: 890 10705 packets sent 891 5536 data packets (1532081 bytes) 892 ... 893 udp: 894 3104045 datagrams received 895 0 with incomplete header 896 ... 898 Facilities used 900 Netstat accesses system internal data structures in order to carry 901 out its function. 903 Availability 905 netstat is included with a variety of operating systems, including 906 UNIX, OS/2, and Windows. For further information, please consult 907 the netstat man page or documentation. 909 5.4.4. mstat 911 Author 913 Dave Thaler, thalerd@eecs.umich.edu 915 Description 917 mstat is a general purpose tool for obtaining router configuration 918 and status information. In order to perform its task, mstat uti- 919 lizes SNMP MIBs (such as the IGMP, multicast routing, PIM, and 920 DVMRP MIBs), as well as ASK_NEIGHBORS IGMP messages. mstat displays 921 the contents of various MBONE-related data structures in various 922 formats, depending on the options selected. Options include: 924 -G Show the PIM group table 925 -I Show the PIM interface table. 926 -K Show the cached IP multicast route table; works for 927 all SNMP-capable routers. 928 -N Show the IP Multicast Next Hop Table. 929 -P Show the PIM neighbor table. 930 -a Show the alternate subnet table. 931 -b Show the scoped boundary table. 932 -d Show the DVMRP neighbor table. 933 -g Show the Group Summary table. 934 -i Show the DVMRP interface table; similar to an 935 mrinfo report. 936 -l Show the IGMP local group table. 937 -r Show the DVMRP routing table; similar to a portion of 938 the mrouted.dump file. 939 -t Show the DVMRP routing next hop table; similar to 940 another portion of the mrouted.dump file. 941 -v Show statistics corresponding to the DVMRP interface table. 943 Examples 945 % mstat 946 IP Multicast Route Table for bigco.com 947 Mcast-group Origin-Subnet InIf UpTime Tmr Pkts Bytes RpF Proto 948 NTP.MCAST.NET 0.0.0.0/32 0 245341 179 0 0 0 pim 949 NTP.MCAST.NET 128.232.0.49/32 7 206403 418 3056 293376 17 dvmrp 950 NTP.MCAST.NET 128.232.2.209/32 7 206403 417 3027 290592 19 dvmrp 951 NTP.MCAST.NET 143.107.103.5/32 7 592 218 3 228 3 dvmrp 952 NTP.MCAST.NET 157.161.114.2/32 7 27703 517 411 31236 11 dvmrp 953 IETF-2-VIDEO.MC 0.0.0.0/32 0 245349 175 0 0 0 pim 954 IETF-2-VIDEO.MC 206.152.163.21/32 7 242567 244 46887 4149336 3388 dvmrp 955 MTRACE.MCAST.NE 0.0.0.0/32 0 1690 177 0 0 0 pim 956 MTRACE.MCAST.NE 194.104.0.25/32 7 405 483 2 792 0 dvmrp 957 MTRACE.MCAST.NE 206.54.224.150/32 7 456 569 4 1072 4 dvmrp 958 CISCO-RP-DISCOV 0.0.0.0/32 0 245534 0 0 0 0 pim 959 224.0.14.1 203.15.123.99/32 4 17 161 0 0 0 dvmrp 960 224.0.92.3 171.68.201.39/32 4 174 4 0 0 0 dvmrp 961 224.2.0.1 13.2.116.11/32 4 150 26 0 0 0 dvmrp 962 224.2.0.1 128.32.38.218/32 4 147 30 0 0 0 dvmrp 963 224.2.2.1 205.226.8.183/32 4 146 30 0 0 0 dvmrp 964 224.2.20.165 13.2.116.11/32 4 55 119 0 0 0 dvmrp 965 224.2.100.100 13.2.116.11/32 4 87 91 0 0 0 dvmrp 966 SAP.MCAST.NET 164.67.63.7/32 4 114 64 1 855 0 dvmrp 967 SAP.MCAST.NET 193.61.212.130/32 4 153 23 1 868 0 dvmrp 968 SAP.MCAST.NET 199.94.220.184/32 4 26 152 1 416 0 dvmrp 969 SAP.MCAST.NET 206.154.213.242/32 4 156 19 1 360 0 dvmrp 970 ... 972 Examples of the many other options are provided in the mstat man pages. 974 Facilities used 976 PIM, DVMRP, IGMP, and multicast routing MIBs 977 IGMP ASK_NEIGHBORS message (DVMRP) 979 Availability 981 mstat is included in the SNMP-capable mrouted distribution, 982 available at: 983 ftp://ftp.merit.edu/net-research/mbone/mirrors/mrouted/ 985 mstat is also available in the MVIEW distribution, available at: 986 ftp://ftp.merit.edu/net-research/mbone/mview/ 988 5.4.5. mconfig 990 Author 992 Dave Thaler, thalerd@eecs.umich.edu 994 Description 995 mconfig allows the user to display and (if the community string is 996 known) to modify the configuration of a multicast router implement- 997 ing the DVMRP MIB. 999 Example 1001 For more information on mconfig, please see the man page. 1003 Facilities used 1005 DVMRP MIB 1007 Availability 1009 mconfig is available for UNIX and is included in the SNMP-capable 1010 mrouted distribution, available at: ftp://ftp.merit.edu/net- 1011 research/mbone/mirrors/mrouted/ 1013 5.5. Multicast traceroute 1015 5.5.1. mtrace 1017 Author 1019 Bill Fenner, fenner@parc.xerox.com 1021 Description 1023 mtrace provides a facility by which to trace the path between a 1024 sender and a receiver of a particular group. This is particularly 1025 useful when used alongside a facility such as RTPmon, which allows 1026 you to identify problem source-receiver pairs. 1028 Note that the utility of mtrace is often limited by the multicast 1029 topology. Where multicast and unicast topologies are not aligned 1030 (as is the case in many multicast-enabled networks) mtrace may not 1031 function. 1033 For information on the details of the protocol, see reference [8]. 1035 Example 1037 % mtrace 131.243.73.36 128.15.1.250 224.2.195.166 1038 Mtrace from 131.243.73.36 to 128.15.1.250 via group 224.2.195.166 1039 Querying full reverse path... * switching to hop-by-hop: 1040 0 bigman.bigco.com (128.15.1.250) 1041 -1 * * littleman.bigco.com (128.15.1.249) DVMRP thresh^ 1 1042 -2 * * * seamr1-gw.nwnet.net (192.35.180.201) DVMRP thresh^ 32 1043 -3 * * seamr2-gw.nwnet.net (192.220.238.130) DVMRP thresh^ 0 1044 -4 * * mcast.cac.washington.edu (140.142.116.1) DVMRP thresh^ 32 1045 -5 * * * * dec3800-1-fddi-0.Sacramento.mci.net (204.70.164.29) didn't respond 1046 -6 * * * 1047 -7 * * 1048 Resuming... 1049 -5 dec3800-1-fddi-0.Sacramento.mci.net (204.70.164.29) DVMRP thresh^ 64 1050 -6 dec3800-2-fddi-0.SanFrancisco.mci.net (204.70.158.61) DVMRP thresh^ 1 1051 -7 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 64 1052 -8 * * llnl-mr2.es.net (134.55.12.229) DVMRP thresh^ 64 1053 -9 * * lbl-mr1.es.net (134.55.12.101) DVMRP thresh^ 8 1054 -10 * * mr1.lbl.gov (131.243.64.184) DVMRP thresh^ 32 1055 -11 * * ir40gw.lbl.gov (131.243.64.1) DVMRP thresh^ 0 1056 -12 * * irals.lbl.gov (131.243.128.6) PIM thresh^ 0 1057 -13 bl7-36.als.lbl.gov (131.243.73.36) 1058 Round trip time 74 ms; total ttl of 72 required. 1060 Waiting to accumulate statistics... Results after 10 seconds: 1062 Source Response Dest Overall Packet Statistics For Traffic From 1063 131.243.73.36 128.15.1.250 Packet 131.243.73.36 To 224.2.195.166 1064 v __/ rtt 77 ms Rate Lost/Sent = Pct Rate 1065 131.243.73.1 1066 131.243.128.6 irals.lbl.gov 1067 v ^ ttl 1 6 pps 0/60 = 0% 6 pps 1068 131.243.128.40 1069 131.243.64.1 ir40gw.lbl.gov 1070 v ^ ttl 2 13 pps 0/60 = 0% 6 pps 1071 131.243.64.184 mr1.lbl.gov 1072 v ^ ttl 35 9 pps 0/60 = 0% 6 pps 1073 198.128.16.13 1074 134.55.12.101 lbl-mr1.es.net 1075 v ^ ttl 35 0 pps 0/60 = 0% 0 pps 1076 134.55.12.229 llnl-mr2.es.net 1077 v ^ ttl 69 0 pps 1/60 = 2% 0 pps 1078 192.203.230.241 mbone.nsi.nasa.gov 1079 v ^ ttl 70 0 pps 0/59 = 0% 0 pps 1080 204.70.158.61 dec3800-2-fddi-0.SanFrancisco.mci.net 1081 v ^ ttl 70 0 pps 0/59 = 0% 0 pps 1082 204.70.164.29 dec3800-1-fddi-0.Sacramento.mci.net 1083 v ^ ttl 72 0 pps 0/59 = 0% 0 pps 1084 140.142.116.1 mcast.cac.washington.edu 1085 v ^ ttl 72 0 pps 0/59 = 0% 0 pps 1086 192.220.249.66 1087 192.220.238.130 seamr2-gw.nwnet.net 1088 v ^ ttl 72 0 pps 0/59 = 0% 0 pps 1089 192.220.238.129 1090 192.35.180.201 seamr1-gw.nwnet.net 1091 v ^ ttl 72 0 pps 0/59 = 0% 0 pps 1092 128.15.1.249 littleman.bigco.com 1093 v __ ttl 72 0 pps ?/59 0 pps 1094 128.15.1.250 128.15.1.250 1095 Receiver Query Source 1097 Facilities used 1099 IGMP multicast trace facility 1101 Availability 1103 mtrace is now distributed independently of mrouted. 1104 Source code is available from: 1105 ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mtrace5.1.tar.Z 1107 Binaries: 1108 ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mtrace5.1-sparc-sunos41x.tar.Z 1109 ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mtrace5.1-sparc-solaris2.tar.Z 1110 ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mtrace5.1-alpha-osf1.tar.Z 1111 ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mtrace5.1-sgi-irix.tar.Z 1113 5.6. MBONE mapping tools 1115 5.6.1. mrtree 1117 Author 1119 Dave Thaler, thalerd@eecs.umich.edu 1120 Andy Adams, ala@merit.edu 1122 Description 1124 mrtree uses a combination of IGMP and SNMP queries to discover the 1125 actual and potential multicast (sub)trees for a given source and 1126 group, rooted at a given router. An actual tree, discovered using 1127 the multicast routing MIB, consists of routers which are currently 1128 forwarding multicast traffic to a group from a given source. A 1129 potential tree, discovered using the DVMRP MIB, is one which would 1130 exist if every host were a member of the group. 1132 Example 1134 % mrtree mbone.merit.edu 224.2.143.24 204.62.246.73 1135 Actual distribution tree rooted at mbone.merit.edu for group 224.2.143.24 1136 and source 204.62.246.73... 1137 0 mbone.merit.edu (198.108.2.20) [ver 3.8,prune,genid,mtrace], 1138 247390 pkts 1139 1 cujo.merit.edu (198.108.60.97) [ver 3.6,prune,genid,mtrace], 333448 1140 6 pkts (1347%) 1141 2 subnet: 198.108.60/24 1142 2 shockwave.merit.edu (198.108.60.69) [ver 3.8,prune,genid,mtrace,snmp], 1143 1239130 pkts (500%) 1144 1 tibia.cic.net (192.217.65.100) [ver 3.8,prune,genid,mtrace] 1145 ... (No response from tibia.cic.net) 1146 2 fibula.cic.net (192.217.65.101) [ver 3.8,prune,genid,mtrace] ? 1147 2 dcl2.gw.uiuc.edu (192.17.2.8) [ver 1.0] ? 1148 2 goober.mci.net (204.70.104.45) [ver 3.6,prune,genid,mtrace] ? 1149 ... (goober.mci.net did not respond to DVMRP 'NEIGHBORS' msg) 1150 1 a-wing.jvnc.net (130.94.40.6) [ver 3.3] 1151 ... (a-wing.jvnc.net does not support SNMP) 1153 2 liberty-eth0/0.jvnc.net (130.94.40.1) [ver 10.2] ? 1154 2 noc.hpc.org (192.187.8.2) [ver 3.8,prune,genid,mtrace] ? 1155 2 liberty.jvnc.net (130.94.40.201) [ver 10.2] ? 1156 2 dstest.ds.internic.net (198.49.45.4) [ver 3.8,prune,genid,mtrace] ? 1157 2 cybercast.cc.nus.sg (137.132.9.70) [ver 3.6,prune,genid,mtrace] ? 1158 ... (cybercast.cc.nus.sg did not respond to DVMRP 'NEIGHBORS' msg) 1160 Facilities used 1162 DVMRP and multicast routing MIBs 1163 IGMP ASK_NEIGHBORS message (DVMRP) 1165 Availability 1167 mrtree is available for UNIX and is included in the 1168 SNMP-capable mrouted distribution, available at: 1169 ftp://ftp.merit.edu/net-research/mbone/mirrors/mrouted/ 1171 mrtree is also available in the MVIEW distribution, available at: 1172 ftp://ftp.merit.edu/net-research/mbone/mview/ 1174 5.6.2. map-mbone 1176 Author 1178 Pavel Curtis, pavel@parc.xerox.com 1180 Description 1182 map-mbone is useful for discovering the topology within a DVMRP 1183 routing domain; to do this, it uses the IGMP ASK_NEIGHBORS message 1184 to discover the neighbors of the starting router. If the -f (flood- 1185 ing) option is enabled (this is the default if no starting router 1186 is specified), then once these neighbors are discovered, they too 1187 are queried. This continues until the leaf routers are reached. 1188 This option should be used with care since it can result in exces- 1189 sive load on multicast routers. 1191 If a starting router is specified but the -f option is not used, 1192 then the search terminates after the first hop routers are discov- 1193 ered, the output of map-mbone is very similar to that for mrinfo. 1194 Routers discovered by map-mbone are queried for their version num- 1195 bers, and if this query is successful, for their metrics, thresh- 1196 olds, and flags, and the results are presented in an indented list 1197 format. 1199 Example 1201 % map-mbone 192.80.214.199 1202 192.41.177.196: alias for 128.167.252.196 1204 128.167.252.196 (collegepk-mbone1.bbnplanet.net): 1205 192.41.177.196: 192.41.177.196 [1/0/querier/down] 1206 192.80.214.199: 192.80.214.199 (collegepk-mbone1.bbnplanet.net) [1/0/querier] 1207 128.167.252.196: 205.128.246.2 (usnrctc.bbnplanet.net) [1/32/tunnel/querier] 1208 204.148.62.28 (mbone-e.ans.net) [1/32/tunnel/querier] 1209 192.41.177.197 (wtn-ms1.bbnplanet.net) [1/32/tunnel/querier] 1210 128.175.13.36 (pfet.nss.udel.edu) [1/32/tunnel/querier/down] 1211 205.130.85.3 (philipii.nap.edu) [1/32/tunnel/querier/down] 1212 204.167.201.38 (dallas2-mbone1.bbnplanet.net) [1/64/tunnel/querier] 1213 192.221.48.234 (atlanta3-mbone1.bbnplanet.net) [1/64/tunnel/querier] 1214 134.205.93.150 (dilbert.sam.pentagon.mil) [1/32/tunnel/querier] 1215 128.167.1.197 (cpk-ms1.ser.bbnplanet.com) [1/16/tunnel/querier] 1216 192.221.34.22 (cdrn.bbnplanet.net) [1/32/tunnel/querier] 1217 128.244.93.3 (sage.jhuapl.edu) [1/32/tunnel/querier] 1218 192.41.177.199 (wtn-ms2.bbnplanet.net) [1/16/tunnel/querier] 1219 137.39.43.34 (MBONE1.UU.NET) [1/32/tunnel/querier] 1220 199.94.207.2 (cambridge1-mbone1.bbnplanet.net) [1/32/tunnel/querier] 1221 131.119.0.197 (paloalto-mbone1.bbnplanet.net) [1/64/tunnel/querier] 1222 128.167.254.165 (devo.sura.net) [1/32/tunnel/querier/down] 1223 128.167.252.196 (collegepk-mbone1.bbnplanet.net) [1/0/querier] 1225 192.80.214.199 (collegepk-mbone1.bbnplanet.net): alias for 128.167.252.196 1227 Facilities used 1229 IGMP ASK_NEIGHBORS message (DVMRP) 1231 Availability 1233 map-mbone is available for UNIX, and the software and manual pages are included 1234 in the SNMP-capable mrouted distribution, available at: 1235 ftp://ftp.merit.edu/net-research/mbone/mirrors/mrouted/ 1237 5.6.3. asn 1239 Author 1241 Dave Thaler, thalerd@eecs.umich.edu 1243 Description 1245 asn gives the AS number of a given IP address by querying the rout- 1246 ing arbiter database. 1248 Example 1250 % asn 141.213.10.41 1251 AS237 1253 Facilities used 1255 Routing arbiter database 1257 Availability 1258 asn is included in the MVIEW distribution, available at: 1259 ftp://ftp.merit.edu/net-research/mbone/mview/ 1261 5.6.4. asname 1263 Author 1265 Dave Thaler, thalerd@eecs.umich.edu 1267 Description 1269 asname gets the name of an AS, given the AS number by querying the 1270 WHOIS database. 1272 Example 1274 % asname 237 1275 NSFNETTEST14-AS 1277 Facilities used 1279 WHOIS database 1281 Availability 1283 asname is included in the MVIEW distribution, available at: 1284 ftp://ftp.merit.edu/net-research/mbone/mview/ 1286 5.7. Network Operations Center tools 1288 These tools are suitable for use in a Network Operations Center. 1290 5.7.1. MVIEW 1292 Authors 1294 Dave Thaler, thalerd@eecs.umich.edu 1295 Andy Adams, ala@merit.edu 1297 Description 1299 MVIEW uses utilities such as mstat, mtrace, mrtree, asn and asname 1300 in order to produce a graphical depiction of the multicast network 1301 topology and the actual and potential multicast trees for a given 1302 group and source. 1304 Example 1306 Further information on MVIEW as well as examples are available from: 1307 http://www.merit.edu/net-research/mbone/mviewdoc/Welcome.html 1309 Facilities used 1311 PIM, DVMRP, IGMP, and multicast routing MIBs (mstat) 1312 IGMP ASK_NEIGHBORS message (mrinfo) 1313 Routing arbiter database (asn) 1314 WHOIS database (asname) 1316 Availability 1318 MVIEW is available for UNIX, and can be obtained from: 1319 ftp://ftp.merit.edu/net-research/mbone/mview/ 1321 Documentation is available as: 1322 ftp://ftp.merit.edu/net-research/mbone/mviewdoc/ 1324 5.7.2. Multicast heartbeat 1326 Author 1328 Many and various 1330 Description 1332 Devices implementing the multicast heartbeat listen on a designated 1333 group. If traffic is not observed on the group for a specified 1334 amount of time, an SNMP trap is generated. This allows multicast 1335 monitoring to be easily integrated into existing SNMP consoles. In 1336 situations where a shared-tree multicast routing protocol is used 1337 (such as sparse-mode PIM or CBT), it is recommended that the heart- 1338 beat generator be located close to the RP or core nodes, so as that 1339 loss of the heartbeat will correlate closely with loss of connec- 1340 tivity to the RP or core. Suitable heartbeat mechanisms include 1341 SNTP, which uses the group 224.0.1.1 (ntp.mcast.net) and UDP port 1342 123; and SAP, which uses the group 224.2.127.254 (sap.mcast.net) 1343 and UDP port 9875. 1345 Example 1347 For further information on the SNTP heartbeat, consult references 1348 [1] and [9]. 1350 Facilities used 1352 SNTP (for time-based heartbeats) 1353 SAP (for session announcement heartbeats) 1354 SNMP traps (for alerts) 1356 Availability 1357 5.8. Network analysis tools 1359 5.8.1. Dr. Watson, the Network Detective's Assistant (DWTNDA) 1361 Author 1363 Karl Auerbach, karl@cavebear.com 1365 Description 1367 DWTNDA is a general purpose troubleshooting tool with some IP mul- 1368 ticast tools (in addition to a fair number of non-multicast tools). 1369 For example it can watch IGMP "join" activity on a LAN and put up a 1370 real-time display in tabular format. It can generate some test 1371 packets, like IGMPv2 Leaves or Group Membership Requests. It can 1372 generate and respond to multicast pings (icmp, udp, or snmp based.) 1373 It will eventually acquire more sophisticated multicast facilities. 1375 Example 1377 See http://www.cavebear.com/dwtnda/ for examples. 1379 Facilities used 1381 This is a troubleshooting tool, so it will typically respond to 1382 packets that, strictly speaking, ought to go unanswered. 1384 Availability 1386 DWTNDA runs on MS-DOS and Win-95 and is free. (Source is not pro- 1387 vided.) See http://www.cavebear.com/dwtnda/ for various documents 1388 and download information. 1390 5.8.2. Mtap 1392 Author 1394 Luis Fernando da Silva Barra, barra@ax.apc.org 1395 Michael Stanton, michael@omega.lncc.br 1397 Description 1399 MTap is a tool for observing IP multicast packet traffic crossing a 1400 subnet, normally an Ethernet. 1402 Each packet sent to an IP multicast group address (class D) is cap- 1403 tured, and information is extracted concerning its origin, its 1404 size, and so forth. This information is summarized, permitting the 1405 determination of the current network load resulting from multicast 1406 traffic. Apart from global summaries, traffic information is 1407 summarized by group and by source, permitting the determination of 1408 the contribution of each group and each individual sender to global 1409 traffic. The data recorded are as follows: number of multicast 1410 packets and total multicast bytes passing through the network, load 1411 level, and date and time of the last packet received. 1413 As well as processing packets sent to a multicast address, MTap 1414 also records separately multicast packets encapsulated in point-to- 1415 point packets. Thus we can also deal with traffic in DVMRP tunnels 1416 between multicast routers, and tunnel traffic data are recorded in 1417 the same way as for a group. 1419 As well as recording the data. MTap also permits that individual 1420 packet data be exhibited in dump format at capture time, both for 1421 multicast packets and for tunneled packets. 1423 In order to evaluate the impact which a group imposes on a subnet- 1424 work, MTap can enter or leave a multicast group, using the IGMP 1425 protocol. Thus traffic can be observed for a group which has no 1426 other members on the subnetwork. 1428 In addition to passively observing and recording multicast traffic, 1429 MTap has a notification mechanism, which sets off an alarm whenever 1430 user-specified load levels are exceeded, either globally, by group 1431 or by tunnel. Notifications are also logged in a dedicated window. 1433 Example 1435 Further information on Mtap will be available from: 1436 http://www.inf.puc-rio.br/~michael/GERENTE/tools 1438 Facilities used 1440 Berkeley Packet Filter (BPF) 1442 Availability 1444 MTap uses a window-based user interface, developed using Tcl/Tk, 1445 and captures packets through the Berkeley Packet Filter (BPF). It 1446 can thus be ported to different platforms. 1448 Mtap, which is still under development, has been ported to Linux 1449 and Solaris; minor problems related to packet capture have still to 1450 be resolved for the Solaris version. When it is released, it will 1451 be available from: 1452 http://www.inf.puc-rio.br/~michael/GERENTE/tools 1454 6. Acknowledgments 1456 Thanks to Karl Auerbach for the description of the Dr. Watson tool, 1457 and to Michael Stanton for the description of the Mtap tool. 1459 7. References 1461 [1] D. Mills. "Simple Network Time Protocol (SNTP) Version 4 for 1462 IPv4, IPv6 and OSI." RFC 2030, University of Delaware, October, 1996. 1464 [2] S.E. Deering. "Host Extensions for IP Multicasting." RFC 1112, 1465 Stanford University, August, 1989. 1467 [3] K. McCloghrie, D. Farinacci, D. Thaler. "Internet Group Manage- 1468 ment Protocol MIB." draft-ietf-idmr-igmp-mib-04.txt, cisco Systems, 1469 University of Michigan, November 1996. 1471 [4] M. Handley. "SAP: Session Announcement Protocol (Version 1)." 1472 draft-ietf-mmusic-sap-02.ps, UCL, December, 1996. 1474 [5] K. McCloghrie, D. Farinacci, D. Thaler. "IP Multicast Routing 1475 MIB." draft-ietf-idmr-multicast-routmib-04.txt, cisco Systems, Univer- 1476 sity of Michigan, November 1996. 1478 [6] K. McCloghrie, D. Farinacci, D. Thaler. "Protocol Independent 1479 Multicast MIB." draft-ietf-idmr-pim-mib-02.txt, cisco Systems, Univer- 1480 sity of Michigan, June 1996. 1482 [7] D. Thaler. "Distance Vector Multicasting Routing Protocol MIB." 1483 draft-ietf-idmr-dvmrp-mib-03.txt, University of Michigan, June 1996. 1485 [8] W. Fenner, S. Casner. "A "traceroute" facility for IP Multi- 1486 cast." draft-ietf-idmr-traceroute-ipm-01.txt, Xerox PARC, Precept 1487 Software, November 1996. 1489 [9] B. Aboba, T. Pfenning. "The Use of SNTP as a Multicast Heart- 1490 beat." draft-ietf-mboned-sntp-heart-02.txt, Microsoft, December, 1996 1492 [10] Y. Rekhter, et al. "Address Allocation for Private Internets." 1493 RFC 1918, Cisco Systems, February, 1996 1495 [11] J. Hawkinson. "Multicast Pruning a Necessity." draft-ietf- 1496 mboned-pruning-01.txt, September, 1996 1498 8. Authors' Addresses 1500 Dave Thaler 1501 EECS Department 1502 University of Michigan 1503 Ann Arbor, MI 48109 1505 Phone: 313-763-5243 1506 EMail: thalerd@eecs.umich.edu 1508 Bernard Aboba 1509 Microsoft Corporation 1510 One Microsoft Way 1511 Redmond, WA 98052 1513 Phone: 206-936-6605 1514 EMail: bernarda@microsoft.com