July 1996 - Test - lists.nanog.org

re: AGIS Route Flaps Interrupting its Peering?
by Sean Doran 08 Jul '96

08 Jul '96

| These NetEdges seem to have three different possible operating states: | completely working (which doesn't happen often enough); broken (often, right | out of the box); and kind of working (which happens all too often). That these things work at all under load is nothing short of miraculous. There are plenty of mixed-media-bridging devices that have been tried and which have failed miserably in the past, most notably: -- Magnum 100s (ethernet<->funny framing<->ethernet), which don't meet the standard IFG specification; jam too many back-to-back packets at them, and it will lose most of a burst of traffic. This hurt the old MAE-EAST. -- various ADSUs (FR<->ATM<->FR), which lack buffering and perform SAR too slowly, which delayed the PAC*Bell and Ameritech NAPs for months and some of which still exhibit flakiness under load -- a horrible idea (ethernet<->MFS ATM<->ethernet) which didn't work under load; perhaps a veteran user of these neato little things could explain the failure mode to anyone interested. I remember one service provider who had a national "10Mbps" ethernet backbone who had various horrible problems including the breakdown of the LIS (such that some routers couldn't talk to others), connections going simplex, frame loss and other wonderful things -- another horrible idea (FR<->MFS ATM<->FR) this was pretty neat; some of the problems above plus a brand new problem: the ADSU would strip the FR frame checksum, perform SAR, send the cells, and the ADSU on the opposite end would reassemble the frame and produce a correct FR checksum. All fine and dandy, unless cells arrived out of order, SAR was done wrong, or there was data corruption under load in the DSU or in the network. This interesting technology advanced the state of IS:IS in one vendor's software rather considerably -- mixed-media bridging (NetEdges, FDDI/Ethernet bridges) these break in all sorts of interesting ways. In particular, NetEdges have an annoying habit of confusing FDDI stations in particularly toxic ways, and some FDDI/Ethernet bridges resemble roach motels: frames check in but they don't check out. Essentially, most of these things worked mostly perfectly under low load, but when faced with the kind of traffic one sees at a busy exchange point, most bridging technology has failed in really awkward ways. My advice is that if you can avoid talking to something across a bridge at an exchange point, you should do so. The keep-it-simple principle is a bunch more expensive, but probably not as expensive as a very public failure. Finally, why is it that most vendors never test their products in a serious battlefield environment like an ISP of size medium to huge? These places tend to be excellent worst-case testing grounds. Sean.

4 3

Re: Interconnecting at MAE-West
by jones＠nsipo.arc.nasa.gov 08 Jul '96

08 Jul '96

Hello Carl... You can connect to MAE-West-SanJose by contacting Steve Feldman of MFSdatanet. See webpage for products and services as well. You may be eligible to connect to MAE-West-MoffettField by contacting me. Our business model allows commercial enterprises to connect for a $10,000 one time fee and $2,000/month/FDDIport, with a reservation on a GIGAswitch port when that becomes necessary. Terms are prepayment of initial fee and 6 mos connection. Fee is adjusted up or down at end of 12 mos to ensure that only "cost to NASA Ames" is collected. To do this, you must send to me on business letterhead a Letter Of Intent to collocate equipment at Moffett Field, and sign a Reimbursable Space Act Agreement prior to connecting your data line and your router. The cost for now is the same for a DS1, a DS3 or an OC3c. The Participant is responsible for obtaining an IP address from Bill Manning, manager of Routing Arbiter project, and for making any and all peering agreements with other participants. If this is of interest, please contact me via email. /bill jones, external interface manager --- Forwarded mail from Carl Forsythe <carlf(a)mbay.net> >From nanog-owner(a)merit.edu Fri Jul 5 23:46:25 1996 Return-Path: <nanog-owner(a)merit.edu> Received: Fri, 5 Jul 1996 23:46:25 -0700 (PDT) from merit.edu (RFC1413 sender merit.edu [35.1.1.42]) by nsipo.arc.nasa.gov (8.7.1/1.5) id XAA22764 Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id AAA10516 for nanog-outgoing; Sat, 6 Jul 1996 00:51:12 -0400 (EDT) Received: from otter.mbay.net (carlf(a)otter.mbay.net [206.40.79.2]) by merit.edu (8.7.5/merit-2.0) with ESMTP id AAA10510 for <nanog(a)merit.edu>; Sat, 6 Jul 1996 00:51:06 -0400 (EDT) Received: (from carlf@localhost) by otter.mbay.net (8.7.2/8.6.12) id VAA09613 for nanog(a)merit.edu; Fri, 5 Jul 1996 21:51:00 -0700 From: Carl Forsythe <carlf(a)mbay.net> Message-Id: <199607060451.VAA09613(a)otter.mbay.net> Subject: Interconnecting at MAE-West To: nanog(a)merit.edu Date: Fri, 5 Jul 1996 21:51:00 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-nanog(a)merit.edu Precedence: bulk Could some kind network operator out there, guide me to a FAQ or some other document with regards to interconnecting at MAE-West (or any other MAE). Specifically, some of the things I would like to find out about are probably old hat to most of you, so if you could pass on some of your knowledge, it would be greatly appreciated. Some of the specifics: 1) Requirements for interconnect at MAE-West 2) Cost? 3) Minimum Line Speed 4) Transit? i.e. if the line is for backup purposes only, how can we arrange for transit, etc... 5) Peering agreements etc. So if there is a document or set of documents that have this info in them, if someone could point me in the right direction, I'd surely appreciate it. -Carl Forsythe carlf(a)mbay.net -- ===================================================================== Carl Forsythe |Webmaster Monterey Bay Internet | carlf(a)mbay.net | http://www.mbay.net | ===================================================================== --- End of forwarded message from Carl Forsythe <carlf(a)mbay.net>

