Subject: Is the mbone broken?

From: Amancio Hasty <[email-masked]>
Date: Thu, 27 Jun 1996 13:36:53 -0700

Hi for the last couple of days dec3800-2-fddi-1.SanFrancisco.mci.net
is down or not routing mbone traffic. Is anyone else having problems
with this router?

	Tnks,
	Amancio

mrinfo toad.com
140.174.2.1 (toad.com) [version 3.8,prune,genid,mtrace]:
  140.174.2.1 -> 0.0.0.0 (local) [1/1/querier/leaf]
  140.174.2.1 -> 204.182.46.1 (hydra.pixi.com) [1/1/tunnel/down/leaf]
  140.174.2.1 -> 140.174.97.13 (flying.fish.com) [1/1/tunnel/down/leaf]
  140.174.2.1 -> 204.188.121.18 (rah.star-gate.com) [1/1/tunnel/leaf]
  140.174.2.1 -> 204.188.119.1 (gateway.v-site.net) [1/1/tunnel/down/leaf]
  140.174.2.1 -> 204.70.158.77 (dec3800-2-fddi-1.SanFrancisco.mci.net) 
[1/1/tunnel]
  140.174.2.1 -> 198.161.236.27 (indy.tcel.com) [1/1/tunnel/leaf]
  140.174.2.1 -> 206.14.228.5 (MIN.BUNGI.COM) [1/1/tunnel]

---

From: Bill Fenner <[email-masked]>
Date: Thu, 27 Jun 1996 14:40:29 PDT

In message <[email-masked]> you write:
>is down or not routing mbone traffic.

>  140.174.2.1 -> 204.70.158.77 (dec3800-2-fddi-1.SanFrancisco.mci.net) 

It is true that someone's Cisco is injecting thousands of unicast routes
into the DVMRP backbone, which tends to hose slower machines running
mrouted, but I doubt there's anything about dec2.hay.mci.net in particular.
In fact, I'd bet that MCI's alphas are doing better than most UNIX-based
MBONE routers; they're certainly doing better than my Sparc1+'s...

  Bill

---

From: Amancio Hasty <[email-masked]>
Date: Thu, 27 Jun 1996 15:28:18 -0700

Oh, I am not getting any mbone traffic from the dec3800...

	Tnks,
	Amancio

---

From: RL "Bob" Morgan <[email-masked]>
Date: Thu, 27 Jun 96 17:23:37 -0700

> > Hi for the last couple of days
> > dec3800-2-fddi-1.SanFrancisco.mci.net is down or not routing mbone traffic.
>   

My path to MCI's MBONE backbone goes through
dec3800-2-fddi-0.SanFrancisco.mci.net, which also shows an "up" tunnel to
paloalto-mbone1.bbnplanet.net, but doesn't respond to mrinfo (nor does
dec3800-2-fddi-1.SanFrancisco.mci.net).  I didn't get any traffic from the IETF
all day; the only source was from NASA, which comes via BBN, not MCI.  I
conclude that MCI's MBONE nodes in San Francisco are toast.

 - RL "Bob" Morgan
   Stanford

---

From: Bill Fenner <[email-masked]>
Date: Thu, 27 Jun 1996 19:51:44 PDT

In message <[email-masked]> you writ
e:
>I didn't get any traffic from the IETF

Did you check an mtrace to the IETF source, to see where the loss was
occurring?

  Bill

---

From: Geert Jan de Groot <[email-masked]>
Date: Fri, 28 Jun 1996 05:31:25 +0200

How about changing mrouted so it would not redistribute _any_ routes
if the number of routes raises above a certain limit?

This would automagically isolate a site that would dump a full routing
table.

The correct solution is, of course, to change the routing protocol,
but if a quick hack can fix things...

Geert Jan

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 Jun 1996 22:33:19 -0700

>> if the number of routes raises above a certain limit?

    I'm going to cut a patch for the ciscos to have a default route-limit
    of 7000. It can be changed when need be. The patch will go in 11.0,
    11.1 and 11.2. I'll try and get it in ASAP.

Dino

---

From: Amancio Hasty <[email-masked]>
Date: Thu, 27 Jun 1996 23:13:40 -0700

Hi Dino,

What you are doing is cool;however, I would say the fault
lies more on mrouted than on your mrouted implementation.

I wonder what is it going to take to fix mrouted so that the mbone does
not choke when someone misconfigures a cisco router;specially, since
it will be a while before the cisco routers get updated to the proper
rev.  

Also, dec3800-1-fddi-0.WillowSprings.mci.net
or dec3800-2-fddi-0.Denver.mci.net is acting up by way of blocking all
video traffic from the FreeBSD Lounge which is originating from 
129.89.9.63. We suspect that the mrouted bug in this case is due to the sun
transmitting video non stop since May 24 (it is a low bandwith
video transmission 10kbit/sec )
The FreeBSD Lounge Channel is advertised on "sdr".

	Tnks,
	Amancio

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 27 Jun 1996 23:21:36 -0700

>> lies more on mrouted than on your mrouted implementation.

    This may be true but I think this is long due. Because of this untimely
    meltdown, many people were not able to hear today's IETF. I feel bad about
    that.

>> it will be a while before the cisco routers get updated to the proper

    Well these sorts of people did the same thing 8 years ago with unicast
    routing. Today there are many unicast routing wizards working for ISPs.
    In 5 years down the road those same folk will be multicast routing
    wizards so the mistakes won't happen (they'll just be different ones
    with longer addresses :-)). Until then we have to protect the fragile 
    infrastructure we have to live with today. At least until transition is 
    under way.

Dino

---

From: Tony Querubin <[email-masked]>
Date: Fri, 28 Jun 1996 08:27:54 -1000 (HST)

>     11.1 and 11.2. I'll try and get it in ASAP.

How about a patch for 10.2 and 10.3 as well?

Antonio Querubin  
[email-masked] / [email-masked]

---

From: Petri Helenius <[email-masked]>
Date: Fri, 28 Jun 1996 21:34:44 +0300 (EET DST)

