July 1998 - Test - lists.nanog.org

RE: NOC communications
by Derek Elder 14 Jul '98

14 Jul '98

The thing that needs to be understood is that if we as an industry don't fix this problem, the government will fix it for us. The government won't care if there is a distinction between a "Big" or "Small" guy amongst ISP's anymore than they will between SBC or BellSouth and some Mom&Pop local Telco. I think that this attitude is -precisely- what the legislators will decide to fix. $.02 Derek Elder US Web / Gray Peak Technologies Network Engineering 212-548-7468 Pager - 888-232-5028 delder(a)graypeak.com http://www.usweb.com A Strategic Partner for the Information Age. -----Original Message----- From: Hui-Hui Hu [mailto:hhui@arcfour.com] Sent: Tuesday, July 14, 1998 12:44 AM To: delder(a)graypeak.com Subject: Re: NOC communications OK, but large providers don't want to talk to small providers. It's a stated policy of many networks to refer a smaller customer/provider to their upstream. I only want to talk to someone who's competent (I get really sick of kids who have just discovered traceroute and send me e-mail, or worse yet call me, because they don't understand what "administratively denied" means) . My point is only that there is always a pecking order and by making network ops egalitarian you end up with a high signal/noise ratio, or worse yet, all the people who actually are relevant leave. (Witness NANOG: half the people from MCI etc. don't read any more) I don't have a solution, unfortunately. Sigh. -h : Shouldn't be that hard to verify that someone is actually a network : provider. Criteria is, run a public network, you qualify. Pretty simple.

1 0

Re: T3 to E3 conversions
by Sean M. Doran 14 Jul '98

14 Jul '98

| We buy our transatlantic stuff with T3 ports either end, all our domestic | private circuits as T3s, and everything else internationally is carried | on circuits which use SDH and the "T" hierarchy. May be I'm unusual in | this respect, but I know people who have bought from BT and got T3s too. In places like 60 Hudson St or 111 8th Av, or anywhere at all in Europe that Colt or MFS (as examples) go, you should push for a full VC3 rather than just a T3 or E3, assuming you have a way of using it. Elsewhere you will more likely be stuck with T3 or E3. | No, I don't know why at the E1/T1 level E1 is the preferred way of doing it. It's historical. Terminating E1s in D.C. (or anywhere else in the US beyond the switches talking to the cables) was a mess involving special gear. Terminating T1s in Europe "couldn't be done". These days, since there are the VT1.5 and VT2 in SONET land and the TU-11 and TU-12 in SDH land, the "standards gap" is fixed by digital cross-connection; the choice of T1 vs E1 payload is mostly down to who has the right trib cards, and who has the most PDH cruft in the way, or (cynically) down to E1s likely bringing in more revenue. Sean.

1 0

Re: T3 to E3 conversions
by Sean M. Doran 14 Jul '98

14 Jul '98

| How do carriers handle E3 to T3 conversions? They don't. That is, they don't convert. It is possible to carry an E3 inside a PDH T3, but it's very ugly. These days an E3 or a T3 is carried inside an SDH VC3, which is then carried in a VC4, which is then carried inside an STM-1 or an OC3, and broken out of the final SDH or SONET ADM by using an appropriate trib card. (At the "final" SDH or SONET ADM, a T3 payload may be digitally cross-connected to a T3 that will be carried in a disjoint SONET network. This avoids dedicating an OC3 to carry the VC4/VC3 structure). If you are fortunate and have an end-to-end SDH/SONET path, then you can use a VC3 in any way you want. Typically, however, for transatlantic traffic, you have to choose one or the other, or an ugly hybrid that uses an E3-in-T3 scheme, because someone will be using PDH gear in the end-to-end path. Usually, the reason you can't do an entire VC3 is because the US carrier doesn't want to waste bandwidth (as above). The commoner case is that you can't do a T3 end-to-end because a non-US carrier has PDH gear in the path that can only do E3s, as SDH has a formally specified and widely implemented means of carrying around T3s. | What equipment is used? The ICM E3 path formerly used by NORDUNET was an E3 from Stockholm to London, connecting to a Cisco router ("speed converter"), and a DS3 from London to Pennsauken, connected to another port on the "speed converter". The "speed converter" ended up being a "TDM" of sorts, since an 8Mbps circuit was eventually stuck to yet another port. This was not an SDH/SONET issue, however; SDH-using or SONET-using cables are quite new. | have heard that trans-Atlantic carriers sell E3s to Europeans when in fact | it is a T3 with T3 costs passed on the customer and merely convert the line | from T3 to E3 - thereby causing 11Mb/sec of b/w to be wasted. Any truth to | that? The T3 and E3 tarriffs are probably the same, but nobody in their right mind would waste even more of a VC3 deliberately by forcing you to take an E3 instead, not even (most) PNOs, since they'd have to coordinate PDH encapsulation. But not all cables and land paths are SDH or SONET yet... Sean.

