April 2000 - Test - lists.nanog.org

Re: Peering Table Question
by I Am Not An Isp 24 Apr '00

24 Apr '00

At 05:54 PM 4/21/00 +0200, Mikael Abrahamsson wrote: >One can also look upon it that the customer of Network A (the web site) >should pay Network A for the costs involved and the customer of Network B >(the dialup user) should pay Network B for their costs. A transfer of data >is never initiated without two parties, one offering the data and the >other requesting it. You never put data online unless you want people to >look at it. Yes, I can see that if a network is very large it would not >want to pay money for a private interchange, but if you are already at a >shared medium you should at least offer restricted routing (for instance, >you offer routes for your Washington DC customers to people at MAE-EAST). Why do you assume most networks even have the ability to offer you "routes for [their] Washington DC customers" at MAE-East? Offering localized routes is not necessarily trivial. It has also been actively discouraged as "dangerous" by some members of this list. I am not at all saying that this is not possible, or even that it is not a good idea. Just that no network "should" do anything it does not want to do. Of course, one could argue that networks which make this extra effort may have better traffic flows and happier customers, which may make them more profitable or bigger companies or whatever. Whether that is actually the case is left as an exercise for the reader. :) >Mikael Abrahamsson email: swmike(a)swm.pp.se TTFN, patrick -- I Am Not An Isp - www.ianai.net ISPF, The Forum for ISPs by ISPs, <http://www.ispf.com> "Think of it as evolution in action." - Niven & Pournelle (Enable? We dunt need no stinkin' enable!!)

1 0

Re: Peering Table Question
by I Am Not An Isp 24 Apr '00

24 Apr '00

At 01:18 AM 4/20/00 -0600, Forrest W. Christian wrote: >But that isn't the case. We live in a world where both the hosters and >the accessors are paying for their access. Any settlement based in that >system will be unfair as it is almost impossible to put a different value >on each end of the link. Who's to say for a given AS whether inbound or >outbound is more important? It is not "inbound" or "outbound" per se, it is the amount of traffic and how far you have to carry it. Simplistic example: Network A hosts big web sites. Network B has a gazillion dial-up users. The two networks peer at MAE-East and MAE-West. The web sites are in San Jose, the dial-up users are in DC. Typical TCP flow looks like this: 1500 byte packet goes from web server to MAE-West on Network A, then transfers to Network B (because of "hot potato" routing) and comes across the country to DC destined for dialup user. Then a 64 byte ACK goes from DC to MAE-East on Network B, then transfers to Network A where it rides to San Jose. In Other Words: Network B is carrying 1500 byte packets 3000 miles, and Network A is carrying 64 byte packets 3000 miles. Sounds to me like an objective, technical reason to require one network to pay another even if they are just "peering". (Unless you are Randy, in which case one is now a "customer" of the other.) Another solution would be to have Network A agree to carry the packet cross-country, relieving Network B of the need to carry big packets long distances. However, that requires useful Network B to give Network A useful MEDs. Or maybe a bazillion other possible solutions. In summary, there is nothing wrong with settlements to help off-set unequal network costs. It is a perfectly valid business practice. Nor, IMHO, does it make one network a "customer" of the other. The two networks are just trying to share everything equally, including network costs. >- Forrest W. Christian (forrestc(a)imach.com) KD7EHZ TTFN, patrick -- I Am Not An Isp - www.ianai.net ISPF, The Forum for ISPs by ISPs, <http://www.ispf.com> "Think of it as evolution in action." - Niven & Pournelle (Enable? We dunt need no stinkin' enable!!)

8 8

Re: Question about strain on the A root server
by Andrew Brown 23 Apr '00

23 Apr '00

