April 2001 - Test - lists.nanog.org

What does 95th %tile mean?
by Alex Rubenstein 22 Apr '01

22 Apr '01

I've gotten myself into an argument with a provider about the definition of 'industry-standard 95th percentile method.' To me, this means the following: a) take the number of bytes xfered over a 5 minute period, and determine rate for both the inbound and outbound. Store this in your favorite data-store. b) at billing time, presumably on the first of the month or some other monthly increment, take all the samples, sort them from greatest to least, hacking off the top 5% of samples. Actually, this is done twice, once for inbound, once for outbound. Then, take the higher of those two, and multiply it by your favorite $ multiple (ie, $500 per megabit per second, or $1 per kilobit per second, etc). I think that most people agree with the above; the issue we are running into is one rogue provider who is billing this at in + out, not the greater of in or out. How is everyone else doing it? Specifically, larger folks (UU, Sprint, CW, Exodus/FGC, GX, Qwest, L3) Thanks!

22 42

www.psi.com up, down, ?
by Sean Donelan 22 Apr '01

22 Apr '01

Is www.psi.com down or just extremely slow. I've been trying to check it since last evening, and can't get response. PSI's network is up, and mail gets to their NOC address. But www.psi.com site seems to be out to lunch.

1 0

Inter-provider communications history
by Sean Donelan 21 Apr '01

21 Apr '01

I was trying to put together a list of the various projects to improve inter-provider communication. Are there any others I missed? Internet Monthly Report - Ann Cooper The purpose of these reports is to communicate to the Internet Research Group the accomplishments, milestones reached, or problems discovered by the participating organizations. IPN - Craig Labovitz This was a web/java database which maintained messages from ISPs, sorted by ASN and data, about scheduled and unscheduled network outages IPNmoo - KC Claffy This was a real-time chat (MUD) which let ISPs send messages between members IOPS - Ira Richer IOPS has a shared trouble-ticketing system, which let ISPs send trouble tickets between members NOCwire - Sean Donelan This was a "hoot-n-holler" network. This was a closed-circuit, out-of-band audio bridge between NOC's which allowed ISPs to share real-time information There have also been several discussions Alan Hannan - NANOG May 1996 Sean Donelan - Network Event Reporting Facility Sean Donelan - IDIG-L Internet Disturbance Investigation Group Stan Barber - outage-discuss(a)academ.com IETF - netstat working group IETF - RFC 1297 NOC trouble ticket requirements Federal Network Council Advisory Committee - Trouble Ticket Tracking as a "priority"

1 0

RE: Chinese hackers plan week-long attack on American websites an d ne tworks
by Jeremy Furr 21 Apr '01

21 Apr '01

Can't we all just get along??? Jeremy -----Original Message----- From: Petri Stephen [mailto:Stephen.Petri@nycboe.net] Sent: Friday, April 20, 2001 10:02 AM To: NANOG List (E-mail) Subject: Chinese hackers plan week-long attack on American websites and ne tworks .....As China and the United States attempt to peacefully end their diplomatic standoff ...........crackers from both countries continue to wage private wars on the Internet. ......Chinese hackers are now vowing to retaliate with a planned week-long all-out crack attack on American websites and networks which will start on May 1. ....... http://www.wired.com/news/politics/0,1283,43134,00.html?tw=wn20010419

6 7

The Cidr Report
by Tony Bates 21 Apr '01

21 Apr '01

