- Test - lists.nanog.org

RE: Fwd: FW: Removal from APNIC lists
by John Fraizer - Administrator 22 May '98

22 May '98

At 12:19 PM 5/20/98 -0500, you wrote: >In other words, if someone were to block the entire 202.x.x.x >range they would be assured they would not lose any contact >with North America ? I don't know about that but when I blocked all IP's assigned to APNIC, my credit card fraud rate went down drasticly. Lil' bastards. ------- John Fraizer (tvo) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:tvo@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

2 1

RE: a little thought on exchanging traffic
by Jim Fleming 22 May '98

22 May '98

On Wednesday, May 20, 1998 6:18 AM, Sean Donelan[SMTP:SEAN@SDG.DRA.COM] wrote: @>Anyone thought about eliminating large physical exchange points and replacing @>them with a more distributed architecture? @ @Yes, lots of folks have given it lots of thought. @ @>Multiple data centers interconnected over ATM in a single metro area run by @>indepdenant entities who are free to provide any level of service or value @>add they wish. @ @The fundamental problem is there are no magic pixie dust in this business. @Sure, some people like to put out press releases saying how they've solved @all the worlds problems using the Magic Frambulator. But what they've usually @done is ignored half the problem. @ Or...they have designed systems that have the wrong goals... For example, some people design routers to "attract packets" like magnets. They design protocols for routers to tell other routers what packets to send them. Why on earth do people and companies want packets ? Processing packets costs time and money. Imagine a world where routers tell other routers what NOT to send them. Routers should be designed to "repel packets" and to quickly get rid of the ones they have. They should also be designed to send them as quickly as possible to the place they belong and not to some black-hole called a NAP so that people can puff out their chests about their NAP being bigger than the next NAP. With the introduction of next-generation Internet systems, we might have a chance to reverse some of the thinking that has produced the current bottle-necks. Organizations like NANOG can play a key role because ultimately the buck stops at your networks, routers, firewalls, servers, etc. The key to the future is to make sure packets do not also stop there or come there when you do not want them. ;-) - Jim Fleming Unir Corporation - http://www.unir.net/IPv8 IPv8 - Designed for the Rest of the Human Race AM Radio Stations ---> http://www.DOT.AM

9 9

Cisco ATM DS3 port adapter?
by Louis Destree 21 May '98

21 May '98

Greetings, I've been up one side and down the other of CCO, but I can't find an ATM DS3 port adapter for the VIP cards. They make vauge references to them online, but I can't find a part number. Anyone know if such a beastie exists? Have a part number? Thanks, Louis -- Louis A. Destree Senior Network Engineer FlashNet Communications destree(a)flash.net

4 4

Re: The questions stand
by Scott Gardner Anderson 21 May '98

21 May '98

On Thu, 21 May 1998, Karl Denninger wrote: > > On Thu, May 21, 1998 at 12:44:11AM -0400, John Fraizer - Administrator wrote: > > > > Lets see how they are performing today, shall we? > > [somebox]:~# traceroute customer.of.blah-12345-we-are-a-nap.net [snip] > > Wow. Now, that's some lightning speed. <sic> > > And NOW, lets look at someone with a real Tier One provider: > > [somebox]:~# traceroute www.mcs.net > > traceroute: Warning: Multiple interfaces found; using x.x.x.x @ eth0 > > traceroute to www.mcs.net (205.164.8.12), 30 hops max, 40 byte packets > > 1 (Default Gateway) (x.x.x.1) 0.495 ms 0.415 ms 0.385 ms > > 2 (Tier One provider) (x.x.x.21) 2.424 ms 1.630 ms 1.529 ms > > 3 aads.good.net (198.32.130.49) 15.131 ms 13.261 ms 13.930 ms > > 4 mcsnet.chicago.good.net (207.98.189.130) 14.775 ms 15.296 ms 16.193 ms > > 5 www.mcs.net (205.164.8.12) 14.592 ms 14.750 ms 14.504 ms > > BTW: Karl, lightning fast as always to your site. > > Then again, my background and engineering efforts have been geared towards > the Fortune-50 marketplace and OLTP environments where ANY packet loss or > significant hysteresis in the transport times is considered unacceptable. > Seems to depend on where you sit. John is only a few hops away (on the same 'Tier 1' provider?) as Karl, so traffic is dependant on only three parties maintaining a clean network. Across another backbone (via public view sage.aspire.net) it's not so clean, probably due to packet loss across the Tier 1 provider that they use (UUNet) or loss at an exchange point between UUNet and Napnet to get to Karl's network. ----205.164.8.12 PING Statistics---- 15 packets transmitted, 13 packets received, 13% packet loss round-trip (ms) min/avg/max = 40/52/190 Meanwhile, it's clean from where I sit: ----205.164.8.12 PING Statistics---- 21 packets transmitted, 21 packets received, 0% packet loss round-trip (ms) min/avg/max = 85/96/299 and Aspire is clean from here: ----sage.aspire.net PING Statistics---- 16 packets transmitted, 16 packets received, 0% packet loss round-trip (ms) min/avg/max = 23/30/54 but I see loss from NetAxs to me: ----199.184.165.2 PING Statistics---- 24 packets transmitted, 22 packets received, 8% packet loss round-trip (ms) min/avg/max = 29/48/70 while it's clean from NetAxs to MCS: ----www.mcs.net PING Statistics---- 17 packets transmitted, 17 packets received, 0% packet loss round-trip (ms) min/avg/max = 22/26/37 Despite our best intentions, packet loss and delay will always exists from our networks to certain destinations, no matter whether we use 'Tier 1' providers or companies that are creating private NAPs of their own. And how it looks from me to you doesn't mean much, in the long run - how it looks across the board from you to your customer's destinations is what makes a difference. If that's accomplished with a small backbone provider, a big player like MCI, or some local 'private nap' company shouldn't make any difference to anyone but yourself. SGA

