- Test - lists.nanog.org

Request
by System Administrator# 30 Oct '95

30 Oct '95

Would you mind .... Subscripte E-mail: chkim(a)garam.kreonet.re.kr ---------------------------------------------- P.O.BOX 1,Youseong-Gu Taejeon-City (Zip Code) 305 - 600 KOREA KIST KOREA INSTITUTE OF SCIENCE AND TECHNOLOGY ( KIST ) SERI SYSTEM ENGINEERING REASEARCH INSTITUTE ( SERI ) ~~~~ National R&D Network Center [ Phone:042-869-1390/FAX:042-861-1999 ] KREONet ( Korea Research Environment Open Network ) ~~~~~~~ [ Phone:+8242-869-1390 ] [ E-mail: chkim(a)garam.kreonet.re.kr ] Choon-Hyoung Kim [ E-mail: chkim(a)garam.kreonet.re.kr ]

1 0

Black holes caused by aggregation
by bmanning＠ISI.EDU 26 Oct '95

26 Oct '95

My appologies if you have already seen this. It appears to be an operational/configuration issue that our clients might be interested in..... :) Perhaps its time to upgrade all that mbone/mrouted software out there. > From: Bill Fenner <fenner(a)parc.xerox.com> > Subject: Black holes caused by aggregation > Date: Wed, 25 Oct 1995 18:52:46 PDT > > Longest-match routing was introduced in mrouted version 3.5 . Previous > versions would only accept the least specific route that it heard, and > if it heard routes that overlapped it would log a message and drop the > new route. > > People now appear to be using Cisco's route aggregation feature in > places that it shouldn't be used, which will cause problems when > forwarding through mrouted versions previous to 3.5 (which is about 75% > of the MBONE). A nice example of the breakage is net UIUC-CAMPUS-B, > 128.174. (Not to pick on UIUC in particular, but it's the easiest > example for me.) The three routes that I have in my routing tables for > 128.174 are: > > 128.174.212.0/25 > 128.174.240/24 > 128.174/16 > > Note that the last route covers the first two, and mrouted versions previous > to 3.5 will only accept the last route. In fact, if I traceroute towards > 128.174.0.0, I have a nice short route: > > Mtrace from 128.174.0.0 to 204.162.228.2 via group 224.2.0.1 > Querying full reverse path... > 0 dartvader (204.162.228.2) > -1 parc.dart.net (204.162.228.1) DVMRP thresh^ 1 200 s > -2 ames.dart.net (140.173.144.1) DVMRP thresh^ 1 200 s > -3 mbone2.nsi.nasa.gov (192.203.230.242) DVMRP thresh^ 64 200 s > -4 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 1 200 s > -5 oday.psc.edu (192.88.114.10) DVMRP thresh^ 64 176 s > -6 mbone.merit.edu (198.108.2.20) DVMRP thresh^ 64 201 s > -7 tibia.cic.net (192.217.65.100) DVMRP thresh^ 32 254 s Next router no mtrace > -8 dcl2.gw.uiuc.edu (192.17.2.8) [proteon/mrouted 1.0] doesn't support mtrace > > However, if I trace towards one of the specific routes, I end up taking > the shortest mrouted-3.5-or-greater path: > > Mtrace from 128.174.240.0 to 204.162.228.2 via group 224.2.0.1 > Querying full reverse path... > 0 dartvader (204.162.228.2) > -1 parc.dart.net (204.162.228.1) DVMRP thresh^ 1 200 s > -2 ames.dart.net (140.173.144.1) DVMRP thresh^ 1 200 s > -3 mbone2.nsi.nasa.gov (192.203.230.242) DVMRP thresh^ 64 200 s > -4 mbone.nsi.nasa.gov (192.203.230.241) DVMRP thresh^ 1 200 s > -5 mbone.sdsc.edu (198.17.47.39) DVMRP thresh^ 64 200 s > -6 VINEGAR.SESQUI.NET (128.241.0.91) DVMRP thresh^ 64 201 s > -7 mae-bone.psi.net (192.41.177.247) DVMRP thresh^ 64 128 s > -8 MBONE1.UU.NET (137.39.43.34) DVMRP thresh^ 64 201 s > -9 MBONE2.UU.NET (137.39.246.98) DVMRP thresh^ 64 201 s > -10 dec3800-2-fddi-0.SanFrancisco.mci.net (204.70.158.61) DVMRP thresh^ 64 2828 ms > -11 dec3800-2-fddi-0.Denver.mci.net (204.70.152.61) DVMRP thresh^ 1 41 s > -12 dec3800-1-fddi-0.WillowSprings.mci.net (204.70.104.29) DVMRP thresh^ 1 -24 s > -13 tibia.cic.net (192.217.65.100) DVMRP thresh^ 32 254 s Next router no mtrace > -14 dcl2.gw.uiuc.edu (192.17.2.8) [proteon/mrouted 1.0] doesn't support mtrace > Round trip time 295 ms > > Now, you might say "Well, that just means that traffic is taking a suboptimal > path, no big deal." But, because of the way DVMRP builds its forwarding > trees, traffic that matches the specific routes (e.g. 128.174.240.1) will > *not* get forwarded from a 3.5-and-up to a 3.4-and-down mrouter. Here is > a (slightly altered, since there is no active source in 128.184.240.x right > now) mtrace showing what you would see on that boundary: > > Mtrace from 128.174.240.0 to 141.210.188.1 via group 224.2.0.1 > Querying full reverse path... > 0 ? (141.210.188.1) > -1 ? (141.210.188.3) DVMRP thresh^ 1 208 s > -2 mbone.wayne.edu (141.217.1.74) DVMRP thresh^ 32 -250 s Not forwarding > -3 mbone.merit.edu (198.108.2.20) DVMRP thresh^ 32 201 s > -4 tibia.cic.net (192.217.65.100) DVMRP thresh^ 32 254 s Next router no mtrace > -5 dcl2.gw.uiuc.edu (192.17.2.8) [proteon/mrouted 1.0] doesn't support mtrace > > Note the "Not forwarding" error code on the mbone.wayne.edu line. > 141.210.188.3 is 3.4, mbone.wayne.edu is 3.5 . (Again, not to pick > on wayne.edu; this was the easiest test case that I could come up with.) > > This means that if you are one of the people advertising this kind of > specific and general routes, that you are isolating your traffic from > the specifically routed subnets to the connected cloud of 3.5-and-above > routers. Of course, the long term solution is to get the whole MBONE > able to accept this kind of routing; the short term solution, however, > is not to advertise this kind of route. Therefore, I will be periodically > posting a list of routes that fall into this category; hopefully, the > people responsible for those networks will reconfigure their routers to > either advertise only a general route or only non-overlapping specific > routes. > > The list follows. I will be posting this list (with a shorter explanation) > periodically. > > Bill > > 36.18/16 is covered by 36/8 > 36.53/16 is covered by 36/8 > 36.56/16 is covered by 36/8 > 36.103/16 is covered by 36/8 > 36.153/16 is covered by 36/8 > 36.224/16 is covered by 36/8 > 128.32.211/24 is covered by 128.32/16 > 128.32.226/24 is covered by 128.32/16 > 128.171.3/24 is covered by 128.171/16 > 128.171.10/24 is covered by 128.171/16 > 128.171.11/24 is covered by 128.171/16 > 128.171.45/24 is covered by 128.171/16 > 128.174.212.0/25 is covered by 128.174/16 > 128.174.240/24 is covered by 128.174/16 > 132.250.88.170/32 is covered by 132.250.88.160/28 > 137.194.2/23 is covered by 137.194/16 > 137.194.34/23 is covered by 137.194/16 > 137.194.98/23 is covered by 137.194/16 > 137.194.160/23 is covered by 137.194/16 > 137.194.224/23 is covered by 137.194/16 > 137.194.230/23 is covered by 137.194/16 > 137.194.232/23 is covered by 137.194/16 > -- --bill

1 0

A bunch-of-morons
by avg＠postman.ncube.com 26 Oct '95

26 Oct '95

Check http://www.hyperspace.net for a good laugh. (Credits to Sean for discovering it). --vadim

1 0

Re: Initial Route Server Stats for MAE-East
by Steven J. Richardson 24 Oct '95

24 Oct '95

Tim: 1) I'm Steve, not Richard. 2) Yes, I did find your analogy (which you admitted was "crude") to be offensive. That was my point. I really don't see the point of that sort of comment in a technical discussion. also... >From bass(a)dune.silkroad.com Tue Oct 24 16:09:07 1995 >From: Tim Bass <bass(a)dune.silkroad.com> >Message-Id: <199510242006.QAA06544(a)dune.silkroad.com> >Subject: Re: Initial Route Server Stats for MAE-East >To: sjr(a)merit.edu (Steven J. Richardson) >Date: Tue, 24 Oct 1995 16:06:08 -0400 (EDT) >Cc: young(a)mci.net, curtis(a)ans.net, mnasto(a)franklin.nysernet.org, > mo(a)uunet.uu.net, nanog(a)home.merit.edu, wbn(a)merit.edu >In-Reply-To: <199510241659.MAA17828(a)home.merit.edu> from "Steven J. Richardson" at Oct 24, 95 12:59:40 pm >> >> >' make sure to put all the hair in your pants before >> > zipping your zipper..... notes ... SPAMtastic >> >> Is this really necessary? I don't see any technical point in this >> sort of argument. >> > >No, Richard, it is not 'really necessary'. I hope that you did not >find my crude analogy offensive. >I plead guilty to taking >my opinion to somewhat arrogant extremes in the above statement. >Furthermore, I made the mistake of thinking that this tread was on >com-priv. Ah... >If I had been more cognizant of the fact that this >discussion was on nanog, I would not have posted such a harsh >critique. > >My mistake, too quick on the elm keys, for sure. Thanks > >Regards, > >Tim Steve Richardson/Merit