1 0

T3 to E3 conversions
by Hank Nussbacher 14 Jul '98

14 Jul '98

How do carriers handle E3 to T3 conversions? What equipment is used? I have heard that trans-Atlantic carriers sell E3s to Europeans when in fact it is a T3 with T3 costs passed on the customer and merely convert the line from T3 to E3 - thereby causing 11Mb/sec of b/w to be wasted. Any truth to that? Thanks, Hank

2 1

NOC Contacts
by Leo Bicknell 14 Jul '98

14 Jul '98

Here's an idea, I'm not sure if it could work. Set up a small "verification company" (or maybe even non-profit org). For a small fee ($50/month?) you could have your contact information entered, and the company would randomly check it frequently (once every 2-3 weeks?). Failure to have current contact info would result in a penalty ($5000?) to stay in the program. Then, networks could require as part of peering agreements and such that both sides participate. For their $50/month each side knows the verification company has current contact info, and they can get it from the company via web sites or monthly news letters. It's a very rough idea, but is there a business model and support for such a thing? -- Leo Bicknell - bicknell(a)dimension.net Network Engineer (CCIE #3440) - Dimension Enterprises 1-703-709-7500, fax, 1-703-709-7699

2 1

MAJOR OUTAGE NYC
by alex＠nac.net 13 Jul '98

13 Jul '98

MFS has a major outage in NYC according to 800-MFS-CITY, which began 24 minutes ago. Details to follow... -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Atheism is a non-prophet organization. I route, therefore I am. Alex Rubenstein, alex(a)nac.net, KC2BUO, ISP/C Charter Member Father of the Network and Head Bottle-Washer Net Access Corporation, 9 Mt. Pleasant Tpk., Denville, NJ 07834 Don't choose a spineless ISP! We have more backbone! http://www.nac.net -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

3 3

Re: Smurf Prevention
by Richard Thomas 13 Jul '98

13 Jul '98

-----Original Message----- From: Joe Shaw <jshaw(a)insync.net> To: Richard Thomas <buglord(a)ex-pressnet.com> Cc: nanog(a)merit.edu <nanog(a)merit.edu> Date: Monday, July 13, 1998 10:44 AM Subject: Re: Smurf Prevention >On Mon, 13 Jul 1998, Richard Thomas wrote: > >> HOW HARD CAN IT BE to take care of 500 broadcasts? Very hard, since the only >> bcasts still left are those with broken contact information and upstreams >> who haven't been informed or who don't give a damn. Maybe if we all picked >> 10 of the worst offenders every day, picked up the phone, and started >> informing people who have missed the boat... > >I'm still quite fond of blackholing entities which are completely >irresponsible, though for the larger carriers this wouldn't be much of a >threat. But after having tried to track down smurfers, I'm wondering if >anyone has ever actually done it. I would think you would have to either >get in touch with a smurf amplifier or their upstream to track the DoS, >but how successful has anyone been in doing so? I would think that >since smurfs have been popular amongst the script kiddies for so long >that all the entities that are easy to get in touch with have already >heard from victims and hopefully fixed the situation. Also, I wonder if >there is any way to hold the amplifiers legally responsible for smurfs >that use their networks after being given repeated notice? I certainly know people who have had it traced back (when a bcast being used is on a major backbone, or after 2-3 days of being attacked), but I have not actually heard of anyone being "caught". In all cases the smurfer was on a university network, several times in euro, a few in the US, and no attempts were made to find the kid involved. Besides we all know the only thing they would find is someone's wingate. As for holding amplifiers responsible, everyone talks about it, nobody does it, and if they are liable for being a broadcast you're not gonna get much of a judgement, since you can't prove malicious intent.

2 1

NeTraMet
by Chris Cappuccio 13 Jul '98

13 Jul '98

I would like to get in touch with someone who has implemented NeTraMet for the purpose of bandwidth accounting. I'm wondering if there are some skeleton configuration files available for implementing this sort of accounting in a relatively simple manner. //chris

2 1

