May 2000 - Test - lists.nanog.org

ISP/CO-LO Start-up...
by York, Tracy (CEI-Atlanta) 17 May '00

17 May '00

For a couple of years now, I've been lurking on this list and have learned some great things... and at times been very amused. Now its time to ask a few questions... My company is starting an ISP/CO-LO to provide services to some of their business units. These business units provide everything from e-mail to web services to their customers, public and private. We have already ordered 4 DS-3's (I know, small time) with tier one providers and plan on setting up BGP peering with each of them. We already have an ASN and IP addresses. What I would like to know, is if their are any good guidelines that we should follow in getting all this cranked up. I know some of you (if not all) have experienced various issues in starting up an ISP and I would like to draw on that knowledge to make sure we get it right the first time. I'm looking for information on everything from BGP to good business practices from the technical side. Please reply off list. Thanks -TY "Give beer to those who are perishing..." (Proverbs 31:6)

1 0

Re: Private ASN suppression
by Danny McPherson 16 May '00

16 May '00

Actually, RFC 2270 is only suggested to be used when sites are homed to a single provider. In this case, there won't be origin AS inconsistencies. I believe most implementors (some listed, some not) of this "remove-private-as" capability only intended for it to be used in configurations where the source of the route(s) is homed only to a single upstream AS. -danny > ...as well as rfc2260. > > to be more specific, we have to note that two different options > are considered there. if you use the first one (read rfc), > then you cannot use private asn until you're ok with > generating inconsistencies (and it seems from the previous > discussions of this topic that this becomes (illegal? -> > no answer...) practice for some smaller isps). > > with the second option of 2260, you can use private asn > since the more specific pa routes are always aggregated > (and you cannot use confederations, btw). > > after all, as was noted, remove-private-as on cisco can be > replaced by a simple route map, and the attribute manipulation > functionality should definitely exist on versalars... > -- > dima. > > > >

2 1

Bell Atlantic DACS failure 280 T3s
by Sean Donelan 16 May '00

16 May '00

Bell Atlantic lost another DACS yesterday taking out 280 T3s for 3-1/2 hours in the northeastern corridor and New York City. I'm not a transmission person, but what is the problem with DACS? Why do these "highly reliable" systems fail in such catastrophic ways?

3 2

Re: The %^&# did it!
by Jared Mauch 16 May '00

16 May '00

I'm not sure what text you're reading, but I'm reading from the ammendment to HR1291 Section 2, sub (2) which states: "(2) RULE OF CONSTRUCTION. -- Nothing in this subsection shall preclude the Commission from imposing access charges on the providers of Internet telephone services, irrespective of the type of cus- tomer premises equipment used in connection with such services.". my (personal) translation is this: Nothing here prohibits the FCC from imposing charges on Internet telephone providers. Because if you're an "ITP", it would likeley require compatability with the existing PSTN infastructure, you would then be charged based upon existing fees associated with telephone calls. (DCS, PRI, etc.. as you interconnected with ILEC/CLEC telephone switches to gain access to the PSTN). - jared On Tue, May 16, 2000 at 02:08:34PM -0700, Owen DeLong wrote: > > Since this specifically addressed per-minute charges/fees/taxes, and > USF is not a per-minute charge as I understand it (I thought it was > per-line), I suspect it is not related. > > Owen > > > > > <i am not a lawyer, but i talked to one> > > > > This is as it relates to the USF (Universal Service Fund). > > > > This means that providers of IP telephony that interconnect with > > the PSTN are not excluded from paying USF fees. Or that's my understanding > > of the ammendment. > > > > - Jared > > > > On Tue, May 16, 2000 at 03:37:45PM -0400, John Fraizer wrote: > > > > > > > > > http://www.wired.com/news/politics/0,1283,36339,00.html > > > > > > Time for a change in Washington. Register to throw them out...er...vote. > > > > > > > > > --- > > > John Fraizer > > > EnterZone, Inc > > > > > > > > > > -- > > Jared Mauch | pgp key available via finger from jared(a)puck.nether.net > > clue++; | http://puck.nether.net/~jared/ My statements are only mine. > > END OF LINE | > > > > -- Jared Mauch | pgp key available via finger from jared(a)puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE |

1 0

The %^&# did it!
by John Fraizer 16 May '00

16 May '00

http://www.wired.com/news/politics/0,1283,36339,00.html Time for a change in Washington. Register to throw them out...er...vote. --- John Fraizer EnterZone, Inc

4 3

Re: Private ASN suppression
by Danny McPherson 16 May '00

16 May '00

In short, see RFC 2270. Some of the primary differences are that several of the BGP attributes are preserved with confederations, versus that autonomous "look and feel" provided by dedicated ASs, not to mention that any such model would assume that the providers employ confederations as well. Also, managing it would be a nightmare. More importantly though, is that if providers allow customers to maintain sub-ASs of a confederation they're placing a considerable amount of trust in the capabilites of those customers, and errors on the customers part could impact much more than just the customers part. -danny > I'm trying to understand the problem being solved by the Cisco > private AS removal feature. In particular, what advantages does it > offer over confederations, which would seem to do the same thing when > externally advertising customer routes? Is there a performance > benefit? > > RFC1998-style multihoming with a private AS is a possible > application, I suppose, for any routes that are NOT marked with > NO-EXPORT. >