> How about a patch for 10.2 and 10.3 as well?
One shouldn't be running MBone, specificially DVMRP in 10.2 and
10.3 code versions anyway since they don't support pruning nor mtrace.
11.0 is generally stable enough if you use only the functionality
present in 10.2 and 10.3. 

Pete

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 28 Jun 1996 14:17:58 -0700

>> How about a patch for 10.2 and 10.3 as well?

    Sorry, you shouldn't be running those releases. Did you attend the MBONE
    BOF? There is an effort to cut-off MBONE connectivity to non-pruning
    DVMRP routers. 10.2 and 10.3 are in that category.

    Please use 11.0 or 11.1. 11.1 has more features, 11.0 has the stability
    feature :-)

    Enclosed are a list of routers running 10.2 and 10.3. You know who you 
    are, and now everyone else does too.

Dino

------------------------------------------------------------------------
Active 10.2 mrouted's

 rtr-900-b22-cf.gsfc.nasa.gov
 137.78.1.1
 lazer8.nrl.navy.mil
 lazer9-f2.nrl.navy.mil
 146.139.254.120
 bambi.cmb.anl.gov
 bambam.re.anl.gov
 171.69.113.17
 lazer3.nrl.navy.mil
 lazer2.nrl.navy.mil
 pancho.nrl.navy.mil
 zorro.nrl.navy.mil
 vipernet-gw.uchicago.edu
 9.2.254.100
 204.140.133.2
 129.250.200.9
 192.5.159.2
 164.54.56.2
 smith-e2.uncc.edu
 router-tele.cs.odu.edu
 inr-666-dmz.berkeley.edu
 whimpy.ctd.anl.gov
 146.139.254.101
 dino.ctd.anl.gov
 erau-jkv1-c1.sura.net
 192.12.15.1
 paris-e0.ucla.edu
 judd-gw.uchicago.edu
 uco-gw.uchicago.edu
 princeton-gateway.jvnc.net
 164.164.164.1
 oit-rtr-int-fddi.gatech.edu
 128.130.5.129
 128.118.100.7
 patteefddi1.gw.psu.edu
 willardfddi1.gw.psu.edu
 daffy.chm.anl.gov
 146.137.128.121
 blondie.ctd.anl.gov
 lsil-gw.ALTER.NET
 128.135.2.15
 osc1-fddi0.net.ohio-state.edu
 inr-109.Berkeley.EDU
 inr-181.Berkeley.EDU
 inr-180.Berkeley.EDU
 128.175.13.117
 utnet-gw.cs.utexas.edu
 boston1.terra.net
 sc-aclink.scbb.aoyama.ac.jp
 gwift.ulaval.ca
 gwdepift.ift.ulaval.ca
 164.67.128.7
 msa1-f0.ucla.edu
 agsm1-f0.ucla.edu
 caip-gw.rutgers.edu
 198.32.136.10
 CDF1.in2p3.fr
 205.158.1.202
 192.54.152.3
 pim-rtr-f2.nrl.navy.mil
 ajax-gw.cc.tut.fi
 ariel-gw.cc.tut.fi

------------------------------------------------------------------------

