idnits 2.17.1 draft-ietf-mboned-mdh-04.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. 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 929 has weird spacing: '... Show the c...' == Line 931 has weird spacing: '... Show the I...' == Line 934 has weird spacing: '... scoped bound...' == Line 935 has weird spacing: '...eighbor table...' == Line 942 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 (7 May 2000) is 8755 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '2' on line 1462 looks like a reference -- Missing reference section? '9' on line 1488 looks like a reference -- Missing reference section? '8' on line 1484 looks like a reference -- Missing reference section? '1' on line 1459 looks like a reference -- Missing reference section? '3' on line 1465 looks like a reference -- Missing reference section? '4' on line 1469 looks like a reference -- Missing reference section? '5' on line 1472 looks like a reference -- Missing reference section? '6' on line 1476 looks like a reference -- Missing reference section? '7' on line 1480 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBONE Deployment Working Group Dave Thaler 2 INTERNET-DRAFT Microsoft 3 Category: Informational Bernard Aboba 4 Microsoft 5 7 May 2000 7 Multicast Debugging Handbook 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. Internet- 17 Drafts are draft documents valid for a maximum of six months and may be 18 updated, replaced, or obsoleted by other documents at any time. It is 19 inappropriate to use Internet-Drafts as reference material or to cite 20 them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 To view the list Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 2. Copyright Notice 30 Copyright (C) The Internet Society (2000). All Rights Reserved. 32 3. Abstract 34 This document serves as a handbook for the debugging of multicast 35 connectivity problems. In addition to reviewing commonly encountered 36 problems, the draft summarizes publicly distributable multicast 37 diagnostic tools, and provides examples of their use, along with 38 pointers to source and binary distributions. 40 4. Introduction 42 In order to deploy multicast on a large scale, it is necessary for 43 Network Operations Centers, support personnel and customers to be able 44 to diagnose problems. Over the years a number of tools have been 45 developed that can assist in the diagnostic process. This document 46 serves as a handbook for the debugging of multicast connectivity 47 problems. In addition to reviewing commonly encountered problems, the 48 draft summarizes publicly distributable multicast diagnostic tools, and 49 provides examples of their use, along with pointers to source and binary 50 distributions. 52 5. Usage scenarios 54 Multicast diagnostic tools are typically employed in one of the 55 following settings: 57 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 58 | | | 59 | Customer service or | SDR | 60 | support | mtrace | 61 | | RTPmon | 62 | | Dr. Watson | 63 | | | 64 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 65 | | | 66 | | SDR | 67 | | mrinfo | 68 | Network or system | netstat | 69 | administrator | mconfig | 70 | | mstat | 71 | | mtrace | 72 | | RTPmon | 73 | | tcpdump | 74 | | Dr. Watson | 75 | | Duppkts | 76 | | mrouted.dump, mrouted.cache | 77 | | | 78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 79 | | | 80 | | SDR | 81 | | mrtree | 82 | | map-mbone | 83 | Network Operations | MVIEW | 84 | Center | Multicast heartbeat | 85 | | mwatch and mcollect | 86 | | asn | 87 | | asname | 88 | | | 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 5.1. Customer service and support 93 ISPs offering multicast services are likely to encounter the following 94 classes of customer questions: 96 Session announcement problems 97 Reception problems 98 Multicast router problems 100 Below we discuss how each of these types of problems may be diagnosed. 102 5.1.1. Session announcement problems 104 Session announcement questions are those which relate to the user's 105 session announcement software. Sample complaints include: 107 No conferences were visible in the session announcement tool 108 Conference X was not visible in the session announcement tool 109 I can see conferences when dialed into POPA, but not POPB 110 I can receive conferences listed in SDR, but sometimes when I join 111 conferences via a Web site, I cannot receive them. 113 Session announcement questions are typically investigated via the 114 following procedure: 116 1. If only a specific session announcement is missing, check the 117 session announcement from somewhere where it is being received, and find 118 the group(s) and ports that the session utilizes, as well as the source 119 IP addresses. If the problem is with all session announcements, find 120 the information on any current session announcement which should be seen 121 by the user. 123 2. Find out the user's IP address, if known, and the POP dialed into or 124 router connected to. One way to determine the user's router given their 125 IP address is to mtrace or traceroute to their address. 127 3. Do an mtrace between the session announcement's origin and the 128 receiver on the sap.mcast.net group. If the mtrace succeeds, note any 129 hops showing loss. 131 4. If the mtrace never gets past the receiver itself, check the NASes 132 or routers with mstat -l to see if the relevant group has been joined. 133 If not, the problem is probably with the receiver's host. Ask the user 134 to check with Dr. Watson or a sniffer to see if the router is sending 135 IGMP membership queries, and if the host is responding with membership 136 reports and if so, what versions are being used. 138 5. If the sap.mcast.net group has been joined, but the mtrace failed, 139 the problem is likely a multicast routing problem (see section 4.1.3). 141 6. If the mtrace succeeded, and one hop shows 100% loss, compare the 142 output with the TTL of the session announcement. Users may download 143 session descriptions from Web sites that they may not be in the position 144 to receive, due to site or regional scoping. The loss may also be the 145 result of a scoped boundary separating the originator and the receiver, 146 which will also be indicated as such by mtrace. 148 7. Otherwise, if the mtrace succeeded, look for hops showing non- 149 negligible loss. These typically denote points of congestion (see 150 section 4.3.1). Note that if rate-limiting is installed on these 151 congested links, session announcements are often lost since SAP traffic 152 is given lower priority. 154 8. If all else fails, request a network sniff from the user, and check 155 whether it shows traffic to sap.mcast.net, and if so, from what sources, 156 and what is being announced. 158 5.1.2. Reception problems 160 Reception questions are those where the user has successfully received 161 the session announcement, but was unable to receive one or more media 162 streams for the session joined. Sample complaints include: 164 I joined conference X, but nothing happened 165 I joined conference X, got video but no audio 166 I joined conference X, and got intermittent audio 167 I can't see source X, but source X can see me (or vice versa) 169 Reception questions are typically investigated via the following 170 procedure: 172 1. Check the session announcement, find the group(s) and ports that the 173 session utilizes, as well as the source IP addresses. 175 2. Find out the user's IP address, if known, and the POP dialed into or 176 router connected to. One way to determine the user's router given their 177 IP address is to mtrace or traceroute to their address. 179 3. Check if the user is sending RTCP reports with RTPmon, and if so, 180 what the loss rate is. 182 4. Do an mtrace between the source and the receiver on the relevant 183 group. If the mtrace succeeds, note any hops showing loss. 185 5. If the mtrace never gets past the receiver itself, check the NASes 186 or routers with mstat -l to see if the relevant group has been joined. 187 If not, the problem is probably with the receiver's host. Check with 188 Dr. Watson to see if the router is sending IGMP membership queries, and 189 if the host is responding with membership reports and if so, what 190 versions are being used. 192 6. If the relevant group has been joined, but the mtrace failed, the 193 problem is likely a multicast routing problem (see section 4.1.3). 195 7. If the mtrace succeeded, and one hop shows 100% loss, compare the 196 output with the TTL of the session announcement. The user may not be in 197 a position to receive data from the source, due to site or regional 198 scoping. The loss may also be the result of a scoped boundary 199 separating the source and the receiver, which will also be indicated as 200 such by mtrace. 202 8. Otherwise, if the mtrace succeeded, look for hops showing non- 203 negligible loss. These typically denote points of congestion (see 204 section 4.3.1). 206 9. If all else fails, request a network sniff from the user, and check 207 whether it shows traffic to the relevant group, and if so, from what 208 sources. 210 Other reception complaints include: 211 When I join my first conference, it works great. But then when I quit 212 that and join another one, it doesn't work anymore. 214 Why is my modem light is still flashing even after I've quit SDR and 215 VIC? 217 Such problems are often IGMP-related problems observed by a user 218 connecting to the network using a host which is running a TCP/IP stack 219 implementing IGMP v1. Such users will experience long leave latencies, 220 with resulting poor reception and/or performance of other applications. 221 Such problems can be distinguished from ordinary reception problems in 222 that they typically do not occur for the first session joined, only for 223 subsequent sessions. The solution consists of upgrading the user to an 224 IGMP v2-capable stack. IGMP is described in [2]. 226 IGMP-related questions are typically investigated by the following 227 procedure: 229 1. Obtain the vendor and version of the user's TCP/IP stack. Determine 230 whether this stack is IGMP v2-enabled. 232 2. Ask the user to run Dr. Watson or a network sniffer and to indicate 233 whether IGMP queries are being seen, whether responses are being sent, 234 and if so, what version. 236 5.1.3. Multicast router problems 238 Multicast router questions are those which relate to the setup of a 239 multicast router. Sample complaints include: 241 I can get video and audio when online with ISDN, but not with a 242 modem, or vice versa. 244 I can't bring up a DVMRP tunnel to my site. Why not? 246 My router works great. Why can't I get multicast? 248 Why can't I source multicast? 250 Multicast routing questions are typically investigated via the following 251 procedure: 253 1. Ask the user what the router vendor is, and what software version 254 they have running. Attempt to verify this information using mrinfo or 255 mstat. 257 2. Check whether this vendor and version supports multicast routing, and 258 whether an upgrade to a later version is recommended. 260 3. Ask for a copy of the router configuration file. 262 4. Check whether the user has NAT enabled; this is incompatible with 263 most multicast routing protocols, and so should be switched off. 265 5. Find out the user's IP address(es), or if not known, the POP dialed 266 into or router connected to. 268 6. Check the loss rate and connectivity by doing an mtrace from various 269 sources to the user's IP address. 271 7. Check the user's router with mstat -l to see if it has joined any 272 multicast groups, and check upstream routers to see if they are 273 subscribed to any groups. 275 8. When all else fails, request a network sniff and examine it to 276 determine what multicast routing protocols are being run, if any. 278 5.2. Network Operations Center 280 A Network Operations Center (NOC) will typically receive a complaint 281 after it has been investigated by customer support and determined to be 282 a network-related issue. Although it is desirable for customer support 283 to have performed the diagnostic tests described above, if this has not 284 been done, NOC personnel will need to perform the tests themselves to 285 isolate the cause of the problem. If the proper systems have been 286 installed, in most cases, the NOC will already have been alerted to the 287 problem prior to receiving referrals from customer support. The 288 following diagnostic procedures are recommended: 290 1. Regularly generate summaries based on RTCP receiver and sender 291 reports, using RTP monitoring tools. Sample reports may include average 292 loss rates experienced during sessions, or users whose loss rates exceed 293 a particular threshold. 295 2. Determine the source of the problems by doing mtraces between the 296 sources and the receivers. 298 3. On a network monitoring station, keep track of the functioning of 299 multicast-enabled hardware, either by doing periodic mtraces, or by 300 using a heartbeat monitor to receive SNMP traps from equipment losing 301 the heartbeat. 303 4. In order to keep track of group topologies, use mapping tools such as 304 map-mbone, MVIEW, or mrtree, along with autonomous system mapping tools 305 such as asn and asname. 307 5.3. Network or system administrator 309 The NOC will escalate network engineering problems to network engineers 310 and system administrators if their intervention is required. In order to 311 understand the origin of the problem and repair it, it is necessary to 312 diagnose the operations of individual systems and routers using router 313 and system diagnostics such as netstat, mrinfo, mstat, mconfig, RTPmon, 314 and mtrace, as well as network analysis tools such as tcpdump or Dr. 315 Watson. 317 In smaller installations the network engineer or system administrator 318 often doubles as customer support and network operations guru, in which 319 case problems may be escalated without any triage (our condolences). 321 Typical classes of problems encountered by network engineers and system 322 administrators include: 324 Congestion and rate-limiting problems 325 Multicast routing problems 327 5.3.1. Congestion and rate limiting problems 329 Congestion and rate limiting problems result in high packet loss with 330 subsequent loss of session announcements and decrease in quality of 331 audio and video. These problems may be investigated via the following 332 procedure: 334 1. Use RTPmon to check for receivers experiencing packet loss. 336 2. Do an mtrace from the source to the receiver on the relevant group in 337 order to locate the problematic hops. 339 3. Do an mtrace in the opposite direction to help distinguish whether 340 the problem is with the router or the link at that hop. 342 4. If the reverse mtrace shows similar loss at an hop adjacent to the 343 lossy hop in the forward mtrace, odds are that the intermediate router 344 is overloaded. Use mrinfo to check the fanout on the router. 345 Overloaded routers are often the result of having too many tunnels. 347 5. If the reverse mtrace shows no problems near that hop, indicating 348 that loss is one-way, then check the router on the upstream end of the 349 link with mstat -nv to see if it has a rate-limit set on the link, and 350 if the link traffic is near that limit. 352 6. If the reverse mtrace shows loss over the same link, the problem is 353 likely to be link congestion. Use mstat -nv to see how much bandwidth 354 is being used by multicast traffic. (If mstat fails, running an mtrace 355 with the -T option may help to confirm link congestion, although the 356 statistics can be misleading.) 358 7. If a congested link is suspected, but mstat failed, another indicator 359 can be obtained by doing an mtrace from the session announcer to the 360 destination on other groups joined by the receiver, such as the SAP 361 group, and comparing loss statistics. 363 8. Check for unicast packet loss over the link using ping. Multicast 364 (but not unicast) packet loss on a link with a rate limit is an 365 indication that the link's multicast rate limit should be raised or 366 eliminated entirely. Packet loss on a link without rate limiting is an 367 indication of congestion. On such links it may be desirable to add a 368 rate limit. Since DVMRP prunes are currently not retransmitted by most 369 routers, prunes may be lost if no rate limit exists, which may further 370 worsen the congestion problem. 372 9. Use mstat -gR to see whether a single group is using an inordinate 373 amount of the link bandwidth. If so, use mstat to see whether a single 374 source to that group is using an inordinate amount of the link 375 bandwidth. If so, attempt to contact the source (contact information 376 may be available in the session announcement). 378 5.3.2. Multicast routing problems 380 Multicast routing problems include: 382 Duplicate packets 383 Injection of bogus routes (typically into DVMRP) 384 Redistribution of unicast routes (via BGP or an IGP) into DVMRP 385 Non-pruning routers 387 Duplicate packets are a symptom of routing loops. This problem may be 388 investigated via the following procedure: 390 1. Use a program such as Duppkts to detect duplicate packets. 392 2. Use a network monitor or RTPmon to find the sources and receivers on 393 the group. 395 3. Do an mtrace from the source(s) to the receivers in order to find 396 the loop. Duplicates will also show up in mtrace output as hops with 397 negative loss. 399 Bogus route injection problems may be investigated via the following 400 procedure: 402 1. Dump the DVMRP routing table. The routing table may be examined 403 remotely via mstat using the -r options, or locally (for mrouted) by 404 sending the USR1 signal to mrouted, generating the /var/tmp/mrouted.dump 405 file. 407 2. Check the table for bogus routes (known as "martians"). Bogus routes 408 include addresses reserved for use by private internets, as described in 409 [9]. These routes include 10/8, 172.16/12, or 192.168/16, or more 410 specific routes within these regions. Injecting a default route into 411 the DVMRP backbone is also considered to be a bogus 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 number 417 of unicast routes (25K+) into DVMRP. The problem may be investigated via 418 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 site 427 is likely to be the problem. One way to check this is to mtrace to 428 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 also 432 wish to set "route-hog notification" at 5000 routes. 434 Non-pruning DVMRP routers are those which maintain groups in the 435 multicast routing table although there are no downstream subscribers. 436 The problem can be solved via the following procedure: 438 1. Check the router version number using mstat or mrinfo. Non-pruning 439 routers include mrouted versions prior to 3, Cisco Systems IOS prior to 440 version 11.0(3), and Bay Networks implementations prior to 9.0. 442 2. Confirm lack of pruning as follows. First, dump the multicast 443 forwarding table. This can be done remotely with mstat -N, or locally 444 (for mrouted) by sending the USR2 signal to mrouted, generating the 445 /var/tmp/mrouted.cache file. 447 3. Check the forwarding table to see if an interface is in the outgoing 448 interface list for every entry in the multicast forwarding table. If 449 so, it is likely that a non-pruner lies downstream in that direction. 451 4. You can confirm the existence of a non-pruner by creating a 452 temporary, unadvertised, session and sending (preferably with a low data 453 rate) data to that group. After a few moments, dump the forwarding 454 table again. If any interfaces appear in the outgoing interface list of 455 the entry for your test stream, then non-pruners lie in those 456 directions. 458 5. If a non-pruner exists downstream, use mrtree to follow the path of 459 the data downstream to the non-pruning router(s). 461 6. If your router supports it, enable the reject non-pruners option. If 462 not, and the unpruned interface is a tunnel, consider disabling the 463 tunnel. 465 6. Appendix - Multicast Diagnostic Tools 467 6.1. Types of tools 469 Multicast diagnostic tools typically fall into the following categories: 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | | | 473 | RTP monitoring tools | RTPmon | 474 | | Msessmon | 475 | | RTPquality | 476 | | RTPdump | 477 | | RTPcast/RTPlisten | 478 | | Duppkts | 479 | | | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | | | 482 | | mrinfo | 483 | Multicast router | netstat | 484 | diagnostics | mconfig | 485 | | mstat | 486 | | mrouted.dump, mrouted.cache | 487 | | | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | | | 490 | Multicast traceroute | mtrace | 491 | | | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | | | 494 | | mrtree | 495 | | map-mbone | 496 | MBONE mapping tools | asn | 497 | | asname | 498 | | mcollect & mwatch | 499 | | | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | | | 502 | NOC tools | MVIEW | 503 | | Multicast heartbeat | 504 | | | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | | | 507 | Network analysis | tcpdump | 508 | tools | Dr. Watson | 509 | | | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 RTP monitoring tools are used to monitor the transmission quality and 513 popularity of individual sessions. Multicast router diagnostics are used 514 to obtain information on the configuration and state of multicast 515 routers. MBONE mapping tools are used to map out the topology for a 516 particular group. These tools can show the topology at the level of 517 individual systems, or at the level of autonomous system connections. 518 Multicast traceroute tools are used to trace the path between a source 519 and destination. Network Operations Center tools are used to monitor the 520 state of network devices within an autonomous system. Network analysis 521 tools (such as tcpdump and Dr. Watson) are used to analyze traffic on 522 the network. 524 6.2. Facilities utilized 526 Multicast diagnostic tools typically rely on one or more of the 527 following facilities: 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | | | 531 | RTCP source and | RTPmon | 532 | receiver reports | Msessmon | 533 | | RTPquality | 534 | | RTPdump | 535 | | RTPcast/RTPlisten | 536 | | Duppkts | 537 | | | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | | | 540 | | multicast heartbeat | 541 | SNMP MIBs | mconfig | 542 | | mstat | 543 | | MVIEW | 544 | | mrtree | 545 | | | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | | | 548 | IGMP trace facility | mtrace | 549 | | | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | | | 552 | | mrinfo | 553 | | mrtree | 554 | IGMP ASK_NEIGHBORS | map-mbone | 555 | message (DVMRP) | | 556 | | | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | | | 559 | Routing arbiter and | asn | 560 | WHOIS Databases | asname | 561 | | | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | | | 564 | Internal structures | tcpdump | 565 | | netstat | 566 | | mrouted.dump, mrouted.cache | 567 | | | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Tools using RTCP reports analyze RTCP source and receiver reports, 571 providing information on packet loss, inter-arrival jitter, bandwidth 572 availability, or listenership. These tools therefore will only work with 573 RTP implementations which support RTCP reporting. Tools using SNMP MIBs 574 perform queries for variables in the IGMP, multicast routing, DVMRP, and 575 PIM MIBs. As a result, these tools depend on implementation of the 576 relevant SNMP MIBs in the network devices that are being monitored. 577 Tools based IGMP ASK_NEIGHBORS messages use these messages to map 578 portions of the MBONE, and thus will only work with routers implementing 579 DVMRP. Tools based on IGMP tracing perform a multicast traceroute. These 580 tools are typically only useful in cases where multicast routers along 581 the path have a route back to the source. 583 Diagnostic tools may use more than one of these facilities. For example, 584 mstat makes use of SNMP MIBs, as well as the IGMP ASK_NEIGHBORS 585 facility. 587 6.3. RTP monitoring tools 589 This class of tools provides information required to monitor the 590 performance of RTP-based applications. 592 6.3.1. RTPmon 594 Authors 596 David Bacher, Andrew Swan, and Lawrence A. Rowe 597 {drbacher,aswan,rowe}@cs.berkeley.edu 598 Computer Science Division - EECS 599 University of California 600 Berkeley, CA 94720-1776 602 Description 604 RTPmon allows network administrators or support personnel to monitor 605 listenership as well as session quality experienced by subscribers. 606 The tool also facilitates tracing the cause of problems resulting in 607 quality degradation. To accomplish this task, RTPmon summarizes and 608 analyzes information provided by RTCP source and receiver reports. 610 Receivers are displayed for a given sender in the form of a 611 spreadsheet, with cells being filled in with metrics such as packet 612 loss rate or jitter. Clicking on a cell displays a stripchart of 613 statistics on packet loss rate, smoothed packet loss rate and jitter. 614 From the stripchart it is possible to launch an mtrace between the 615 sender and the receiver, a convenient way of diagnosing network 616 problems along the multicast distribution path. Clicking on a 617 receiver or sender displays summary information. 619 For groups with large memberships, the display may be limited to 620 members surpassing a given threshold in packet loss rate or jitter. 621 Using RTPmon it is possible to sort receivers for a given sender 622 according to maximum or average loss. 624 Further information is available in the RTPmon man page. 626 Example 628 For examples and further information, see the rtpmon man page, or: 629 http://bmrc.berkeley.edu/~drbacher/projects/mm96-demo/ 631 Facilities used 633 RTCP source and receiver reports 634 IGMP multicast trace (if installed) 636 Availability 638 RTPmon is available for UNIX and may be obtained from: 639 ftp://mm-ftp.cs.berkeley.edu/pub/rtpmon/ 641 Bug reports and suggestions should be sent to: 642 rtpmon@bmrc.berkeley.edu. 644 6.3.2. RTPcast/RTPlisten, RTPquality, Duppkts, RTPdump, RTPtools, 645 Msessmon, Mpoll 647 Author 648 Mpoll: Andrew Patrick 650 Description 652 RTPcast listens to RTCP receiver reports and forwards data to another 653 multicast group; RTPlisten then listens to that group. RTPdump 654 listens for, and dumps RTP and RTCP packets. Duppkts listens on a 655 multicast group and port, and reports the number of packets received 656 and lost, as well as the number of duplicates. RTPquality listens to 657 RTCP receiver reports and writes data on packet loss, as well as late 658 and non-sequenced packets. RTPtools allows recording and playback of 659 RTP sessions. Msessmon provides a routemap of participants in RTP 660 conferences as well as stripcharts of statistics on RTP packet loss 661 and jitter. Mpoll is a survey collection tool that can be used to 662 collect quality ratings during multicast sessions. 664 Example 666 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 679 Source code for RTPquality is available from: 680 ftp://sauce.uio.no/mice-nsc/util/rtp/rtpqual.c 682 Source code for RTPdump is available at: 683 ftp://sauce.uio.no/mice-nsc/util/rtpdump-1.0.tar.gz 685 Source code for RTPtools is available at: 686 ftp://sauce.uio.no/mice-nsc/util/rtptools/rtptools-1.9.tar.gz 688 Source and binaries for Msessmon is available at: 689 ftp://sauce.uio.no/mice-nsc/util/msessmon/ 691 Source and binaries for Mpoll is available at: 692 ftp://sauce.uio.no/mice-nsc/util/mpoll/ 694 6.4. Multicast router diagnostics 696 This class of tools facilitates monitoring and management of multicast 697 routers. 699 6.4.1. mrouted.dump, mrouted.cache 701 Author 703 Bill Fenner, fenner@research.att.com 705 Description 707 Sending the USR1 signal to mrouted dumps the internal routing table 708 to /var/tmp/mrouted.dump; sending the USR2 signal dumps the 709 forwarding cache to /var/tmp/mrouted.cache. 711 Further information on mrouted and the mrouted.dump and mrouted.cache 712 file formats is available in the mrouted man page. 714 Example 715 % cat mrouted.dump 716 vifs_with_neighbors = 2 718 Virtual Interface Table 719 Vif Name Local-Address M Thr Rate Flags 720 0 ed0 128.31.107.1 subnet: 128.31.107/24 1 1 0 querier 721 peers: 128.31.107.249 (3.8) (0xe) 722 groups: 239.109.100.200 723 224.0.0.2 724 224.0.0.4 725 pkts in : 4075 726 pkts out: 0 728 1 ed0 128.31.107.1 tunnel: 204.67.107.11 1 32 500 729 peers: 204.67.107.11 (11.2) (0x1a) 730 pkts in : 0 731 pkts out: 2359 733 Multicast Routing Table (3801 entries) 734 Origin-Subnet From-Gateway Metric Tmr In-Vif Out-Vifs 735 207.10.165.51/32 128.31.107.249 10 20 0 1 736 207.10.165.50/32 128.31.107.249 10 20 0 1 737 206.172.195.32/32 128.31.107.249 9 20 0 1 738 172/8 128.31.107.249 10 20 0 1 739 ... 741 % cat mrouted.cache 742 Multicast Routing Cache Table (198 entries) 743 Origin Mcast-group CTmr Age Ptmr IVif Forwvifs 744 131.107.2.139/32 224.0.12.0 58s 7m - -1 745 >131.107.2.139 746 143.107.103.0/27 224.0.1.1 3m 2m 3m 0P 747 >143.107.103.5 748 128.232/16 224.0.1.1 4m 7m 4m 0P 749 >128.232.2.209 750 157.161/16 224.0.1.1 67s 6m - 0 1 751 >157.161.114.2 752 206.152.163/24 224.0.1.15 74s 7m - 0 1 753 >206.152.163.21 754 4.0.0.34/32 224.0.1.32 56s 4m 25s 0P 1p 755 >4.0.0.34 756 137.39.2.254/32 224.0.1.32 3m 5m - 0 1 757 >137.39.2.254 758 137.39.43.32/30 224.0.1.32 38s 5m - 0 1 759 >137.39.43.34 760 ... 762 Facilities used 764 Internal facilities (forwarding cache and routing table) 766 Availability 768 The SNMP-capable mrouted distribution is available at: 769 ftp://ftp.merit.edu/net-research/mbone/mirrors/mrouted/ 771 6.4.2. mrinfo 773 Author 775 Van Jacobson, van@ee.lbl.gov 777 Description 779 mrinfo displays information about a multicast router; to do this, it 780 uses the IGMP ASK_NEIGHBORS message to discover the router's physical 781 and virtual interfaces. Routers are also queried for their version 782 number, and if this query is successful, for their metrics, 783 thresholds, and flags. Results are printed in an indented list format 784 similar to that for map-mbone. 786 Example 788 % mrinfo 192.80.214.199 789 192.80.214.199 (collegepk-mbone1.bbnplanet.net) [version 11.2,prune,mtrace,snmp]: 790 128.167.252.196 -> 0.0.0.0 (local) [1/0/pim/querier/leaf] 791 192.80.214.199 -> 0.0.0.0 (local) [1/0/pim/querier/leaf] 792 192.41.177.196 -> 0.0.0.0 (local) [1/0/pim/querier/down/leaf] 793 128.167.252.196 -> 128.167.254.165 (devo.sura.net) [1/32/tunnel/querier/down/leaf] 794 128.167.252.196 -> 131.119.0.197 (paloalto-mbone1.bbnplanet.net) 795 [1/64/tunnel/pim/querier] 796 128.167.252.196 -> 199.94.207.2 (cambridge1-mbone1.bbnplanet.net) 797 [1/32/tunnel/pim/querier] 798 128.167.252.196 -> 137.39.43.34 (MBONE1.UU.NET) [1/32/tunnel/querier] 799 128.167.252.196 -> 192.41.177.199 (wtn-ms2.bbnplanet.net) [1/16/tunnel/querier] 800 128.167.252.196 -> 128.244.93.3 (sage.jhuapl.edu) [1/32/tunnel/querier] 801 128.167.252.196 -> 192.221.34.22 (cdrn.bbnplanet.net) [1/32/tunnel/querier] 802 128.167.252.196 -> 128.167.1.197 (cpk-ms1.ser.bbnplanet.com) [1/16/tunnel/querier] 803 128.167.252.196 -> 134.205.93.150 (dilbert.sam.pentagon.mil) [1/32/tunnel/querier] 804 128.167.252.196 -> 192.221.48.234 (atlanta3-mbone1.bbnplanet.net) 805 [1/64/tunnel/pim/querier] 806 128.167.252.196 -> 204.167.201.38 (dallas2-mbone1.bbnplanet.net) 807 [1/64/tunnel/pim/querier] 808 128.167.252.196 -> 205.130.85.3 (philipii.nap.edu) [1/32/tunnel/querier/down/leaf] 809 128.167.252.196 -> 128.175.13.36 (pfet.nss.udel.edu) [1/32/tunnel/querier/down/leaf] 810 128.167.252.196 -> 192.41.177.197 (wtn-ms1.bbnplanet.net) [1/32/tunnel/querier] 811 128.167.252.196 -> 204.148.62.28 (mbone-e.ans.net) [1/32/tunnel/querier] 812 128.167.252.196 -> 205.128.246.2 (usnrctc.bbnplanet.net) [1/32/tunnel/pim/querier] 814 Facilities used 816 IGMP ASK_NEIGHBORS message (DVMRP) 818 Availability 820 mrinfo is available for UNIX and is included in the SNMP-capable 821 mrouted distribution, available at: 822 ftp://ftp.merit.edu/net-research/mbone/mirrors/mrouted/ 824 mrinfo is also available in the MVIEW distribution, available at: 825 ftp://ftp.merit.edu/net-research/mbone/mview/ 827 6.4.3. netstat 829 Author 831 Unknown 833 Description 835 On multicast-enabled systems, netstat is typically extended so as to 836 provide information on virtual interfaces and the multicast 837 forwarding cache (-g option), as well as multicast routing statistics 838 (-gs option), and igmp behavior (-s option). 840 Example 842 %netstat -g 844 Virtual Interface Table 845 Vif Thresh Rate Local-Address Remote-Address Pkts-In Pkts-Out 846 0 1 0 128.15.2.120 16323 385 847 1 32 512 128.15.2.120 202.34.126.2 2 0 849 Multicast Forwarding Cache 850 Origin Group Packets In-Vif Out-Vifs:Ttls 851 128.15.2.120 224.2.195.166 281 0 852 128.15.1.110 239.100.101.223 1660 0 853 128.15.1.135 238.27.27.1 1660 0 854 128.15.1.110 239.111.111.235 1660 0 855 ... 857 %netstat -gs 858 multicast forwarding: 859 182880 multicast forwarding cache lookups 860 8237 multicast forwarding cache misses 861 6736 upcalls to mrouted 862 193 upcall queue overflows 863 5567 upcalls dropped due to full socket buffer 864 177 cache cleanups 865 7234 datagrams with no route for origin 866 0 datagrams arrived with bad tunneling 867 0 datagrams could not be tunneled 868 954 datagrams arrived on wrong interface 869 0 datagrams selectively dropped 870 0 datagrams dropped due to queue overflow 871 0 datagrams dropped for being too large 873 %netstat -s 874 ip: 875 3807182 total packets received 876 0 bad header checksums 877 ... 878 icmp: 879 40 calls to icmp_error 880 0 errors not generated 'cuz old message was icmp 881 ... 882 igmp: 883 18504 messages received 884 0 messages received with too few bytes 885 48 messages received with bad checksum 886 2478 membership queries received 887 0 membership queries received with invalid field(s) 888 194 membership reports received 889 0 membership reports received with invalid field(s) 890 0 membership reports received for groups to which we belong 891 8510 membership reports sent 892 tcp: 893 10705 packets sent 894 5536 data packets (1532081 bytes) 895 ... 896 udp: 897 3104045 datagrams received 898 0 with incomplete header 899 ... 901 Facilities used 903 Netstat accesses system internal data structures in order to carry 904 out its function. 906 Availability 908 netstat is included with a variety of operating systems, including 909 UNIX, OS/2, and Windows. For further information, please consult the 910 netstat man page or documentation. 912 6.4.4. mstat 914 Author 916 Dave Thaler, dthaler@microsoft.com 918 Description 920 mstat is a general purpose tool for obtaining router configuration 921 and status information. In order to perform its task, mstat utilizes 922 SNMP MIBs (such as the IGMP, multicast routing, PIM, and DVMRP MIBs), 923 as well as ASK_NEIGHBORS IGMP messages. mstat displays the contents 924 of various MBONE-related data structures in various formats, 925 depending on the options selected. Options include: 927 -G Show the PIM group table 928 -I Show the PIM interface table. 929 -K Show the cached IP multicast route table; works for 930 all SNMP-capable routers. 931 -N Show the IP Multicast Next Hop Table. 932 -P Show the PIM neighbor table. 933 -a Show the alternate subnet table. 934 -b Show the scoped boundary table. 935 -d Show the DVMRP neighbor table. 936 -g Show the Group Summary table. 937 -i Show the DVMRP interface table; similar to an 938 mrinfo report. 939 -l Show the IGMP local group table. 940 -r Show the DVMRP routing table; similar to a portion of 941 the mrouted.dump file. 942 -t Show the DVMRP routing next hop table; similar to 943 another portion of the mrouted.dump file. 944 -v Show statistics corresponding to the DVMRP interface table. 946 Examples 948 % mstat 949 IP Multicast Route Table for bigco.com 950 Mcast-group Origin-Subnet InIf UpTime Tmr Pkts Bytes RpF Proto 951 NTP.MCAST.NET 0.0.0.0/32 0 245341 179 0 0 0 pim 952 NTP.MCAST.NET 128.232.0.49/32 7 206403 418 3056 293376 17 dvmrp 953 NTP.MCAST.NET 128.232.2.209/32 7 206403 417 3027 290592 19 dvmrp 954 NTP.MCAST.NET 143.107.103.5/32 7 592 218 3 228 3 dvmrp 955 NTP.MCAST.NET 157.161.114.2/32 7 27703 517 411 31236 11 dvmrp 956 IETF-2-VIDEO.MC 0.0.0.0/32 0 245349 175 0 0 0 pim 957 IETF-2-VIDEO.MC 206.152.163.21/32 7 242567 244 46887 4149336 3388 dvmrp 958 MTRACE.MCAST.NE 0.0.0.0/32 0 1690 177 0 0 0 pim 959 MTRACE.MCAST.NE 194.104.0.25/32 7 405 483 2 792 0 dvmrp 960 MTRACE.MCAST.NE 206.54.224.150/32 7 456 569 4 1072 4 dvmrp 961 CISCO-RP-DISCOV 0.0.0.0/32 0 245534 0 0 0 0 pim 962 224.0.14.1 203.15.123.99/32 4 17 161 0 0 0 dvmrp 963 224.0.92.3 171.68.201.39/32 4 174 4 0 0 0 dvmrp 964 224.2.0.1 13.2.116.11/32 4 150 26 0 0 0 dvmrp 965 224.2.0.1 128.32.38.218/32 4 147 30 0 0 0 dvmrp 966 224.2.2.1 205.226.8.183/32 4 146 30 0 0 0 dvmrp 967 224.2.20.165 13.2.116.11/32 4 55 119 0 0 0 dvmrp 968 224.2.100.100 13.2.116.11/32 4 87 91 0 0 0 dvmrp 969 SAP.MCAST.NET 164.67.63.7/32 4 114 64 1 855 0 dvmrp 970 SAP.MCAST.NET 193.61.212.130/32 4 153 23 1 868 0 dvmrp 971 SAP.MCAST.NET 199.94.220.184/32 4 26 152 1 416 0 dvmrp 972 SAP.MCAST.NET 206.154.213.242/32 4 156 19 1 360 0 dvmrp 973 ... 975 Examples of the many other options are provided in the mstat man pages. 977 Facilities used 979 PIM, DVMRP, IGMP, and multicast routing MIBs 980 IGMP ASK_NEIGHBORS message (DVMRP) 982 Availability 984 mstat is included in the SNMP-capable mrouted distribution, 985 available at: 986 ftp://ftp.merit.edu/net-research/mbone/mirrors/mrouted/ 988 mstat is also available in the MVIEW distribution, available at: 989 ftp://ftp.merit.edu/net-research/mbone/mview/ 991 6.4.5. mconfig 993 Author 995 Dave Thaler, dthaler@microsoft.com 997 Description 999 mconfig allows the user to display and (if the community string is 1000 known) to modify the configuration of a multicast router implementing 1001 the DVMRP MIB. 1003 Example 1005 For more information on mconfig, please see the man page. 1007 Facilities used 1009 DVMRP MIB 1011 Availability 1013 mconfig is available for UNIX and is included in the SNMP-capable 1014 mrouted distribution, available at: ftp://ftp.merit.edu/net- 1015 research/mbone/mirrors/mrouted/ 1017 6.5. Multicast traceroute 1019 6.5.1. mtrace 1021 Author 1023 Bill Fenner, fenner@research.att.com 1025 Description 1027 mtrace provides a facility by which to trace the path between a 1028 sender and a receiver of a particular group. This is particularly 1029 useful when used alongside a facility such as RTPmon, which allows 1030 you to identify problem source-receiver pairs. 1032 Note that the utility of mtrace is often limited by the multicast 1033 topology. Where multicast and unicast topologies are not aligned (as 1034 is the case in many multicast-enabled networks) mtrace may not 1035 function. 1037 For information on the details of the protocol, see reference [8]. 1039 Example 1041 % mtrace 131.243.73.36 128.15.1.250 224.2.195.166 1042 Mtrace from 131.243.73.36 to 128.15.1.250 via group 224.2.195.166 1043 Querying full reverse path... * switching to hop-by-hop: 1044 0 bigman.bigco.com (128.15.1.250) 1045 -1 * * littleman.bigco.com (128.15.1.249) DVMRP thresh^ 1 1046 -2 * * * seamr1-gw.nwnet.net (192.35.180.201) DVMRP thresh^ 32 1047 -3 * * seamr2-gw.nwnet.net (192.220.238.130) DVMRP thresh^ 0 1048 -4 * * mcast.cac.washington.edu (140.142.116.1) DVMRP thresh^ 32 1049 -5 * * * * dec3800-1-fddi-0.Sacramento.mci.net (204.70.164.29) didn't respond 1050 -6 * * * 1051 -7 * * 1052 Resuming... 1053 -5 dec3800-1-fddi-0.Sacramento.mci.net (204.70.164.29) DVMRP thresh^ 64 1054 -6 dec3800-2-fddi-0.SanFrancisco.mci.net (204.70.158.61) DVMRP thresh^ 1 1055 -7 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 64 1056 -8 * * llnl-mr2.es.net (134.55.12.229) DVMRP thresh^ 64 1057 -9 * * lbl-mr1.es.net (134.55.12.101) DVMRP thresh^ 8 1058 -10 * * mr1.lbl.gov (131.243.64.184) DVMRP thresh^ 32 1059 -11 * * ir40gw.lbl.gov (131.243.64.1) DVMRP thresh^ 0 1060 -12 * * irals.lbl.gov (131.243.128.6) PIM thresh^ 0 1061 -13 bl7-36.als.lbl.gov (131.243.73.36) 1062 Round trip time 74 ms; total ttl of 72 required. 1064 Waiting to accumulate statistics... Results after 10 seconds: 1066 Source Response Dest Overall Packet Statistics For Traffic From 1067 131.243.73.36 128.15.1.250 Packet 131.243.73.36 To 224.2.195.166 1068 v __/ rtt 77 ms Rate Lost/Sent = Pct Rate 1069 131.243.73.1 1070 131.243.128.6 irals.lbl.gov 1071 v ^ ttl 1 6 pps 0/60 = 0% 6 pps 1072 131.243.128.40 1073 131.243.64.1 ir40gw.lbl.gov 1074 v ^ ttl 2 13 pps 0/60 = 0% 6 pps 1075 131.243.64.184 mr1.lbl.gov 1076 v ^ ttl 35 9 pps 0/60 = 0% 6 pps 1077 198.128.16.13 1078 134.55.12.101 lbl-mr1.es.net 1079 v ^ ttl 35 0 pps 0/60 = 0% 0 pps 1080 134.55.12.229 llnl-mr2.es.net 1081 v ^ ttl 69 0 pps 1/60 = 2% 0 pps 1082 192.203.230.241 mbone.nsi.nasa.gov 1083 v ^ ttl 70 0 pps 0/59 = 0% 0 pps 1084 204.70.158.61 dec3800-2-fddi-0.SanFrancisco.mci.net 1085 v ^ ttl 70 0 pps 0/59 = 0% 0 pps 1086 204.70.164.29 dec3800-1-fddi-0.Sacramento.mci.net 1087 v ^ ttl 72 0 pps 0/59 = 0% 0 pps 1088 140.142.116.1 mcast.cac.washington.edu 1089 v ^ ttl 72 0 pps 0/59 = 0% 0 pps 1090 192.220.249.66 1091 192.220.238.130 seamr2-gw.nwnet.net 1092 v ^ ttl 72 0 pps 0/59 = 0% 0 pps 1093 192.220.238.129 1094 192.35.180.201 seamr1-gw.nwnet.net 1095 v ^ ttl 72 0 pps 0/59 = 0% 0 pps 1096 128.15.1.249 littleman.bigco.com 1097 v __ ttl 72 0 pps ?/59 0 pps 1099 128.15.1.250 128.15.1.250 1100 Receiver Query Source 1102 Facilities used 1104 IGMP multicast trace facility 1106 Availability 1108 mtrace is now distributed independently of mrouted. 1109 Source code is available from: 1110 ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mtrace5.1.tar.Z 1112 Binaries: 1113 ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mtrace5.1-sparc-sunos41x.tar.Z 1114 ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mtrace5.1-sparc-solaris2.tar.Z 1115 ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mtrace5.1-alpha-osf1.tar.Z 1116 ftp://ftp.parc.xerox.com/pub/net-research/ipmulti/mtrace5.1-sgi-irix.tar.Z 1118 6.6. MBONE mapping tools 1120 6.6.1. mrtree 1122 Author 1124 Dave Thaler, dthaler@microsoft.com 1125 Andy Adams, ala@merit.edu 1127 Description 1129 mrtree uses a combination of IGMP and SNMP queries to discover the 1130 actual and potential multicast (sub)trees for a given source and 1131 group, rooted at a given router. An actual tree, discovered using the 1132 multicast routing MIB, consists of routers which are currently 1133 forwarding multicast traffic to a group from a given source. A 1134 potential tree, discovered using the DVMRP MIB, is one which would 1135 exist if every host were a member of the group. 1137 Example 1139 % mrtree mbone.merit.edu 224.2.143.24 204.62.246.73 1140 Actual distribution tree rooted at mbone.merit.edu for group 224.2.143.24 1141 and source 204.62.246.73... 1142 0 mbone.merit.edu (198.108.2.20) [ver 3.8,prune,genid,mtrace], 1143 247390 pkts 1144 1 cujo.merit.edu (198.108.60.97) [ver 3.6,prune,genid,mtrace], 333448 1145 6 pkts (1347%) 1146 2 subnet: 198.108.60/24 1147 2 shockwave.merit.edu (198.108.60.69) [ver 3.8,prune,genid,mtrace,snmp], 1148 1239130 pkts (500%) 1149 1 tibia.cic.net (192.217.65.100) [ver 3.8,prune,genid,mtrace] 1150 ... (No response from tibia.cic.net) 1151 2 fibula.cic.net (192.217.65.101) [ver 3.8,prune,genid,mtrace] ? 1152 2 dcl2.gw.uiuc.edu (192.17.2.8) [ver 1.0] ? 1153 2 goober.mci.net (204.70.104.45) [ver 3.6,prune,genid,mtrace] ? 1154 ... (goober.mci.net did not respond to DVMRP 'NEIGHBORS' msg) 1155 1 a-wing.jvnc.net (130.94.40.6) [ver 3.3] 1156 ... (a-wing.jvnc.net does not support SNMP) 1157 2 liberty-eth0/0.jvnc.net (130.94.40.1) [ver 10.2] ? 1158 2 noc.hpc.org (192.187.8.2) [ver 3.8,prune,genid,mtrace] ? 1159 2 liberty.jvnc.net (130.94.40.201) [ver 10.2] ? 1160 2 dstest.ds.internic.net (198.49.45.4) [ver 3.8,prune,genid,mtrace] ? 1161 2 cybercast.cc.nus.sg (137.132.9.70) [ver 3.6,prune,genid,mtrace] ? 1162 ... (cybercast.cc.nus.sg did not respond to DVMRP 'NEIGHBORS' msg) 1164 Facilities used 1166 DVMRP and multicast routing MIBs 1167 IGMP ASK_NEIGHBORS message (DVMRP) 1169 Availability 1171 mrtree is available for UNIX and is included in the 1172 SNMP-capable mrouted distribution, available at: 1173 ftp://ftp.merit.edu/net-research/mbone/mirrors/mrouted/ 1175 mrtree is also available in the MVIEW distribution, available at: 1176 ftp://ftp.merit.edu/net-research/mbone/mview/ 1178 6.6.2. map-mbone 1180 Author 1182 Pavel Curtis, pavel@parc.xerox.com 1184 Description 1186 map-mbone is useful for discovering the topology within a DVMRP 1187 routing domain; to do this, it uses the IGMP ASK_NEIGHBORS message to 1188 discover the neighbors of the starting router. If the -f (flooding) 1189 option is enabled (this is the default if no starting router is 1190 specified), then once these neighbors are discovered, they too are 1191 queried. This continues until the leaf routers are reached. This 1192 option should be used with care since it can result in excessive load 1193 on multicast routers. 1195 If a starting router is specified but the -f option is not used, then 1196 the search terminates after the first hop routers are discovered, the 1197 output of map-mbone is very similar to that for mrinfo. Routers 1198 discovered by map-mbone are queried for their version numbers, and if 1199 this query is successful, for their metrics, thresholds, and flags, 1200 and the results are presented in an indented list format. 1202 Example 1204 % map-mbone 192.80.214.199 1205 192.41.177.196: alias for 128.167.252.196 1207 128.167.252.196 (collegepk-mbone1.bbnplanet.net): 1208 192.41.177.196: 192.41.177.196 [1/0/querier/down] 1209 192.80.214.199: 192.80.214.199 (collegepk-mbone1.bbnplanet.net) [1/0/querier] 1210 128.167.252.196: 205.128.246.2 (usnrctc.bbnplanet.net) [1/32/tunnel/querier] 1211 204.148.62.28 (mbone-e.ans.net) [1/32/tunnel/querier] 1212 192.41.177.197 (wtn-ms1.bbnplanet.net) [1/32/tunnel/querier] 1213 128.175.13.36 (pfet.nss.udel.edu) [1/32/tunnel/querier/down] 1214 205.130.85.3 (philipii.nap.edu) [1/32/tunnel/querier/down] 1215 204.167.201.38 (dallas2-mbone1.bbnplanet.net) [1/64/tunnel/querier] 1216 192.221.48.234 (atlanta3-mbone1.bbnplanet.net) [1/64/tunnel/querier] 1217 134.205.93.150 (dilbert.sam.pentagon.mil) [1/32/tunnel/querier] 1218 128.167.1.197 (cpk-ms1.ser.bbnplanet.com) [1/16/tunnel/querier] 1219 192.221.34.22 (cdrn.bbnplanet.net) [1/32/tunnel/querier] 1220 128.244.93.3 (sage.jhuapl.edu) [1/32/tunnel/querier] 1221 192.41.177.199 (wtn-ms2.bbnplanet.net) [1/16/tunnel/querier] 1222 137.39.43.34 (MBONE1.UU.NET) [1/32/tunnel/querier] 1223 199.94.207.2 (cambridge1-mbone1.bbnplanet.net) [1/32/tunnel/querier] 1224 131.119.0.197 (paloalto-mbone1.bbnplanet.net) [1/64/tunnel/querier] 1225 128.167.254.165 (devo.sura.net) [1/32/tunnel/querier/down] 1226 128.167.252.196 (collegepk-mbone1.bbnplanet.net) [1/0/querier] 1228 192.80.214.199 (collegepk-mbone1.bbnplanet.net): alias for 128.167.252.196 1230 Facilities used 1232 IGMP ASK_NEIGHBORS message (DVMRP) 1234 Availability 1236 map-mbone is available for UNIX, and the software and manual pages are included 1237 in the SNMP-capable mrouted distribution, available at: 1238 ftp://ftp.merit.edu/net-research/mbone/mirrors/mrouted/ 1240 6.6.3. asn 1242 Author 1244 Dave Thaler, dthaler@microsoft.com 1246 Description 1248 asn gives the AS number of a given IP address by querying the routing 1249 arbiter database. 1251 Example 1253 % asn 141.213.10.41 1254 AS237 1256 Facilities used 1258 Routing arbiter database 1260 Availability 1262 asn is included in the MVIEW distribution, available at: 1263 ftp://ftp.merit.edu/net-research/mbone/mview/ 1265 6.6.4. asname 1267 Author 1269 Dave Thaler, dthaler@microsoft.com 1271 Description 1273 asname gets the name of an AS, given the AS number by querying the 1274 WHOIS database. 1276 Example 1278 % asname 237 1279 NSFNETTEST14-AS 1281 Facilities used 1283 WHOIS database 1285 Availability 1287 asname is included in the MVIEW distribution, available at: 1289 ftp://ftp.merit.edu/net-research/mbone/mview/ 1291 6.7. Network Operations Center tools 1293 These tools are suitable for use in a Network Operations Center. 1295 6.7.1. MVIEW 1297 Authors 1299 Dave Thaler, dthaler@microsoft.com 1300 Andy Adams, ala@merit.edu 1302 Description 1304 MVIEW uses utilities such as mstat, mtrace, mrtree, asn and asname in 1305 order to produce a graphical depiction of the multicast network 1306 topology and the actual and potential multicast trees for a given 1307 group and source. 1309 Example 1311 Further information on MVIEW as well as examples are available from: 1312 http://www.merit.edu/net-research/mbone/mviewdoc/Welcome.html 1314 Facilities used 1316 PIM, DVMRP, IGMP, and multicast routing MIBs (mstat) 1317 IGMP ASK_NEIGHBORS message (mrinfo) 1318 Routing arbiter database (asn) 1319 WHOIS database (asname) 1321 Availability 1323 MVIEW is available for UNIX, and can be obtained from: 1324 ftp://ftp.merit.edu/net-research/mbone/mview/ 1326 Documentation is available as: 1327 ftp://ftp.merit.edu/net-research/mbone/mviewdoc/ 1329 6.7.2. Multicast heartbeat 1331 Author 1333 Many and various 1335 Description 1336 Devices implementing the multicast heartbeat listen on a designated 1337 group. If traffic is not observed on the group for a specified amount 1338 of time, an SNMP trap is generated. This allows multicast monitoring 1339 to be easily integrated into existing SNMP consoles. In situations 1340 where a shared-tree multicast routing protocol is used (such as 1341 sparse-mode PIM or CBT), it is recommended that the heartbeat 1342 generator be located close to the RP or core nodes, so as that loss 1343 of the heartbeat will correlate closely with loss of connectivity to 1344 the RP or core. Suitable heartbeat mechanisms include SNTP, which 1345 uses the group 224.0.1.1 (ntp.mcast.net) and UDP port 123; and SAP, 1346 which uses the group 224.2.127.254 (sap.mcast.net) and UDP port 9875. 1348 Example 1350 For further information on SNTP, consult [1]. 1352 Facilities used 1354 SNTP (for time-based heartbeats) 1355 SAP (for session announcement heartbeats) 1356 SNMP traps (for alerts) 1358 Availability 1360 6.8. Network analysis tools 1362 6.8.1. Dr. Watson, the Network Detective's Assistant (DWTNDA) 1364 Author 1366 Karl Auerbach, karl@cavebear.com 1368 Description 1370 DWTNDA is a general purpose troubleshooting tool with some IP 1371 multicast tools (in addition to a fair number of non-multicast 1372 tools). For example it can watch IGMP "join" activity on a LAN and 1373 put up a real-time display in tabular format. It can generate some 1374 test packets, like IGMPv2 Leaves or Group Membership Requests. It can 1375 generate and respond to multicast pings (icmp, udp, or snmp based.) 1376 It will eventually acquire more sophisticated multicast facilities. 1378 Example 1380 See http://www.cavebear.com/dwtnda/ for examples. 1382 Facilities used 1384 This is a troubleshooting tool, so it will typically respond to 1385 packets that, strictly speaking, ought to go unanswered. 1387 Availability 1389 DWTNDA runs on MS-DOS and Windows 95/98 and is free. Source is not 1390 provided. See http://www.cavebear.com/dwtnda/ for various documents 1391 and download information. 1393 6.8.2. Mtap 1395 Author 1397 Luis Fernando da Silva Barra, barra@ax.apc.org 1398 Michael Stanton, michael@omega.lncc.br 1400 Description 1402 MTap is a tool for observing IP multicast packet traffic crossing a 1403 subnet, normally an Ethernet. 1405 Each packet sent to an IP multicast group address (class D) is 1406 captured, and information is extracted concerning its origin, its 1407 size, and so forth. This information is summarized, permitting the 1408 determination of the current network load resulting from multicast 1409 traffic. Apart from global summaries, traffic information is 1410 summarized by group and by source, permitting the determination of 1411 the contribution of each group and each individual sender to global 1412 traffic. The data recorded are as follows: number of multicast 1413 packets and total multicast bytes passing through the network, load 1414 level, and date and time of the last packet received. 1416 As well as processing packets sent to a multicast address, MTap also 1417 records separately multicast packets encapsulated in point-to-point 1418 packets. Thus we can also deal with traffic in DVMRP tunnels between 1419 multicast routers, and tunnel traffic data are recorded in the same 1420 way as for a group. 1422 As well as recording the data. MTap also permits that individual 1423 packet data be exhibited in dump format at capture time, both for 1424 multicast packets and for tunneled packets. 1426 In order to evaluate the impact which a group imposes on a 1427 subnetwork, MTap can enter or leave a multicast group, using the IGMP 1428 protocol. Thus traffic can be observed for a group which has no other 1429 members on the subnetwork. 1431 In addition to passively observing and recording multicast traffic, 1432 MTap has a notification mechanism, which sets off an alarm whenever 1433 user-specified load levels are exceeded, either globally, by group or 1434 by tunnel. Notifications are also logged in a dedicated window. 1436 Example 1438 Further information on Mtap will be available from: 1439 http://www.inf.puc-rio.br/~michael/GERENTE/tools 1441 Facilities used 1443 Berkeley Packet Filter (BPF) 1445 Availability 1447 MTap uses a window-based user interface, developed using Tcl/Tk, and 1448 captures packets through the Berkeley Packet Filter (BPF). It can 1449 thus be ported to different platforms. 1451 Mtap, which is still under development, has been ported to Linux and 1452 Solaris; minor problems related to packet capture have still to be 1453 resolved for the Solaris version. When it is released, it will be 1454 available from: 1455 http://www.inf.puc-rio.br/~michael/GERENTE/tools 1457 7. References 1459 [1] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, 1460 IPv6 and OSI", RFC 2030, October 1996. 1462 [2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 1463 2236, November 1997. 1465 [3] McCloghrie, K., Farinacci, D., Thaler, D., "Internet Group 1466 Management Protocol MIB", Internet draft (work in progress), draft- 1467 ietf-idmr-igmp-mib-10.txt, June 1999. 1469 [4] Handley, M., Jacobson, V., "SDP: Session Descripton Protocol 1470 (Version 1)", RFC 2327, April 1998. 1472 [5] McCloghrie, K., Farinacci, D., Thaler D., "IP Multicast Routing 1473 MIB", Internet draft (work in progress), draft-ietf-idmr-multicast- 1474 routmib-10.txt, July 1999. 1476 [6] McCloghrie, K., Farinacci, D., Thaler, D., "Protocol Independent 1477 Multicast MIB", Internet draft (work in progress), draft-ietf-idmr- 1478 pim-mib-07.txt, July 1999. 1480 [7] Thaler, D., "Distance Vector Multicasting Routing Protocol MIB", 1481 Internet draft (work in progress), draft-thaler-dvmrp-mib-09.txt, 1482 May 1998. 1484 [8] Fenner, W., Casner, S., "A "traceroute" facility for IP Multicast", 1485 Internet draft (work in progress), draft-ietf-idmr-traceroute- 1486 ipm-05.txt, June 1999. 1488 [9] Rekhter, Y. et al., "Address Allocation for Private Internets", RFC 1489 1918, February, 1996. 1491 8. Security Considerations 1493 SNMP-based monitoring tools require that the manager be provided access 1494 to the relevant MIBs. In order to limit security risks, such access will 1495 typically be provided on a selective basis. For example, the 1496 authentication and access control facilities in SNMP v3 can be used to 1497 limit access to authorized users. 1499 MBONE-mapping tools such as map-mbone should be used with care since in 1500 flooding mode they can result in excessive load on multicast routers. 1502 Through use of RTP monitoring tools, it may be possible to obtain 1503 sensitive information on user viewing habits. In order to protect 1504 against this, encryption technologies such as IPSEC can be used to 1505 provide confidentiality. 1507 9. Acknowledgments 1509 Thanks to Karl Auerbach for the description of the Dr. Watson tool, and 1510 to Michael Stanton for the description of the Mtap tool. 1512 10. Authors' Addresses 1514 Dave Thaler 1515 Microsoft Corporation 1516 One Microsoft Way 1517 Redmond, WA 98052 1519 Phone: 425-703-8835 1520 EMail: dthaler@microsoft.com 1522 Bernard Aboba 1523 Microsoft Corporation 1524 One Microsoft Way 1525 Redmond, WA 98052 1526 Phone: 425-936-6605 1527 EMail: bernarda@microsoft.com 1529 11. Full Copyright Statement 1531 Copyright (C) The Internet Society (1999). All Rights Reserved. 1532 This document and translations of it may be copied and furnished to 1533 others, and derivative works that comment on or otherwise explain it or 1534 assist in its implmentation may be prepared, copied, published and 1535 distributed, in whole or in part, without restriction of any kind, 1536 provided that the above copyright notice and this paragraph are included 1537 on all such copies and derivative works. However, this document itself 1538 may not be modified in any way, such as by removing the copyright notice 1539 or references to the Internet Society or other Internet organizations, 1540 except as needed for the purpose of developing Internet standards in 1541 which case the procedures for copyrights defined in the Internet 1542 Standards process must be followed, or as required to translate it into 1543 languages other than English. The limited permissions granted above are 1544 perpetual and will not be revoked by the Internet Society or its 1545 successors or assigns. This document and the information contained 1546 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1547 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1548 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1549 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1550 WARRANTIES OF 1552 12. Expiration Date 1554 This memo is filed as , and expires 1555 December 1, 2000.