1 0

AS numbers question
by algold＠lambda.lncc.br 07 Jul '96

07 Jul '96

Are there "reserved" AS numbers, the same way there are reserved IP addresses for non-connected networks? Are As numbers considered scarce ? (I think of many small Internet providers asking for AS numbers just to peer BGP with more than one ISP). TIA -- ----------------------------------------------------------------------------- | Alexandre Leib Grojsgold | tel: + 55 21 542-2746 | | LABORATORIO NACIONAL DE COMPUTACAO CIENTIFICA | fax: + 55 21 295-8499 | | 22.290 Rio de Janeiro - RJ - Brasil | | -----------------------------------------------------------------------------

4 3

Interconnecting at MAE-West
by Carl Forsythe 06 Jul '96

06 Jul '96

Could some kind network operator out there, guide me to a FAQ or some other document with regards to interconnecting at MAE-West (or any other MAE). Specifically, some of the things I would like to find out about are probably old hat to most of you, so if you could pass on some of your knowledge, it would be greatly appreciated. Some of the specifics: 1) Requirements for interconnect at MAE-West 2) Cost? 3) Minimum Line Speed 4) Transit? i.e. if the line is for backup purposes only, how can we arrange for transit, etc... 5) Peering agreements etc. So if there is a document or set of documents that have this info in them, if someone could point me in the right direction, I'd surely appreciate it. -Carl Forsythe carlf(a)mbay.net -- ===================================================================== Carl Forsythe |Webmaster Monterey Bay Internet | carlf(a)mbay.net | http://www.mbay.net | =====================================================================

6 7

ANNOUNCEMENT: New listserver - ISP-Telco
by Richard Cramer 06 Jul '96

06 Jul '96

Hopefully we will be filling a void. People have asked for a list that would have as its subject: Telco equipment as related to the ISP environment. We hope to deal with a broad subject matter; CSU/DSU configuration, equipment feature comparisons, T-Carrier analyzer tips, lease line procurement, etc, etc, etc. The list is now open for subscriptions. We will take subscriptions for about 3-5 days. This way no one will miss anything and we can also shake out any last minute problems. Postings will be accepted starting July 10th unless notified otherwise. SUBSCRIPTION INFO: Subscribe to: majordomo(a)list.sytex.net, with no subject, and "subscribe isp-telco" in the body of the message. Regards, Dick -- Richard Cramer rcramer(a)sytex.net Phone: 703-425-2515 President Fax: 703-425-4585 Sytex Access Ltd. POB 2385, Fairfax, VA 22031-0385

1 0

re: AGIS Route Flaps Interrupting its Peering?
by Peter Kline, Sr. Network Engineer 05 Jul '96

05 Jul '96

