- Test - lists.nanog.org

Re: BBN Peering issues
by Lawrence A. Deleski 16 Aug '98

16 Aug '98

Perhaps BBN is not answerable to you and I, but they should care deeply about and be answerable to the community that makes the Internet work, which, in some cases, just might *be* you and I. Or maybe they should find a new business where they can operate unobstructed by convention, guidelines, consensus, and historical precedent. --- Lawrence A. Deleski lad(a)inficad.com ---------- >From: shields(a)crosslink.net (Michael Shields) >To: mark(a)exodus.net (Mark Tripod) >Subject: Re: BBN Peering issues >Date: Sun, Aug 16, 1998, 7:59 AM > >> fundamentally important that these ideals be extended to the future of >> the Internet, if it is to have a future. No company should have the >> right to force another to pay for connectivity simply because the latter >> has not been around since the beginning or they are not a telco. > >BBN is answerable to their customers and shareholders and not to your >or my ideals of how the Internet should work. >-- >Shields, CrossLink. >

1 0

Re: BBN Peering issues
by Hank Nussbacher 15 Aug '98

15 Aug '98

On Thu, 13 Aug 1998, Jay R. Ashworth wrote: > > What I would like more than anything right now is some official word from > > high-up's at BBN regarding what this policy entails exactly, and what > > their rationale is behind it. > > > Based on just that little slice of the conversation, is BBN doing what > UUnet apparently failed in _it's_ attempt to do last fall, to Jack > Rickard's (and my) vast amusement? Now it all fits in to something I didn't quite understand 2 weeks ago. I consult for a university network planning the purchase of a T3 to the Chicago NAP for access to StarTap and Internet-2. Part of the cost planning is finding Internet-1 access via an ATM VC of 8Mb. I sent around to a number of major ISPs at the Chicago NAP asking to *pay* for full peering at the Chicago NAP via an 8Mb VC. A number of them came back with good answers. But BBN's sales droids indicated very clearly that they will not peer with me unless I purchase the line into the NAP from them: >Date: Thu, 23 Jul 1998 11:34:33 -0500 >Organization: GTE Internetworking > >We will allow the peering if you get the lines from us. So if you order the >T3 through GTE Internetworking, you can peer with us at a NAP. Where are >you getting the T3 from now? > >-----Original Message----- >From: Hank Nussbacher [SMTP:hank@ibm.net.il] >Sent: Saturday, July 18, 1998 1:25 PM >To: xxxxx >Subject: RE: T3s > >On Fri, 17 Jul 1998, xxxxx wrote: > >Even to pay you won't allow a university to peer with you at a NAP?! >-Hank > >> Hank, we only do private peering with telco companies. The only way to >do the peering you want to do with us is to order the T3 through us. Needless to say, they are now off my short list. Tis a shame though. The BBN NOC is by far the most responsive I have seen. When sending our Smurf complaints to UUnet, MCI, Sprint, BBN, etc., I will usually get 5 responses in 24 hours from their NOC (different people). The others just send an automated trouble ticket and I never hear from them again. Hank

1 0

DNS Headaches.
by max＠inc.net 15 Aug '98

15 Aug '98

I am having some very bizzare DNS issues and am wondering if anyone will be able to shed some light on this. A customer of ours started recieving thousands of DNS requests for a wide range of domains, mostly foreign. The requests are coming from a wide range of ips most of which respond to nslookups "ie are nameservers". I have done a whois on some of the domains and the 2 name servers having the problems don't show up, I have also check to root servers and dont see anything which would direct those domains to the name servers. Their entire T1 is full from these requests about 1.2 meg. As the customer is in the business of web hosting they can kill named nor can they put up a packet filter to fix this. Also because there are literally hundreds of diffrent domains both preforming the lookups and being looked up it is not feasable to call the admin of each one to work this out. Anyone have any ideas? Max Spaulding Internet Connect, INC. max(a)inc.net

6 8

Re: BBN peering, a technical issue
by Sean M. Doran 15 Aug '98

15 Aug '98