1 0

Re: Initial Route Server Stats for MAE-East
by Steven J. Richardson 24 Oct '95

24 Oct '95

>From list-admin(a)merit.edu Sun Oct 22 22:24:49 1995 >From: Tim Bass <bass(a)dune.silkroad.com> >Message-Id: <199510230155.VAA03167(a)dune.silkroad.com> >Subject: Re: Initial Route Server Stats for MAE-East >To: young(a)mci.net (Jeff Young) >Date: Sun, 22 Oct 1995 21:55:04 -0400 (EDT) >Cc: mnasto(a)franklin.nysernet.org, mo(a)uunet.uu.net, curtis(a)ans.net, > wbn(a)merit.edu, nanog(a)home.merit.edu >In-Reply-To: <199510230104.VAA15334(a)foghorn.reston.mci.net> from "Jeff Young" at Oct 22, 95 09:04:19 pm >X-Mailer: ELM [version 2.4 PL24 PGP2] >MIME-Version: 1.0 >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: 7bit >Content-Length: 1915 >Status: RO > Tim: >' make sure to put all the hair in your pants before > zipping your zipper..... notes ... SPAMtastic Is this really necessary? I don't see any technical point in this sort of argument. >Tim > >-- >+--------------------------------------------------------------------------+ >| Tim Bass | #include<campfire.h> | >| Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | >| The Silk Road Group, Ltd. | take_one_down(); | >| | pass_it_around(); | >| http://www.silkroad.com/ | } | >| | back_to_work(); /*never reached */ | >+--------------------------------------------------------------------------+ Steve Richardson speaking for himself, not Merit Network, Inc.

