idnits 2.17.00 (12 Aug 2021) /tmp/idnits54103/draft-ietf-mboned-mdh-05.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 33 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 34 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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.) ** There are 78 instances of too long lines in the document, the longest one being 21 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 930 has weird spacing: '... Show the c...' == Line 932 has weird spacing: '... Show the I...' == Line 935 has weird spacing: '... scoped bound...' == Line 936 has weird spacing: '...eighbor table...' == Line 943 has weird spacing: '... Show the ...' == (2 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.) -- The document date (20 November 2000) is 7845 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '2' on line 1463 looks like a reference -- Missing reference section? '9' on line 1489 looks like a reference -- Missing reference section? '8' on line 1485 looks like a reference -- Missing reference section? '1' on line 1460 looks like a reference -- Missing reference section? '3' on line 1466 looks like a reference -- Missing reference section? '4' on line 1470 looks like a reference -- Missing reference section? '5' on line 1473 looks like a reference -- Missing reference section? '6' on line 1477 looks like a reference -- Missing reference section? '7' on line 1481 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 11 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 Microsoft 4 Category: Informational Bernard Aboba 5 Microsoft 6 20 November 2000 8 Multicast Debugging Handbook 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. Internet- 18 Drafts are draft documents valid for a maximum of six months and may be 19 updated, replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet-Drafts as reference material or to cite 21 them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 To view the list Internet-Draft Shadow Directories, see 27 http://www.ietf.org/shadow.html. 29 2. Copyright Notice 31 Copyright (C) The Internet Society (2000). All Rights Reserved. 33 3. Abstract 35 This document serves as a handbook for the debugging of multicast 36 connectivity problems. In addition to reviewing commonly encountered 37 problems, the draft summarizes publicly distributable multicast 38 diagnostic tools, and provides examples of their use, along with 39 pointers to source and binary distributions. 41 4. Introduction 43 In order to deploy multicast on a large scale, it is necessary for 44 Network Operations Centers, support personnel and customers to be able 45 to diagnose problems. Over the years a number of tools have been 46 developed that can assist in the diagnostic process. This document 47 serves as a handbook for the debugging of multicast connectivity 48 problems. In addition to reviewing commonly encountered problems, the 49 draft summarizes publicly distributable multicast diagnostic tools, and 50 provides examples of their use, along with pointers to source and binary 51 distributions. 53 5. Usage scenarios 55 Multicast diagnostic tools are typically employed in one of the 56 following settings: 58 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 59 | | | 60 | Customer service or | SDR | 61 | support | mtrace | 62 | | RTPmon | 63 | | Dr. Watson | 64 | | | 65 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 66 | | | 67 | | SDR | 68 | | mrinfo | 69 | Network or system | netstat | 70 | administrator | mconfig | 71 | | mstat | 72 | | mtrace | 73 | | RTPmon | 74 | | tcpdump | 75 | | Dr. Watson | 76 | | Duppkts | 77 | | mrouted.dump, mrouted.cache | 78 | | | 79 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 80 | | | 81 | | SDR | 82 | | mrtree | 83 | | map-mbone | 84 | Network Operations | MVIEW | 85 | Center | Multicast heartbeat | 86 | | mwatch and mcollect | 87 | | asn | 88 | | asname | 89 | | | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 5.1. Customer service and support 94 ISPs offering multicast services are likely to encounter the following 95 classes of customer questions: 97 Session announcement problems 98 Reception problems 99 Multicast router problems 101 Below we discuss how each of these types of problems may be diagnosed. 103 5.1.1. Session announcement problems 105 Session announcement questions are those which relate to the user's 106 session announcement software. Sample complaints include: 108 No conferences were visible in the session announcement tool 109 Conference X was not visible in the session announcement tool 110 I can see conferences when dialed into POPA, but not POPB 111 I can receive conferences listed in SDR, but sometimes when I join 112 conferences via a Web site, I cannot receive them. 114 Session announcement questions are typically investigated via the 115 following procedure: 117 1. If only a specific session announcement is missing, check the 118 session announcement from somewhere where it is being received, and find 119 the group(s) and ports that the session utilizes, as well as the source 120 IP addresses. If the problem is with all session announcements, find 121 the information on any current session announcement which should be seen 122 by the user. 124 2. Find out the user's IP address, if known, and the POP dialed into or 125 router connected to. One way to determine the user's router given their 126 IP address is to mtrace or traceroute to their address. 128 3. Do an mtrace between the session announcement's origin and the 129 receiver on the sap.mcast.net group. If the mtrace succeeds, note any 130 hops showing loss. 132 4. If the mtrace never gets past the receiver itself, check the NASes 133 or routers with mstat -l to see if the relevant group has been joined. 134 If not, the problem is probably with the receiver's host. Ask the user 135 to check with Dr. Watson or a sniffer to see if the router is sending 136 IGMP membership queries, and if the host is responding with membership 137 reports and if so, what versions are being used. 139 5. If the sap.mcast.net group has been joined, but the mtrace failed, 140 the problem is likely a multicast routing problem (see section 4.1.3). 142 6. If the mtrace succeeded, and one hop shows 100% loss, compare the 143 output with the TTL of the session announcement. Users may download 144 session descriptions from Web sites that they may not be in the position 145 to receive, due to site or regional scoping. The loss may also be the 146 result of a scoped boundary separating the originator and the receiver, 147 which will also be indicated as such by mtrace. 149 7. Otherwise, if the mtrace succeeded, look for hops showing non- 150 negligible loss. These typically denote points of congestion (see 151 section 4.3.1). Note that if rate-limiting is installed on these 152 congested links, session announcements are often lost since SAP traffic 153 is given lower priority. 155 8. If all else fails, request a network sniff from the user, and check 156 whether it shows traffic to sap.mcast.net, and if so, from what sources, 157 and what is being announced. 159 5.1.2. Reception problems 161 Reception questions are those where the user has successfully received 162 the session announcement, but was unable to receive one or more media 163 streams for the session joined. Sample complaints include: 165 I joined conference X, but nothing happened 166 I joined conference X, got video but no audio 167 I joined conference X, and got intermittent audio 168 I can't see source X, but source X can see me (or vice versa) 170 Reception questions are typically investigated via the following 171 procedure: 173 1. Check the session announcement, find the group(s) and ports that the 174 session utilizes, as well as the source IP addresses. 176 2. Find out the user's IP address, if known, and the POP dialed into or 177 router connected to. One way to determine the user's router given their 178 IP address is to mtrace or traceroute to their address. 180 3. Check if the user is sending RTCP reports with RTPmon, and if so, 181 what the loss rate is. 183 4. Do an mtrace between the source and the receiver on the relevant 184 group. If the mtrace succeeds, note any hops showing loss. 186 5. If the mtrace never gets past the receiver itself, check the NASes 187 or routers with mstat -l to see if the relevant group has been joined. 188 If not, the problem is probably with the receiver's host. Check with 189 Dr. Watson to see if the router is sending IGMP membership queries, and 190 if the host is responding with membership reports and if so, what 191 versions are being used. 193 6. If the relevant group has been joined, but the mtrace failed, the 194 problem is likely a multicast routing problem (see section 4.1.3). 196 7. If the mtrace succeeded, and one hop shows 100% loss, compare the 197 output with the TTL of the session announcement. The user may not be in 198 a position to receive data from the source, due to site or regional 199 scoping. The loss may also be the result of a scoped boundary 200 separating the source and the receiver, which will also be indicated as 201 such by mtrace. 203 8. Otherwise, if the mtrace succeeded, look for hops showing non- 204 negligible loss. These typically denote points of congestion (see 205 section 4.3.1). 207 9. If all else fails, request a network sniff from the user, and check 208 whether it shows traffic to the relevant group, and if so, from what 209 sources. 211 Other reception complaints include: 212 When I join my first conference, it works great. But then when I quit 213 that and join another one, it doesn't work anymore. 215 Why is my modem light is still flashing even after I've quit SDR and 216 VIC? 218 Such problems are often IGMP-related problems observed by a user 219 connecting to the network using a host which is running a TCP/IP stack 220 implementing IGMP v1. Such users will experience long leave latencies, 221 with resulting poor reception and/or performance of other applications. 222 Such problems can be distinguished from ordinary reception problems in 223 that they typically do not occur for the first session joined, only for 224 subsequent sessions. The solution consists of upgrading the user to an 225 IGMP v2-capable stack. IGMP is described in [2]. 227 IGMP-related questions are typically investigated by the following 228 procedure: 230 1. Obtain the vendor and version of the user's TCP/IP stack. Determine 231 whether this stack is IGMP v2-enabled. 233 2. Ask the user to run Dr. Watson or a network sniffer and to indicate 234 whether IGMP queries are being seen, whether responses are being sent, 235 and if so, what version. 237 5.1.3. Multicast router problems 239 Multicast router questions are those which relate to the setup of a 240 multicast router. Sample complaints include: 242 I can get video and audio when online with ISDN, but not with a 243 modem, or vice versa. 245 I can't bring up a DVMRP tunnel to my site. Why not? 247 My router works great. Why can't I get multicast? 249 Why can't I source multicast? 251 Multicast routing questions are typically investigated via the following 252 procedure: 254 1. Ask the user what the router vendor is, and what software version 255 they have running. Attempt to verify this information using mrinfo or 256 mstat. 258 2. Check whether this vendor and version supports multicast routing, and 259 whether an upgrade to a later version is recommended. 261 3. Ask for a copy of the router configuration file. 263 4. Check whether the user has NAT enabled; this is incompatible with 264 most multicast routing protocols, and so should be switched off. 266 5. Find out the user's IP address(es), or if not known, the POP dialed 267 into or router connected to. 269 6. Check the loss rate and connectivity by doing an mtrace from various 270 sources to the user's IP address. 272 7. Check the user's router with mstat -l to see if it has joined any 273 multicast groups, and check upstream routers to see if they are 274 subscribed to any groups. 276 8. When all else fails, request a network sniff and examine it to 277 determine what multicast routing protocols are being run, if any. 279 5.2. Network Operations Center 281 A Network Operations Center (NOC) will typically receive a complaint 282 after it has been investigated by customer support and determined to be 283 a network-related issue. Although it is desirable for customer support 284 to have performed the diagnostic tests described above, if this has not 285 been done, NOC personnel will need to perform the tests themselves to 286 isolate the cause of the problem. If the proper systems have been 287 installed, in most cases, the NOC will already have been alerted to the 288 problem prior to receiving referrals from customer support. The 289 following diagnostic procedures are recommended: 291 1. Regularly generate summaries based on RTCP receiver and sender 292 reports, using RTP monitoring tools. Sample reports may include average 293 loss rates experienced during sessions, or users whose loss rates exceed 294 a particular threshold. 296 2. Determine the source of the problems by doing mtraces between the 297 sources and the receivers. 299 3. On a network monitoring station, keep track of the functioning of 300 multicast-enabled hardware, either by doing periodic mtraces, or by 301 using a heartbeat monitor to receive SNMP traps from equipment losing 302 the heartbeat. 304 4. In order to keep track of group topologies, use mapping tools such as 305 map-mbone, MVIEW, or mrtree, along with autonomous system mapping tools 306 such as asn and asname. 308 5.3. Network or system administrator 310 The NOC will escalate network engineering problems to network engineers 311 and system administrators if their intervention is required. In order to 312 understand the origin of the problem and repair it, it is necessary to 313 diagnose the operations of individual systems and routers using router 314 and system diagnostics such as netstat, mrinfo, mstat, mconfig, RTPmon, 315 and mtrace, as well as network analysis tools such as tcpdump or Dr. 316 Watson. 318 In smaller installations the network engineer or system administrator 319 often doubles as customer support and network operations guru, in which 320 case problems may be escalated without any triage (our condolences). 322 Typical classes of problems encountered by network engineers and system 323 administrators include: 325 Congestion and rate-limiting problems 326 Multicast routing problems 328 5.3.1. Congestion and rate limiting problems 330 Congestion and rate limiting problems result in high packet loss with 331 subsequent loss of session announcements and decrease in quality of 332 audio and video. These problems may be investigated via the following 333 procedure: 335 1. Use RTPmon to check for receivers experiencing packet loss. 337 2. Do an mtrace from the source to the receiver on the relevant group in 338 order to locate the problematic hops. 340 3. Do an mtrace in the opposite direction to help distinguish whether 341 the problem is with the router or the link at that hop. 343 4. If the reverse mtrace shows similar loss at an hop adjacent to the 344 lossy hop in the forward mtrace, odds are that the intermediate router 345 is overloaded. Use mrinfo to check the fanout on the router. 346 Overloaded routers are often the result of having too many tunnels. 348 5. If the reverse mtrace shows no problems near that hop, indicating 349 that loss is one-way, then check the router on the upstream end of the 350 link with mstat -nv to see if it has a rate-limit set on the link, and 351 if the link traffic is near that limit. 353 6. If the reverse mtrace shows loss over the same link, the problem is 354 likely to be link congestion. Use mstat -nv to see how much bandwidth 355 is being used by multicast traffic. (If mstat fails, running an mtrace 356 with the -T option may help to confirm link congestion, although the 357 statistics can be misleading.) 359 7. If a congested link is suspected, but mstat failed, another indicator 360 can be obtained by doing an mtrace from the session announcer to the 361 destination on other groups joined by the receiver, such as the SAP 362 group, and comparing loss statistics. 364 8. Check for unicast packet loss over the link using ping. Multicast 365 (but not unicast) packet loss on a link with a rate limit is an 366 indication that the link's multicast rate limit should be raised or 367 eliminated entirely. Packet loss on a link without rate limiting is an 368 indication of congestion. On such links it may be desirable to add a 369 rate limit. Since DVMRP prunes are currently not retransmitted by most 370 routers, prunes may be lost if no rate limit exists, which may further 371 worsen the congestion problem. 373 9. Use mstat -gR to see whether a single group is using an inordinate 374 amount of the link bandwidth. If so, use mstat to see whether a single 375 source to that group is using an inordinate amount of the link 376 bandwidth. If so, attempt to contact the source (contact information 377 may be available in the session announcement). 379 5.3.2. Multicast routing problems 381 Multicast routing problems include: 383 Duplicate packets 384 Injection of bogus routes (typically into DVMRP) 385 Redistribution of unicast routes (via BGP or an IGP) into DVMRP 386 Non-pruning routers 388 Duplicate packets are a symptom of routing loops. This problem may be 389 investigated via the following procedure: 391 1. Use a program such as Duppkts to detect duplicate packets. 393 2. Use a network monitor or RTPmon to find the sources and receivers on 394 the group. 396 3. Do an mtrace from the source(s) to the receivers in order to find 397 the loop. Duplicates will also show up in mtrace output as hops with 398 negative loss. 400 Bogus route injection problems may be investigated via the following 401 procedure: 403 1. Dump the DVMRP routing table. The routing table may be examined 404 remotely via mstat using the -r options, or locally (for mrouted) by 405 sending the USR1 signal to mrouted, generating the /var/tmp/mrouted.dump 406 file. 408 2. Check the table for bogus routes (known as "martians"). Bogus routes 409 include addresses reserved for use by private internets, as described in 410 [9]. These routes include 10/8, 172.16/12, or 192.168/16, or more 411 specific routes within these regions. Injecting a default route into 412 the DVMRP backbone is also considered to be a bogus route. 414 3. Locate the origin of the bogus routes by doing an mtrace to an IP 415 address in the bogus range. 417 Symptoms of unicast route redistribution are injection of a large number 418 of unicast routes (25K+) into DVMRP. The problem may be investigated via 419 the following procedure: 421 1. Examine the routing table. The DVMRP routing table may be examined 422 remotely via mstat -r, or locally (for mrouted) by sending the USR1 423 signal to mrouted, generating the /var/tmp/mrouted.dump file. For 424 protocol independent multicast routing protocols (such as Sparse-Mode 425 PIM), examine the unicast routing table. 427 2. Check if a single site is the predominant route injector. This site 428 is likely to be the problem. One way to check this is to mtrace to 429 addresses in a number of "suspect" prefixes. 431 3. If your router supports it, set a route limit on the DVMRP tunnel 432 interface. A limit of 7000 routes is currently recommended. You may also 433 wish to set "route-hog notification" at 5000 routes. 435 Non-pruning DVMRP routers are those which maintain groups in the 436 multicast routing table although there are no downstream subscribers. 437 The problem can be solved via the following procedure: 439 1. Check the router version number using mstat or mrinfo. Non-pruning 440 routers include mrouted versions prior to 3, Cisco Systems IOS prior to 441 version 11.0(3), and Bay Networks implementations prior to 9.0. 443 2. Confirm lack of pruning as follows. First, dump the multicast 444 forwarding 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 outgoing 449 interface list for every entry in the multicast forwarding table. If 450 so, it is likely that a non-pruner lies downstream in that direction. 452 4. You can confirm the existence of a non-pruner by creating a 453 temporary, unadvertised, session and sending (preferably with a low data 454 rate) data to that group. After a few moments, dump the forwarding 455 table again. If any interfaces appear in the outgoing interface list of 456 the entry for your test stream, then non-pruners lie in those 457 directions. 459 5. If a non-pruner exists downstream, use mrtree to follow the path of 460 the data downstream to the non-pruning router(s). 462 6. If your router supports it, enable the reject non-pruners option. If 463 not, and the unpruned interface is a tunnel, consider disabling the 464 tunnel. 466 6. Appendix - Multicast Diagnostic Tools 468 6.1. Types of tools 470 Multicast diagnostic tools typically fall into the following categories: 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | | | 474 | RTP monitoring tools | RTPmon | 475 | | Msessmon | 476 | | RTPquality | 477 | | RTPdump | 478 | | RTPcast/RTPlisten | 479 | | Duppkts | 480 | | | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | | | 483 | | mrinfo | 484 | Multicast router | netstat | 485 | diagnostics | mconfig | 486 | | mstat | 487 | | mrouted.dump, mrouted.cache | 488 | | | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | | | 491 | Multicast traceroute | mtrace | 492 | | | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | | | 495 | | mrtree | 496 | | map-mbone | 497 | MBONE mapping tools | asn | 498 | | asname | 499 | | mcollect & mwatch | 500 | | | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | | | 503 | NOC tools | MVIEW | 504 | | Multicast heartbeat | 505 | | | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | | | 508 | Network analysis | tcpdump | 509 | tools | Dr. Watson | 510 | | | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 RTP monitoring tools are used to monitor the transmission quality and 514 popularity of individual sessions. Multicast router diagnostics are used 515 to obtain information on the configuration and state of multicast 516 routers. MBONE mapping tools are used to map out the topology for a 517 particular group. These tools can show the topology at the level of 518 individual systems, or at the level of autonomous system connections. 519 Multicast traceroute tools are used to trace the path between a source 520 and destination. Network Operations Center tools are used to monitor the 521 state of network devices within an autonomous system. Network analysis 522 tools (such as tcpdump and Dr. Watson) are used to analyze traffic on 523 the network. 525 6.2. Facilities utilized 527 Multicast diagnostic tools typically rely on one or more of the 528 following facilities: 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | | | 532 | RTCP source and | RTPmon | 533 | receiver reports | Msessmon | 534 | | RTPquality | 535 | | RTPdump | 536 | | RTPcast/RTPlisten | 537 | | Duppkts | 538 | | | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | | | 541 | | multicast heartbeat | 542 | SNMP MIBs | mconfig | 543 | | mstat | 544 | | MVIEW | 545 | | mrtree | 546 | | | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | | | 549 | IGMP trace facility | mtrace | 550 | | | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | | | 553 | | mrinfo | 554 | | mrtree | 555 | IGMP ASK_NEIGHBORS | map-mbone | 556 | message (DVMRP) | | 557 | | | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | | | 560 | Routing arbiter and | asn | 561 | WHOIS Databases | asname | 562 | | | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | | | 565 | Internal structures | tcpdump | 566 | | netstat | 567 | | mrouted.dump, mrouted.cache | 568 | | | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 Tools using RTCP reports analyze RTCP source and receiver reports, 572 providing information on packet loss, inter-arrival jitter, bandwidth 573 availability, or listenership. These tools therefore will only work with 574 RTP implementations which support RTCP reporting. Tools using SNMP MIBs 575 perform queries for variables in the IGMP, multicast routing, DVMRP, and 576 PIM MIBs. As a result, these tools depend on implementation of the 577 relevant SNMP MIBs in the network devices that are being monitored. 578 Tools based IGMP ASK_NEIGHBORS messages use these messages to map 579 portions of the MBONE, and thus will only work with routers implementing 580 DVMRP. Tools based on IGMP tracing perform a multicast traceroute. These 581 tools are typically only useful in cases where multicast routers along 582 the path have a route back to the source. 584 Diagnostic tools may use more than one of these facilities. For example, 585 mstat makes use of SNMP MIBs, as well as the IGMP ASK_NEIGHBORS 586 facility. 588 6.3. RTP monitoring tools 590 This class of tools provides information required to monitor the 591 performance of RTP-based applications. 593 6.3.1. RTPmon 595 Authors 597 David Bacher, Andrew Swan, and Lawrence A. Rowe 598 {drbacher,aswan,rowe}@cs.berkeley.edu 599 Computer Science Division - EECS 600 University of California 601 Berkeley, CA 94720-1776 603 Description 605 RTPmon allows network administrators or support personnel to monitor 606 listenership as well as session quality experienced by subscribers. 607 The tool also facilitates tracing the cause of problems resulting in 608 quality degradation. To accomplish this task, RTPmon summarizes and 609 analyzes information provided by RTCP source and receiver reports. 611 Receivers are displayed for a given sender in the form of a 612 spreadsheet, with cells being filled in with metrics such as packet 613 loss rate or jitter. Clicking on a cell displays a stripchart of 614 statistics on packet loss rate, smoothed packet loss rate and jitter. 615 From the stripchart it is possible to launch an mtrace between the 616 sender and the receiver, a convenient way of diagnosing network 617 problems along the multicast distribution path. Clicking on a 618 receiver or sender displays summary information. 620 For groups with large memberships, the display may be limited to 621 members surpassing a given threshold in packet loss rate or jitter. 622 Using RTPmon it is possible to sort receivers for a given sender 623 according to maximum or average loss. 625 Further information is available in the RTPmon man page. 627 Example 629 For examples and further information, see the rtpmon man page, or: 630 http://bmrc.berkeley.edu/~drbacher/projects/mm96-demo/ 632 Facilities used 634 RTCP source and receiver reports 635 IGMP multicast trace (if installed) 637 Availability 639 RTPmon is available for UNIX and may be obtained from: 640 ftp://mm-ftp.cs.berkeley.edu/pub/rtpmon/ 642 Bug reports and suggestions should be sent to: 643 rtpmon@bmrc.berkeley.edu. 645 6.3.2. RTPcast/RTPlisten, RTPquality, Duppkts, RTPdump, RTPtools, 646 Msessmon, Mpoll 648 Author 649 Mpoll: Andrew Patrick 651 Description 653 RTPcast listens to RTCP receiver reports and forwards data to another 654 multicast group; RTPlisten then listens to that group. RTPdump 655 listens for, and dumps RTP and RTCP packets. Duppkts listens on a 656 multicast group and port, and reports the number of packets received 657 and lost, as well as the number of duplicates. RTPquality listens to 658 RTCP receiver reports and writes data on packet loss, as well as late 659 and non-sequenced packets. RTPtools allows recording and playback of 660 RTP sessions. Msessmon provides a routemap of participants in RTP 661 conferences as well as stripcharts of statistics on RTP packet loss 662 and jitter. Mpoll is a survey collection tool that can be used to 663 collect quality ratings during multicast sessions. 665 Example 667 Information on these tools is available from: 669 http://sauce.mmlab.uninett.no/mice-nsc/tools.html 671 Facilities used 673 RTCP source and receiver reports 675 Availability 677 Binaries for RTPcast/RTPlisten are available from: 678 ftp://sauce.uio.no/mice-nsc/util/rtp 680 Source code for RTPquality is available from: 681 ftp://sauce.uio.no/mice-nsc/util/rtp/rtpqual.c 683 Source code for RTPdump is available at: 684 ftp://sauce.uio.no/mice-nsc/util/rtpdump-1.0.tar.gz 686 Source code for RTPtools is available at: 687 ftp://sauce.uio.no/mice-nsc/util/rtptools/rtptools-1.9.tar.gz 689 Source and binaries for Msessmon is available at: 690 ftp://sauce.uio.no/mice-nsc/util/msessmon/ 692 Source and binaries for Mpoll is available at: 693 ftp://sauce.uio.no/mice-nsc/util/mpoll/ 695 6.4. Multicast router diagnostics 697 This class of tools facilitates monitoring and management of multicast 698 routers. 700 6.4.1. mrouted.dump, mrouted.cache 702 Author 704 Bill Fenner, fenner@research.att.com 706 Description 708 Sending the USR1 signal to mrouted dumps the internal routing table 709 to /var/tmp/mrouted.dump; sending the USR2 signal dumps the 710 forwarding cache to /var/tmp/mrouted.cache. 712 Further information on mrouted and the mrouted.dump and mrouted.cache 713 file formats is available in the mrouted man page. 715 Example 716 % cat mrouted.dump 717 vifs_with_neighbors = 2 719 Virtual Interface Table 720 Vif Name Local-Address M Thr Rate Flags 721 0 ed0 128.31.107.1 subnet: 128.31.107/24 1 1 0 querier 722 peers: 128.31.107.249 (3.8) (0xe) 723 groups: 239.109.100.200 724 224.0.0.2 725 224.0.0.4 726 pkts in : 4075 727 pkts out: 0 729 1 ed0 128.31.107.1 tunnel: 204.67.107.11 1 32 500 730 peers: 204.67.107.11 (11.2) (0x1a) 731 pkts in : 0 732 pkts out: 2359 734 Multicast Routing Table (3801 entries) 735 Origin-Subnet From-Gateway Metric Tmr In-Vif Out-Vifs 736 207.10.165.51/32 128.31.107.249 10 20 0 1 737 207.10.165.50/32 128.31.107.249 10 20 0 1 738 206.172.195.32/32 128.31.107.249 9 20 0 1 739 172/8 128.31.107.249 10 20 0 1 740 ... 742 % cat mrouted.cache 743 Multicast Routing Cache Table (198 entries) 744 Origin Mcast-group CTmr Age Ptmr IVif Forwvifs 745 131.107.2.139/32 224.0.12.0 58s 7m - -1 746 >131.107.2.139 747 143.107.103.0/27 224.0.1.1 3m 2m 3m 0P 748 >143.107.103.5 749 128.232/16 224.0.1.1 4m 7m 4m 0P 750 >128.232.2.209 751 157.161/16 224.0.1.1 67s 6m - 0 1 752 >157.161.114.2 753 206.152.163/24 224.0.1.15 74s 7m - 0 1 754 >206.152.163.21 755 4.0.0.34/32 224.0.1.32 56s 4m 25s 0P 1p 756 >4.0.0.34 757 137.39.2.254/32 224.0.1.32 3m 5m - 0 1 758 >137.39.2.254 759 137.39.43.32/30 224.0.1.32 38s 5m - 0 1 760 >137.39.43.34 761 ... 763 Facilities used 765 Internal facilities (forwarding cache and routing table) 767 Availability 769 The SNMP-capable mrouted distribution is available at: 770 ftp://ftp.merit.edu/net-research/mbone/mirrors/mrouted/ 772 6.4.2. mrinfo 774 Author 776 Van Jacobson, van@ee.lbl.gov 778 Description 780 mrinfo displays information about a multicast router; to do this, it 781 uses the IGMP ASK_NEIGHBORS message to discover the router's physical 782 and virtual interfaces. Routers are also queried for their version 783 number, and if this query is successful, for their metrics, 784 thresholds, and flags. Results are printed in an indented list format 785 similar to that for map-mbone. 787 Example 789 % mrinfo 192.80.214.199 790 192.80.214.199 (collegepk-mbone1.bbnplanet.net) [version 11.2,prune,mtrace,snmp]: 791 128.167.252.196 -> 0.0.0.0 (local) [1/0/pim/querier/leaf] 792 192.80.214.199 -> 0.0.0.0 (local) [1/0/pim/querier/leaf] 793 192.41.177.196 -> 0.0.0.0 (local) [1/0/pim/querier/down/leaf] 794 128.167.252.196 -> 128.167.254.165 (devo.sura.net) [1/32/tunnel/querier/down/leaf] 795 128.167.252.196 -> 131.119.0.197 (paloalto-mbone1.bbnplanet.net) 796 [1/64/tunnel/pim/querier] 797 128.167.252.196 -> 199.94.207.2 (cambridge1-mbone1.bbnplanet.net) 798 [1/32/tunnel/pim/querier] 799 128.167.252.196 -> 137.39.43.34 (MBONE1.UU.NET) [1/32/tunnel/querier] 800 128.167.252.196 -> 192.41.177.199 (wtn-ms2.bbnplanet.net) [1/16/tunnel/querier] 801 128.167.252.196 -> 128.244.93.3 (sage.jhuapl.edu) [1/32/tunnel/querier] 802 128.167.252.196 -> 192.221.34.22 (cdrn.bbnplanet.net) [1/32/tunnel/querier] 803 128.167.252.196 -> 128.167.1.197 (cpk-ms1.ser.bbnplanet.com) [1/16/tunnel/querier] 804 128.167.252.196 -> 134.205.93.150 (dilbert.sam.pentagon.mil) [1/32/tunnel/querier] 805 128.167.252.196 -> 192.221.48.234 (atlanta3-mbone1.bbnplanet.net) 806 [1/64/tunnel/pim/querier] 807 128.167.252.196 -> 204.167.201.38 (dallas2-mbone1.bbnplanet.net) 808 [1/64/tunnel/pim/querier] 809 128.167.252.196 -> 205.130.85.3 (philipii.nap.edu) [1/32/tunnel/querier/down/leaf] 810 128.167.252.196 -> 128.175.13.36 (pfet.nss.udel.edu) [1/32/tunnel/querier/down/leaf] 811 128.167.252.196 -> 192.41.177.197 (wtn-ms1.bbnplanet.net) [1/32/tunnel/querier] 812 128.167.252.196 -> 204.148.62.28 (mbone-e.ans.net) [1/32/tunnel/querier] 813 128.167.252.196 -> 205.128.246.2 (usnrctc.bbnplanet.net) [1/32/tunnel/pim/querier] 815 Facilities used 817 IGMP ASK_NEIGHBORS message (DVMRP) 819 Availability 821 mrinfo is available for UNIX and is included in the SNMP-capable 822 mrouted distribution, available at: 823 ftp://ftp.merit.edu/net-research/mbone/mirrors/mrouted/ 825 mrinfo is also available in the MVIEW distribution, available at: 826 ftp://ftp.merit.edu/net-research/mbone/mview/ 828 6.4.3. netstat 830 Author 832 Unknown 834 Description 836 On multicast-enabled systems, netstat is typically extended so as to 837 provide information on virtual interfaces and the multicast 838 forwarding cache (-g option), as well as multicast routing statistics 839 (-gs option), and igmp behavior (-s option). 841 Example 843 %netstat -g 845 Virtual Interface Table 846 Vif Thresh Rate Local-Address Remote-Address Pkts-In Pkts-Out 847 0 1 0 128.15.2.120 16323 385 848 1 32 512 128.15.2.120 202.34.126.2 2 0 850 Multicast Forwarding Cache 851 Origin Group Packets In-Vif Out-Vifs:Ttls 852 128.15.2.120 224.2.195.166 281 0 853 128.15.1.110 239.100.101.223 1660 0 854 128.15.1.135 238.27.27.1 1660 0 855 128.15.1.110 239.111.111.235 1660 0 856 ... 858 %netstat -gs 859 multicast forwarding: 860 182880 multicast forwarding cache lookups 861 8237 multicast forwarding cache misses 862 6736 upcalls to mrouted 863 193 upcall queue overflows 864 5567 upcalls dropped due to full socket buffer 865 177 cache cleanups 866 7234 datagrams with no route for origin 867 0 datagrams arrived with bad tunneling 868 0 datagrams could not be tunneled 869 954 datagrams arrived on wrong interface 870 0 datagrams selectively dropped 871 0 datagrams dropped due to queue overflow 872 0 datagrams dropped for being too large 874 %netstat -s 875 ip: 876 3807182 total packets received 877 0 bad header checksums 878 ... 879 icmp: 880 40 calls to icmp_error 881 0 errors not generated 'cuz old message was icmp 882 ... 883 igmp: 884 18504 messages received 885 0 messages received with too few bytes 886 48 messages received with bad checksum 887 2478 membership queries received 888 0 membership queries received with invalid field(s) 889 194 membership reports received 890 0 membership reports received with invalid field(s) 891 0 membership reports received for groups to which we belong 892 8510 membership reports sent 893 tcp: 894 10705 packets sent 895 5536 data packets (1532081 bytes) 896 ... 897 udp: 898 3104045 datagrams received 899 0 with incomplete header 900 ... 902 Facilities used 904 Netstat accesses system internal data structures in order to carry 905 out its function. 907 Availability 909 netstat is included with a variety of operating systems, including 910 UNIX, OS/2, and Windows. For further information, please consult the 911 netstat man page or documentation. 913 6.4.4. mstat 915 Author 917 Dave Thaler, dthaler@microsoft.com 919 Description 921 mstat is a general purpose tool for obtaining router configuration 922 and status information. In order to perform its task, mstat utilizes 923 SNMP MIBs (such as the IGMP, multicast routing, PIM, and DVMRP MIBs), 924 as well as ASK_NEIGHBORS IGMP messages. mstat displays the contents 925 of various MBONE-related data structures in various formats, 926 depending on the options selected. Options include: 928 -G Show the PIM group table 929 -I Show the PIM interface table. 930 -K Show the cached IP multicast route table; works for 931 all SNMP-capable routers. 932 -N Show the IP Multicast Next Hop Table. 933 -P Show the PIM neighbor table. 934 -a Show the alternate subnet table. 935 -b Show the scoped boundary table. 936 -d Show the DVMRP neighbor table. 937 -g Show the Group Summary table. 938 -i Show the DVMRP interface table; similar to an 939 mrinfo report. 940 -l Show the IGMP local group table. 941 -r Show the DVMRP routing table; similar to a portion of 942 the mrouted.dump file. 943 -t Show the DVMRP routing next hop table; similar to 944 another portion of the mrouted.dump file. 945 -v Show statistics corresponding to the DVMRP interface table. 947 Examples 949 % mstat 950 IP Multicast Route Table for bigco.com 951 Mcast-group Origin-Subnet InIf UpTime Tmr Pkts Bytes RpF Proto 952 NTP.MCAST.NET 0.0.0.0/32 0 245341 179 0 0 0 pim 953 NTP.MCAST.NET 128.232.0.49/32 7 206403 418 3056 293376 17 dvmrp 954 NTP.MCAST.NET 128.232.2.209/32 7 206403 417 3027 290592 19 dvmrp 955 NTP.MCAST.NET 143.107.103.5/32 7 592 218 3 228 3 dvmrp 956 NTP.MCAST.NET 157.161.114.2/32 7 27703 517 411 31236 11 dvmrp 957 IETF-2-VIDEO.MC 0.0.0.0/32 0 245349 175 0 0 0 pim 958 IETF-2-VIDEO.MC 206.152.163.21/32 7 242567 244 46887 4149336 3388 dvmrp 959 MTRACE.MCAST.NE 0.0.0.0/32 0 1690 177 0 0 0 pim 960 MTRACE.MCAST.NE 194.104.0.25/32 7 405 483 2 792 0 dvmrp 961 MTRACE.MCAST.NE 206.54.224.150/32 7 456 569 4 1072 4 dvmrp 962 CISCO-RP-DISCOV 0.0.0.0/32 0 245534 0 0 0 0 pim 963 224.0.14.1 203.15.123.99/32 4 17 161 0 0 0 dvmrp 964 224.0.92.3 171.68.201.39/32 4 174 4 0 0 0 dvmrp 965 224.2.0.1 13.2.116.11/32 4 150 26 0 0 0 dvmrp 966 224.2.0.1 128.32.38.218/32 4 147 30 0 0 0 dvmrp 967 224.2.2.1 205.226.8.183/32 4 146 30 0 0 0 dvmrp 968 224.2.20.165 13.2.116.11/32 4 55 119 0 0 0 dvmrp 969 224.2.100.100 13.2.116.11/32 4 87 91 0 0 0 dvmrp 970 SAP.MCAST.NET 164.67.63.7/32 4 114 64 1 855 0 dvmrp 971 SAP.MCAST.NET 193.61.212.130/32 4 153 23 1 868 0 dvmrp 972 SAP.MCAST.NET 199.94.220.184/32 4 26 152 1 416 0 dvmrp 973 SAP.MCAST.NET 206.154.213.242/32 4 156 19 1 360 0 dvmrp 974 ... 976 Examples of the many other options are provided in the mstat man pages. 978 Facilities used 980 PIM, DVMRP, IGMP, and multicast routing MIBs 981 IGMP ASK_NEIGHBORS message (DVMRP) 983 Availability 985 mstat is included in the SNMP-capable mrouted distribution, 986 available at: 987 ftp://ftp.merit.edu/net-research/mbone/mirrors/mrouted/ 989 mstat is also available in the MVIEW distribution, available at: 990 ftp://ftp.merit.edu/net-research/mbone/mview/ 992 6.4.5. mconfig 994 Author 996 Dave Thaler, dthaler@microsoft.com 998 Description 1000 mconfig allows the user to display and (if the community string is 1001 known) to modify the configuration of a multicast router implementing 1002 the DVMRP MIB. 1004 Example 1006 For more information on mconfig, please see the man page. 1008 Facilities used 1010 DVMRP MIB 1012 Availability 1014 mconfig is available for UNIX and is included in the SNMP-capable 1015 mrouted distribution, available at: ftp://ftp.merit.edu/net- 1016 research/mbone/mirrors/mrouted/ 1018 6.5. Multicast traceroute 1020 6.5.1. mtrace 1022 Author 1024 Bill Fenner, fenner@research.att.com 1026 Description 1028 mtrace provides a facility by which to trace the path between a 1029 sender and a receiver of a particular group. This is particularly 1030 useful when used alongside a facility such as RTPmon, which allows 1031 you to identify problem source-receiver pairs. 1033 Note that the utility of mtrace is often limited by the multicast 1034 topology. Where multicast and unicast topologies are not aligned (as 1035 is the case in many multicast-enabled networks) mtrace may not 1036 function. 1038 For information on the details of the protocol, see reference [8]. 1040 Example 1042 % mtrace 131.243.73.36 128.15.1.250 224.2.195.166 1043 Mtrace from 131.243.73.36 to 128.15.1.250 via group 224.2.195.166 1044 Querying full reverse path... * switching to hop-by-hop: 1045 0 bigman.bigco.com (128.15.1.250) 1046 -1 * * littleman.bigco.com (128.15.1.249) DVMRP thresh^ 1 1047 -2 * * * seamr1-gw.nwnet.net (192.35.180.201) DVMRP thresh^ 32 1048 -3 * * seamr2-gw.nwnet.net (192.220.238.130) DVMRP thresh^ 0 1049 -4 * * mcast.cac.washington.edu (140.142.116.1) DVMRP thresh^ 32 1050 -5 * * * * dec3800-1-fddi-0.Sacramento.mci.net (204.70.164.29) didn't respond 1051 -6 * * * 1052 -7 * * 1053 Resuming... 1054 -5 dec3800-1-fddi-0.Sacramento.mci.net (204.70.164.29) DVMRP thresh^ 64 1055 -6 dec3800-2-fddi-0.SanFrancisco.mci.net (204.70.158.61) DVMRP thresh^ 1 1056 -7 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 64 1057 -8 * * llnl-mr2.es.net (134.55.12.229) DVMRP thresh^ 64 1058 -9 * * lbl-mr1.es.net (134.55.12.101) DVMRP thresh^ 8 1059 -10 * * mr1.lbl.gov (131.243.64.184) DVMRP thresh^ 32 1060 -11 * * ir40gw.lbl.gov (131.243.64.1) DVMRP thresh^ 0 1061 -12 * * irals.lbl.gov (131.243.128.6) PIM thresh^ 0 1062 -13 bl7-36.als.lbl.gov (131.243.73.36) 1063 Round trip time 74 ms; total ttl of 72 required. 1065 Waiting to accumulate statistics... Results after 10 seconds: 1067 Source Response Dest Overall Packet Statistics For Traffic From 1068 131.243.73.36 128.15.1.250 Packet 131.243.73.36 To 224.2.195.166 1069 v __/ rtt 77 ms Rate Lost/Sent = Pct Rate 1070 131.243.73.1 1071 131.243.128.6 irals.lbl.gov 1072 v ^ ttl 1 6 pps 0/60 = 0% 6 pps 1073 131.243.128.40 1074 131.243.64.1 ir40gw.lbl.gov 1075 v ^ ttl 2 13 pps 0/60 = 0% 6 pps 1076 131.243.64.184 mr1.lbl.gov 1077 v ^ ttl 35 9 pps 0/60 = 0% 6 pps 1078 198.128.16.13 1079 134.55.12.101 lbl-mr1.es.net 1080 v ^ ttl 35 0 pps 0/60 = 0% 0 pps 1081 134.55.12.229 llnl-mr2.es.net 1082 v ^ ttl 69 0 pps 1/60 = 2% 0 pps 1083 192.203.230.241 mbone.nsi.nasa.gov 1084 v ^ ttl 70 0 pps 0/59 = 0% 0 pps 1085 204.70.158.61 dec3800-2-fddi-0.SanFrancisco.mci.net 1086 v ^ ttl 70 0 pps 0/59 = 0% 0 pps 1087 204.70.164.29 dec3800-1-fddi-0.Sacramento.mci.net 1088 v ^ ttl 72 0 pps 0/59 = 0% 0 pps 1089 140.142.116.1 mcast.cac.washington.edu 1090 v ^ ttl 72 0 pps 0/59 = 0% 0 pps 1091 192.220.249.66 1092 192.220.238.130 seamr2-gw.nwnet.net 1093 v ^ ttl 72 0 pps 0/59 = 0% 0 pps 1094 192.220.238.129 1095 192.35.180.201 seamr1-gw.nwnet.net 1096 v ^ ttl 72 0 pps 0/59 = 0% 0 pps 1097 128.15.1.249 littleman.bigco.com 1098 v __ ttl 72 0 pps ?/59 0 pps 1100 128.15.1.250 128.15.1.250 1101 Receiver Query Source 1103 Facilities used 1105 IGMP multicast trace facility 1107 Availability 1109 mtrace is now distributed independently of mrouted. 1110 Source code is available from: 1111 ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mtrace5.1.tar.Z 1113 Binaries: 1114 ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mtrace5.1-sparc-sunos41x.tar.Z 1115 ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mtrace5.1-sparc-solaris2.tar.Z 1116 ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mtrace5.1-alpha-osf1.tar.Z 1117 ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mtrace5.1-sgi-irix.tar.Z 1119 6.6. MBONE mapping tools 1121 6.6.1. mrtree 1123 Author 1125 Dave Thaler, dthaler@microsoft.com 1126 Andy Adams, ala@merit.edu 1128 Description 1130 mrtree uses a combination of IGMP and SNMP queries to discover the 1131 actual and potential multicast (sub)trees for a given source and 1132 group, rooted at a given router. An actual tree, discovered using the 1133 multicast routing MIB, consists of routers which are currently 1134 forwarding multicast traffic to a group from a given source. A 1135 potential tree, discovered using the DVMRP MIB, is one which would 1136 exist if every host were a member of the group. 1138 Example 1140 % mrtree mbone.merit.edu 224.2.143.24 204.62.246.73 1141 Actual distribution tree rooted at mbone.merit.edu for group 224.2.143.24 1142 and source 204.62.246.73... 1143 0 mbone.merit.edu (198.108.2.20) [ver 3.8,prune,genid,mtrace], 1144 247390 pkts 1145 1 cujo.merit.edu (198.108.60.97) [ver 3.6,prune,genid,mtrace], 333448 1146 6 pkts (1347%) 1147 2 subnet: 198.108.60/24 1148 2 shockwave.merit.edu (198.108.60.69) [ver 3.8,prune,genid,mtrace,snmp], 1149 1239130 pkts (500%) 1150 1 tibia.cic.net (192.217.65.100) [ver 3.8,prune,genid,mtrace] 1151 ... (No response from tibia.cic.net) 1152 2 fibula.cic.net (192.217.65.101) [ver 3.8,prune,genid,mtrace] ? 1153 2 dcl2.gw.uiuc.edu (192.17.2.8) [ver 1.0] ? 1154 2 goober.mci.net (204.70.104.45) [ver 3.6,prune,genid,mtrace] ? 1155 ... (goober.mci.net did not respond to DVMRP 'NEIGHBORS' msg) 1156 1 a-wing.jvnc.net (130.94.40.6) [ver 3.3] 1157 ... (a-wing.jvnc.net does not support SNMP) 1158 2 liberty-eth0/0.jvnc.net (130.94.40.1) [ver 10.2] ? 1159 2 noc.hpc.org (192.187.8.2) [ver 3.8,prune,genid,mtrace] ? 1160 2 liberty.jvnc.net (130.94.40.201) [ver 10.2] ? 1161 2 dstest.ds.internic.net (198.49.45.4) [ver 3.8,prune,genid,mtrace] ? 1162 2 cybercast.cc.nus.sg (137.132.9.70) [ver 3.6,prune,genid,mtrace] ? 1163 ... (cybercast.cc.nus.sg did not respond to DVMRP 'NEIGHBORS' msg) 1165 Facilities used 1167 DVMRP and multicast routing MIBs 1168 IGMP ASK_NEIGHBORS message (DVMRP) 1170 Availability 1172 mrtree is available for UNIX and is included in the 1173 SNMP-capable mrouted distribution, available at: 1174 ftp://ftp.merit.edu/net-research/mbone/mirrors/mrouted/ 1176 mrtree is also available in the MVIEW distribution, available at: 1177 ftp://ftp.merit.edu/net-research/mbone/mview/ 1179 6.6.2. map-mbone 1181 Author 1183 Pavel Curtis, pavel@parc.xerox.com 1185 Description 1187 map-mbone is useful for discovering the topology within a DVMRP 1188 routing domain; to do this, it uses the IGMP ASK_NEIGHBORS message to 1189 discover the neighbors of the starting router. If the -f (flooding) 1190 option is enabled (this is the default if no starting router is 1191 specified), then once these neighbors are discovered, they too are 1192 queried. This continues until the leaf routers are reached. This 1193 option should be used with care since it can result in excessive load 1194 on multicast routers. 1196 If a starting router is specified but the -f option is not used, then 1197 the search terminates after the first hop routers are discovered, the 1198 output of map-mbone is very similar to that for mrinfo. Routers 1199 discovered by map-mbone are queried for their version numbers, and if 1200 this query is successful, for their metrics, thresholds, and flags, 1201 and the results are presented in an indented list format. 1203 Example 1205 % map-mbone 192.80.214.199 1206 192.41.177.196: alias for 128.167.252.196 1208 128.167.252.196 (collegepk-mbone1.bbnplanet.net): 1209 192.41.177.196: 192.41.177.196 [1/0/querier/down] 1210 192.80.214.199: 192.80.214.199 (collegepk-mbone1.bbnplanet.net) [1/0/querier] 1211 128.167.252.196: 205.128.246.2 (usnrctc.bbnplanet.net) [1/32/tunnel/querier] 1212 204.148.62.28 (mbone-e.ans.net) [1/32/tunnel/querier] 1213 192.41.177.197 (wtn-ms1.bbnplanet.net) [1/32/tunnel/querier] 1214 128.175.13.36 (pfet.nss.udel.edu) [1/32/tunnel/querier/down] 1215 205.130.85.3 (philipii.nap.edu) [1/32/tunnel/querier/down] 1216 204.167.201.38 (dallas2-mbone1.bbnplanet.net) [1/64/tunnel/querier] 1217 192.221.48.234 (atlanta3-mbone1.bbnplanet.net) [1/64/tunnel/querier] 1218 134.205.93.150 (dilbert.sam.pentagon.mil) [1/32/tunnel/querier] 1219 128.167.1.197 (cpk-ms1.ser.bbnplanet.com) [1/16/tunnel/querier] 1220 192.221.34.22 (cdrn.bbnplanet.net) [1/32/tunnel/querier] 1221 128.244.93.3 (sage.jhuapl.edu) [1/32/tunnel/querier] 1222 192.41.177.199 (wtn-ms2.bbnplanet.net) [1/16/tunnel/querier] 1223 137.39.43.34 (MBONE1.UU.NET) [1/32/tunnel/querier] 1224 199.94.207.2 (cambridge1-mbone1.bbnplanet.net) [1/32/tunnel/querier] 1225 131.119.0.197 (paloalto-mbone1.bbnplanet.net) [1/64/tunnel/querier] 1226 128.167.254.165 (devo.sura.net) [1/32/tunnel/querier/down] 1227 128.167.252.196 (collegepk-mbone1.bbnplanet.net) [1/0/querier] 1229 192.80.214.199 (collegepk-mbone1.bbnplanet.net): alias for 128.167.252.196 1231 Facilities used 1233 IGMP ASK_NEIGHBORS message (DVMRP) 1235 Availability 1237 map-mbone is available for UNIX, and the software and manual pages are included 1238 in the SNMP-capable mrouted distribution, available at: 1239 ftp://ftp.merit.edu/net-research/mbone/mirrors/mrouted/ 1241 6.6.3. asn 1243 Author 1245 Dave Thaler, dthaler@microsoft.com 1247 Description 1249 asn gives the AS number of a given IP address by querying the routing 1250 arbiter database. 1252 Example 1254 % asn 141.213.10.41 1255 AS237 1257 Facilities used 1259 Routing arbiter database 1261 Availability 1263 asn is included in the MVIEW distribution, available at: 1264 ftp://ftp.merit.edu/net-research/mbone/mview/ 1266 6.6.4. asname 1268 Author 1270 Dave Thaler, dthaler@microsoft.com 1272 Description 1274 asname gets the name of an AS, given the AS number by querying the 1275 WHOIS database. 1277 Example 1279 % asname 237 1280 NSFNETTEST14-AS 1282 Facilities used 1284 WHOIS database 1286 Availability 1288 asname is included in the MVIEW distribution, available at: 1290 ftp://ftp.merit.edu/net-research/mbone/mview/ 1292 6.7. Network Operations Center tools 1294 These tools are suitable for use in a Network Operations Center. 1296 6.7.1. MVIEW 1298 Authors 1300 Dave Thaler, dthaler@microsoft.com 1301 Andy Adams, ala@merit.edu 1303 Description 1305 MVIEW uses utilities such as mstat, mtrace, mrtree, asn and asname in 1306 order to produce a graphical depiction of the multicast network 1307 topology and the actual and potential multicast trees for a given 1308 group and source. 1310 Example 1312 Further information on MVIEW as well as examples are available from: 1313 http://www.merit.edu/net-research/mbone/mviewdoc/Welcome.html 1315 Facilities used 1317 PIM, DVMRP, IGMP, and multicast routing MIBs (mstat) 1318 IGMP ASK_NEIGHBORS message (mrinfo) 1319 Routing arbiter database (asn) 1320 WHOIS database (asname) 1322 Availability 1324 MVIEW is available for UNIX, and can be obtained from: 1325 ftp://ftp.merit.edu/net-research/mbone/mview/ 1327 Documentation is available as: 1328 ftp://ftp.merit.edu/net-research/mbone/mviewdoc/ 1330 6.7.2. Multicast heartbeat 1332 Author 1334 Many and various 1336 Description 1337 Devices implementing the multicast heartbeat listen on a designated 1338 group. If traffic is not observed on the group for a specified amount 1339 of time, an SNMP trap is generated. This allows multicast monitoring 1340 to be easily integrated into existing SNMP consoles. In situations 1341 where a shared-tree multicast routing protocol is used (such as 1342 sparse-mode PIM or CBT), it is recommended that the heartbeat 1343 generator be located close to the RP or core nodes, so as that loss 1344 of the heartbeat will correlate closely with loss of connectivity to 1345 the RP or core. Suitable heartbeat mechanisms include SNTP, which 1346 uses the group 224.0.1.1 (ntp.mcast.net) and UDP port 123; and SAP, 1347 which uses the group 224.2.127.254 (sap.mcast.net) and UDP port 9875. 1349 Example 1351 For further information on SNTP, consult [1]. 1353 Facilities used 1355 SNTP (for time-based heartbeats) 1356 SAP (for session announcement heartbeats) 1357 SNMP traps (for alerts) 1359 Availability 1361 6.8. Network analysis tools 1363 6.8.1. Dr. Watson, the Network Detective's Assistant (DWTNDA) 1365 Author 1367 Karl Auerbach, karl@cavebear.com 1369 Description 1371 DWTNDA is a general purpose troubleshooting tool with some IP 1372 multicast tools (in addition to a fair number of non-multicast 1373 tools). For example it can watch IGMP "join" activity on a LAN and 1374 put up a real-time display in tabular format. It can generate some 1375 test packets, like IGMPv2 Leaves or Group Membership Requests. It can 1376 generate and respond to multicast pings (icmp, udp, or snmp based.) 1377 It will eventually acquire more sophisticated multicast facilities. 1379 Example 1381 See http://www.cavebear.com/dwtnda/ for examples. 1383 Facilities used 1385 This is a troubleshooting tool, so it will typically respond to 1386 packets that, strictly speaking, ought to go unanswered. 1388 Availability 1390 DWTNDA runs on MS-DOS and Windows 95/98 and is free. Source is not 1391 provided. See http://www.cavebear.com/dwtnda/ for various documents 1392 and download information. 1394 6.8.2. Mtap 1396 Author 1398 Luis Fernando da Silva Barra, barra@ax.apc.org 1399 Michael Stanton, michael@omega.lncc.br 1401 Description 1403 MTap is a tool for observing IP multicast packet traffic crossing a 1404 subnet, normally an Ethernet. 1406 Each packet sent to an IP multicast group address (class D) is 1407 captured, and information is extracted concerning its origin, its 1408 size, and so forth. This information is summarized, permitting the 1409 determination of the current network load resulting from multicast 1410 traffic. Apart from global summaries, traffic information is 1411 summarized by group and by source, permitting the determination of 1412 the contribution of each group and each individual sender to global 1413 traffic. The data recorded are as follows: number of multicast 1414 packets and total multicast bytes passing through the network, load 1415 level, and date and time of the last packet received. 1417 As well as processing packets sent to a multicast address, MTap also 1418 records separately multicast packets encapsulated in point-to-point 1419 packets. Thus we can also deal with traffic in DVMRP tunnels between 1420 multicast routers, and tunnel traffic data are recorded in the same 1421 way as for a group. 1423 As well as recording the data. MTap also permits that individual 1424 packet data be exhibited in dump format at capture time, both for 1425 multicast packets and for tunneled packets. 1427 In order to evaluate the impact which a group imposes on a 1428 subnetwork, MTap can enter or leave a multicast group, using the IGMP 1429 protocol. Thus traffic can be observed for a group which has no other 1430 members on the subnetwork. 1432 In addition to passively observing and recording multicast traffic, 1433 MTap has a notification mechanism, which sets off an alarm whenever 1434 user-specified load levels are exceeded, either globally, by group or 1435 by tunnel. Notifications are also logged in a dedicated window. 1437 Example 1439 Further information on Mtap will be available from: 1440 http://www.inf.puc-rio.br/~michael/GERENTE/tools 1442 Facilities used 1444 Berkeley Packet Filter (BPF) 1446 Availability 1448 MTap uses a window-based user interface, developed using Tcl/Tk, and 1449 captures packets through the Berkeley Packet Filter (BPF). It can 1450 thus be ported to different platforms. 1452 Mtap, which is still under development, has been ported to Linux and 1453 Solaris; minor problems related to packet capture have still to be 1454 resolved for the Solaris version. When it is released, it will be 1455 available from: 1456 http://www.inf.puc-rio.br/~michael/GERENTE/tools 1458 7. References 1460 [1] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, 1461 IPv6 and OSI", RFC 2030, October 1996. 1463 [2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 1464 2236, November 1997. 1466 [3] McCloghrie, K., Farinacci, D., Thaler, D., "Internet Group 1467 Management Protocol MIB", Internet draft (work in progress), draft- 1468 ietf-idmr-igmp-mib-10.txt, June 1999. 1470 [4] Handley, M., Jacobson, V., "SDP: Session Descripton Protocol 1471 (Version 1)", RFC 2327, April 1998. 1473 [5] McCloghrie, K., Farinacci, D., Thaler D., "IP Multicast Routing 1474 MIB", Internet draft (work in progress), draft-ietf-idmr-multicast- 1475 routmib-10.txt, July 1999. 1477 [6] McCloghrie, K., Farinacci, D., Thaler, D., "Protocol Independent 1478 Multicast MIB", Internet draft (work in progress), draft-ietf-idmr- 1479 pim-mib-07.txt, July 1999. 1481 [7] Thaler, D., "Distance Vector Multicasting Routing Protocol MIB", 1482 Internet draft (work in progress), draft-thaler-dvmrp-mib-09.txt, 1483 May 1998. 1485 [8] Fenner, W., Casner, S., "A "traceroute" facility for IP Multicast", 1486 Internet draft (work in progress), draft-ietf-idmr-traceroute- 1487 ipm-05.txt, June 1999. 1489 [9] Rekhter, Y. et al., "Address Allocation for Private Internets", RFC 1490 1918, February, 1996. 1492 8. Security Considerations 1494 SNMP-based monitoring tools require that the manager be provided access 1495 to the relevant MIBs. In order to limit security risks, such access will 1496 typically be provided on a selective basis. For example, the 1497 authentication and access control facilities in SNMP v3 can be used to 1498 limit access to authorized users. 1500 MBONE-mapping tools such as map-mbone should be used with care since in 1501 flooding mode they can result in excessive load on multicast routers. 1503 Through use of RTP monitoring tools, it may be possible to obtain 1504 sensitive information on user viewing habits. In order to protect 1505 against this, encryption technologies such as IPSEC can be used to 1506 provide confidentiality. 1508 9. Acknowledgments 1510 Thanks to Karl Auerbach for the description of the Dr. Watson tool, and 1511 to Michael Stanton for the description of the Mtap tool. 1513 10. Authors' Addresses 1515 Dave Thaler 1516 Microsoft Corporation 1517 One Microsoft Way 1518 Redmond, WA 98052 1520 Phone: 425-703-8835 1521 EMail: dthaler@microsoft.com 1523 Bernard Aboba 1524 Microsoft Corporation 1525 One Microsoft Way 1526 Redmond, WA 98052 1527 Phone: 425-936-6605 1528 EMail: bernarda@microsoft.com 1530 11. Full Copyright Statement 1532 Copyright (C) The Internet Society (2000). All Rights Reserved. 1533 This document and translations of it may be copied and furnished to 1534 others, and derivative works that comment on or otherwise explain it or 1535 assist in its implmentation may be prepared, copied, published and 1536 distributed, in whole or in part, without restriction of any kind, 1537 provided that the above copyright notice and this paragraph are included 1538 on all such copies and derivative works. However, this document itself 1539 may not be modified in any way, such as by removing the copyright notice 1540 or references to the Internet Society or other Internet organizations, 1541 except as needed for the purpose of developing Internet standards in 1542 which case the procedures for copyrights defined in the Internet 1543 Standards process must be followed, or as required to translate it into 1544 languages other than English. The limited permissions granted above are 1545 perpetual and will not be revoked by the Internet Society or its 1546 successors or assigns. This document and the information contained 1547 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1548 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1549 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1550 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1551 WARRANTIES OF 1553 12. Expiration Date 1555 This memo is filed as , and expires July 1556 1, 2001.