Jerry - The problem boils down to making traffic move the right way, and making sure the traffic is well-behaved. The biggest problem with using MEDs to attract traffic to the right places, in your model, is simply route aggregation. The next-biggest -- and less immediately soluble -- problem is policing the MEDs. How do you tell whether your rival is obeying your MED announcements faithfully, and what do you do when they don't? (Conversely, how can you tell if the MEDs are being fair to you?) There are other small issues involving what happens in the face of failures -- peering routers crash, peering infrastructure fails, people mess up configurations, etc. In other words, even if you design for traffic going the right way, sometimes it doesn't. What do you do then? Finally, my own concern is what happens if the big colo site ends up playing with devices which deliberately over-ack -- adding fractional ACKs into the stream coming back from web browsers -- and other techniques for opening the congestion window larger or faster than it should be opened, or otherwise sending traffic that does not back off in the face of congestion in your network. It would be ironic if a business race was triggered by people deliberately breaking congestion-avoidance. "Come buy colo from us -- your web pages will seem faster even than web pages on our peers' networks!" would be pretty bad. I say bad not for business reasons, but because TCP's timers and other congestion-avoiding mechanisms are *THE* key mechanism for stability in the Internet. Classic congestion collapse would not be nice for anyone. Sean.

2 1

Re: DNS Headaches.
by Sean Donelan 15 Aug '98

15 Aug '98

That'll teach me not to ignore the first lesson in all the 'security awareness' classes. If something seems odd, it probally is, and should be reported. Name resolution was sluggish enough I thought Hmm? when I first logged in yesterday. But the name resolved, and I had fun-filled day pending with the United States Post Office about something else so the odd DNS delay was quickly forgotten. Any reports if this was just an "Oops"(tm), or another Kasporov-type incident? a.root-servers.net is running BIND 8.1.2-T3B. I didn't notice any security patches between the beta and the final release of 8.1.2. >This wouldn't be webteam.net, would it? =) > >This morning, Chris Yarnell from NASA pointed out the response >to "dig @a.root-servers.net . soa": > >. 2D IN NS PANIC.WEBTEAM.NET. >. 2D IN NS TORGO.WEBTEAM.NET. >PANIC.WEBTEAM.NET. 2D IN A 207.67.50.8 >TORGO.WEBTEAM.NET. 2D IN A 207.67.50.7 > >I don't know how this happened, but it doesn't look pretty. =) > >(The "standard" zone files were okay -- .COM, .NET, etc...) -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: BBN Peering issues
by owen＠DeLong.SJ.CA.US 15 Aug '98

15 Aug '98

> The question above is rather interesting, and what I'd like to know is > what are the various types of "peering" that various ISPs have arranged > between each other? > PEERING == Equal relation ship wher provider A announces routes to themselves and their customers to provider B and Provider B does likewise. There is no announcement by either party of non-customer 3rd party routes to the other. TRANSIT == Provider A is a customer of provider B. Provider A announces routes to itself and it's customers. Provider B announces a complete routing table and/or a default route to provider A. These are separate and distinct entities from Exchange points... Exchanges (places where traffic gets handed off) come in the following varieties: PUBLIC == An exchange point where multiple providers connect with each other across a shared media, such as ATM, FR, Ethernet, FDDI, etc. Generally most public exchanges are run by a third party to whom all of the ISPs connecting have a customer relationship. PRIVATE == A circuit or virtual circuit between two providers which does not provide a shared media type of environment with multiple providers. Generally, there is no third party customer relationship, other than possibly one or both ISPs paying a telco for a circuit. There are many different financial arrangements that can be made around private peering. One of the most common ones I've seen is to bring up multiple circuits and agree that provider A pays for one circuit while provider B pays for the other. No other money changes hands. Sometimes, provider A is willing to pay for all circuits just to get better connectivity for their customers. I hope this clarifies the terms. Owen > "public" - each ISP is at a public exchange point and traffic that is > destined to/from each provider moves across whatever hardware is provided > at the exchange point. This could exist at all exchange points where both > parties have an adequate presence. Possible additional cost if traffic > that would come from another peer is shifted here and bandwidth to the > exchange needs to be increased. > > "private" - A connection exists either via PTP, ATM, FR, or whatever else > you can think of between the involved parties. One or both parties pay > for the link. One time hardware outlay. Seems expensive. Less expensive > than "buying" an DS3 or higher port from the provider. Who buys from > whom? Who pays? These must be NDA'd. Can anyone cite some examples of > what some providers *might* do to make it a fair trade when this is an > NDA'd agreement? > > "public/private hybrid" - Existing exchange point equipment and > connections are used. Purchase ether/fddi cable from MFS to run between > your equipment. Cheap? No telco charges, consolidate your pipes. > > So what was the Exodus/GTEI agreement like? Did it fit neatly into one of > these categories? Are there other more esoteric arrangements? Is GTEI > basically trying to get Exodus as a "customer" in a round-about way? That > certainly seems like an easy way to make more cash. "I'll talk to you, > but only if you buy 'Peering Bundle #A13' from us at $100,000/mo. and you > have no other options. We are big, and this is what you need to do to > be a peer." > > Is this an accurate assessment? Please set me on track if I'm > misunderstanding the concepts at work here... > > Thanks, > > Charles > > =-----------------= = > | Charles Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork(a)inch.com access(a)inch.com | > = =----------------= > >