Active 10.3 mrouted's

 157.193.44.254
 mqu.gw.CSIRO.AU
 dunet2.router.tudelft.nl
 164.54.56.1
 146.139.254.107
 dcs1gw-f0.umd.edu
 avw1gw-f0.umd.edu
 lazer1.nrl.navy.mil
 john-manyjohns.net.CSUChico.EDU
 john-gomez.net.CSUChico.EDU
 john-oconnor.net.CSUChico.EDU
 anatomy-gw.uchicago.edu
 130.206.4.2
 198.32.136.24
 liberty.jvnc.net
 mbone.aco.net
 140.140.233.254
 129.46.48.97
 nml.gw.CSIRO.AU
 nersc-noc.es.net
 139.130.5.10
 140.254.113.1
 193.59.0.9
 132.250.100.37
 sprint-oeb-e0.columbus.oar.net
 146.139.254.103
 198.82.149.145
 csc1gw-f0.umd.edu
 avw2gw-f0.umd.edu
 dcs3gw-f0.umd.edu
 dcs2gw-f0.umd.edu
 132.241.60.84
 132.241.60.72
 171.68.27.230
 itd-router.nrl.navy.mil
 aac-gw.uchicago.edu
 efi-jfi-gw.uchicago.edu
 130.238.7.2
 194.85.221.10
 166.90.1.33
 171.69.8.7
 171.69.8.8
 134.93.9.254
 cis48.hrz.th-darmstadt.de
 193.84.48.182
 128.112.200.254
 198.128.16.41
 nersc2-mrfd.nersc.gov
 203.15.123.34
 203.15.123.39
 198.92.112.161
 E-G.bb.uec.ac.jp
 W-6.bb.uec.ac.jp
 DUMB.bb.uec.ac.jp
 E-P.bb.uec.ac.jp
 130.153.12.26
 E-1.bb.uec.ac.jp
 HONKAN.bb.uec.ac.jp
 W-4.bb.uec.ac.jp
 W-8.bb.uec.ac.jp
 W-2.bb.uec.ac.jp
 W-9.bb.uec.ac.jp
 E-M.bb.uec.ac.jp
 E-L.bb.uec.ac.jp
 W-1.bb.uec.ac.jp
 W-5.bb.uec.ac.jp
 W-3.bb.uec.ac.jp
 W-C.bb.uec.ac.jp
 E-F.bb.uec.ac.jp
 ny-columbia-1-s0-T3.nysernet.net
 152.15.253.160
 152.15.253.45
 inr-107-styx.Berkeley.EDU
 171.68.43.2
 lafo-f00.gw.nd.edu
 coba-f00.gw.nd.edu
 fitz-f00.gw.nd.edu
 sofh-f00.gw.nd.edu
 nwfh-f00.gw.nd.edu
 hagg-f00.gw.nd.edu
 shub-f00.gw.nd.edu
 mbone.wr.usgs.gov
 192.221.32.14
 204.255.245.248
 r-s-hub.fnal.gov
 171.69.220.34
 171.69.6.21
 171.69.6.18
 138.100.3.2
 166.90.111.226
 138.25.17.23
 kh1-fddi4-0.net.ohio-state.edu
 bh1-fddi4-0.net.ohio-state.edu
 inr-100.Berkeley.EDU
 198.93.182.3
 dome-e07.gw.nd.edu
 SanDiego.wr.usgs.gov
 131.247.254.2
 131.247.254.3
 147.155.3.252
 137.39.12.38
 r-s-hub-2.fnal.gov
 138.100.4.10
 dbar-e00.gw.nd.edu
 137.39.12.3
 131.225.219.214
 r-g-hep-dec.fnal.gov
 r-s-wh11nw.fnal.gov
 171.69.161.8
 128.83.7.7
 ens.gw.utexas.edu
 128.83.8.163
 128.83.8.40
 128.83.9.135
 128.83.9.131
 128.83.9.153
 129.241.107.99
 wch.gw.utexas.edu
 cse1-gw.ogi.edu
 ogi1-gw.ogi.edu
 ece-gw-out.ece.ORST.EDU
 205.158.2.38
 206.159.195.26
 opn-s0.len.net
 205.158.3.62
 ser1.gw.utexas.edu
 205.158.9.114
 205.158.9.98
 205.158.9.122
 205.158.9.126
 205.158.9.102
 205.158.9.130
 205.158.9.134
 adlgtv-rtr-S0.InterNex.Net
 205.158.9.150
 205.158.9.142
 205.158.9.106
 205.158.9.178
 205.158.9.170
 205.158.1.62
 205.158.1.58
 205.158.2.10
 205.158.1.78
 205.158.9.6
 206.159.195.6
 199.103.128.250
 199.103.132.66
 157.88.31.186
 157.88.31.184
 157.88.31.183
 157.88.31.141
 206.111.15.6
 206.111.15.10
 206.111.15.18
 206.111.1.26
 205.158.1.138
 node4-16.gw.uiuc.edu
 206.111.1.17
 192.153.156.1
 131.215.131.2
 166.90.111.241
 192.108.195.26
 192.108.195.25
 128.2.1.12
 206.48.171.10
 157.161.139.4
 157.161.139.5
 157.161.101.1
 198.32.136.26
 waters-gateway.jvnc.net
 206.111.1.25
 205.158.9.74
 205.158.9.70
 205.158.9.186
 205.158.9.222
 205.158.9.230
 205.158.1.250
 205.158.1.126
 205.158.9.10
 205.158.9.26
 205.158.9.58
 205.158.9.42
 198.68.121.1
 205.158.1.178
 205.158.1.162
 205.158.1.186
 205.158.1.182
 205.158.1.166
 205.158.1.94
 205.158.1.142
 205.158.1.98
 205.158.1.190
 206.159.194.10
 205.158.1.254
 bayfront-rtr-S0.InterNex.Net
 205.158.1.146
 205.158.1.222
 205.158.1.150
 128.135.23.19
 132.250.100.26
 145.41.6.71
 it-gw.electrum.kth.se

---

From: Tony Querubin <[email-masked]>
Date: Fri, 28 Jun 1996 23:52:28 -1000 (HST)

> present in 10.2 and 10.3. 

So IOS 10.2 and 10.3 multicasting basically is forever broken?  What
happens when a 10.2 router is adjacent to an 11.0 router which happens to
have a tunnel to the MBONE?

Antonio Querubin

---

From: Petri Helenius <[email-masked]>
Date: Sat, 29 Jun 1996 13:34:44 +0300 (EET DST)

-----BEGIN PGP SIGNED MESSAGE-----

 > have a tunnel to the MBONE?
Not actually, 10.2 and 10.3 are on the ok side for multicasting if you
are not having too big fanout (because of all traffic is process
switched) and you don't require mtrace. (or don't care if somebody
else is not able to diagnose your potential problems) And you don't
need boundary support. If you put 11.0(3.1) or newer at the border the
'MBone community' will give you an amnesty...

Actually I do disagree (a little) with Dino's recently posted list in
the sense that he didn't make any distinction between 10.3's and
10.2's running DVMRP and 10.3's and 10.2's _WITHIN_ a PIM cloud where
they are (disregarding the mtrace issue) fully functional with pruning
capabilities.

The numbers are:
         amount % of all mrouteds
10.3pim    122  6.3%
10.2pim     34  1.8%
11.0Mpim    30  1.6%
10.3        79  4.1%
10.2        26  1.3%
11.0M        5  0.3%

You also have to take into account those 11.0 boxes that _ARE_ running
DVMRP and are of 11.0(3) and earlier, which fortunately there is only
five of:
137.224.2.11                  (C7507-COMP.WAU.NL) [V11.0M]
207.18.8.1                           (207.18.8.1) [V11.0M]
137.78.1.28                         (137.78.1.28) [V11.0M]
199.95.233.34             (rutgers.bbnplanet.net) [V11.0M]
165.230.128.1                 (nb-gw.rutgers.edu) [V11.0M]

So I would consider the numbers '79','26' and '5' REALLY BAD and the
rest something that you should consider upgrading but nobody really
has a technical reason to tell you that you are hurting anybody else
except yourself on running those versions with MBone.

The good thing here is that 85% of the mrouteds currently running are
(or are supposed to be) fully functionally pruning. I just wish
everybody would run SNMP-enabled devices that debugging information
would be more readily available. Now figuring out the distribution
trees is close to impossible and the lack of real management
applications is a great burden.

Pete

---

From: Magnus Danielson <[email-masked]>
Date: Sat, 29 Jun 1996 17:34:15 +0200

Hi!

