February 2002 - Test - lists.nanog.org

Re: Reducing Usenet Bandwidth
by rs＠seastrom.com 03 Feb '02

03 Feb '02

Jared Mauch <jared(a)puck.nether.net> writes: > The routers don't tend to have very multicast related bugs anymore, > it's all people who can't configure their routers. > > Of the 100+ sessions that are in sdr/sap these days I can typically > reach (at least) 65%+ of them without any problems. I'll buy that. Better than it was a year and a half or so ago, that's for sure. But nowhere near acceptable IMHO. ---Rob

1 0

Re: Reducing Usenet Bandwidth
by rs＠seastrom.com 03 Feb '02

03 Feb '02

"Stephen Sprunk" <ssprunk(a)cisco.com> writes: > > Thinking about doing multicast Usenet feeds as a way to cut down the > > bandwidth in and out of your ISP overlooks the fact that reliable > > transport for such things doesn't exist. > > Ah, but the point of Muse was not to provide reliable news service, but to > reduce the average propagation time and provide "good enough" delivery which > could be supplanted by a traditional reliable feed. I probably shouldn't have used the term "reliable transport" because I'm talking about propensity for one's network to break (ie, whether you can count on the transport being available), not reliable data streams a la TCP. "High maintenance" in the vein of Sally Albright in "When Harry Met Sally" is probably more appropriate. ---Rob

1 0

Re: Legacy NAP/NSP support
by Ted Fischer 02 Feb '02

02 Feb '02

At 04:26 PM 2/2/02 -0500, Sean wrote: >I was wondering if any NSP or NAP still supports the requirement >to carry OSI/CLNP traffic. > > > NAPs can be proposed to be implemented as LANs or MANs or > > other innovative approaches. NAPs must operate at speeds > > commensurate with the speeds of attached networks and > > must be upgradable as required by demand, usage, and > > Program goals. NAPs must support the switching of IP > > (Internet Protocol) and CLNP (ConnectionLess Networking > > Protocol) packets > >I think this is a legacy, aka obsolete, requirement. But some >folks with checklists insist you can't be a NSP or NAP if you >don't support it. All my memory is not firing these days (somtimes working on 71 pins), but methinks I recall from my active duty days a requirement that came out around 89/90 (?) that stated something like "all future procurements of DOD computer hardware and software (in 1980's verbiage, I'm sure) must be OSI compliant". I remember shaking my head, wondering where and how I was going to find this equipment, but it never became a problem because there was (may have also been) a clause that included "TCP/IP" as an acceptable option ... I just don't recall all the details. I think this may have been driven by the reasoning of some at the time the we would soon be seeing TCP/IP in our rear view mirror was we embraced "International Standards" (CMIP anyone?). Further background ... the "new" DOD messaging progam (Defense Message System, or DMS) RFP included a requirement for the selected vendor to offer software that supported both "Internet" protocols and "OSI" protocols. In all my contact with military commands and civilian agencies working in DMS implentation I have never come across anyone who was running OSI protocols in house, and would therefore need (or choose) the OSI version of the software. Also, DMS requirements state that if you do use the OSI version of the software, you must translate CLNP to IP via your _own_ "gateway" into the uNclassified but sensitive Internet Protocol Routed NETwork (NIPRNET), or Secret Internet Protocol Routed NETwork (SIPRNET), because those military networks (and their associated "NAPs", if you will) only - by definition - support IP today. Note "military" references above. I wonder, then, if the definition of a "NAP" associated with this requirement refers to an ARPANET NAP, (look up "legacy" for a picutre) and really has (or should not have) any meaning today. Perhaps it is time to really redefine a NAP. Ted Fischer On my own

1 0

Exodus Sale to C&W Completed
by Tim Wilde 02 Feb '02

02 Feb '02

It's been announced today that the sale of Exodus to C&W has been completed, after approval by the courts and regulatory agencies. Executive summary is that Exodus will run as a separate business unit, with all C&W and Digital Island hosting coming under the Exodus name with the C&W "globe" logo. Full details at: http://www.exodus.net/about_exodus/press_room/press_releases/20020201_01.ht… The only question that remains in my mind, as an Exodus customer, is "will they merge the IP networks?" And I sure hope the answer is no :) Tim -- Tim Wilde twilde(a)dyndns.org Systems Administrator Dynamic DNS Network Services http://www.dyndns.org/