>> binfo.c = Bind Version Checker >> 'binfo' is a quick little script to pull back the version >> of named running on a remote nameserver. This is handy >> for >> comparing it to a list of known vulnerable versions of >> named/bind. Previous to this, it took a few commands to >> extract out the version. > >It seems to have been written more of not as a DNS admin convenience, >but more as for inclusion into rootkit type packages, IMO. perhaps, but it's certainly (a) not malicious or (b) gonna swamp the root servers. >A few commands? More like one :) > >$ nslookup -q=txt -class=chaos version.bind <nameserver> or dig version.bind chaos txt @nameserver :) >And here's how to disable giving out that information to untrusted hosts >or networks: > >in named.conf, set up something like this (*NOT* in the options section): >... >Now, create a file called 'chaos' (in same directory where your zone >files lives) with something like: >... been there, done that. and it's interesting to see all the people who are checking out your name server after their addresses get logged for hitting the acl. -- |-----< "CODE WARRIOR" >-----| codewarrior(a)daemon.org * "ah! i see you have the internet twofsonet(a)graffiti.com (Andrew Brown) that goes *ping*!" andrew(a)crossbar.com * "information is power -- share the wealth."

1 0

name servers
by Dana Hudes 23 Apr '00

23 Apr '00

I have a name server for the few domains I host and my little local LAN. with reverse DNS lookup on for incoming e-mail and for web server logging, it does a fair bit of ns queries. I considered making it forward to concentric (my DSL ISP) name server but the result would be degraded performance of my network (or possibly no improvement over concentric, depending on which root is queried): PING hudson.concentric.net (207.155.183.72): 56 data bytes 64 bytes from hudson.concentric.net (207.155.183.72): seq=0 ttl=247 time=85.1 ms . 64 bytes from hudson.concentric.net (207.155.183.72): seq=1 ttl=247 time=85.9 ms . 64 bytes from hudson.concentric.net (207.155.183.72): seq=2 ttl=247 time=86.3 ms . ---- hudson.concentric.net (207.155.183.72) PING Statistics ---- 3 packets transmitted, 3 packets received, 0% packet loss round-trip (ms) min/avg/max = 85.1/85.8/86.3 (std = 0.475) PING a.root-servers.net (198.41.0.4): 56 data bytes 64 bytes from a.root-servers.net (198.41.0.4): seq=0 ttl=249 time=28.9 ms. 64 bytes from a.root-servers.net (198.41.0.4): seq=1 ttl=249 time=19.2 ms. 64 bytes from a.root-servers.net (198.41.0.4): seq=2 ttl=249 time=18.0 ms. 64 bytes from a.root-servers.net (198.41.0.4): seq=3 ttl=249 time=48.6 ms. PING b.root-servers.net (128.9.0.107): 56 data bytes 64 bytes from b.root-servers.net (128.9.0.107): seq=0 ttl=248 time=73.1 ms. 64 bytes from b.root-servers.net (128.9.0.107): seq=1 ttl=248 time=72.5 ms. 64 bytes from b.root-servers.net (128.9.0.107): seq=2 ttl=248 time=73.7 ms. 64 bytes from b.root-servers.net (128.9.0.107): seq=3 ttl=248 time=73.3 ms. 64 bytes from b.root-servers.net (128.9.0.107): seq=4 ttl=248 time=76.9 ms. ò ---- b.root-servers.net (128.9.0.107) PING Statistics ---- 5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max = 72.5/73.9/76.9 (std = 1.54) PING c.root-servers.net (192.33.4.12): 56 data bytes 64 bytes from c.root-servers.net (192.33.4.12): seq=0 ttl=247 time=23.4 ms. 64 bytes from c.root-servers.net (192.33.4.12): seq=1 ttl=247 time=20.8 ms. 64 bytes from c.root-servers.net (192.33.4.12): seq=2 ttl=247 time=22.7 ms. 64 bytes from c.root-servers.net (192.33.4.12): seq=3 ttl=247 time=20.2 ms. 64 bytes from c.root-servers.net (192.33.4.12): seq=4 ttl=247 time=20.6 ms. ò ---- c.root-servers.net (192.33.4.12) PING Statistics ---- 5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max = 20.2/21.5/23.4 (std = 1.25) PING d.root-servers.net (128.8.10.90): 56 data bytes 64 bytes from d.root-servers.net (128.8.10.90): seq=0 ttl=246 time=91.7 ms. 64 bytes from d.root-servers.net (128.8.10.90): seq=1 ttl=246 time=109 ms. 64 bytes from d.root-servers.net (128.8.10.90): seq=2 ttl=246 time=109 ms. 64 bytes from d.root-servers.net (128.8.10.90): seq=3 ttl=246 time=111 ms. 64 bytes from d.root-servers.net (128.8.10.90): seq=4 ttl=246 time=99.6 ms. ò ---- d.root-servers.net (128.8.10.90) PING Statistics ---- 5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max = 91.7/104/111 (std = 7.34) PING E.ROOT-SERVERS.NET (192.203.230.10): 56 data bytes 64 bytes from E.ROOT-SERVERS.NET (192.203.230.10): seq=0 ttl=56 time=75.1 ms. 64 bytes from E.ROOT-SERVERS.NET (192.203.230.10): seq=1 ttl=56 time=78.3 ms. 64 bytes from E.ROOT-SERVERS.NET (192.203.230.10): seq=2 ttl=56 time=75.0 ms. 64 bytes from E.ROOT-SERVERS.NET (192.203.230.10): seq=3 ttl=56 time=75.9 ms. ò ---- E.ROOT-SERVERS.NET (192.203.230.10) PING Statistics ---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 75.0/76.0/78.3 (std = 1.35) Clearly BTW I'm not getting what I'm paying for (1.1Mb SDSL via Covad) from Concentric. 85ms is ridiculously bad to a name server.