2 1

bcast LQM
by William Allen Simpson 24 Oct '95

24 Oct '95

> From: Curtis Villamizar <curtis(a)ans.net> > LQM on non-PPP links sure would be great. A number of times I've > suggested we consider LQM on bcast, with a set of LQM parameters per > ARP entry. This way one end sends a LQM packet that serves as a time > marker, counts packets, then includes the count in the next LQM time > marker. The receiver needs only count packets between LQM packets and > compare the local count against the count sent by the other end. This > is an enormously oversimplified summary of LQM, but it just to make > the point that LQM is Good Stuff. > Yes, but a bit tough on broadcast, as you would need all nodes sending a history of all the other LQM counts it heard. Quite a big packet or set of packets with many nodes participating. What might be a better idea is to add it to BGP-n. Say between routing peers. That's what I did for IPng, in my (now mangled) Neighbor Discovery. > In the absence of LQM we have the DS3 MIB (poor substitute) Hey, the original PPP LQM was designed and built for DS3 (at Network Systems). NSFnet was very interested at the time. Aren't we already running PPP LQM for all the DS3's? PPP LQM was one of the reasons for PPP/FrameRelay, too. Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

2 1

Re: IPPM: Measuring IP performance
by Guy T Almes 24 Oct '95

24 Oct '95