6 6

Re: Reducing Usenet Bandwidth
by Robert Boyle 02 Feb '02

02 Feb '02

At 04:06 PM 2/2/2002 -0500, you wrote: >On Sat, 2 Feb 2002, Alex Rubenstein wrote: > > > Perhaps the same time the end-users (whose fees go towards paying for the > > hardware, presumably) say "we don't want binaries anymore." > >It would be interesting to survey the customers and see: > >A) how many would care if we didn't provide usenet >B) how many would care if we didn't carry any binaries >C) how many have never heard of usenet > >I suspect A and B would be small, and C large. We are a medium sized ISP with about 15,000 customers using connection types from dialup to T3. We have found that at any given time, we have 5-10 users connected to our news server per hour. Assuming the average session is at least 1-2 hours for most binaries users and the same people probably use news each day... .0002% of our users actually use usenet. We have outsourced news for about 2 years to Giganews and we have found it to be a far more effective solution for our needs anyway. -Robert Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Good will, like a good name, is got by many actions, and lost by one." - Francis Jeffrey

1 0

Legacy NAP/NSP support
by Sean Donelan 02 Feb '02

02 Feb '02

I was wondering if any NSP or NAP still supports the requirement to carry OSI/CLNP traffic. > NAPs can be proposed to be implemented as LANs or MANs or > other innovative approaches. NAPs must operate at speeds > commensurate with the speeds of attached networks and > must be upgradable as required by demand, usage, and > Program goals. NAPs must support the switching of IP > (Internet Protocol) and CLNP (ConnectionLess Networking > Protocol) packets I think this is a legacy, aka obsolete, requirement. But some folks with checklists insist you can't be a NSP or NAP if you don't support it.

1 0

NANOG 24: NAP BoF
by Mike Hughes 02 Feb '02

02 Feb '02

Hi all, As you may have seen from the NANOG 24 agenda, I'm running two NAP sessions at the coming meeting. In the General Session, there is a NAP update, from a handful of NAPs. We've had to keep this session small, and tightly timed, to fit well into the agenda. On the Monday evening, we'll have a NAP BoF session, which will I'm planning on being fairly free-form, but will consist of: * an "open-mic" for operators who didn't participate in the general session to introduce themselves and their IX/NAP. * a chance to carry out further discussion of any "hot topics" from the general session - I've even asked for a whiteboard/flipchart. * a place where participants get the opportunity to meet and chat with the operators of the NAPs where they participate now, or may be participating in the future. * We'll probably head toward the bar at some point too... :-) Why have we chosen to split it up like this? Well, in Europe, at the RIPE meeting, there is an open European IXP working-group for which we get 3 hours of agenda time. Not all the IXPs show up, and still we are hard-pressed to fit things in the schedule! So, if there are any NAP/IX operators who would be interested in coming along to the evening BoF, drop me a mail, or you're free to just turn up on the night. Of course, we would also like plenty of NAP participants to show up too! It will also be a good chance to meet with potential new peers as well... See you in Miami! Mike

12 19

The Cidr Report
by CIDR Report 02 Feb '02

02 Feb '02

