- Test - lists.nanog.org

frame relay to atm conversion tool?
by Brennan_Murphy＠NAI.com 09 Jan '03

09 Jan '03

I'm trying to locate a tool (eg, spreadsheet) to convert throughput on a frame circuit to an ATM circuit. So, for example if you have a 512k CIR with burst to 1024k and 80% of the time you get your burst bandwidth and you want to convert that link to ATM, what corresponding SCR/PCR/MBS values would you need. I'm less concerned with Frame vs ATM protocol overhead than I am with calculating the difference in the way the burst bandwidth is meted out. Any recommendations? Supposing no one knows of such a tool. Would anyone be interesting in helping me put one together? Best Regards, -BM

1 0

RE: Weird networking issue.
by Proctor, Chris (EPIK.ORL) 09 Jan '03

09 Jan '03

In the real world, auto-negotiation on fiber vs. auto-negotiation on copper have been two different animals. Most of the compatibility issues result from 10/100 auto-negotiation on copper as this was the first major deployment of the technique in Ethernet devices. Most devices engineered recently should auto-negotiate properly. In the early to mid 90's this was only true within the product line of a single vendor. Many of the products Cisco sells were engineered by different companies and often have problems auto-negotiating to other "Cisco gear" made by other companies. Also remember that many of the products that Cisco still sells have roots back 5 or more years. There is a good chance that any 3600 copper interface could have the same issues that its cousins did in 1997. The question of hard-setting speed/duplex on these types of interfaces is about as murky an issue as spanning-tree. You solve some problems and create others. I suppose the primary goal is to eliminate support calls and outages within your own environment. In my experience, connections which as static (servers, routers, etc...) should be hard coded on both sides as incorrect negotiations can and do occur. It is also frustrating to discover that your primary file server has been running at half duplex for a week. It may also be interesting to know that IEEE 802.3-2002 says that auto-negotiation is optional (in section 28.1.2.) It may also be interesting to know that if a device does support auto negotiation it must allow manually overriding of the function (IE.. an unconfigurable device is not allowed to auto-negotiate.) -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] Sent: Wednesday, January 08, 2003 2:39 AM To: nanog(a)merit.edu Subject: RE: Weird networking issue. On Wed, 8 Jan 2003, Stephen J. Wilcox wrote: > So thats human error not a problem with using forced settings, eliminate the > human error and I think you'll see forced always works, autoneg sometimes > works. (For future reference dont employ incompetent people to run your networks > folks!) Problem with autoneg is that you always have to have manageble equipment and you always have to check both ends after changing anything. In an ISP environment that is generally not a problem luckily, apart from the equipment you connect to on the customer side, some customers insist on using cheapo stuff. Autoneg does add good things, especially on GigE. Autoneg on a GigE yields the most desireable effect of "link loss return", ie if you lose fiber link one way the link goes down at both ends. > Have you looked at what autoneg is.. its horrible, a hack to help out the above > incompetent engineers who dont know how to force duplex. Hmm, I might draw the same conclusion regarding automatic gear boxes on cars but I think I should not considering the situation in the US regarding that perticular issue :) Personally I think the idea with autoneg is really a good thing, why shouldnt two units advertise their capabilities and then act accordingly to what they both can do? We do the same on SMTP (EHLO) and so on. -- Mikael Abrahamsson email: swmike(a)swm.pp.se

1 0

Verio yesterday
by Peter Salus 09 Jan '03

09 Jan '03

Verio appears to have had a number of problems yesterday: We noticed a tremendous packet loss spike and a loss in "reachability" to various sites. Verio states that it had issues [!] with www1501 and that "customers in Boca Raton" may have experienced delays. Anyone know what happened? Peter

1 0

MSN IM Outage last week.
by Al Rowland 09 Jan '03

09 Jan '03

If you haven't seen it regarding last weeks outage: Microsoft: Human Error Was The Cause Of Five-Hour Instant Message Outage The service went out due to configuration errors when setting up new routers that were -- ironically enough -- installed to make the service more reliable. http://update.internetweek.com/cgi-bin4/flo?y=eKGj0BfFir0V30BpZb0Ad It's the interface between the chair and the keyboard... Best regards, ______________________________ Al Rowland

1 0

Colocation In Jopan
by Tom Daly 08 Jan '03

08 Jan '03

Hi All, I am new to this list. Our company is interested in starting to colocate in Tokyo, Japan. We are looking for the following: 1/4 Rack (10U) 20Amps Equiv US Power 1 MEG CIR Pipe over 10BaseT or 100BaseT /28 IP Network Space I am getting prices of approx $1500 - $2000 USD. Has anyone done better? Does anyone know any particular hosts? Regards, Tom -- Tom Daly tom(a)dyndns.org Senior Support Engineer Dynamic DNS Network Services http://www.dyndns.org/