I do agree with Pete on that 10.2 and 10.3 with direct DVMRP connectivity is
far more worse that 1102. (sorry) 10.2 and 10.3 totally inside and.. an PIM
cloud. But since 10.2 and 10.3 do lack mtrace support etc. these are not
recommended, but migth be viewed as secondary targets in a cleanup action.
We should discorage people from useing the 10.x versions on Mbone as much as
possible.
This is basically analoguous to the Mrouted versions.. earlier than 3.6 should
be uppgraded and 3.6 versions is secondary target. 3.7 and 3.5 should also be
removed.
So far I haven't made any real distinction between routers with and without
SNMP support, but I always recommend people to use the SNMP version .
I think we should distinct the SNMP versions/boxes and make it the reference.

Today to few boxes run SNMP but claiming that there is no tools for it is
also wrong, there is tools which with proper use (just like with mtrace) can
speed up debuging and maintainence a lot. Also, there is still more tools to
be written so we are certainly not all there...

In promoting the usage of SNMP I think it should be in the standard mrouted
distrobution, this is now possible since the SNMP code now have support for
a much wider base of machnies than it used for (also a reason for not haveing
it in there as default).

A peak route limit and maybe also a route flux limit in mrouted (both 
being configurable) should be a not to hard adition to mrouted in order to
dampening a exxess route annaouncment flood.

BWT.. BTW. The mrouted implementation of how routes are announced etc. is not
to blame for boxes falling over, it is really the method of agregating routes
(RIP like) which is to blame. We can certainly reduce the damage by useing
some dampening parameters, but it will not solve the long-run problem.
I beleive that an overbeleif of what PIM can do for us is unhelthy so just
saing that PIM will solve it is being very naive... it will help thougth.

Magnus

---

From: dave pratt <[email-masked]>
Date: Sat, 29 Jun 1996 20:30:28 +0100 (BST)

Petri,

I appreciate all the work on mrouter managagement. However, I feel SNMP based
tools for this are fundamentally flawed in that SNMP will *NEVER* be allowed
to pass through firewalls. (problems also where there's no unicast route to
the querier - MCI ?). 

Where possible I would recommend tools that use the regular tunnels, and which
should thereby pass through firewalls without too much trouble.

I do miss a tool that would do the equivalent of "show ip multicast route
active" on a remote mrouted machine.

Cheers
Dave P

On Sat, 29 Jun 1996, Petri Helenius wrote:

->(or are supposed to be) fully functionally pruning. I just wish
->everybody would run SNMP-enabled devices that debugging information
->would be more readily available. Now figuring out the distribution
->trees is close to impossible and the lack of real management
->applications is a great burden.
->
->Pete

--------
The views expressed here may or may not be my own.
WWW - doesn't that stand for "Wait a Week Word" ?
Dave Pratt      (tel: +44 1473 643840 )
[email-masked]

---

From: Dave Thaler <[email-masked]>
Date: Sat, 29 Jun 1996 20:10:08 -0400 (EDT)

> to pass through firewalls. (problems also where there's no unicast route to

Even with firewalls, SNMP-based tools are still useful to those inside
the firewall (e.g., an ISP).  And from the outside, at least you can
point your finger towards whoever owns the firewall and let them worry
about the problem.

> active" on a remote mrouted machine.

I'm not sure what that command does, but if you're looking for the forwarding
table, the snmp tool command is "mstat <router>".

-Dave

---

From: "Jeff Young" <[email-masked]>
Date: Sat, 29 Jun 1996 20:34:45 -0400

if, at some point, the snmp working groups bring it
all together and get a version which supports encryption
why wouldn't you let it through your firewalls?

security is the reason that there are no unicast routes to the mci
machines.  no one has any business with those boxes unless they're
attached directly to tunnels that originate in them.  you
can appreciate the attraction of a 266 mhz alpha inside of one of 
our pops...

we don't allow non-customers to snmp poll our routers either (for
various reasons).

Jeff Young
[email-masked]

> Return-Path: [email-masked] 
> Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by postoffice.Reston.mci.net (8.7.5/8.7.3) with SMTP id QAA00144; Sat, 29 Jun 1996 16:06:29 -0400 (EDT)
> Received: by zephyr.isi.edu (5.65c/5.61+local-23)
> 	id <AA25740>; Sat, 29 Jun 1996 12:34:30 -0700
> Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
> 	id <AA25734>; Sat, 29 Jun 1996 12:34:29 -0700
> Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-23)
> 	id <AA18262>; Sat, 29 Jun 1996 12:34:28 -0700
> Received: by zephyr.isi.edu (5.65c/5.61+local-23)
> 	id <AA25722>; Sat, 29 Jun 1996 12:34:03 -0700
> Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
> 	id <AA25716>; Sat, 29 Jun 1996 12:34:01 -0700
> Received: from zaphod.axion.bt.co.uk by venera.isi.edu (5.65c/5.61+local-23)
> 	id <AA18247>; Sat, 29 Jun 1996 12:33:59 -0700
> Received: from percy.futures.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Sat, 29 Jun 1996 20:32:46 +0100
> Received: from percy (percy.futures.bt.co.uk) by percy.futures.bt.co.uk (5.x/SMI-SVR4) id AA23203;
>           Sat, 29 Jun 1996 20:30:28 +0100
> Date: Sat, 29 Jun 1996 20:30:28 +0100 (BST)
> From: dave pratt <[email-masked]>
> X-Sender: djp@percy
> Reply-To: dave pratt <[email-masked]>
> To: Petri Helenius <[email-masked]>
> Cc: mbone global list <[email-masked]>
> Subject: Re: SNMP management tools
> In-Reply-To: <[email-masked]>
> Message-Id: <Pine.SOL.3.93.960629202116.22970E-100000@percy>
> Mime-Version: 1.0
> Sender: [email-masked]
> Precedence: bulk
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> Content-Length: 1066
> 
> Petri,
>

---

From: Amancio Hasty <[email-masked]>
Date: Sat, 29 Jun 1996 17:47:54 -0700

> we don't allow non-customers to snmp poll our routers either (for

Gosh,

 How are we supposed to monitor the Mbone?

	Amancio

