- NANOG - lists.nanog.org

uunet fiber cut (pgh, pa)
by deeann mikula 20 Jun '00

20 Jun '00

does anyone have the scoop on the "major fiber cut" in the UUnet backbone affecting areas around pgh, pa? i just sat thru two separate hold queues of about 40 minutes each time only to be given a master ticket number regarding a major fiber cut (no ETA.) for us, the outtage was apparent at about 18:00 EDT, and is holding steady now at approx 22:00. [for the rest of you inconvenienced by this outtage, at least you weren't celebrating your AND your significant other's birthday at bar...only to have to sit on hold with UUnet for entire time! :) ] deeann m.m. mikula network administrator telerama internet abuse@telerama.com/spam@telerama.com

1 0

Re: Media: Demise of the UUCP mapping project
by Steven M. Bellovin 20 Jun '00

20 Jun '00

In message <394EA7ED.3652707F(a)NorthShoreTechnologies.net>, Steve Sobol writes: > > >http://www.wired.com/news/print/0,1294,37031,00.html > >Quoted in the article: Stan Barber and Eric Ziegast, >along with our friends Randy Bush and Roeland Meyer. Speaking as the original author of pathalias, I agree -- it's time to shut down the project. --Steve Bellovin

1 0

Media: Demise of the UUCP mapping project
by Steve Sobol 19 Jun '00

19 Jun '00

http://www.wired.com/news/print/0,1294,37031,00.html Quoted in the article: Stan Barber and Eric Ziegast, along with our friends Randy Bush and Roeland Meyer. -- North Shore Technologies, Cleveland, OH http://NorthShoreTechnologies.net Steve Sobol, BOFH - President, Chief Website Architect and Janitor Spammers and Net-abusers: Don't bother asking me for service. See http://NorthShoreTechnologies.net/go/policy/ for more information.

1 0

RE: Jumbo Frames (was Re: MAE-EAST Moving? from Tysons corner toreston VA. )
by sthaug＠nethelp.no 19 Jun '00

19 Jun '00

> > These are important for many reasons. Without these > > techniques, we can't > > even do line rate GigE on "common place" servers, let alone > > have any CPU > > left over to do more then just send packets. > > Actually, my testing shows a falure to utilize even 100baseTX > fully. Even in a switched FDX environment (no collisions) I can't > achieve line rate without bumping the packet size up. Considering > that the smallest box is a quad-CPU SMP machine (550Mhz), I don't > think that there is a CPU shortage <grin>. The your problem probably lies elsewhere. A decent operating system (e.g. FreeBSD) can do line rate on 100baseTX with something along the line of a Pentium-166. Not exactly a very powerful machine by current standards. (And btw this was measured three years ago...) Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

4 3

Re: using IRR tools for BGP route filtering
by Peter Francis 19 Jun '00

19 Jun '00

My mistake in the original post. I am looking for the list of (for instance) customers of Sprint that are purely "downstream" of Sprint. Now that I think about there may not be any easy way to distinguish between a small ISP that is multi-homed to Sprint and some other provider (their traffic I would want to send to Sprint) and BBN (who also appear to be one AS hop behind Sprint from my networks perspective and whose traffic I do not want to send to Sprint.) I know I can come up with a list of "major" backbone AS's and filter their traffic off by hand but I was looking for a "cleaner" solution by using the IRR. I hope that clarifies what I am trying to accomplish. Peter At 2:35 PM -0700 6/19/00, Joe Rhett wrote: > > How would one extract the following information from the IRR: > >> the list of AS's which are non-transit customers of a given backbone provider > >Wish upon a star? > >If they are non-transit customers, then their networks won't be announced >outside of that provider's own network. So unless you can access that >provider's own BGP tables directly you can't know this information. > >-- >Joe Rhett Chief Technology Officer >JRhett(a)ISite.Net ISite Services, Inc. > >PGP keys and contact information: http://www.noc.isite.net/Staff/

2 1

Re: PMTU-D: remember, your load balancer is broken
by Paul Vixie 19 Jun '00

19 Jun '00

akyol(a)akyol.org ("Bora Akyol") writes: > FYI, there are core routers out there that can support line rate > HW-based fragmentation. I believe this is necessary in any router > with heterogeneous interfaces. OK, somebody check me on this. "Line rate" means back to back, minimum spaced packets. Fragmentation means turning single packets into multiple packets. Each such packet will have its own headers, thus, fragmentation means turning a single header into multiple headers. Headers take space. Therefore if there's a 100Mb/s FDDI (MTU 4400) on the input side of a router, and a 100Mb/s FastEthernet (MTU 1500) on the output side of that router, then there WILL be lossage due to fragmentation, since "line rate" on the output side has more IP headers octets per IP payload octet than "line rate" on the input side did. This is a contrived example but there are more complex and more subtle flows in real life that would excite this problem. Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed. -- Paul Vixie <vixie(a)mibh.net> SVP for Internet Services, MFNX M.I.B.H. Inc. is a subsidiary of Metromedia Fiber Network, Inc.

