- Test - lists.nanog.org

ATM overhead [WAS: Re: UUNET stops peering at MAE-West]
by Paul Ferguson 25 Mar '96

25 Mar '96

Kent, Have you done any statistical gathering on the overhead required to route IP traffic in the Pac Bell ATM NAP? I'd be interested in seeing this, for certain. :-) - paul At 05:50 PM 3/24/96 -0800, Kent W. England wrote: > >Give it a try. Pacific Bell has upgraded the Bay Area NAP to Stratacom BPX >ATM switches and the new PacBell LA NAP will also be a BPX switch. These >switches have sufficient buffer size to manage OC-3 connections. > >Check out our NAP stats page http://www.PacBell.COM/Products/NAP/Stats/ to >see how much aggregate traffic is already flowing through the Bay Area NAP. >Still some headroom left and no cell loss! > >--Kent >

1 0

Re: UUNET stops peering at MAE-West
by Kent W. England 25 Mar '96

25 Mar '96

At 12:07 AM 3/24/96 -0800, Mark Kent wrote: >>> Why haven't more networks taken advantage of the PacBell NAP facility >>> in San Francisco?? > >I should note that I don't see any issues going over the SF NAP from >my neck of the woods. > >-mark > Give it a try. Pacific Bell has upgraded the Bay Area NAP to Stratacom BPX ATM switches and the new PacBell LA NAP will also be a BPX switch. These switches have sufficient buffer size to manage OC-3 connections. Check out our NAP stats page http://www.PacBell.COM/Products/NAP/Stats/ to see how much aggregate traffic is already flowing through the Bay Area NAP. Still some headroom left and no cell loss! --Kent

1 0

UUNET stops peering at MAE-West
by Roy 24 Mar '96

24 Mar '96

According to the night shift at UUNET's NOC, they have stopped peering at MAE-West. Traceroutes show that they are using MAE-West for outbound trafiic but it doesn't look like they are advertising any routes there since I couldn't find anyone going to UUNET via MAE-West. The fellow I spoke with said this will remain until the GigaSwitch is installed at MAE West scheduled for this week. I have not seen an announcement to their customers of this policy change. On one particular route I use, I am now seeing 10% packet loss up from the previous 1-2%. The route has become unusable for telnet.

2 1

Blargh, Foo, Sabotage, and an RS/6000
by Alan B. Clegg 24 Mar '96

24 Mar '96

Sorry to change the current topic of interest & digress into a plea for help, BUT.... I'm looking for a little time (probably less than 12 hours total on-line) on an RS/6000 (AIX). I'm willing to talk $$$, but don't need a long-term (ie: month) contract. Anyone have a box somewhere that I can get an account on? I need about 40Meg disk space and access to the "standard" C compiler. I might even be interested in buying one of these things if anyone has one for sale (relatively cheap & in working order). [BTW, the project that I need the account for has nothing to do with Foo, Blargh, OR Sabotage] Happily Consulting for NOs across NA, -abc \ Alan B. Clegg Just because I can \ Network Technologist does not mean I will. \ gateway.com, inc. \ <http://www.gateway.com/>

1 0

Re: packet loss (was re: mae-west congestion)
by nicholas harteau 23 Mar '96

23 Mar '96

Peter Kaminski wrote: > > Matthew Kaufman writes about the Ames FDDI ring saturation: > > >What I don't understand is why that has _stayed_ saturated... it seems > >to me that some of the big players would have rerouted their traffic > >by now to avoid subjecting it to this, which would also have the side > >effect of causing the problem to, at least for the short term, go > >away. > > ...or why MFS hasn't installed a Gigaswitch there, or whatever. We're > seeing 20% - 30% packet loss through AGIS to MCI and Sprintlink during > the day, and it's not fun. Speaking of fddi rings, saturation, and packet loss.. has anyone taken a look at the peering between mcinet and cicnet at the chicago nap? i get about the same (20-30%) packet loss during the day. and no, it's not fun at all. -- panic(a)cyborganic.com

2 1

Re: Blargh sabotages Foo...
by Joe Provo 23 Mar '96

23 Mar '96

This drama has reminded me of something I had been meaning to ask "the community" for a while now. If InterNetBlargh has customer FooCo and breaks things badly, it is fairly obvious that they both should have their respective suits and legals hash things out over existing contracts. But if InterNetBlargh mangles one/more routes [by virtue of, say, a shorter AS path] for *non-customer* BazNet, without regard for WHOIS/RA data, currently-visible announcements, registered servers, etc., what sort of recourse is considered a Good Thing? Let's face it, typos happen, even at major transit providers, but that means squat when your /16 goes *poof*. Airing it as a made-for-mailinglist miniseries is just a waste of everyone's time. What sort of action would any propose to BazNet? Send email and I'll summarize. Cheers, Joe Provo Network Operations Center UltraNet Communications, Inc.

