Subject: cisco messing up multicast mtrace

From: Van Jacobson <[email-masked]>
Date: Sun, 01 Dec 96 21:01:43 PST

We designed mtrace with the ability to accept queries & send
responses to a multicast address.  This allows it to work
whereever multicast works (e.g., through firewalls & to backbone
routers that don't have full unicast forwarding tables).  The
mechanism works by putting the unicast address of the mtrace
source & destination in the multicast query so the last hop
router for that source/dest pair can pick up & initiate the
trace.  Unfortunately, this mechanism doesn't work very well if
some router(s) are confused about what nets they service and
respond to queries they shouldn't.  (Many multicast mechanisms,
e.g., duplicate suppression, don't work well when routers get
confused about this).

Tonight I tried to do some 3rd party mtraces to sites reporting
high loss on the shuttle video.  Unfortunately, eng-abu-serv-1.cisco.com
(171.69.95.202) thinks it is the last hop for most of the world
(see below).  This breaks multicast mtrace, an important mbone
diagnostic, for everyone.  Is cisco aware of this bug?  Is the
bug in production PIM releases?  Any idea when it might be
fixed?  Thanks.

 - Van

-------------
% mtrace shuttle-bone.arc.nasa.gov 224.2.206.143 estel.nikhef.nl
Mtrace from 128.102.84.134 to 192.16.195.126 via group 224.2.206.143
Querying full reverse path... 
  0  estel.nikhef.nl (192.16.195.126)
 -1  eng-abu-serv-1.cisco.com (171.69.95.202) UNKNOWN(0) thresh 0 Not forwarding [128.102.84.134/32]
Round trip time 235 ms

% mtrace shuttle-bone.arc.nasa.gov 224.2.206.143 132.195.20.106
Mtrace from 128.102.84.134 to 132.195.20.106 via group 224.2.206.143
Querying full reverse path... 
  0  wrin26.urz.uni-wuppertal.de (132.195.20.106)
 -1  eng-abu-serv-1.cisco.com (171.69.95.202) UNKNOWN(0) thresh 0 Not forwarding [128.102.84.134/32]
Round trip time 221 ms

% mtrace shuttle-bone.arc.nasa.gov 224.2.206.143 133.54.170.140 
Mtrace from 128.102.84.134 to 133.54.170.140 via group 224.2.206.143
Querying full reverse path... 
  0  bolt.te.miyazaki-u.ac.jp (133.54.170.140)
 -1  eng-abu-serv-1.cisco.com (171.69.95.202) UNKNOWN(0) thresh 0 Not forwarding [128.102.84.134/32]
Round trip time 241 ms

---

From: Manoj Leelanivas <[email-masked]>
Date: Mon, 2 Dec 1996 00:19:39 -0800 (PST)

=>    
=>    Tonight I tried to do some 3rd party mtraces to sites reporting
=>    high loss on the shuttle video.  Unfortunately, eng-abu-serv-1.cisco.com
=>    (171.69.95.202) thinks it is the last hop for most of the world
=>    (see below).  This breaks multicast mtrace, an important mbone
=>    diagnostic, for everyone.  Is cisco aware of this bug?  Is the
=>    bug in production PIM releases?  Any idea when it might be
=>    fixed?  Thanks.
=>    

This bug(CSCdi68628) has been identified and fixed. When a multicast
mtrace query arrives on a cisco which is not enabled for multicast routing,
extraneous error responses were sent back to the querier.

This is fixed in versions 11.1(6.3), 11.0(11.1), 11.2(1.1) and after.
We will get eng-abu-serv-1 upgraded.

thanks,
-Manoj