---

From: Petri Helenius <[email-masked]>
Date: Sun, 30 Jun 1996 08:42:07 +0300 (EET DST)

>  How are we supposed to monitor the Mbone?
The answer is 'you don't when it comes across MCI'. One should prefer
anyhow to avoid MCI being used as transit at any cost if you are
interested in low loss-%'s on your traffic.

It also prevents you from figuring out optimal connect-point for your
tunnel, but I guess that's why the bandwidth isn't there anyway :-)

Pete

---

From: Amancio Hasty <[email-masked]>
Date: Sat, 29 Jun 1996 23:39:13 -0700

Hi,

You wouldn't happen to be talking about something like this :

{hasty} mrinfo toad.com
140.174.2.1 (toad.com) [version 3.8,prune,genid,mtrace]:
  140.174.2.1 -> 0.0.0.0 (local) [1/1/querier/leaf]
  140.174.2.1 -> 204.182.46.1 (hydra.pixi.com) [1/1/tunnel/down/leaf]
  140.174.2.1 -> 140.174.97.13 (flying.fish.com) [1/1/tunnel/down/leaf]
  140.174.2.1 -> 204.188.121.18 (rah.star-gate.com) [1/1/tunnel/leaf]
  140.174.2.1 -> 204.188.119.1 (gateway.v-site.net) [1/1/tunnel/down/leaf]
  140.174.2.1 -> 204.70.158.77 (dec3800-2-fddi-1.SanFrancisco.mci.net) 
[1/1/tunnel]
  140.174.2.1 -> 198.161.236.27 (indy.tcel.com) [1/1/tunnel/leaf]
  140.174.2.1 -> 206.14.228.5 (MIN.BUNGI.COM) [1/1/tunnel]
{hasty} traceroute dec3800-2-fddi-1.SanFrancisco.mci.net
traceroute to dec3800-2-fddi-1.SanFrancisco.mci.net (204.70.158.77), 30 hops 
max, 40 byte packets
 1  ascend (204.188.121.17)  1.812 ms  1.615 ms  1.598 ms
 2  asc400-1.v-site.net (204.188.119.2)  27.635 ms  27.614 ms  27.483 ms
 3  gateway.v-site.net (204.188.119.1)  29.791 ms  29.887 ms  29.719 ms
 4  tlg-cust-link.tlg.net (140.174.37.17)  41.029 ms  39.015 ms  38.235 ms
 5  gw1-sf-tlg.tlg.net (140.174.13.2)  41.648 ms  40.456 ms  40.013 ms
 6  h0.r0.pdx.rain.rg.net (199.2.96.9)  60.109 ms  55.014 ms  55.716 ms
 7  s1.r0.tig.rain.rg.net (199.2.96.6)  62.285 ms  58.287 ms  67.193 ms
 8  border1-serial2-4.Seattle.mci.net (204.70.52.25)  67.154 ms  59.850 ms  
68.439 ms
 9  core1-fddi-0.Seattle.mci.net (204.70.2.145)  61.747 ms  174.709 ms  70.366 
ms
10  core2.SanFrancisco.mci.net (204.70.4.201)  60.626 ms  71.869 ms  64.044 ms
11  * *^C

Oh, I am located in San Francisco .

Hope things get better soon....

	Regards,
	Amancio

---

From: Petri Helenius <[email-masked]>
Date: Sun, 30 Jun 1996 12:47:22 +0300 (EET DST)

> Hope things get better soon....
Actually no since that is called 'creative routing' which seems to be
mainly due to your choice of providers. That the last hop does not
answer falls into 'you have no business of...' category of MCI policy.

Pete

---

From: Amancio Hasty <[email-masked]>
Date: Sun, 30 Jun 1996 03:58:49 -0700

> Actually no since that is called 'creative routing' which seems to be
Yes, is 'creative routing' now the question is why?

Is not clear to me that the problem is due to TLG and this problem has
been reported to TLG and I am hoping that MCI will also take note of 
this problem --- who knows TLG and MCI  may even decide to shake hands and
be friends 8)

All, I can say is wish us luck guys !

	Amancio

---

From: "Jeff Young" <[email-masked]>
Date: Sun, 30 Jun 1996 11:25:43 -0400

how about the same way you monitor unicast networks.  
mtrace == traceroute?  mtrace gives you much more than
traceroute.  if you see a problem with our portion of the
mbone at least cc:  [email-masked] or [email-masked].
people monitor [email-masked] 24x7, we don't actively 
monitor  nanog or mbone.

besides mrinfo, why do you need unicast connectivity
to the mci mbone routers?

Jeff Young
[email-masked]

> Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by postoffice.Reston.mci.net (8.7.5/8.7.3) with SMTP id VAA02079; Sat, 29 Jun 1996 21:54:53 -0400 (EDT)
> 	id <AA28889>; Sat, 29 Jun 1996 18:27:34 -0700
> 	id <AA28883>; Sat, 29 Jun 1996 18:27:33 -0700
> 	id <AA26298>; Sat, 29 Jun 1996 18:27:33 -0700
> 	id <AA28877>; Sat, 29 Jun 1996 18:27:23 -0700
> 	id <AA28871>; Sat, 29 Jun 1996 18:27:18 -0700
> Received: from rah.star-gate.com by venera.isi.edu (5.65c/5.61+local-23)
> 	id <AA26293>; Sat, 29 Jun 1996 18:27:17 -0700
> Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id RAA00421; Sat, 29 Jun 1996 17:47:55 -0700 (PDT)
> Message-Id: <[email-masked]>
> X-Mailer: exmh version 1.6.5 12/11/95
> To: "Jeff Young" <[email-masked]>
> Cc: dave pratt <[email-masked]>, Petri Helenius <[email-masked]>,
>         mbone global list <[email-masked]>
> In-Reply-To: Your message of "Sat, 29 Jun 1996 20:34:45 EDT."
>              <[email-masked]> 
> Mime-Version: 1.0
> Date: Sat, 29 Jun 1996 17:47:54 -0700
> From: Amancio Hasty <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
> Content-Length: 355
>