2 1

Question about strain on the A root server
by Nick Patience 23 Apr '00

23 Apr '00

Hi all, Disclosure: I'm a journalist with a company called the451.com (details in sig file). Anyhow, that said, I was talking to Network Solutions about their decision to swap out the Sun box that is the A root server and change it for a more powerful RS/6000 S80. Also it is using IBM servers for its new network of name servers - it has already deployed 8 of the intended 12 according to the company, including one brought on stream two days ago in Hong Kong. As most on this list probably already know, it is separating the root servers from the name servers. Anyhow, NSI claims that the strain on the A root server has jumped from 220 million 'hits' to 420 million during Q1 alone. I haven't managed to define what hit is yet but intend to at some point. NSI seems slightly unsure as to the main reason for the increase in hits, but speculates that one of the reasons may be says the main reason for this is that ISP's are using different caching techniques and more & more searches are going right to the top of the tree than before. What do people on this list feel about this as a reason? It seems a little woolly to me. Cheers, Nick -- Nick Patience Internet Editor & NY Dep. Bureau Chief the451.com | wap.the451.com T: 212 460 7131 M: 917 312 5712 F: 413 826 8217 nick.patience(a)the451.com

8 9

Win, win...
by Dennis Targa 23 Apr '00

23 Apr '00

*Earn $2000 - $5000 weekly-starting within 1-4 weeks *78% Profit Paid Daily *No Selling *No Risk Guarantee *Work from home, No overhead, or employees. *High Tech Training & Support *Not MLM, 100x more profitable *Multibillion Dollar Travel Industry The most incredible part of our business is that ALL MY CLIENTS CALL ME! DO YOU QUALIFY FOR OUR MENTOR PROGRAM? ACCEPTING ONLY 12 NEW ASSOCIATES This is not a hobby! Serious Inquires Only!! Please reply with the following information NAME: EMAIL ADDRESS: PHONE: (Required) BEST TIME TO CALL: TO: mailto:perr89@populus.net?subject=more_info ////////////////////////////////////////////////////////////////// If you would like to be removed from our list reply to: mailto:vvxx76@yahoo.com?subject=remove //////////////////////////////////////////////////////////////////