1 0

51923 prefixes not announced in the last 3 months.
by Curtis Villamizar 21 May '98

21 May '98

Just an FYI- Please see: http://engr.ans.net/route-dumps/problem-summary.html 51923 prefixes in the IRR that have not been announced in the last 3 months. 7328 registered and never announced This is the list of prefixes that are registered in the IRR but have not been announced in the last three months. If these are no longer used, deleting the route objects is very easy. <http://engr.ans.net/route-dumps/orphans.html> 44595 never announced but aggregated This is the list of prefixes that are registered in the IRR but have not been announced in the last three months but are likely to still be reachable since and aggregate is announced. The route objects can be deleted, marked as withdrawn, or using RPSL, the aggregate can be marked to limit the scope of the more specific routes. <http://engr.ans.net/route-dumps/leaks.html> Reports are broken down by origin AS: http://engr.ans.net/route-dumps/orphans.html There were 7328 prefixes that are registered in the IRR but have not been announced and recorded in the route dumps taken during the past 3 months. Route dumps are taken at all border routers within ANS every 1-2 days. Below is the set of 914 origin AS under which these route objects are registered. [ ... table follows ... ] http://engr.ans.net/route-dumps/leaks.html There were 44595 prefixes that are registered in the IRR but have not been announced and recorded in the route dumps taken during the past 3 months, but are covered by an announced aggregate. These prefixes are likely to be due to previously registered and announced prefixes that are now aggregated and no longer individually announced. Route dumps are taken at all border routers within ANS every 1-2 days. Below is the set of 1417 origin AS under which these route objects are registered. [ ... table follows ... ] Please clean up your own origin AS. We'll be cleaning up the no longer announced prefixes in our origin AS and customer AS. Thanks in advance, Curtis ps- flames to /dev/null please.

1 0

NANOG 13 REMINDER
by Pam Ciesla 21 May '98

21 May '98

The NANOG attendee list has been updated. If you are not on it and should be please contact me. All attendees need to register via the webpage http://www.nanog.org. The $150 registration fee is due by Midnight EDT, May 29. The fee goes up to $170 after May 29, cancellations recieved after this date will have a $20 charge. The Hyatt Regency Dearborn is still excepting reseravations at the NANOG rate of $125 + tax per night. Be sure to mention the NANOG Meeting when registering at the hotel. Thanks ---------------------------------------------------------------------- Pam Ciesla 734-936-0172 - phone Merit Network, Inc. 734-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 -----------------------------------------------------------------------

1 0

Re: The questions stand
by John Fraizer - Administrator 21 May '98

21 May '98