3 2

fiber cut in VA?
by Jim Dawson 08 Jan '03

08 Jan '03

We've had reports of a fiber cut between Washington, DC and Richmond that's affecting traffic as far south as South Carolina - anybody know anything about this? thanks, Jim -- See what ISP-Planet is saying about us! http://isp-planet.com/services/wholesalers/flexpop.html __________________________________________________________________ Jim Dawson jdawson(a)flexpop.net Flexpop/Navi.Net http://www.flexpop.net 618 NW Glisan St. Ste. 101 v. +1.503.517.8866 Portland, Or 97209 USA f. +1.503.517.8868 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

NANOG 27 - IXP Panel
by Mike Hughes 08 Jan '03

08 Jan '03

Hi all, Some of you may recall that I moderated an IX Panel at the Winter 2002 NANOG in Miami. The programme committee have asked me to prepare and moderate a panel to be held in the general session at the upcoming NANOG in Phoenix, AZ. In addition, especially for all you peering people, Bill Norton will be running a Peering Co-ordinator BoF on the Monday evening. The style of the panel will be similar to last year, i.e. time limits for each IX. We will also be limiting the number of slides each IX can use as a presentation aid. We're primarily interested in new developments at your exchanges over the past 12 months, or forthcoming developments you may want to preview with the NANOG audience. If you want to talk about technical challenges, innovations, or even nasty outages at your IX, that's also welcome. Customer lists, corporate info we can find on your website, etc., are not relevant! ;-) If your (preferably North American!) IX is interested in participating, please send me an email, containing a short abstract of what you intend to talk about during the panel, to arrive in my inbox no later than 13th January. As we're time limited, I'll have to select the panel members from a shortlist, if we have too many potential participants. If selected, be prepared to have a draft of your presentation slides with me by 24th/25th Jan. If you are going to "wing it" without visual accompaniment, then let me know. Look forward to hearing from you, especially exchanges which couldn't make it last year! NANOG participants, feel free to think up some questions for the exchanges which you can ask on the day! If you wish to ask a question anonymously, you can direct it either through myself or through the NANOG Chair. Look forward to seeing you in Phoenix! Mike -- Mike Hughes Chief Technical Officer London Internet Exchange mike(a)linx.net http://www.linx.net/ "Only one thing in life is certain: init is Process #1"

1 0

space at 401 N. Broad in PHL
by alex＠yuriev.com 08 Jan '03

08 Jan '03

Hello, If anyone has space at 401 N. Broad in PHL available, please drop me an email off list. Thanks, Alex --

1 0

Cogent running through MFN to get through AOL
by Gil Cohen 08 Jan '03

08 Jan '03

7 p15-0.core02.dfw01.atlas.cogentco.com (66.28.4.26) 31.564 ms 31.735 ms 31.036 ms 8 ge-5-2-1.pr1.dfw3.us.mfnx.net (64.124.51.169) 47.949 ms 48.001 ms 47.844 ms 9 so-3-1-0.cr1.dfw2.us.mfnx.net (64.125.31.217) 47.969 ms 47.888 ms 48.370 ms 10 aol-above.dfw2.above.net (209.249.119.230) 48.048 ms 47.887 ms 47.845 ms 11 bb2-dal-P0-0.atdn.net (66.185.146.146) 48.706 ms 48.169 ms 48.041 ms Just thought I'd let you guys know :)

1 0

Re: COM/NET informational message
by Joel Rowbottom 08 Jan '03

08 Jan '03

At 17:40 07/01/2003 +0000, Steve Dyer wrote: >This is to inform you that Characterisation GmbH (www.characterisation.de) >has patents pending Ref PCT/DE02/00632 filed 28th February 2001. CentralNic have actually been working with this system for around 12 months now, and it's pretty cool. It works with a lot more browsers than the VGRS one, and requires no client or server-side plugins or patches :) It's really rather good at providing a seamless end-to-end IDN solution for web browsers; granted there are problems with Squid and such, but any IDN solution will have problems with things which filter. Personally I think it's a good transition for IDNs - but then again I've said that before ;) BR j -- Joel Rowbottom, http://www.centralnic.com - CTO and self-confessed Unix geek <t> +44 (0)20 7751 9000 <f> +44 (0)20 7736 9253 <e> joel(a)centralnic.com # Note: Contents may not necessarily represent the opinions of CentralNic.

2 3