June 2000 - NANOG - lists.nanog.org

Global Crossing
by Shawn McMahon 21 Jun '00

21 Jun '00

Anybody seeing any problems with Global Crossing (gblx.net) today?

1 0

using IRR tools for BGP route filtering
by Peter Francis 20 Jun '00

20 Jun '00

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 Peter Francis Sr. Network Engineer SoftAware Inc.

4 3

FW: Private and Public Peering
by Lane Patterson 20 Jun '00

20 Jun '00

Hansen, to directly answer your original question: 1. if ISP A peers with ISP B through a switch run by an exchange point operator, this is generally considered to be public peering. The same switch may be aggregating many other ISP's giving O(N^^2) peering relationships. 2. if ISP A peers with ISP B by connecting to ISP B's switch (which then may aggregate into ISP B's router), this is considered to be private peering, and scales to O(N) peering relationships for ISP B. This seems to be a more common way for ISP's to privately aggregate smaller (10 mbps, 100 mbps) peers to a switch, which can then use a GbE trunk to a router. However, I believe the question limits the answer and that we should think about operational peering interconnection as more than public vs. private: 1. Public Peering in Public Places: Peering via FDDI, ATM, Ethernet 3rd party exchange switches. Great for cost-effectively aggregating larger numbers of smaller peers (and scaling multicast trees). 2. Private Peering in Public Places: cross connects between colocated peers, ala Equinix, PAIX, ... bilateral control over fewer large flows, generally for Tier 1<->1 and Tier 1<->2. 3. Private Peering between Private Places: circuit from ISP POP A to ISP POP B. These aren't exact. There are a number of operational or technical gray areas: - POP-friendly buildings like Westin Bldg in Seattle can act as a "partly public space" via fiber pulls and cabling "meet-me" rooms - DPT/SRP peering ring is a multiaccess "public peering" fabric but generally seen as a way to interconnect a small number of private POPs on a ring (although extending a ring to a "public place" could be a variation) - 3rd party DACS (for SONET) and eventually OXC (for lambda trades) can scale/channelize large numbers of private cross connects. Is this a form of private peering, or public? This may depend on operational, business, and technical definitions, but it's probably a mix of 1. and 2. Cheers, -Lane > From: Scott Marcus [mailto:smarcus@genuity.com] > Sent: Monday, June 19, 2000 5:46 AM > > > 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. > > > >For example, peering through a FDDI, Ethernet, or ATM switch > >is always called "public" (unless perhaps the switch is > >owned by one of the peers). And peering through a wire or > >SONET/SDH circuit seems to always be called private, > >even though the data might pass through SONET/SDH > >multiplexers, cross-connects, and switches operated by > >a third party... > > > Steve, this happens to be true in most cases, but I would > view it as being > sort of coincidental. > > What most people term "public peering" is effected at a public traffic > interchange point, where many providers appear, or can choose > to appear. > Note that the decision whether to interconnect is still, in almost all > cases, a bilateral business decision between each pair of > providers. The > word "public" is thus something of a misnomer. > > It's usually implemented over FDDI, ATM, whatever, because the traffic > interchange point needs to implement any-to-any connectivity. > That's a > matter of engineering practicality, but the definition should > not rest on it. > > 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. > > Hope this was helpful, > - Scott >

2 1

Re: uunet fiber cut (pgh, pa)
by Sean Donelan 20 Jun '00

20 Jun '00

On Mon, 19 June 2000, deeann mikula wrote: > does anyone have the scoop on the "major fiber cut" in the UUnet > backbone affecting areas around pgh, pa? Worldcom has a fiber cut affecting at least 11 OC48s between Pittsburgh and Washington DC. Folks have reported that UUNET's Pittsburg hub was isolated from the rest of the network. The best estimated time to repair is sometime overnight. Also Sprint reloaded most of their routers recently, and there have been sporadic reports of problems in different Sprint cities yesterday. I don't have good information about the reasons.

2 1

Re: Jumbo Frames (was Re: MAE-EAST Moving? from Tysons corner to reston VA. )
by michael.dillon＠gtsip.net 20 Jun '00

20 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? --- Michael Dillon Phone: +44 (20) 7769 8489 Mobile: +44 (79) 7099 2658 Director of Product Engineering, GTS IP Services 151 Shaftesbury Ave. London WC2H 8AL UK

4 4

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