- Test - lists.nanog.org

RE: Internet access and telco usage patterns
by Hank Nussbacher 02 Jul '96

02 Jul '96

On Mon, 1 Jul 1996 18:12:27 -0700 (PDT) Michael Dillon wrote: >Has anybody looked at the practicality of installing modem pools in each >telco switch location to grab the dialup user's traffic at the IP level >and then route it to their ISP of choice for authentication and further >routing. In other words, an ISP wouldn't buy phone lines, modems and >terminal servers, they would buy IP access ports. The PTT in Israel tried doing something like this for a period of a month before the government shut them down but they are planning on reopening soon. A user dials the number 135 and gets connected to a Cisco t/s in his area. One message unit per 5 minutes directly on the customers phone bill. No authentication, no userid. The PTT stated that the ISPs can sell services to the end user, such email boxes, Usenet access, proxy services, etc. The PTT would run no server - just pure IP level access. The one hitch that was discovered was that hackers loved the system since they did not have to identify themselves at an IP level. Israeli CERT teams got lots of complaints from foreign systems about cracking attempts from the PTTs dialup users. Since their phone systems and IP systems were seperate, there was no handoff of the dialing phone number to the t/s for recording as a traceback. They are now trying to reengineer the system so as to have that capability. Anyone designing such a system should take that into account. >Michael Dillon ISP & Internet Consulting >Memra Software Inc. Fax: +1-604-546-3049 >http://www.memra.com E-mail: michael(a)memra.com > ---------------------------------------------------------------------- Hank Nussbacher Manager, Internet Technology Programs Telephone: +972 3 6978852 Vnet: HANK at TELVM1 Fax: +972 3 6978115 Internet: hank(a)ibm.net.il WWW: http://www.ibm.net.il/~hank ---------------------------------------------------------------------- IBM Israel 2, Weizmann St. Tel Aviv 61336 ====== ======= === === http://www.ibm.net.il/ ====== ======== ==== ==== Dialup registration: 177-022-3993 == == == ==== ==== Company services: 03-6978663 == ====== == === == Internet sales fax: 03-6978115 == == === == = == Enquiries: info(a)ibm.net.il ====== ======== === === Technical support: noc(a)ibm.net.il ====== ======= === === ----------------------------------------------------------------------

1 0

Re: Internet access and telco usage patterns
by Michael Dillon 02 Jul '96

02 Jul '96

Here is something that I got in a private email message with permission to quote to the list. ----------begin forwarded segment----------- It is common knowledge that the local telcos are in a panic. Call hold time has increased from the traditional 3 minutes to 10 minutes in the last 2 years. The effect is CO class 5 switch capacity is bursting at the seams, but even worse is the intra-office trunks are maxed out. The cost of adding more trunks has them looking for something cheaper. None of the traditional traffic engineering works anymore - HA! What's even better is this comes at a time when they are all wanting to screw the local business and invest in long distance. ----------end forwarded segment----------- I should mention that another incident that happened in Vancouver was that BC Tel called up one of the larger Internet Providers on a Friday before the long weekend and said "Your lines are being shut off today. Your only option is to relocate to a particular suburb and we will transfer them there for you". The reason for this action was that dialup users to the ISP had completely used up the inter-office trunks in one of the business districts which at times was causing *EVERYBODY* in the area to get "no dialtone at all" when they picked up the phone. You couldn't even dial 911 which was the thing that prodded the telco into such drastic action. Imagine the lawsuits in the case of someone maimed or killed due to inability to phone for assistance! When we discussed some of these things last year on can.infohighway I pointed out that if they could divide the traffic by type that they could get better trunk utilization by running IP between the CO's. This is the modem in every switch location scenario. Additionally, if they segregate voice traffic they could use compression technology to get as much as 4 times the conversations on a trunk. Gandalf makes boxes that will run 4 voice lines down a digital DS0 circuit and the quality is very good. You can tell there is compression there but it's better than long distance line quality often is. I know that the end-user connection has in the past been considered the domain of the ISP, not the NSP, but when you look at the traffic engineering issues and the deregulation of local loop, I still see some sort of role here for the larger telco-type organizations (and I include ANS, UUNET, et al. as potentially in this group). There is no doubt that the ISP can provide better customer support and training and that the ISP can do a better job of running the servers for the most part (news being a sometime exception). However, I can still see room here for NSP's to step into local loop without damaging the ISP part of the industry. Ford makes cars, ships cars to car lots, maintains spare parts inventories, trains mechanics and sales people, and yet it still makes sense to have a local business running the Ford dealership. Similar analogy applies here I think. Michael Dillon ISP & Internet Consulting Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael(a)memra.com