At 05:17 PM 5/20/98 -0400, you wrote: >I do so wish we could get over the "tier" fixation. > >If I start the Tampa Bay Internet Exchange, let's say, and I haul in >OC-3 links from the 5 top backbones, and DS-3's to the 4 NAP's, I can >then (very likely) a) resell bandwidth to local ISP's for quite a bit less >than the backbones could sell them a local drop, which would b) be >quintuply redundant in cast of feed failure, and c) unload all the >cross provider traffic from the NAP's, and indeed, the backbone itself. That happened here in Columbus with a provider whom I won't name since they are very imfamous for threatening legal action at the drop of a hat. The fact of the matter is that they claim to be carrying some ungodly portion of the internet traffic on their "private network" thereby providing faster connections for their customers. Well, this is America folks. Lets face it. If there is opportunity for someone to make a quick buck, they will. These guys ended up with DS1's to the big-4, put in an OC3 circuit provisioned for a single DS3 to a local ISP that was a partner in the project and at the time had a 10MB partial DS3 circuit to one of the big-4 and advertised their network as "OC3 Fiber Optics based" and "Faster than a Teier One". Lets see how they are performing today, shall we? [somebox]:~# traceroute customer.of.blah-12345-we-are-a-nap.net traceroute: Warning: Multiple interfaces found; using x.x.x.x @ eth0 traceroute to customer.of.blah-12345-we-are-a-nap.net (y.y.y.y), 30 hops max, 40 byte packets 1 (default gateway) (x.x.x.1) 1.069 ms 0.454 ms 0.434 ms 2 (Tier One provider) (x.x.x.21) 1.456 ms 1.295 ms 1.268 ms 3 aads-nap.att.net (198.32.130.60) 42.083 ms 55.715 ms 51.440 ms 4 br2-a3110s2.cgcil.ip.att.net (192.205.31.122) 50.639 ms 54.973 ms 51.153 ms 5 br1-h30.sl9mo.ip.att.net (12.127.15.210) 59.831 ms 51.588 ms 44.678 ms 6 ar1-a300s1.sl9mo.ip.att.net (12.127.4.5) 42.652 ms 33.012 ms 35.015 ms 7 (y.y.y.y) 50.081 ms 42.371 ms 43.084 ms 8 customer.demarc.blah-12345-we-are-a-nap.net (y.y.y.y) 69.753 ms 74.542 ms OSPF? (y.y.y.z) 89.058 ms 9 router.customer.of.blah-12345-we-are-a-nap.net (y.y.y.y) 92.875 ms 87.486 ms 95.569 ms 10 www.customer.of.blah-12345-we-are-a-nap.net (y.y.y.y) 86.939 ms 58.300 ms 64.930 ms Wow. Now, that's some lightning speed. <sic> And NOW, lets look at someone with a real Tier One provider: [somebox]:~# traceroute www.mcs.net traceroute: Warning: Multiple interfaces found; using x.x.x.x @ eth0 traceroute to www.mcs.net (205.164.8.12), 30 hops max, 40 byte packets 1 (Default Gateway) (x.x.x.1) 0.495 ms 0.415 ms 0.385 ms 2 (Tier One provider) (x.x.x.21) 2.424 ms 1.630 ms 1.529 ms 3 aads.good.net (198.32.130.49) 15.131 ms 13.261 ms 13.930 ms 4 mcsnet.chicago.good.net (207.98.189.130) 14.775 ms 15.296 ms 16.193 ms 5 www.mcs.net (205.164.8.12) 14.592 ms 14.750 ms 14.504 ms [somebox]:~# The Tier one's who want the business will maintain adequate bandwidth for their downstreams. Time and time again, people who haven't been interested in investing in the facilities to provide Tier One access have cut corners to line their pockets at the expence of their downstreams who far too often have no clue and accept the poor performance of their circuit as "normal." BTW: Karl, lightning fast as always to your site. ------- John Fraizer (tvo) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:tvo@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

3 2

Re: The questions stand
by John Fraizer - Administrator 21 May '98

21 May '98

At 09:43 AM 5/21/98 -0400, you wrote: >Yes, John, I've been reading NANOG long enough to be aware that there >are hundreds of ways to do it wrong. > >There are about a dozen ways to do it right, too. > >There are only about 40 ISPs in this area, OC-3 is probably overkill... >not to mention whether it's actually _available_ reasonably, but you'll >notice that's where I started. You tell the telco what you're up to and they'll gladly provision you on glass. It is much more cost effective for them than to provision (and maintain) multiple copper circuits. > >Cheers, >-- jra >-- >Jay R. Ashworth jra(a)baylink.com >Member of the Technical Staff Unsolicited Commercial Emailers Sued >The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, >Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592 > >Managing Editor, Top Of The Key sports e-zine ------------ http://www.totk.com > > ------- John Fraizer (tvo) | __ _ | The System Administrator | / / (_)__ __ ____ __ | The choice mailto:tvo@EnterZone.Net | / /__/ / _ \/ // /\ \/ / | of a GNU http://www.EnterZone.Net/ | /____/_/_//_/\_,_/ /_/\_\ | Generation A 486 is a terrible thing to waste...

1 0

SkyTel 2Way pagers DOWN all US
by Mark Allan Rizzo 21 May '98

21 May '98

Just wanted to inform anyone that relies on this for system notifications etc. Skytel lost a satellite feed and all of their 2-Way pagers are down. I called them and they told me that it had been down since 5:00pm CST and they hoped to have it back 'soon'. Mark Rizzo Origin Systems, INC

14 20

Re: a little thought on exchanging traffic
by Tim Salo 20 May '98

20 May '98

> From: black(a)bleep.ishiboo.com > Subject: a little thought on exchanging traffic > To: nanog(a)merit.edu > Date: Tue, 19 May 1998 16:03:17 -0500 (EST) > > Anyone thought about eliminating large physical exchange points and replacing > them with a more distributed architecture? > > Multiple data centers interconnected over ATM in a single metro area run by > indepdenant entities who are free to provide any level of service or value > add they wish. Why restrict yourself to a single metro area? Why not simply use a nationwide ATM service? -tjs

4 4