Kent, Two minor changes, but I'd like to underscore the rest of your note. -- Guy At 09:11 PM 10/23/95 -0800, Kent W. England wrote: > >Then there is treno, Matt's latest tool. From a note by Matt to IPPM list: > >" >... send a note to ippm-request(a)psc.edu. this should now be <ippm-request(a)advanced.org> > >>From the draft charter: >The IPPM WG will develop a set of standard metrics that can be applied to the >the quality, performance and reliability of an IP datagram service. These >metrics will be designed such that they can be performed by the providers >themselves, customers, potential customers or independent testing groups. The work is now organizationally taking place within the Benchmark Methodology WG, and we'll be meeting at the Dallas IETF. -- Guy

1 0

IPPM: Measuring IP performance
by kwe＠6SigmaNets.com 24 Oct '95

24 Oct '95

At 5:44 PM 10/22/95, Brett D. Watson wrote: > > Has anyone come up with *any* way to measure network performance (packet >loss, throughput, delay) other than ping and traceroute? ttcp with a good tcpdump sniffer is very useful. Matt Mathis, sparkplug of the IPPM, invented "wping" which is useful but dangerous to use because of loading. Then there is treno, Matt's latest tool. From a note by Matt to IPPM list: " ... send a note to ippm-request(a)psc.edu. >From the draft charter: The IPPM WG will develop a set of standard metrics that can be applied to the the quality, performance and reliability of an IP datagram service. These metrics will be designed such that they can be performed by the providers themselves, customers, potential customers or independent testing groups. There is now a home page at http://www.psc.edu/~mathis/ippm, including pointers to the minutes, etc. " ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~ Kent W. England <URL:pots://619.632.8400/Hello,Kent?> Six Sigma Networks <URL:fax://1+619.632.8400/SEND> 1655 Landquist Drive, Suite 100 <URL:mailto:kwe@6SigmaNets.com> Encinitas, CA 92024 <URL:pagerto:kwe-pager@pbi.net> Experienced Internet Consulting ~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~

1 0

Initial Route Server Stats for MAE-East
by William B. Norton 24 Oct '95

24 Oct '95

Hi all - Since the deployment of the RSes at the interconnection points the RA team has been collecting network statistics including packet loss and latency across the media to our peers, BGP message counts, RS memory utilization, various interface counts on the RS, and so forth. We have installed a sample web page containing data collected at the MAE-East facility. Over the next month we will finish up the automated portion of the data collection and report generation for the rest of the interconnection points. Our MAE-East data is located at http://www.ra.net/~ra/statistics. Feedback and suggestions welcome. We will try and incorporate your ideas into the layout for next month. Thanks to Dun Liu and Susan Horvath for putting all of this together. Bill ------------------------------------------------------------------------- William B. Norton Merit Network Inc. e-mail: wbn(a)merit.edu phone: (313) 936-2656 WWW: http://home.merit.edu/~wbn

10 16

Re: MAE-East
by Vadim Antonov 24 Oct '95

24 Oct '95

"William Allen Simpson" <bsimpson(a)morningstar.com> wrote: smd> I should also note that Sprint and MCI are in the final smd> phases of negotiating direct point-to-point peerings... >You mean, we might end up with a Network instead of a Treework!?!? Net-work: n., Russian-English. 1) Any computer network, compare with meaning 2. 2) Literally: "No-work", or does not work; meaning the sustained state of a computer network (see 1). --vadim

1 0