1 0

Re: MCI [ATM overhead]
by Paul Ferguson 22 Mar '96

22 Mar '96

At 08:38 AM 3/20/96 -0800, Wolfgang Henke wrote: > >Thank you for the reference. I will certainly check it out. Here is a >little table which I hope will help ISPs planning to upgrade bandwidth: > > >SONET (Synchronous Optical Network) speeds given in Mbps > > nominal w/o Sonet ATM TCP/IP > overhead > >OC-3 STS-3c 155.520 149 122 137 future net backbone > >OC-12 STS-12c 622.080 599 488 549 > >OC-48 STS-48c 2488.32 2396 1953 2197 current telco backbone > >OC-192 STS-192c 9953.28 9585 7813 8788 > >on single mode fiber >or multi mode fiber >or CATV 75 ohm coax (the lower speeds) > And here's one that [fills in the gaps] shows the relationship between STS and SDH: SONET/SDH Heirarchies SONET Bit Rate SDH STS-1/OC-1 51.84 Mb - STS-3/OC-3 155.52 Mb STM-1 STS-12/OC-12 622.08 Mb STM-4 STS-24/OC-24 1244.15 Mb - STS-48/OC-48 2488.32 Mb STM-16 STS-192/OC-192 9953.28 Mb STM-64 - paul

2 1

Re: MCI [ATM overhead]
by Kent W. England 22 Mar '96

22 Mar '96

At 03:09 PM 3/21/96 +0800, Vadim Antonov wrote: > ... (as ATM does not handle >levels of overcommitment found in IP backbones now). > > >--vadim > > Vadim; I think that statement, as I interpret it, could only apply if you are running IP over a rate-controlled ATM backbone (either CBR or VBR QoS). Nobody in their right mind does that if they have an alternative. ATM responds to "overcommitment", if you mean "excess offered load", by shedding that load either in the middle of the backbone at the bottleneck if you are running IP over UBR or at the edge of the network if you are running a proprietary ABR. IP routers respond to excess offered load by shedding that load in the middle of the backbone, since IP router QoS is essentially the same as ATM UBR. In this sense, with ATM you have two choices for handling overcommit- ment (if your ATM switch vendor has a proprietary ABR) but with routers you have only one. --Kent

1 0

OOPS! Cisco OC3 retraction!
by Carl Payne 22 Mar '96

22 Mar '96

Holy guacamole! Hmm...where to begin. Well, first, let me apologize for my rudeness. I meant to insert a little smiley (no, really, I did!) and I did not. My post was not meant to be so hostile. Second, let me apologize for my ignorance. On our entire network, only 2 of our routers are 4500s and both are outfitted with 2 ethernet and 8 serial ports. I had no idea there was ALREADY an OC3 interface available for that router, nor did I plan on learning such because we've moved on to bigger things. FWIW, I apologize. Had I flipped to pp139 of this year's Ciscoble, I would have spared my damaged soul the embarrasment of trying to be funny. Doggonnit, and I thought I was going to be able to give up being a jerk by Christmas. Carl

1 0

Re: mae-west congestion
by lance＠nsipo.arc.nasa.gov 22 Mar '96

22 Mar '96

Yes, agis is on the MFS side and mci+sprint is on the nasa side, though it is my understanding that mci put in a line on the mfs side as well. I believe ANS has pulled a line in on the mfs side as well. The two sides of the mae-west are connected by an OC-3. At 11:43 PM 3/21/96 -0800, Nikos Mouat wrote: > >On Thu, 21 Mar 1996, Peter Kaminski wrote: > >> >What I don't understand is why that has _stayed_ saturated... it seems to me >> >that some of the big players would have rerouted their traffic by now to avoid >> >subjecting it to this, which would also have the side effect of causing the >> >problem to, at least for the short term, go away. >> >> ...or why MFS hasn't installed a Gigaswitch there, or whatever. We're seeing >> 20% - 30% packet loss through AGIS to MCI and Sprintlink during the day, and >> it's not fun. > >isn't agis on the mfs side and mci+sprint on the nasa side? (i know that >net99 was/is on the mfs side, but i dunno if agis is using their cage or >have a different one) > >are the two 'sides' of mae-west still connected by only a ds3? > >/nm > >

1 0