2 1

co-location/machine room facilities in germany
by Jim Mercer 16 May '00

16 May '00

can anyone recommend a goo co-location or machine room facility in germany? i need to set up 2-3 racks. - need ability to patch into one or more first tier providers - AC power with battery/deisel backup - 7x24 access - local person to do intermittent reboots preferred location is frankfurt, other cities would be considered. -- [ Jim Mercer jim(a)reptiles.org +1 416 410-5633 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]

1 0

Re: New Internet-draft on DDOS defense...
by Vipul Shah 16 May '00

16 May '00

>>> <mixter(a)newyorkoffice.com> 05/13/00 07:19PM >>> Hi, I'm sorry it took me so long to reply. I couldn't find the particular message, and there seemed to be a couple of new ones, so I'm posting my reply here... It is true that with the proposed solution, attackers can still launch smurf attacks with the broadcast of a local LAN, however they cannot use arbitrary broadcasts to commence smurf attacks. They have to get inside access on every subnet they want to smurf from, which also means they can be tracked down by looking at the broadcast replies to the victim. Also, it is true that the bandwidth of a smurf is a multiple of the attackers bandwidth, so it is relevant. But launching *smurf* attacks (not DDOS) from anything as fast as an OC-12 would simply overload the used broadcast addresses. The maximal bandwidth of each broadcast reply is the bandwidth of the subnet whose broadcast you're pinging, it is not limited only by your own bandwidth. That's also the point why only the use of *many different* broadcasts at a time can launch a devastating attack. You would have to operate from several moderately-fast boxes, e.g. smurf with 100 different broadcast addresses, each from one T1, or smurf them from a T3, cycling through the broadcast list, in order not to concentrate to much bandwith on a single broadcast, which could overload the broadcast itself (like the smurf.c programs do). Additionally, the proposed solution is obviously meant to be implemented along with ingress traffic policing. If a subnets external router uses both rfc1122 and ingress filtering rules, there is no chance for an outside or inside attacker to ever launch a broadcast amplifier flood. On Fri, 12 May 2000, Vipul Shah wrote: > Mixter, > > Currently, we have started a discussion thread on NANOG mailing list for DDoS Smurf attack solution... > http://www.merit.edu/mail.archives/nanog/ > > One of the response (attached mail) says that, such Smurf attack is not effective unless it is launched from sites with switched ethernet and OC-3 or better connectivity. Hence it is not beneficial to any attacker. > > Since I don't have experience/knowledge about which kind of sites are compromized for generating attacks, I suggest , if you can reply to the attached mail (either to me or directly to NANOG list). Like kind of networks used for launching attacks and typical number of DDoS agents. Such knowledge will help us to finalize , whether the proposed solution is useful to implement or not? > > Thanks, > Vipul >

1 0

Internet helps fire victims of Los Alamos Fire.
by John M. Brown 16 May '00

16 May '00

Its a wonderful thing to see the Internet help bond people together. Folks at ShoutCAST have a kick butt product. It allowed us to whip up a internet broadcast of the only radio station in Los Alamos and to get LIVE information to the evacuated towns people. Over 25,000 people where evac'd and are just now returning home. Folks like The New Mexico Internet Professional Assoc. put up a database to track people and to let them communicate with each other via BBS system. Folks at other ISP's around the state helped keep things glued together. Backbone provided by several companies. CW, Verio, UUNET, QWEST All ran without a hitch. The biggest thing was the ability to get informationn out to people as quickly and as correct as possible. We where able to use the power of the net to get the word out quickly about a wide range of things. I hope that other communities and the ISp's that service those areas work together as well as the folks that did here. This is really what the net is about. Bringing people together, not only locally, but regionally, nationally, and globally. People from around the world where able to help, send their prayers, etc by getting from the various web sites. Let us not forget that the net is also about: Doing Good Having Fun Local ISP's and providers that I'd like to thank for their direct or indirect support. C&W CyberMesa.com iHighway.net LosAlamos.com La-Tierra NM.NET/ORG UUNET QWEST Verio News providers: KRSN Los Alamos Radio krsn.losalamos.com ABQ Journal www.abqjournal.com The various TV (local and nantional)

1 0

IETF TE Interim Meeting
by Randy Bush 15 May '00

15 May '00

To: IETF-Announce: ; Subject: Interim TEWG meeting June 14, 20000 Date: Sun, 14 May 2000 12:06:32 -0400 From: Steve Coya <scoya(a)cnri.reston.va.us> An interim meeting of the Traffic Engineering Working Group (tewg_ will be held on the 14th of June, 2000 Time: 9.00AM to 1.00PM. The venue is shown below: Hyatt Regency Albuquerque Convention Center 330 Tijeras Albuquerque New Mexico 87102

1 0