This is an auto-generated mail on Fri Apr 20 23:00:00 PDT 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 20Apr01 0) General Status Table History ------------- Date Prefixes 130401 99823 140401 99656 150401 99795 160401 99731 170401 99601 180401 99779 190401 99884 200401 100216 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 223.255.46.0 from AS6853 *** Bogus 223.255.70.0 from AS6853 AS Summary ---------- Number of ASes in routing system: 10519 Number of ASes announcing only one prefix: 6219 (3531 cidr, 2688 classful) Largest number of cidr routes: 1218 announced by AS705 Largest number of classful routes: 1592 announced by AS1221 1) Gains by aggregating at the origin AS level --- 20Apr01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1592 1194 398 25.0% Telstra Pty Ltd AS701 1462 1276 186 12.7% 1 AS705 368 251 117 31.8% 1 AS6429 214 105 109 50.9% 1 AS4151 247 139 108 43.7% 1 AS6595 163 62 101 62.0% 1 AS13999 104 8 96 92.3% 1 AS4293 370 277 93 25.1% 1 AS7018 694 605 89 12.8% 1 AS15412 430 341 89 20.7% FLAG Telecom Global Internet AS AS8013 319 236 83 26.0% 1 AS4755 218 138 80 36.7% Videsh Sanchar Nigam Ltd. Autonom AS577 241 172 69 28.6% 1 AS5106 101 37 64 63.4% 1 AS3749 120 59 61 50.8% 1 AS9498 75 15 60 80.0% BHARTI BT INTERNET LTD. AS3464 151 92 59 39.1% 1 AS11252 92 34 58 63.0% 1 AS724 203 146 57 28.1% 1 AS16758 63 6 57 90.5% 1 AS1 609 552 57 9.4% 1 AS6413 67 11 56 83.6% 1 AS226 149 93 56 37.6% 1 AS7568 84 29 55 65.5% C.S. Communications Co., Ltd. AS6471 99 46 53 53.5% 1 AS4323 230 178 52 22.6% 1 AS9269 116 67 49 42.2% City Telecom (H.K.) Ltd. AS852 200 152 48 24.0% 1 AS10692 62 14 48 77.4% 1 AS9683 48 2 46 95.8% Kyonggi Cable TV For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

RE: Torturous routes.
by Jeff Doyle 21 Apr '01

21 Apr '01

[snip] > And hey, at least it's staying within the same state. > I have seen lots of situations where traffic going across the > street will cross the country at least once to get there. Anyone > who's ever lived in a rural market has to deal with much, much > worse on a daily basis. > > --msa > ...such as this old trace, that I've saved for some time, from an access point in Denver to a destination in Denver. --- traceroute to www.rmi.net (166.93.8.30), 30 hops max, 18 byte packets 1 ( 207.155.168.5) ts003e01.den-co.concentric.net 152 ms 2 ( 207.155.168.1) rt001e0102.den-co.concentric.net.168.155.207.IN-ADDR.ARPA 161 ms 3 ( 207.88.24.21) 207.88.24.21 190 ms 4 ( 207.88.0.253) us-ca-scl-core1-f9-0.rtr.concentric.net 189 ms 5 ( 207.88.0.178) 207.88.0.178 206 ms 6 ( 144.228.207.73) sl-gw18-chi-5-1-0-T3.sprintlink.net 210 ms 7 ( 144.232.0.217) sl-bb11-chi-3-3.sprintlink.net 216 ms 8 ( 144.232.0.174) sl-bb5-chi-4-0-0.sprintlink.net 211 ms 9 ( 144.232.8.85) sl-bb7-pen-5-1-0.sprintlink.net 225 ms 10 ( 144.232.5.53) sl-bb10-pen-1-3.sprintlink.net 236 ms 11 ( 144.232.5.62) sl-nap1-pen-4-0-0.sprintlink.net 228 ms 12 ( 192.157.69.13) p219.t3.ans.net 263 ms 13 ( 140.223.60.209) f1-1.t60-6.Reston.t3.ans.net 264 ms 14 ( 140.223.65.17) h12-1.t64-0.Houston.t3.ans.net 286 ms 15 ( 140.223.25.14) h13-1.t80-1.St-Louis.t3.ans.net 283 ms 16 ( 140.223.25.29) h14-1.t24-0.Chicago.t3.ans.net 292 ms 17 ( 140.223.9.18) h14-1.t96-0.Denver.t3.ans.net 309 ms 18 ( 140.222.96.122) f1-0.c96-10.Denver.t3.ans.net 313 ms 19 ( 207.25.224.14) h1-0.enss3191.t3.ans.net 306 ms 20 ( 166.93.46.246) 166.93.46.246 305 ms 21 ( 166.93.8.30) www.rmi.net 285 ms --------------------------------------------- Jeff Doyle Professional Services Engineer Juniper Networks, Inc. Denver, Colorado jeff(a)juniper.net (303)910-0820 ---------------------------------------------