Here's some background: AGIS's router is not colocated at the MAE parking garage, but is in fact colocated at WorldCom in downtown Washington DC. Our bits get from there to the MAE via a DS3, and that DS3 is terminated at each end with a device called a NetEdge, which does the FDDI to DS3 ATM conversion. These NetEdges seem to have three different possible operating states: completely working (which doesn't happen often enough); broken (often, right out of the box); and kind of working (which happens all too often). This third operating state results in some very interesting, possibly misleading, and sometimes damaging behavior. It looks quite similar to the kind of behavior you get when you change the MAC layer device but keep the same ip address at either of the MAE's: ARP caches get inconsistent, and BGP sessions with other routers flop around, leading to routes getting flap dampened by those running the appropriate code. Here's what happened: AGIS's connection to MAE-East experienced one of these kind-of-working problems which resulted in the erratic behavior above. Digex customers wishing to reach AGIS customers called the Digex NOC, and the posting which started this all was made to the Digex internal news group. Similarly, AGIS customers had problems, and we worked with MFS to get the problem resolved (they must have a warehouse full of swapped-out NetEdges at this point). In the interval, a short-on-facts bozo spit into the wind and got us and Digex wet. I'm in private correspondence with Ed Kern to postmortem the situation. Peter At 10:25 AM 7/5/96 -0400, Ed Kern wrote: >> >> One key point is that we have not received any complaints or reports >> of any sort concerning any perceived issues at mae-east from any >> mae-east peers. Digex made no attempt to contact us. We were already >> working with Advantis on the unreachable issue above, but the first we >> heard of the "AGIS attacks mae-east" report was when a Digex customer >> sent us a report similar to that forwarded to all of you by Cook. > >Went into this in the last message...Digex will try and be more >proactive with pointing out Agis flapping prefixes in the future. > > >> An appropriate audience would have been the AGIS noc and the Digex >> noc. I think the Cook approach was inappropriate because the issue >> was purely between Digex and AGIS until Cook distributed it to the >> three widespread mailing lists. > >I agree.. > > >> > How is the report flawed? >> >> I see that Ed Kern has already replied indicating that the report was >> indeed flawed. I don't think that there is anything to be gained by >> going into further detail. > >What I was referring to was the internal circulation here...which I was >under the impression got to external customers....now im not so >sure... > >The internal report was flawed because it relied to much on source >routes and came to some bad conclusions on the internal state of agis. > > >> My key point is that nothing of interest happened. This was a >> non-issue until the misinformation was blasted around the Internet >> technical universe. >> > >I would argue that the external message that got sent around was >misinformation...It was correct information from what the people >could see at the time it was released...(lots of dampened prefixes and >a down peer).. > > >Ed > > > _____________________________________________________________________ Peter Kline Senior Network Engineer| 313-730-5151 AGIS - Internet Backbone Services | _Lucem Diffundo_ Post-Traumatic Success Disorder+ | ///////////////////////////////////////////////////////////////////// You can pretend to care, but you can't pretend to be there.

3 2

Re: Internet access and telco usage patterns
by Hong Chen 05 Jul '96

05 Jul '96

Eric, As a matter of fact, it is quite doable. Aimnet developed a roaming server (check www.aimnet.com) that allows international ISPs to use each other's network to provide dialup services. A group of ISPs have joined a consortium GRIC (Global Reach Internet Consortium) lead by Aimnet. The roaming server is based on Radius protocol. A telco company can install modems and route the authentication to the specific ISP for authentication. I just came back from Montreal INet 96 last week and a new roaming IETF group will be started. We are working on the IETF draft for the roaming and stay tuned. Hong Aimnet -------- Begin Included Message ------- > At 05:36 PM 7/4/96 -0700, 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. > > > >I now find that BC-Tel is offering this service in parts of British > >Columbia. BC-Tel is half owned by GTE. > > Michael, > > Also of possible interest here is that Westel, another telco in British > Columbia started offering this service early 3rd quarter of last year (with > Livingston Portmasters, ISP managed RADIUS authentication, and its own > Internet connection) which pressured to BCTel to offer a similar service. > Eric Woodward. > ejw(a)wedirect.ca. > > -------- End Included Message --------

1 0

re: AGIS Route Flaps Interrupting its Peering?
by Peter Kline, Sr. Network Engineer 05 Jul '96

05 Jul '96

At 06:41 AM 7/5/96 +0100, Sean Doran wrote: >| Since ANS seems to be passing our interface address as the >| next-hop directly to some nets (e.g., Digex and Advantis), the failure >| as I described above did lead to a loss of connectivity between AGIS >| and at least Digex and Advantis. Pending the solution of the MFS >| problem, it would have been possible to work around the issue if the >| affected nets had routed _through_ their transit provider. > >Let me reiterate the point that propagating third-party >next-hops in the absence of guaranteed fate-sharing is EVIL, >or at least very very risky. I agree. >My opinion is probably at one pole of the spectrum of ideas >about NAPs and MAEs, however it's essentially this: do not >propagate other people's next-hops at all to your NAP/MAE peers, >either using next-hop-self (or the equivalent) or announcing only >those prefixes for which you have yourself as a next-hop. Moreover, >one should be very cagey about accepting third-party next-hops >from one's peers, and either refuse routes with such next-hops, >or (with permission only), rewrite the next-hops in question, >unless there is a very good reason to do otherwise. AGIS always configures with next-hop-self, so that the only way we can propagate a nonworking next-hop is if our own router is down. I'm considering seriously Sean's recommendation about vetting next hops from others. [...chop...] >an issue. However, this should not be the default behaviour >at any exchange-point, because the AGIS/DIGEX disconnectivity >is a well-known and formerly oft-seen problem. If "well-known" means "the net is all a-twitter about it", then I agree. If "well-known" means "seen over a long period of time" then I disagree. In any case, as Sean now characterizes the problem as "formerly", he obviously considers it fixed. Further, as AGIS sees AS2548 directly at MAE-East, as well as behind AS690 and AS1239_1800 (!), we'd have to be broken two or three ways at each of 5 exchange points to completely lose connectivity to Digex. [...whack...] >On another front, *weird* MAE and NAP setups have caused >so much trouble that I sometimes wonder when the next time >I get to say "I told you so" about multi-fabric-bridging-from-hell >will be, and how bad it will hurt. I'm afraid it will be all too soon. LAN-based exchange points presuppose that every router at the exchange point will want to talk to every other router at the exchange point. That deprives the router operator of some meaningful control. Peter _____________________________________________________________________ Peter Kline Senior Network Engineer| 313-730-5151 AGIS - Internet Backbone Services | _Lucem Diffundo_ Post-Traumatic Success Disorder+ | ///////////////////////////////////////////////////////////////////// You can pretend to care, but you can't pretend to be there.

1 0

re: AGIS Route Flaps Interrupting its Peering?
by Mark Kent 05 Jul '96

05 Jul '96

> So, Mark, you're saying that your routers did not have a problem? > If your routers did have a problem, did it affect other providers? Right. Our routers did not create any problems that we are aware of. There was a minor problem at mae-east that appears to have been caused by the MFS NetEdge. Several IP addresses in 192.41.177.0/24 became unreachable from our router at 192.41.177.145, but not our router at 192.41.177.170. We contacted MFS about the problem and they rebooted the NetEdge in the middle of last night. Things are back to normal. Since ANS seems to be passing our interface address as the next-hop directly to some nets (e.g., Digex and Advantis), the failure as I described above did lead to a loss of connectivity between AGIS and at least Digex and Advantis. Pending the solution of the MFS problem, it would have been possible to work around the issue if the affected nets had routed _through_ their transit provider. > If it did affect other providers, were you available to resolve > the problems in a timely manner? I do not believe that we affected other providers in the manner implied by the [internal] Digex report. We had three bgp sessions down. We could not ping those neighbours. MAE-East transit customers of other networks could have been affected as I described above, if they were not protected by "next-hop-self" from their transit provider. One key point is that we have not received any complaints or reports of any sort concerning any perceived issues at mae-east from any mae-east peers. Digex made no attempt to contact us. We were already working with Advantis on the unreachable issue above, but the first we heard of the "AGIS attacks mae-east" report was when a Digex customer sent us a report similar to that forwarded to all of you by Cook. > ] Gordon Cook asks of an inappropriate audience: > > I'm not certain it's innapropriate. If someone's trying to play > with us, and causing us problems, then I would like to know about > it. An appropriate audience would have been the AGIS noc and the Digex noc. I think the Cook approach was inappropriate because the issue was purely between Digex and AGIS until Cook distributed it to the three widespread mailing lists. > ] The Digex report is seriously flawed. Ed Kern of Digex has told us > ] that he is looking into how the conclusions in that report were reached. > > How is the report flawed? I see that Ed Kern has already replied indicating that the report was indeed flawed. I don't think that there is anything to be gained by going into further detail. > ] However, I'm sure that Kern didn't think that he would have to share > ] his findings with nanog, inet-access, and agislist... > > Could you share your findings? If there was a problem, I think > we'd all prefer an explanation rather than a finger shaking for > having interest. My key point is that nothing of interest happened. This was a non-issue until the misinformation was blasted around the Internet technical universe. -mark