1 0

Anyone encountered Cisco ATM PVC large delay bug?
by Yu Ning 23 Apr '00

23 Apr '00

Hi nanog, I'm not sure how many percentage of global NSP/ISP use ATM PVC to provide links between their Cisco routers. It seems there is some large delay bugs in Cisco ATM interface, esp on GSR level routers. In more detail, our situation is: if we get a high bandwidth PVC, say 51M(or 80M), and if the bandwidth utilization reaches 80% percent, the ATM link will encounter a 1500~2000 ms delay - just point to point ping across the link. We have found this situation is associated with "sar txpool" setting in Cisco GSR, and a manipulation of the "sar txpool" together with bandwidth increasing has solved the problem now. But I still wonder if any of you ever encounter this situation(bug), and how did you overcome it? If you are still puzzled by this bug, I'd like share our temp solution with you. regards, Yu Ning ------------------------------------------- (Mr.) Yu Ning ChinaNet Backbone Operation Networking Dep.,Datacom Bureau China Telecom.,Beijing(100088),P.R.C +86-10-66418121/66418122/66418123(fax) -------------------------------------------

3 3

April 2000 COVAD dsl problems
by Sean Donelan 22 Apr '00

22 Apr '00

I've received a report that COVAD had several switch problems affecting their DSL service across the country dating back to April 5. At least three multi-hour outages have happened. I tried contacting COVAD, but was directed to call my local ISP. Mail to noc(a)covad.net bounced as undeliverable. Is anyone aware what is happening. Is it a switch problem, operation, or something else.

4 3

Network Solutions
by Stewart Gott 22 Apr '00

22 Apr '00

I've been silently reading the posts about Network Solutions, and boy! I cannot agree more. I deal with a lot of Vendor Tech Support and Network Solutions Tech Support is in a class by itself (the absolute worst I have ever dealt with)! Their incompetency knows no bounds! It is scary! Their attitude seems to be if you fill out the on-line or email form to the computer's satisfaction, and the computer accepts and processes it, fine, otherwise they have absolutely no clue how to help you, how to change anything, how to update anything, it really is pathetic! Stewart Gott Network Manager None of us will be free until nerd persecution ends!

3 2

RE: New Federal Law (COPPA)
by Robert Cannon 22 Apr '00

22 Apr '00

The law in question is the Child Online Privacy Protection Act, passed in 1998. Today, (Friday April 21) FTC rules implementing the new law take effect. You may be interested in the following information: FTC's How to Comply with COPPA http://www.ftc.gov/bcp/conline/pubs/buspubs/coppa.htm FTC's Privacy website http://www.ftc.gov/privacy/index.html According to the FTC guide, the following people must comply and thus will want to learn more about this: QUOTE If you operate a commercial Web site or an online service directed to children under 13 that collects personal information from children or if you operate a general audience Web site and have actual knowledge that it collects personal information from children, you must comply with the Children's Online Privacy Protection Act. * To determine whether a Web site is directed to children, the FTC will consider several factors, including the subject matter; visual or audio content; the age of models on the site; language; whether advertising on the Web site is directed to children; information regarding the age of the actual or intended audience; and whether a site uses animated characters or other child-oriented features. * To determine whether an entity is an "operator" with respect to information collected at a site, the FTC will consider who owns and controls the information; who pays for the collection and maintenance of the information; what the pre-existing contractual relationships are in connection with the information; and what role the Web site plays in collecting or maintaining the information. END QUOTE -Robert Cannon Internet Telecom Project www.cybertelecom.org ------Original Message------ From: "Moe Allen" <moe(a)vidnet.net> To: <nanog(a)merit.edu> Sent: April 21, 2000 7:10:50 PM GMT Subject: New Federal Law The Federal Government just announced a new Law that goes into effect today. ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup

6 6