---

From: "Jeff Young" <[email-masked]>
Date: Sun, 30 Jun 1996 12:35:58 -0400

i'm getting to you over the pac-bell nap.  i don't
know the particulars about your network, but this 
doesn't look right.  i assume that rg.net has a  local
connection to mci in sanfrancisco.  perhaps we should 
move this to our noc...

from dec2.hay.mci.net:
# traceroute toad.com
traceroute to toad.com (140.174.2.1), 30 hops max, 40 byte packets
 1  core2-fddi-1.SanFrancisco.mci.net (204.70.158.65)  2 ms  1 ms  2 ms
 2  core3.SanFrancisco.mci.net (204.70.4.17)  2 ms  2 ms  2 ms
 3  pacbell-nap-atm.SanFrancisco.mci.net (204.70.1.202)  7 ms  3 ms  3 ms
 4  pb-nap.crl.net (198.32.128.20)  27 ms  6 ms  5 ms
 5  tlg.atm.us.crl.net (165.113.56.29)  26 ms  23 ms  35 ms
 6  gw1-sf-tlg.tlg.net (140.174.13.2)  22 ms  31 ms  24 ms
 7  gw-t1.toad.com (140.174.202.2)  29 ms  24 ms  27 ms
 8  toad.com (140.174.2.1)  27 ms  27 ms  27 ms
# 
# mrinfo toad.com
140.174.2.1 (toad.com) [version 3.8,prune,genid,mtrace]:
  140.174.2.1 -> 0.0.0.0 (local) [1/1/querier/leaf]
  140.174.2.1 -> 204.182.46.1 (hydra.pixi.com) [1/1/tunnel/down/leaf]
  140.174.2.1 -> 140.174.97.13 (flying.fish.com) [1/1/tunnel/down/leaf]
  140.174.2.1 -> 204.188.121.18 (rah.star-gate.com) [1/1/tunnel/down/leaf]
  140.174.2.1 -> 204.188.119.1 (gateway.v-site.net) [1/1/tunnel/down/leaf]
  140.174.2.1 -> 204.70.158.77 (dec3800-2-fddi-1.SanFrancisco.mci.net) [1/1/tunnel]
  140.174.2.1 -> 198.161.236.27 (indy.tcel.com) [1/1/tunnel/leaf]
  140.174.2.1 -> 206.14.228.5 (MIN.BUNGI.COM) [1/1/tunnel]

Jeff Young
[email-masked]

> Return-Path: [email-masked] 
> Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by postoffice.Reston.mci.net (8.7.5/8.7.3) with ESMTP id CAA04071 for <[email-masked]>; Sun, 30 Jun 1996 02:39:47 -0400 (EDT)
> Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id XAA01005; Sat, 29 Jun 1996 23:39:14 -0700 (PDT)
> Message-Id: <[email-masked]>
> cc: "Jeff Young" <[email-masked]>, dave pratt <[email-masked]>,
> In-reply-to: Your message of "Sun, 30 Jun 1996 08:42:07 +0300."
>              <[email-masked]> 
> Mime-Version: 1.0
> Date: Sat, 29 Jun 1996 23:39:13 -0700
> Content-Length: 2527

---

From: "Jeff Young" <[email-masked]>
Date: Sun, 30 Jun 1996 13:17:11 -0400

was that another snipe at us, or are you picking on
rg.net now?  :-)

Jeff Young
[email-masked]

> Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by postoffice.Reston.mci.net (8.7.5/8.7.3) with SMTP id GAA05887; Sun, 30 Jun 1996 06:22:04 -0400 (EDT)
> 	id <AA02924>; Sun, 30 Jun 1996 02:48:25 -0700
> 	id <AA02918>; Sun, 30 Jun 1996 02:48:24 -0700
> 	id <AA06747>; Sun, 30 Jun 1996 02:48:24 -0700
> 	id <AA02911>; Sun, 30 Jun 1996 02:47:47 -0700
> 	id <AA02905>; Sun, 30 Jun 1996 02:47:42 -0700
> Received: from silver.sms.fi by venera.isi.edu (5.65c/5.61+local-23)
> 	id <AA06740>; Sun, 30 Jun 1996 02:47:41 -0700
> Received: (from pete@localhost) by silver.sms.fi (8.7.5/8.6.9) id MAA14312; Sun, 30 Jun 1996 12:47:22 +0300 (EET DST)
> Date: Sun, 30 Jun 1996 12:47:22 +0300 (EET DST)
> Message-Id: <[email-masked]>
> From: Petri Helenius <[email-masked]>
> To: Amancio Hasty <[email-masked]>
> Cc: "Jeff Young" <[email-masked]>, dave pratt <[email-masked]>,
> In-Reply-To: <[email-masked]>
> References: <[email-masked]>
> 	<[email-masked]>
> Content-Type: text
> Content-Length: 1141

---

From: Petri Helenius <[email-masked]>
Date: Sun, 30 Jun 1996 21:18:43 +0300 (EET DST)

> was that another snipe at us, or are you picking on
Actually at Amancio who was complaining in the first place that his
choice of provider seems to be suboptimal.

Other than that I dislike most of the 'information safekeeping'
policies in effect that make operational information unavailable to
concerned parties. As the MBone is still at early maturing stage, all
feasible information should be readily available if there is no
technical reason to do othervise.

Pete

---

From: Amancio Hasty <[email-masked]>
Date: Sun, 30 Jun 1996 14:29:27 -0700

Okay, I am not sure who is responsible for the "creative routing" tunnel
connection from tlg.net to mci. The "creative routing" problem was
first reported to John Gilmore around May 15 and he then pass on the
information to tlg.net . I am sure that John can clarify further
at his attempts to get a better mbone connection.

I am hoping that MCI also takes notice of this "creative routing" problem
so that it may be solved soon. 

As for the  need for unicast connection , I am hoping that if we use
snmp we will get better stats :