2 1

re: AGIS Route Flaps Interrupting its Peering?
by Ed Kern 05 Jul '96

05 Jul '96

> > One key point is that we have not received any complaints or reports > of any sort concerning any perceived issues at mae-east from any > mae-east peers. Digex made no attempt to contact us. We were already > working with Advantis on the unreachable issue above, but the first we > heard of the "AGIS attacks mae-east" report was when a Digex customer > sent us a report similar to that forwarded to all of you by Cook. Went into this in the last message...Digex will try and be more proactive with pointing out Agis flapping prefixes in the future. > An appropriate audience would have been the AGIS noc and the Digex > noc. I think the Cook approach was inappropriate because the issue > was purely between Digex and AGIS until Cook distributed it to the > three widespread mailing lists. I agree.. > > How is the report flawed? > > I see that Ed Kern has already replied indicating that the report was > indeed flawed. I don't think that there is anything to be gained by > going into further detail. What I was referring to was the internal circulation here...which I was under the impression got to external customers....now im not so sure... The internal report was flawed because it relied to much on source routes and came to some bad conclusions on the internal state of agis. > My key point is that nothing of interest happened. This was a > non-issue until the misinformation was blasted around the Internet > technical universe. > I would argue that the external message that got sent around was misinformation...It was correct information from what the people could see at the time it was released...(lots of dampened prefixes and a down peer).. Ed

1 0