1 0

Re: Internet access and telco usage patterns
by Bill Woodcock 02 Jul '96

02 Jul '96

MFS is apparently offering a "virtual POP" service for dialup IAPs here in the S.F. Bay Area... They'll backhaul calls from each of the Pac Bell COs they're colocated at back to serial ports at a central location. Not of any use to us, so I don't know any more about it. Apparently a fairly new service, last two-three months or so. -Bill Woodcock ________________________________________________________________________________ bill woodcock woody(a)zocalo.net woody(a)applelink.apple.com user(a)host.domain.com

1 0

Re: Internet access and telco usage patterns
by sob＠academ.com 02 Jul '96

02 Jul '96

> Has anybody looked at the practicality of installing modem pools in each > telco switch location to grab the dialup user's traffic at the IP level > and then route it to their ISP of choice for authentication and further > routing. In other words, an ISP wouldn't buy phone lines, modems and > terminal servers, they would buy IP access ports. Southwestern Bell has described such a service they claim to offer here in Texas, though I have not seen it yet. At one point, I had heard that Ameritech and PAC*BELL were bothing looking at something like this. I never saw if they actually did it or not, though. CampusMCI is something like this, but of course there is only one ISP of choice in that case :-). -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

NETCOM downtime a programming error. (fwd)
by Michael Dillon 28 Jun '96

28 Jun '96

---------- Forwarded message ---------- Date: Fri, 28 Jun 1996 17:42:30 -0400 (EDT) From: Brian Tao <taob(a)io.org> Reply-To: inet-access(a)earth.com To: inet-access(a)earth.com Subject: NETCOM downtime a programming error. (fwd) Resent-Date: Fri, 28 Jun 1996 16:45:28 -0500 (CDT) Resent-From: inet-access(a)earth.com Not sure where this first showed up, but it sounds like some sort of trade publication... ---------- Forwarded message ---------- IA: Take us through what happened... GARRISON: Think about the network in three layers. The first layer is Network Access Points, where we have peer agreements with other careers. It's the entry point to the Internet. (They're about a half dozen across the U.S.) The next level down are hubs, which are our internal virtual private network routing hubs that look at traffic and direct it along the speediest line available. The third level down is where the customer actually logs on, at an access POP (Point Of Presence). At each of those levels there are routers made by Cisco and others that have instruction tables on them -- "IF THEN" statements that tell the traffic where to go, what route to go to get to its destination. At the network access level, you have some pretty complex code that says, 'If the traffic comes from this party, then do the following thing with it.' And because of the number of new access providers or changes in the access providers, there are daily changes made at the network access layer. And these are changes that are made in software to the routers. It's done in a language called BGP, or Border Gateway Protocol. So, there was one line of code that said, literally, "No redist bgp access list 25 in," just a line of code that revised an instruction. Because the two sentences were put together as opposed to being done on separate lines, the network read it as an "AND" statement instead of an "OR" or an "IF statement. So, what happens is the network automatically replicates the instruction set from the network access point from where this was entered, which was Washington, DC, and it replicated itself to the other network access points. Because of the way the code was written, it then said, 'ah hah, it's a network instruction, not a peering instruction -- I'd better send it out to the hubs.' The hubs saw it, and said, 'ah hah, I'd better send it out to the POPs.' Well, the POPs memory -- the routers at the lower levels of the network -- do not have the memory or capacity for the peering instructions because they don't interface with anybody else, so they don't need that capacity. So, when they got it, it basically froze the routers down at the third level of the network. Meantime, we're sitting reprogramming the routers, but as fast as we can reprogram the replication feature of the intelligent network, it overwhelms our ability to reprogram. Basically our decision was to shut down the network to reboot the routers, to put in a fresh instruction set. That's a long winded explanation, but because your readers are more technical, it's worthwhile! ============================== ISP Mailing List ============================== Email ``unsubscribe'' to inet-access-request(a)earth.com to be removed. inet-access archives are at ftp://ftp.earth.com/pub/archive/inet-access/