{hasty} mtrace dec3800-1-fddi-0.WillowSprings.mci.net 224.2.100.102
Mtrace from 204.70.104.29 to 204.188.121.18 via group 224.2.100.102
Querying full reverse path... * switching to hop-by-hop:
  0  rah.star-gate.com (204.188.121.18)
 -1  rah.star-gate.com (204.188.121.18)  DVMRP  thresh^ 1  
 -2  toad.com (140.174.2.1)  DVMRP  thresh^ 1  
 -3  * * dec3800-2-fddi-1.SanFrancisco.mci.net (204.70.158.77)  DVMRP  thresh^ 
64  
 -4  * * dec3800-2-fddi-0.Denver.mci.net (204.70.152.61)  DVMRP  thresh^ 1  
 -5  * * dec3800-1-fddi-0.WillowSprings.mci.net (204.70.104.29)  DVMRP  
thresh^ 1  
 -6  dec3800-1-fddi-0.WillowSprings.mci.net (204.70.104.29)
Round trip time 159 ms

Waiting to accumulate statistics... Results after 9 seconds:

  Source        Response Dest    Packet Statistics For     Only For Traffic
204.70.104.29   224.0.1.32       All Multicast Traffic     From 204.70.104.29
     v       __/  rtt  186 ms    Lost/Sent = Pct  Rate       To 224.2.100.102
204.70.104.29   dec3800-1-fddi-0.WillowSprings.mci.net 
     v     ^      ttl    1        0/29   =  0%   0 pps     0/0    = --%   0 pps
204.70.152.77  
204.70.152.61   dec3800-2-fddi-0.Denver.mci.net 
     v     ^      ttl    2        0/24   =  0%   0 pps     0/0    = --%   0 pps
204.70.158.77   dec3800-2-fddi-1.SanFrancisco.mci.net 
     v     ^      ttl   64       -3/656  =  0%   0 pps     0/0    = --%   0 pps
                                 ^^^^^^^
140.174.2.1     toad.com       
     v     ^      ttl   65        1/19   =  5%   2 pps     0/0    = --%   0 pps
204.188.121.18  rah.star-gate.com 
     v      \__   ttl   66          20           0 pps       0            0 pps
204.188.121.18  204.188.121.18
  Receiver      Query Source

BTW: On a good note is that the mci routers seems to be routing the
FreeBSD video lounge --- not sure if the Sun box got rebooted 
or the mci routers got fixed however it is nice that the video 
stream is now working again --- Tnks!

	Regards,
	Amancio

From The Desk Of "Jeff Young" :
> > Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by postoffic
e.Reston.mci.net (8.7.5/8.7.3) with SMTP id GAA05887; Sun, 30 Jun 1996 06:22:04
 -0400 (EDT)
> > Received: (from pete@localhost) by silver.sms.fi (8.7.5/8.6.9) id MAA14312;
 Sun, 30 Jun 1996 12:47:22 +0300 (EET DST)

---

From: Magnus Danielson <[email-masked]>
Date: Mon, 01 Jul 1996 00:28:24 +0200

Hi Jeff!

I would like to have your opinion on allowing (from MCI's standpoint)
non-useer (really some Mbone manager) to have read access into the multicast
MIBs of your Mbone routers.

Does it fall into any general rules or is there (in)pure technical aspects
(which?) ?

Maf.. Magnus

---

From: Tony Querubin <[email-masked]>
Date: Sun, 30 Jun 1996 14:26:33 -1000 (HST)

> 11.0Mpim    30  1.6%

I wish cisco would just release pruning patches for their older IOS
versions.  I know of a couple of organizations that are avoiding deploying
native multicast routing on their largely cisco-based networks because of
fears about the older software.  And doing a major-version IOS upgrade can
be costly when you have a lot of those ciscos. 

Antonio Querubin

---

From: Bill Fenner <[email-masked]>
Date: Sun, 30 Jun 1996 18:46:37 PDT

>snmp we will get better stats :

...

>     v     ^      ttl   64       -3/656  =  0%   0 pps     0/0    = --%   0 pp
>                                 ^^^^^^^
>140.174.2.1     toad.com       

A brief quote from the mtrace man page:

     Because the packet counts may be changing as the trace query
     is propagating, there may be small errors (off by 1 or 2) in
     these statistics.

So this time it was off by 3, big deal.  This means that three packets
flowed "past" the mtrace packet while it was in transit between toad.com
and dec2.hay.mci.net; this is easy to accomplish because mtrace packets
get processed hop-by-hop and go up and down the stack while other packets
get forwarded through.  Note that it was off by 3/656, or less than 0.5%.

It's likely that you'll get significantly worse stats in this kind of
situation if you use snmp, since you will have a seperate round trip
to each node.  I'd guarantee that you're not likely to get an error of
only 0.5%.

I hope to release a new mtrace soon, based upon some discussion that I
had with John Hawkinson, Steve Casner and Van Jacobson, which will make
mtrace easier to use.

  Bill

---

From: John Gilmore <[email-masked]>
Date: Mon, 01 Jul 1996 01:34:21 -0700

MBone routing in TLGnet is my problem.  I'm the volunteer coordinator,
because I wanted mbone and nobody else volunteered.  This has worked
more or less OK, but I'd be happy to give the job to someone else if
we have a serious new volunteer.

TLGnet has been upgrading its configuration rapidly, and I have
deliberately left our connection to the rest of the MBone unchanged
while asking around to figure out what to do next.  Now that we have
working T3 to MAE-West, I should switch to using a tunnel through that
link.  I'm looking for someone who has an mrouter there to tunnel to,
on a network that peers with us there.  (Traceroute to toad.com and
see if it goes through *mae-west*.)

Our current tunnel is from an MCI POP in San Francisco to my location
in San Francisco.  TLGnet was carrying more MCI traffic than could be
handled on the two T1 lines to that POP, so we bought fractional T3
transit from CRL.NET and have switched our MCI link to backup use
only.  We also have a wide link with our good friends at RAINnet.
In our current configuration, it appears that packets from MCI come
to toad.com via CRL, but packets from toad.com go to MCI via RAINnet.

TLGnet has just installed T3 between San Francisco and our San Jose
POP, and FDDI from there to Mae West.  If your network peers with us
over at Mae's, we can set up an mbone tunnel across that link; send me
email at [email-masked].  If your network doesn't yet peer (exchange BGP4
routes) with us there, ask your routing guy to talk to us.  For that
purpose contact me at [email-masked] and TLG network operations at
[email-masked].