Re: SPAM, RE: Internic and there lame response
by Anthony Sticha 13 Jul '98

13 Jul '98

OK so what to do if their upstream does nothing? Like PBI >>There are many other ways to track a spammer. >> >>- Do nslookup on the IP that originated the spam (sometimes this takes a >>bit of detective work to find what IP actually originated the spam). >>- Traceroute to the originating IP. Email the ISP that is directly upstream. > >*I* know these techniques. Joe User who's irritated at his spam likely >does not. > >>- Look in the Whois information for contact emails and nameservers - if >>these are for the upstream ISP, or some ISP other than the spammer, report >>it to them. > >But there's the rub. A great deal of the information (including >delegations) in domain registrations by net.abusers is complete >fabrication. InterNIC refuses to deal with it, even when it's pointed out >to them. > >>- If they are advertising a web page, track the web page host, and their >>upstream, and report it to them. > >All the time :> >> >>>What do spammers and nails have in common? They're both intended for >>>hammering. >> >>Amen. > >Witnesses available at www.witness.com...:) > > >What do spammers and nails have in common? They're both intended for >hammering. > >Dean Robb >PC-Easy >On-site computer services >(757) 495-EASY [3279] > > >

2 1

Re: NOC communications (was Re: Process management)
by Sean Donelan 13 Jul '98

13 Jul '98

>You bring up an interesting (if unspoken) point in your prior statement, >and that is: "Communications between entities is worthwhile if the >communications facility has a high signal-to-noise rate." While I am not >certain, I have strong suspicions that the SS7 NOCs pushed their emergency >directory numbers to the general number due to useless, misdirected calls. Most of the SS7 providers involved reported no problems with misuse of their contact information. A couple of providers said they were changing the contact information out of fear the information might be misused. One provider stated they had problems, but didn't give any specifics. As some anecdotal evidence I've found our WHOIS e-mail contact information tends to get spammed by the small time bulk mailers, usually whose own contact information is bogus. While our phone information tends to get junk calls by large corporations, usually one particular major ISP's telemarketing operation trying to sell Internet service. Handling such calls through the general purpose number can work well, IF and I repeat IF, the staff at the general purpose number is trained how to handle the calls and direct the information expeditiously. Unfortunately, it seems the person changing the emergency contact information forgets to inform the customer service operation they will now be getting those calls. Some companies seem to do this well, some seem to do this poorly. As I found out, you never know when it will be your newest, greenest tech who happens to get the call at the exact same time the senior engineer is in the bathroom. Even though the calls are fairly rare, it is an ongoing training process. Of course, if the general purpose contact number was working well, there wouldn't be a need for another contact method. > Being a secretary is not something that a NOC can afford to do. Being a secretary is also something most NOCs don't do well. It is a different set of skills. Dealing with a good receptionist is a pleasure. On the other hand, a bad receptionist is really bad. How many folks remember the recurring receptionist character sketch on Saturday Night Live. I doubt most NOC engineers would last 30 minutes on the front desk of a large law firm. >Therefore, to avoid this problem, one must limit the ubiquity of the >contact mechanism and increase the value of each message. Using a medium >like a phone number is of course the standard method for contact in any >emergency situation (email is great, but it lacks a rapid >question-answer-experiment ability) but phones also carry with them the >ease of use that works against them, as well as for them. A phone number >gets handed out on web sites, "emergency call" sheets, etc. and soon >people who do not have anything directly relating to operations are calling >the operations hot line. Either more staff is required to start answering >these questions, or (more likely) the "hot line" becomes not-so-hot and it >will go unanswered or not taken seriously, or simply nobody will care about >it and it will get forwarded to the Void. Yes, I'm aware of the 9-1-1 problem. If you make something that works well, everyone is afraid it will be overwhelmed with all sorts of calls not relevant to its primary purpose. On the other hand, if you make a something that is so restricted, it will never be abused, but it will also likely never get used or important pieces of information won't get through. How do you set things up to create a 'shared fate' among all the participants? Do you need a strong moderator, editor or dispatcher to make such a system work? To avoid the 'whose in charge' problem do we draw lots each week for the moderator position? If each of the participants don't feel some pressure from their management, shareholders, customers to make a good faith effort; will any and every system fail of active neglect? There have been several attempts in the past, and have not had a sucessfull track record. I'm going to keep throwing ideas against the wall to see what sticks. Are any of these ideas even close to being useful? Or do people think there is not a problem and I should just shut up. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2