1 0

Network Maps/Directory
by William B. Norton 28 Jun '96

28 Jun '96

Hi all - At last NANOG we talked a little bit about network maps, contact info, etc. Brian Noto (BoardWatch) mailed me their latest BoardWatch directory, which lists a rather astounding number of ISPs across the U.S. along with some ISP history, contact #, services and prices, topology maps for some, etc. It looks pretty cool, and after talking with Brian, he agreed to make a copy of the directory available for free to the NANOG community (there is a form to fill out and e-mail below). Bill >From: Jack Rickard[SMTP:jack.rickard@boardwatch.com] >Sent: Tuesday, June 25, 1996 4:09 PM >To: 'Brian' >Cc: 'bob_metcalfe(a)infoworld.com' >Subject: NANOG Participation > >Brian: > >Here's what I think we can do for the NANOG members vis a vis the directory and ONE ISPCON that they might find attractive. > > >BACKGROUND > >We had contacted NANOG earlier in the year regarding participation at the Online Networking Exposition and Internet Service Provider Convention scheduled for August 7-10 in San Francisco. Bill Norton had demurred on holding a NANOG event at ONE ISPCON, but had agreed to come present a briefing on NANOG activities. > >In the June 17th issue of InfoWorld, columnist Bob Metcalfe noted rather publicly the desireability of getting some dialog going between NANOG members and the rank and file small ISP's that make up the bulk of ONE ISPCON. He had also spoken directly with Bill Norton on this same subject at the NANOG meeting. > >By way of explanation and disclaimer, Dr. Metcalfe is not connected with Boardwatch Magazine or ONE, Inc., or ONE ISPCON in any financial sense, and is not responsible for our annual bevy of mistakes and miscues. But he does stand tall in our world quite beyond his role as InfoWorld columnist and Ethernet inventor. He has served a purely mentor/advisor role on our Executive Advisory Board and has spoken at our last two annual shows. He's also the smartest man I've ever met, in my unqualified but nonetheless strongly held opinion, and I routinely find myself tongue tied in his presence. Bottom line, if Bob wants it, we go into scramble mode to make it happen. > >He thinks NANOG and ultimately the Internet could benefit from some level of dialog between the "top of the net" and the little guys at the bottom hooking real people up. Here's my official "me too" then. > >THE DIRECTORY > >In March 1987, Boardwatch Magazine published a Directory of Internet Service Providers - their first effort listing some 1447 Internet Service Providers who had actually been contacted by the publication and interviewed. > >As a result of response to the first directory, the second issue, June 1996, was revised to include more detailed information about the architecture of the Internet. Nine "profiles" of large national backbone providers were added with color maps of their backbones, POP lists, product lists and prices, Internconnects, etc. along with a description of the NAP architecture. The directory listings had grown to some 2266 Internet Service Providers. > >The directory has been sufficiently successful to warrant further development and we are already working on the Fall issue. Bill Norton commented on the value of the architecture descriptions. In discussion with Norton, he thought we might find input from NANOG members valuable. Since anything we can do to make the depiction of the Internet more accurate and useful directly benefits our publishing efforts, we concur. So we are attempting to devise a kind of informal peer review process. The objective here is a bit questionable of course. We are trying to diagram and present a rational picture of the Internet two dimensionally on paper. We are bound to fail for obvious reasons, but hope to do so artfully. From Mr. Norton's response to our June efforts, I think we've achieved that. But we would like to improve it. > >To do this, we've agreed to provide a free copy of the Directory of Internet Service Providers to any NANOG member who cares to identify themselves. The book sells on the newsstand at $9.95 and we normally sell them directly at $9.95 plus $4 s&h. We will provide a copy via first class mail at our expense FREE to any NANOG member who requests one. > >To obtain your review copy, send the following information to BRIAN.NOTO(a)BOARDWATCH.COM > >Name: >Job Title: >Company/Organization: >Street Address: >State/Province: >Zip or Postal Code: >Country: >Voice Telephone: >Fax: >Electronic Mail: > >Please note in the e-mail that you are a NANOG member. We will send a copy of the June 1996 Spring issue, along with a brochure for ONE ISPCON via first class mail. We would appreciate any comments/critique to BRIAN.NOTO(a)BOARDWATCH.COM prior to August 1, 1996. > >ONE ISPCON > >ONE ISPCON is a very focused trade show specifically for Internet Service Providers. It is NOT a general Internet show to get people together and talk about how cool the Internet is. We do have vendor exhibitors at Moscone including Cisco, DEC, Microsoft, Livingston, Bay Networks, U.S. Robotics, etc. - about 60 vendors as of June 15. We also have about 100 educational sessions slated including Mark Corbitt of the FCC, John C. Dvorak, David Graves and Kim Hubbard of NSI, and so on. Sessions will cover marketing, financing, and a lot of technical sessions on building local/regional NAPS, multihoming issues, ADSL, HDSL, wireless, etc. Again, the focus is on how to actually do this stuff as a small ISP - typically 12 employees and 1500 customers. We expect about 1000-1200 true Internet Service Providers, 400-500 ISP wannabees in the main convention/session schedule at San Francisco Hilton Towers, with 3000-4000 peripherally interested vendors, software developers, and assorted hangers on at the vendor exhibits in Moscone. The core "meeting" then at the Hilton will be relatively small and some three blocks distant from the vendor exhibits. > >Registration is $425 until July 15th. > >To encourage NANOG members to come see how the smaller half lives and fulfill the Metcalfe initiative, we will discount this a full $100 to $325 for identified NANOG members registering by July 15. > >MORE INFORMATION > >More information is available at http://www.ispcon.com. The ONE, Inc. office is available at (303)693-5253. Direct questions, particularly regarding session schedules and speakers to BRIAN.NOTO(a)BOARDWATCH.COM. > >Jack Rickard >Editor and Publisher, Boardwatch Magazine >President, ONE, Inc. > >===================================================== >Jack Rickard Boardwatch Magazine >Editor/Publisher 8500 West Bowles Ave., Ste 210 >jack.rickard(a)boardwatch.com Littleton, CO 80123 >303.973.6038 voice 303.973.3731 fax http://www.boardwatch.com >======================================================== > > > >