1 0

Torturous routes.
by Roeland Meyer 20 Apr '01

20 Apr '01

This reminds me of those daze when they did experiments with spiders. They dosed them with LSD and took pictures of the webs they wove afterwards. I've intentionally deleted the end-points. I also sent this to both Qwest and SPeakEasy over two weeks ago. These routes are persistent. Going out ---This starts in Livermore CA 2 spkez.gw.mhsc.net (216.27.184.225) 2.575 ms 2.707 ms 2.558 ms ---Gets to San Francisco on the first hop (looks like an overloaded router) 3 gw-081-176.sfo1.dsl.speakeasy.net (216.27.176.1) 24.758 ms 118.038 ms 27.967 ms ---Plays around on the InterNAP. 4 border3.fe5-3.speakeasy-9.sff.pnap.net (216.52.86.28) 20.485 ms 20.795 ms 21.185 ms 5 core4.fe0-0-bbnet1.sff.pnap.net (216.52.80.6) 22.027 ms 20.601 ms 21.605 ms ---Finally gets to QWest (used to be USworst ... may still be) but still hasn't left SF 6 sfo-01.qwest.net (208.46.207.53) 27.531 ms 25.920 ms 25.610 ms 7 sfo-core-02.inet.qwest.net (205.171.18.13) 49.049 ms 25.583 ms 25.332 ms ---After playing around in SF, it finally makes it to San Jose (really, SJC). 8 sjo-core-01.inet.qwest.net (205.171.5.121) 27.116 ms 27.924 ms 27.754 ms 9 sjo-core-02.inet.qwest.net (205.171.22.2) 28.149 ms 60.099 ms 50.570 ms ---Then goes down to Los Angeles, for some sunshine. 10 lax-core-01.inet.qwest.net (205.171.5.153) 34.183 ms 35.243 ms 34.637 ms 11 lax-brdr-01.inet.qwest.net (205.171.19.38) 33.980 ms 40.761 ms 33.618 ms ---Where it finally crosses over to AboveNet 12 sjc2-lax1-oc12.sjc2.above.net (208.184.102.145) 51.917 ms 45.190 ms 47.872 ms 13 sjc2-lax1-oc48.sjc2.above.net (208.185.156.125) 49.168 ms 52.816 ms 62.538 ms ---and heads back to San Jose 14 core5-sjc2-oc48.sjc1.above.net (216.200.0.177) 48.298 ms 80.466 ms 43.326 ms 15 main2-core5-oc12.sjc1.above.net (209.133.31.190) 44.550 ms 64.522 ms 47.930 ms Coming back seems to be much more intelligent (less drifty); 3 main3-main4-fe.sjc1.above.net (209.249.192.4) 7.212 ms 5.777 ms 7.242 ms 4 core1-main1-oc12.sjc1.above.net (208.185.175.245) 7.237 ms 6.944 ms 7.232 ms 5 sl-gw8-sj-0-1.sprintlink.net (144.232.192.129) 7.231 ms 6.973 ms 7.233 ms 6 sl-bb21-sj-13-0.sprintlink.net (144.232.3.113) 7.230 ms 6.973 ms 7.245 ms 7 sl-gw12-sj-10-0.sprintlink.net (144.232.3.142) 7.227 ms 6.926 ms 7.241 ms 8 sl-internap-40-0-0.sprintlink.net (144.232.217.18) 18.254 ms 17.886 ms 18.251 ms 9 border4.ge2-0-bbnet1.sff.pnap.net (216.52.80.9) 18.170 ms 17.905 ms 21.890 ms 10 spk-1-sfo.dsl-isp.net (216.52.86.1) 29.110 ms 21.618 ms 32.778 ms 11 dsl027-176-139.sfo1.dsl.speakeasy.net (216.27.176.139) 40.001 ms 39.886 ms 40.082 ms Note that these two are the same box. spkez.gw.mhsc.net (216.27.184.225) dsl027-176-139.sfo1.dsl.speakeasy.net (216.27.176.139)

2 1

Re: Torturous routes.
by Richard A. Steenbergen 20 Apr '01

20 Apr '01