2 1

Re: DNS Headaches
by max＠inc.net 15 Aug '98

15 Aug '98

Oh man thanks for finding this. Those are indeed the servers in question. Earlier in the day when I tried to get some help from internic on this they totally would not do anything for me. Think I am going to enjoy the return call. -Max Max Spaulding Internet Connect, INC. max(a)inc.net On 14 Aug, Robert Cantrel wrote: > I think it's related to something I noticed last night. It was gone > when I checked again around noon today. > > ; <<>> DiG 2.2 <<>> . soa @a.root-servers.net > ; (1 server found) > ;; res options: init recurs defnam dnsrch > ;; got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 > ;; flags: qr rd; Ques: 1, Ans: 0, Auth: 2, Addit: 2 > ;; QUESTIONS: > ;; ., type = SOA, class = IN > > ;; AUTHORITY RECORDS: > . 172800 NS PANIC.WEBTEAM.NET. > . 172800 NS TORGO.WEBTEAM.NET. > > ;; ADDITIONAL RECORDS: > PANIC.WEBTEAM.NET. 172800 A 207.67.50.8 > TORGO.WEBTEAM.NET. 172800 A 207.67.50.7 > > Some kind of technical glitch at InterNIC. None of the other > root servers displayed this behaviour when I checked. > >>I have an added note. Someone asked me about what domains are being >>looked up and if it might be something someone registered. I dont >>believe this to be the case. There are literally hundreds of domains >>being looked up to many to have had someone register them all. Also >>many of the domains are actual domains I know to be real such as >>excite.com. >> -Max > > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com

1 0

DNS Headaches
by max＠inc.net 15 Aug '98

15 Aug '98

I have an added note. Someone asked me about what domains are being looked up and if it might be something someone registered. I dont believe this to be the case. There are literally hundreds of domains being looked up to many to have had someone register them all. Also many of the domains are actual domains I know to be real such as excite.com. -Max

3 3

Re: DNS Headaches
by max＠inc.net 15 Aug '98

15 Aug '98

Once again there are hundreds of diffrent origin addressess. Most of which appear to be actual name servers. -Max Max Spaulding Internet Connect, INC. max(a)inc.net On 15 Aug, Richard Irving wrote: > What about origin IP, while this may be thousands of domains... > What IP's are the requests originating from....... > > If it is a small block, they could filter it. > > max(a)inc.net wrote: >> >> I have an added note. Someone asked me about what domains are being >> looked up and if it might be something someone registered. I dont >> believe this to be the case. There are literally hundreds of domains >> being looked up to many to have had someone register them all. Also >> many of the domains are actual domains I know to be real such as >> excite.com. >> >> -Max

1 0

SPAM
by Adam D. McKenna 15 Aug '98

15 Aug '98

My hosts/customers have been getting repeatedly spammed for the last three days from someone using Earthlink mail relays. The hosts in question: gull.prod.itd.earthlink.net snipe.prod.itd.earthlink.net (some other prod.itd.earthlink.net hosts, I can't remember the others now.) I have been sending mail repeatedly to abuse(a)earthlink.net but have gotten no response, and the spam hasn't stopped. I'd appreciate if a nice Earthlink admin could step in here and make sure the problem gets fixed. Otherwise, I'd like to "nominate" earthlink.net for RBL. --Adam adam(a)flounder.NO-SPAM.net

1 0