I think it'd also be a good idea to hook up some mbone cross-connections
among Mae's resident machines, to create redundant paths across a high
capacity backplane.  Or, is native multicast on FDDI defined and working?

We're all working toward engineering the MBone for real production use
now, aren't we?  For the low, low price of a couple of Ethernet cards,
we could perhaps cable point-to-point slow or fast ethernets among
nearby hosts there, giving mbone traffic reasonable, dedicated bandwidth.

How much human babysitting would it take to try running mrouting on
one of TLGnet's secondary Ciscos there?  Does somebody have that
well-debugged cheat-sheet built yet?  There's nothing with an obvious
name like README or index.html in ftp.cisco.com/dino/multicast/Docs or
ftpeng.cisco.com/ipmulticast/.  Though there are three different ways
to "quickstart" and dozens of commands documented, there's nothing
obvious that says WHICH quickstart or WHICH commands are best for easy
drop-in use on the MBone.  By the way, TLG's Cisco manuals are
permanently on a CD on a DOS machine halfway across town from me (and
even the guys who use them daily complain that it takes real work to
find what you're looking for.)  In short, is there a working shortcut?

	John Gilmore
	mbone coordinator for TLGnet

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 1 Jul 1996 07:56:28 -0700

>> have a tunnel to the MBONE?

    No, not broken, but just not optimal for the MBONE at large. 

    In your example, you won't get pruning if the 10.2 router is a leaf
    router for groups your site are not members of. For local sources for
    groups that are not active to the MBONE, the pruning can traverse all
    the way to your 11.0 router.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 1 Jul 1996 07:59:39 -0700

>> 'MBone community' will give you an amnesty...

    There is some "boundary" support in 10.2 and 10.3 that is TTL thresholding
    and access-lists.

>> they are (disregarding the mtrace issue) fully functional with pruning

    Yes, good point. Within PIM clouds there is pruning (or explicit
    joining) using dense-mode (or sparse-mode) PIM mechanisms.

Dino

---

From: "John M. Zwiebel" <[email-masked]>
Date: Mon, 01 Jul 1996 09:19:27 -0700

>name like README or index.html:

Try ftp:/ftpeng.cisco.com/ipmulticast.html -- the html links from this
page are no longer actively supported but most of the information is 
"good enough" for what you are trying to do.

  > in ftp.cisco.com/dino/multicast/Docs or
  >drop-in use on the MBone.  

	Hmmm... I would think that you would want to read all three of these
	they aren't that long.

jzwiebel@puli% ls -l /ftp/ipmulticast/*uick*
-rw-rw-r--  1 lwei     eng          2722 May 22 15:40 /ftp/ipmulticast/Quickstart-autorp
-r-xr-xr-x  1 dino     eng          2760 Oct 14  1994 /ftp/ipmulticast/Quickstart-dvmrp*
-rw-r--r--  1 jzwiebel eng          1334 Aug  3  1994 /ftp/ipmulticast/Quickstart-pim

	As far as the long list of configuration commands, you will have
	to be familiar with all of them because you are planning on doing
	something a bit more complicated than hooking up a single router
	to support a stub multicast AS to the MBONE.

  >By the way, TLG's Cisco manuals are

	No there are no short-cuts for doing what I understand that you
	want to do.  Quickstart-pim and Quickstart-dvmrp are good enough
	for someone that has a stub network, but you want to be a transit
	so you have to know a bit more.  If you want to provide a description
	of your network to "[email-masked]", we should be 
	able to help you.

	You _might_ also try http://www.cisco.com and follow the link
	to "Search Cisco".  You can also provide them some information on 
	what you think of cisco's documentation.

	z

---

From: Petri Helenius <[email-masked]>
Date: Mon, 1 Jul 1996 21:06:56 +0300 (EET DST)

>     the way to your 11.0 router.
Excuse me? Not that I'm in position to tell what your code does but
I'm in the impression that for data flowing *from* the MBone (which
usually is majority) you'll be able to prune up into the DVMRP
neighbor of your 11.0 router and from that point it's actually not
your problem any longer.
For traffic that you initiate within your site, you are sending all of
that likely to your border router and TTL permitting into the MBone
and there is no way in practice you could get a prune from the MBone
since the MBone is seriously enough broken not to achieve that.
In Finland we've also implemented a boundary that is on the DVMRP
tunnel between Helsinki and Stockholm and the DVMRP cloud also prunes
back (when that's supposed to happen) towards the sources in the PIM
cloud. With 11.1(4.1) Cisco code this actually works that way also.
I'm not sure in which 11.0 version this is fixed.

Pete

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 1 Jul 1996 12:22:19 -0700

>> neighbor of your 11.0 router and from that point it's actually not

    Not if the leaf router is a non-pruning (10.2 system).

>> since the MBone is seriously enough broken not to achieve that.

    Well this is somewhat true. But if a prune did come in....

Dino

---

From: Petri Helenius <[email-masked]>
Date: Mon, 1 Jul 1996 22:41:07 +0300 (EET DST)

>     Not if the leaf router is a non-pruning (10.2 system).
Depending on the definition of 'leaf' which seems to be different
here.
This works:
MBone<---DVMRP-->11.0<--PIM-XX-->10.2<--->LAN
This doesn't:
MBone<---DVMRP-->10.2<--PIM-XX-->Any IOS<--->LAN

Definition of works:
- Pruning is functional towards the MBone.

Pete