On Fri, Apr 20, 2001 at 02:11:01PM -0700, Roeland Meyer wrote: > > This reminds me of those daze when they did experiments with spiders. > They dosed them with LSD and took pictures of the webs they wove > afterwards. I've intentionally deleted the end-points. I also sent > this to both Qwest and SPeakEasy over two weeks ago. These routes are > persistent. It's not their fault (not counting poor decisions of where to peer or buy transit), it's INAPs. > ---Gets to San Francisco on the first hop (looks like an overloaded router) > 3 gw-081-176.sfo1.dsl.speakeasy.net (216.27.176.1) 24.758 ms 118.038 ms 27.967 ms > > ---Plays around on the InterNAP. > 4 border3.fe5-3.speakeasy-9.sff.pnap.net (216.52.86.28) 20.485 ms 20.795 ms 21.185 ms > 5 core4.fe0-0-bbnet1.sff.pnap.net (216.52.80.6) 22.027 ms 20.601 ms 21.605 ms Speakeasy uses InterNAP for transit... Though why a DSL provider would pick a company who's model for optimizing traffic is far more useful outbound then inbound is beyond me. Maybe INAP gave them some $200/meg transit to try and stay in business... > ---Finally gets to QWest (used to be USworst ... may still be) but still > hasn't left SF And InterNAP uses QWest for transit... > ---Then goes down to Los Angeles, for some sunshine. Semi reasonable on qwest's part... Can't afford to peer with everyone everywhere can you... :P > ---Where it finally crosses over to AboveNet > 12 sjc2-lax1-oc12.sjc2.above.net (208.184.102.145) 51.917 ms 45.190 ms 47.872 ms > 13 sjc2-lax1-oc48.sjc2.above.net (208.185.156.125) 49.168 ms 52.816 ms 62.538 ms Well you did find some broken DNS at AboveNet... (or else they're trying out some new IP over teleportation technology)... From tracerouting around a little bit it looks like that hop 13 is actually an OC48 between core1 and core4 in sjc2.above.net. > ---and heads back to San Jose > 14 core5-sjc2-oc48.sjc1.above.net (216.200.0.177) 48.298 ms 80.466 ms 43.326 ms > 15 main2-core5-oc12.sjc1.above.net (209.133.31.190) 44.550 ms 64.522 ms > 47.930 ms Over to another facility in San Jose... > Coming back seems to be much more intelligent (less drifty); > > 3 main3-main4-fe.sjc1.above.net (209.249.192.4) 7.212 ms 5.777 ms 7.242 ms > 4 core1-main1-oc12.sjc1.above.net (208.185.175.245) 7.237 ms 6.944 ms 7.232 ms > 5 sl-gw8-sj-0-1.sprintlink.net (144.232.192.129) 7.231 ms 6.973 ms 7.233 ms > 6 sl-bb21-sj-13-0.sprintlink.net (144.232.3.113) 7.230 ms 6.973 ms 7.245 ms > 7 sl-gw12-sj-10-0.sprintlink.net (144.232.3.142) 7.227 ms 6.926 ms 7.241 ms > 8 sl-internap-40-0-0.sprintlink.net (144.232.217.18) 18.254 ms 17.886 ms 18.251 ms > 9 border4.ge2-0-bbnet1.sff.pnap.net (216.52.80.9) 18.170 ms 17.905 ms 21.890 ms > 10 spk-1-sfo.dsl-isp.net (216.52.86.1) 29.110 ms 21.618 ms 32.778 ms > 11 dsl027-176-139.sfo1.dsl.speakeasy.net (216.27.176.139) 40.001 ms 39.886 ms 40.082 ms Well who's to say that InterNAP didn't find a better path... It's always possible that using Qwest and peering with AboveNet in LA is better then using Sprint and peering with AboveNet in the bay area... That being said, it's more likely then not just minus points for the ASimilator... Can't win 'em all... -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: How to game the system (was Re: What does 95th %tile mean?)
by Richard A. Steenbergen 20 Apr '01

20 Apr '01