1 0

RE: Telco discussions
by John R. Sosebee 27 Jun '96

27 Jun '96

from Vadim: > The lack of any meaningful clock source negotiation and > idiotic defaults in CSU/DSUs is a major source of rapid > link flap, too. It seems that most (if not all) equipment > vendors simply don't have any clue of what effect their > design choices have in the real world. I'm seeing that also. I've been using ADC/Kentrox T-1 CSUs lately and they come out of the box set for D4/AMI ... go figure ... BTW: Is there a mailing list for ISP related telco hardware? Or telco hardware as related to ISP's? :) Not that I'm aware of. That would really be very vendor specific. News groups are good for this but like you said it's not data only, voice/video equipment gets mixed in. We talk incessantly about BGP configs, route flaps, saturation stats and Powerpoint graphs, and I don't hear boo about CSU/DSU caveats, typical misconfigs, tips on how to spot DXC/OCU mis-options (Can You Say B8ZS through a C/O that's optioned for AMI???), NIU settings, T-Carrier analyzer tips, etc, etc, etc... It's all black magic for most people. I did hardware/telco at BARRNet for so long, I still have withdrawl symptoms when I see a DSX patch panel or walk into a Wiltel co-lo. me too at SURAnet ... and when I pass a MCI c/o Yes, I know, there are endless mailing lists about telco hardware in general, but those tend to be geared for voice apps, and besides, how long would you read it when the discussions turn to how good the latest NorTel M-1/3 is compared to Brand-X (especially when probably <-1% of ISP's would configure an M-1/3 anyway). Yeah, so you're large enough to hire a contractor to do all your telco. What about us small-fry who can't afford contractors. See if @home is hiring ;) Case-in-point: How many of you tried to figure out why the arrow keys only worked 50% of the time when you used a telnet session to configure a Digital Link Encore DSU / Ensemble shelf? And do you know what Digital Link did as a work around (ans: use the "U" and "D" keys for up/down). DL was real good in getting us a CSU firmware fix for the CSUs. There was a problem where accessing the console port of the DL chassis through a terminal server, the three characters of the arrow key would be received with too much spacing/time between them ... packetman helped picking this up ... Anyway, I made my point. Just curious. nay, too vendor specific ... newsgroups ... John rob.