1 0

Re: Private and Public Peering
by Paul Vixie 19 Jun '00

19 Jun '00

At 21:42 06/18/2000 -0700, Steve Feldman wrote: > The closest to a real distinction that I've been able to come up with is > whether or not a third party is involved *and* whether packets (or cells) > are switched. smarcus(a)genuity.com (Scott Marcus) writes: > What most people mean by "private peering" is a direct interconnection > between two providers. That's most often implemented over a circuit > between the two, without either deploying equipment to the other's > premises; again, however, that's simply a matter of engineering > convenience. These connections are conceptually point-to-point. I like Steve's distinction better. When folks peer at PAIX, they do so with a "direct interconnection between two providers". The fact that both providers have extended their networks to PAIX, or are using PAIX as a POP, doesn't make the "peering" less "private". -- Paul Vixie <vixie(a)mibh.net> SVP for Internet Services, MFNX M.I.B.H. Inc. is a subsidiary of Metromedia Fiber Network, Inc.

2 1

Re: Pacbell Internet NOC #?
by Walter Prue 19 Jun '00

19 Jun '00

Dan, >Does Pacbell Internet have a NOC phone #? You might try 800-463-8724. It is possible that that 800 number only works in California. I don't know. Walt

1 0

Pacbell Internet NOC #?
by Dan Hollis 19 Jun '00

19 Jun '00

Does Pacbell Internet have a NOC phone #? Jared's NOC list doesnt list one, only an email address. -Dan

1 0

Re: Jumbo Frames (was Re: MAE-EAST Moving? from Tysons corner to reston VA. )
by Richard A. Steenbergen 19 Jun '00

19 Jun '00

> On Mon, 19 June 2000, "Bora Akyol" wrote: > > > As long as most end users are running Ethernet, Fast Ethernet, DSL or Cable > > Modems, what is the point of jumbo frames/packets other than transferring > > BGP tables really fast. Did any one look into how many packets are moved > > through an OC-48 in 1 seconds. (approx. 6 million 40 byte packets). I think > > even without jumbo frames, this bandwidth will saturate most CPUs. > > > > Jumbo frames are pointless until most of the Internet end users switch to a > > jumbo frame based media. > > > > Yes, they look cool on the feature list (we support it as well). Yes they > > are marginally more efficient than 1500 byte MTUs ( 40/1500 vs 40/9000). But > > in reality, 99% or more of the traffic out there is less than 1500 bytes. In > > terms of packet counts, last time I looked at one, 50% of the packets were > > around 40 byte packets (ACKs) with another 40% or so at approx 576 bytes or > > so. > > > > What is the big, clear advantage of supporting jumbo frames? > > When 1500 byte frames from the customer's LAN enter the customer's > router and enter some form of IP tunnel, then a core fabric which > supports larger than 1500 byte frames will not cause fragmentation. > It's not necessary to do the full jumbo size frames. I suspect that > supporting two levels of encapsulation will be enough in 99.9% of the > cases. For the sake of argument, what would be the downside of using a > 2000 byte MTU as the minimum MTU in your core? When the next end user upgrade is deployed and everyone has devices which can support larger MTUs, wouldn't it be a shame if they said "if only the internet core ran at larger MTUs, we could negiotate higher MTUs and make everyone happier". Also, it is far more then "marginally more efficient". For every packet you deal with, there is a great amount of work doing routing lookups, dealing with memory management, and handling interrupts. Copying another few bytes of data is easy in comparison. Since we are asking GigE to act in a server and backbone role, we should acknowledge that the requirements will be different from the average end-user ethernet. One of those requirements is that the backbone should be able to pass larger packets it may encounter without resorting to fragmentation (which only gets harder and we start getting into higher speeds). Aside from that, and the fact that there is nothing harmful in supporting larger packets through your network, there is the fact that if we want people to support standards we KNOW are good for them (even if they don't), we have to actually ask for it. Imagine an internet with a reliable MTU negiotation mechinism, which can take advantage of improved thruput, much lower CPU usage, zero copy, page-flipping, DMA transfers, and all those other lovely things. These are important for many reasons. Without these techniques, we can't even do line rate GigE on "common place" servers, let alone have any CPU left over to do more then just send packets. Its easy to just say "we'll throw a server farm at it" or "we'll just get a faster processor", but as higher speed links become more common place, and as GigE becomes common in servers (when servers can actually use it effectively) and 10GigE becomes commonplace for backbone links, we'll start to see these things matter. Why engineer ourselves into a corner of shortsightedness which only gets harder and harder to fix, because its "easier" to do nothing? (sorry Michael, just using your msg as a good point to reply :P) -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

4 3