On Fri, Apr 20, 2001 at 01:11:14PM -0400, Greg A. Woods wrote: > > The difference with most DDoS attacks is that they have one or a very > few "targets" (i.e. one host, or one subnet which equals one port on a > router, etc.). Those types of DDoS attacks are damaging to everyone's > perception of how a network is performing because they present a > radically unbalanced flow, or small set of flows, against the normal > traffic distribution. The result is that lots of little connections get > pushed aside, and too many packets over all get dropped. Obviously the > DDoS attacker doesn't really care if all his data gets through -- he's > more than happy to have it mostly all end up in the bit bucket just so > long as he's causing other flows to end up there too. In the real world Actually, making it to the target is precisely the point of a DDoS. If an attacker fires off a single machine's 100Mbit worth of attack, it's more likely to kill a single ds3 peer somewhere along the way then to make it to the target (and in the process piss off all the people who were trying to use that link, but not necessarily the people trying to use the target, the exact opposite of their goals). If on the other hand, the attacker fires off 100 1Mbit syn floods from diverse network locations, it's more likely to a) go unnoticed by 99 of those source sites, b) reach the target or as close to the target's last bottleneck as possible, and c) only affect the victim and not the intermediate networks in between. > a paying customer will be using TCP or some such protocol which will > flow control itself if there's not enough available capacity to run at > full speed (or heaven forbid if there's loss that can't be avoided by > flow control). So, no matter how big my pipe, and how many or few TCP > connections I try to push/pull through it, I cannot create a burst that > will affect other customers in any long-term significant fashion, > especially if all the other customers also have the same size pipe. That is absolutily not the case. You may have no problem self-regulating a few TCP sessions ftp'ing some files while ssh'ing on a 10Mbit network, but when you have many thousands or hundreds of thousands of TCP flows on an internet backbone, the link will quickly suffer from the combined window-probing and packet loss backoffs effects of all those flows. Don't forget all that web traffic with all the flow start and stops, and the humans clicking refresh which is not self regulating at all... The internet does not behave like a linksys hub-based network... Having more flows is sortof like having a TCP which doesn't back off quite as easily (for those of you running an open source operating system, go see what happens if you tune some of the retransmit settings so you aren't quite as friendly as everyone else)... DDoS doesn't back off either... :P The only way you can compete under these conditions is if you have a transport protocol which doesn't take packet loss for an answer, and you are willing to have a bandwidth free-for-all (obviously this is completely self destructive when applied to the internet)... > Who sets up what?!?!?!? Show me a real-world example of how somone can > cause distruptive peaks of normal traffic and not get billed for them, > and also not end up paying more than they would have paid if they'd > simply played fairly. Alex Pilsov's example scenario is about the only See my previous email regarding monthly backups... It's not that uncommon among ecommerce people with multiple locations... > Maybe the industry will eventually find that 95 is a bad number and it > really has to be 96, or even 98. All I know is that if you're selling > ethernet, or even high-speed SDSL, you cannot fairly bill at the 100'th > percentile of peak bandwidth usage. Any user stupid enough to sign a > deal based on 100'th percentile peak bandwidth usage (when buying a pipe > much fatter than they require) is probably getting taken to the cleaners > and obviously doesn't understand now data moves on the Internet. This is really a backwards scheme. If you use 20Mbit for 90% of the time, and then you use 80Mbit because you are slashdotted for 3 days or something, your maximium rate is still 80Mbit... You've already paid for 27 days * 60Mbps = 17.5TB of unsent data outbound, and 30 days * 80Mbps = 26TB of unreceived data inbound. It has an advantage for the provider of motivating the customer not to burst their traffic (and thus making their network more predictable), but if you are in the business to encourage your customers NOT to use the internet then what is the point. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

RE: Chinese hackers plan week-long attack on American websites an d ne tworks
by Roeland Meyer 20 Apr '01

20 Apr '01

> -----Original Message----- > From: scott w [mailto:scott@digisle.net] > Sent: Friday, April 20, 2001 2:43 PM > Subject: Re: Chinese hackers plan week-long attack on > American websites > an d ne tworks > > > > Can't we all just get along??? > > > > heh, obviously not ... > > Yes we can... http://www.friends-partners.org/friends/mirnet No we can't http://www.dnso.org

1 0