2 1

RE: Telco discussions
by John Oliveira 27 Jun '96

27 Jun '96

At 04:50 PM 6/25/96 -0400, John R. Sosebee wrote: > > >I'm seeing that also. I've been using ADC/Kentrox T-1 CSUs lately and they come out of the box set for D4/AMI ... go figure ... > This is because most vendors still believes that T1 circuits are provision as D4/AMI..:-) Digital Link Encore csu/dsu by default has it setup as ESF/B8ZS. > >Case-in-point: How many of you tried to figure out why the arrow keys >only worked 50% of the time when you used a telnet session to configure >a Digital Link Encore DSU / Ensemble shelf? And do you know what Digital >Link did as a work around (ans: use the "U" and "D" keys for up/down). > Believe it or not I was the person who made Digital Link come up with the "U" and "D" keys ( don't forget the "L" and "R" for left and right keys). I had meetings with their Engineers to come up with this solution since we had problems telnetting to the csu/dsu through the Terminal Server due to very poor delay response using the arrow keys. It would take at least 5/6 strokes on one arrow key just to toggle it up/down or left/right. This still applies on the 3800 Digital Link Imuxes. John

4 3

Re: Netcom Outage (Was: My InfoWorld Column About NANOG)
by Sean Doran 26 Jun '96

26 Jun '96

| As for routing loops we all know whom to thank for the wise | decision to give packet forwarding higher priority than to | handling routing updates Fixed. | and for using textual regexp matching in policy evaluation, too. Also fixed. C'mon, beat up on cisco for things that are STILL broken, not for things that have been fixed after being discovered as problems. Sean.

1 0

Re: Netcom Outage (Was: My InfoWorld Column About NANOG)
by avg＠postman.ncube.com 26 Jun '96

26 Jun '96

Stephen Balbach <stephen(a)clark.net> wrote: >Having a fully meshed/redundant network should be the goal of any serious >ISP. The only one that claims it with any substance IMO is UUNET. The "full mesh" in this case is a figment of imagination. Level-2 mapping of cirtuits over the same (non-meshed) physical wires does not make network a tiny weeny bit more reliable, and the added complexity brought by such mapping actually makes system less robust. Other ISPs who happen to be in position to control physical routing of circuits use IP-level rerouting to attack the problem. The IGP rerouting with modern link-state IGPs is sub-second so the redundancy of interior paths is easy to achieve (perticularly if you use tricks like BGP confederations which eliminate need to recompute iBGP routing in case of IGP changes). The hard part is exterior routing where topology changes require massive crunching of BGP tables. Multiplying paths actually makes the problem worse. >We are trying to build one and its not easy. Haveing redundant links >in place does not guarantee instant fall over of traffic. Static routes, IGRP, >iBGP, bridgeing, rip1 vs rip2, etc. are some of the issues we are running >into. The Golden Rule of engineering (often forgotten in US) -- the simplier the system is the better it works. The root of many Internet woes is in overly complicated router software, that complexity appears to be running out of control. An ISP engineer's nightmare is a Bysantine-mode failure -- when redundancy does not help because a problem in one place triggers failures in a lot of other places. Any RISKs reader knows that software problems in distributed systems often have that nature. Internet configurations are particularly prone to that, especially considering that they're in state of constant flux. That's why draconian revision controls and highly skilled backbone engineering staff (which is actually able to understand global consequences of all their actions) are vital to operations of any serious ISP. Netcom seems to be in stage of learning that hard way. >As well as when an interface is down, but actually looks up to the >router, etc..it can be done, but there are so many possible points of >failure and unforseen scenarios, it is very difficult to construct and >certainly takes time to develop. That example is a perfect illustration on why many backbone engineers are sceptical about "advanced" level-2 technologies. Even good ol' Ethernet may have numerous quite interesting ways to fail, if not built properly (remember ol' MAE-E? :) --vadim

2 1