This is an auto-generated mail on Fri Feb 1 23:00:00 PST 2002 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 01Feb02 0) General Status Table History ------------- Date Prefixes 250102 104855 260102 104659 270102 104702 280102 104727 290102 104793 300102 105544 310102 105664 010202 105568 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 12323 Number of ASes announcing only one prefix: 7490 (4238 cidr, 3252 classful) Largest number of cidr routes: 705 announced by AS701 Largest number of classful routes: 1364 announced by AS701 1) Gains by aggregating at the origin AS level --- 01Feb02 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1171 901 270 23.1% Telstra Pty Ltd AS701 1364 1130 234 17.2% UUNET Technologies, Inc. AS4151 287 156 131 45.6% USDA AS577 318 194 124 39.0% Bell Advanced Communications Inc. AS16473 198 77 121 61.1% Bell South AS7018 818 700 118 14.4% AT&T AS6595 172 61 111 64.5% DoD Education Activity Network As AS17557 196 85 111 56.6% Pakistan Telecom AS705 286 183 103 36.0% UUNET Technologies, Inc. AS7046 327 226 101 30.9% UUNET Technologies, Inc. AS852 384 288 96 25.0% Telus Advanced Communications AS19632 94 9 85 90.4% Metropolis Intercom S.A. AS2048 185 105 80 43.2% State of Louisiana AS12302 112 33 79 70.5% MobiFon S.A. AS1239 469 393 76 16.2% Sprint AS4755 222 151 71 32.0% Videsh Sanchar Nigam Ltd. Autonom AS703 275 213 62 22.5% UUNET Technologies, Inc. AS3464 159 97 62 39.0% Alabama SuperComputer Network AS4200 118 57 61 51.7% Apex Global Information Services, AS7303 107 49 58 54.2% Telecom Argentina Stet-France Tel AS724 210 153 57 27.1% DLA Systems Automation Center AS16758 63 6 57 90.5% IKON Office Solutions AS3908 329 273 56 17.0% Supernet, Inc. AS226 145 89 56 38.6% Los Nettos AS13999 70 14 56 80.0% Mega Cable S.A. de C.V. AS702 654 599 55 8.4% UUNET Technologies, Inc. AS19834 63 8 55 87.3% NetForce, Inc. AS4323 384 330 54 14.1% Time Warner Communications, Inc. AS2149 310 257 53 17.1% Performance Systems, Inc. AS1 487 436 51 10.5% BBN Planet Total 53887 42128 11759 21.8% For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Re: DNS DOS increasing?
by Steven M. Bellovin 01 Feb '02

01 Feb '02

In message <24810615.1012581411(a)[172.25.106.112]>, Mike Batchelor writes: > >Stop allowing the world to recurse through your authoritative servers. >This invites abuse. > >Provide a separate set of servers for your customers to recurse through, >which serve no authoritative data and which have access restricted to your >own network and your customers'. > >--On Saturday, January 19, 2002 1:59 PM -0500 Matt Martini ><martini(a)invision.net> wrote: > >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> I've been seeing some strange problems in DNS lately (named 8.2.4-REL) >> where the nameserver stops resolving certain sites. During investigation >> I noticed that my query rate is way up. Many more DNS requests than >> normal are hitting my servers. Is anyone else seeing anything like this? You might be the intermediary in a DNS reflector attack (see http://www.icir.org/vern/papers/reflectors.CCR.01/index.html for details) --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.com

1 0

DNS DOS increasing?
by Matt Martini 01 Feb '02

01 Feb '02

-----BEGIN PGP SIGNED MESSAGE----- I've been seeing some strange problems in DNS lately (named 8.2.4-REL) where the nameserver stops resolving certain sites. During investigation I noticed that my query rate is way up. Many more DNS requests than normal are hitting my servers. Is anyone else seeing anything like this? Matt __________________________ http://www.invision.net/ _______________________ Matthew E. Martini, PE InVision.com, Inc. (631) 543-1000 x104 Chief Technology Officer matt(a)invision.net (631) 864-8896 Fax _______________________________________________________________________pgp_ -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1i iQEVAwUBPEnCFmtXn16/JS7ZAQHZnAf9HUy+AtG7xOhKoHvPvjtESVdLLtw8ZKto xRkvSvzLIFUep77vi7w/CXQ7RBpoOrHMp1y1WFRMdwaVp4WWGk5qdiqcrtQiAyWn vmzP+VbaW3TT0jdRAdz98O1bW98GCZwLa9WR/xdO0bSQOvtCFuqV0P3XqGmTO0Jl fI7TViUzF6LpOcGGrTKxxj+A7rlOVVjCRozilZsMDKG9QVGZwdSG7/u8K+3U9mIq keyZKGRla1tFbVp4VXEaC6P0zdxh2OHqMTZSdd9nETQEFf9vUjR/ZUfXQfK5l3A9 4GCyAQ3VjhCFdt+xWBww2zh0c0F531eMrFCrrrU4jue4E+0Wuih89g== =+eIJ -----END PGP SIGNATURE-----

4 3