- NANOG - lists.nanog.org

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 21 Apr '01

21 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

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 12:33:01PM -0400, Leo Bicknell wrote: > > There is a much simpler game that costs the ISP a lot more > money. Fortunately, it's not a common business model. > > Let's say I am a TV network, and I want to simulcast a TV show > once a week to the Internet. I might need 2-3 Gig of capacity during > the simulcast, but the rest of the time I need none. So, I buy 95% > service, stream for 4 hours a month, which is thrown away in any of > the counting schemes put forth so far, and pay nothing. Another variant which is actually done by the big enterprise eWhatever companies with servers in multiple locations at a big colo provider is the 95th percentile monthly backup or db exchange. They'll push gigabit(s) between facilities for exactly under the mark where they'd have to pay for it, and they're not always nice enough to warn you before hand. For those colo providers, who have a model of dumping traffic out to peers locally and usually don't have a longhaul backbone capacity which is significantly larger then those "big" customer interfaces... Well you get 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

gTLD Informational Message
by Brad Verd 20 Apr '01

20 Apr '01

This is an Informational Message to the internet community: Friday evening, the 20th of April, Verisign Global Registry Services will be changing the IP address for e.gtld-servers.net in the authoritative NS set serving com/net/org. The new set of servers authoritative for these TLDs will be: A.GTLD-SERVERS.NET. 6D IN A 192.5.6.30 G.GTLD-SERVERS.NET. 6D IN A 192.42.93.30 C.GTLD-SERVERS.NET. 6D IN A 192.26.92.30 I.GTLD-SERVERS.NET. 6D IN A 192.36.144.133 B.GTLD-SERVERS.NET. 6D IN A 203.181.106.5 D.GTLD-SERVERS.NET. 6D IN A 192.31.80.30 L.GTLD-SERVERS.NET. 6D IN A 192.41.162.30 F.GTLD-SERVERS.NET. 6D IN A 192.35.51.30 J.GTLD-SERVERS.NET. 6D IN A 210.132.100.101 K.GTLD-SERVERS.NET. 6D IN A 213.177.194.5 E.GTLD-SERVERS.NET. 6D IN A 192.12.94.30 M.GTLD-SERVERS.NET. 6D IN A 202.153.114.101 This will not require any change to root.cache file and both the old and new IP's for e.gtld-servers.net will provide answers for com, net, and org in parallel for enough time to accommodate the zones TTL's. -------------------------------------- Brad Verd Operations Manager Resolution Systems Verisign Global Registry Services Email - bverd(a)verisign.com ---------------------------------------

1 0

Re: Routing Loops
by Kyle C. Bacon 20 Apr '01

20 Apr '01

All, I confess, 6295 is easy to type instead of 6259 when your are trying to type it multiple times after a long week...:( Back to the ol "no network changes on Fridays"... Everything should be good now... K Marshall Eubanks To: Nanog mailing list <nanog(a)merit.edu>, hostmaster(a)fnsi.net <tme@21rst-ce cc: ntury.com> Subject: Routing Loops Sent by: owner-nanog@m erit.edu 04/20/2001 02:23 PM Please respond to tme Hello; I suddenly see a whole bunch of routing loops for paths going through AS 6259 Unicast Autonomous System Routing Loop Detection Date of BGP Dump Fri Apr 20 13:57:36 EDT 2001 1 ROUTING LOOPS Detected for ASN 11548 Prefix = 63.69.155.0/24 : PATH = : 1239 3549 6259 6295 6259 11548 1 ROUTING LOOPS Detected for ASN 11548 Prefix = 63.81.238.0/24 : PATH = : 1239 3549 6259 6295 6259 11548 1 ROUTING LOOPS Detected for ASN 13944 Prefix = 64.241.89.0/24 : PATH = : 1239 3549 6259 6295 6259 13944 1 ROUTING LOOPS Detected for ASN 13944 Prefix = : PATH = : 1239 3549 6259 6295 6259 13944 1 ROUTING LOOPS Detected for ASN 14813 Prefix = 66.35.68.0/22 : PATH = : 1239 3549 6259 6295 6259 13944 14813 1 ROUTING LOOPS Detected for ASN 17266 Prefix = 66.35.72.0/23 : PATH = : 1239 3549 6259 6295 6259 13944 17266 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 138.46.0.0 : PATH = : 701 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 2015 Prefix = 139.171.0.0/19 : PATH = : 1239 3549 6259 6295 6259 2015 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 143.61.153.0/24 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 143.61.233.0/24 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 192.84.218.0 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 198.181.242.0 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 204.107.238.0 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 204.238.145.0 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 206.183.224.0/19 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 209.41.192.0/18 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 8142 Prefix = : PATH = : 1239 3549 6259 6295 6259 8142 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 209.115.0.0/17 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = 216.28.0.0/15 : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 14470 Prefix = 216.28.223.0 : PATH = : 1239 3549 6259 6295 6259 14470 1 ROUTING LOOPS Detected for ASN 11325 Prefix = 216.29.50.0 : PATH = : 1239 3549 6259 6295 6259 11325 1 ROUTING LOOPS Detected for ASN 11303 Prefix = 216.52.158.0 : PATH = : 1239 11853 11303 11301 11303 1 ROUTING LOOPS Detected for ASN 11303 Prefix = : PATH = : 701 11853 11303 11301 11303 1 ROUTING LOOPS Detected for ASN 6259 Prefix = : PATH = : 1239 3549 6259 6295 6259 1 ROUTING LOOPS Detected for ASN 6259 Prefix = : PATH = : 1239 3549 6259 6295 6259 Anyone know a NOC contact for Fiber Network Solutions, Inc. (ASN-FIBERNET) ? Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme(a)multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/

1 0

How to game the system (was Re: What does 95th %tile mean?)
by Sean Donelan 20 Apr '01

20 Apr '01

On Thu, 19 April 2001, John Hawkinson wrote: > The 5-minute average is not being sampled every five minutes. > > The raw number of octets is being sampled every five minutes, and > divided by the time since the previous sample (5 minutes). Then, > 95th percentile is taken of that. How do you game the system? Economists like to write a lot of papers on this subject. The problem with calculating the average is the fencepost error. Warning, majore simplifying assumptions ahead... If you transfer 1GB for exactly 5 minutes, what is your 95% bill? It depends on your timing. 00:00 Start transfer, Start measurement window 01:00 02:00 03:00 04:00 05:00 End transfer, End measurement window Elapsed time 5 minutes, total bytes 1000000, or 3,333 Bps. Bandwidth billed 3.3Kbps peak 00:00 Start measurement window #1 01:00 02:00 02:30 Start transfer #1 03:00 04:00 05:00 End measurement window #1 (500,000 Bytes, 300 Seconds) Start measurement window #2 06:00 07:00 07:30 End transfer #1 (1,000,000 Bytes, 300 Seconds) 08:00 09:00 01:00 End measurement window #2 (500,000 Bytes, 300 Seconds) Bandwidth billed 1.6Kbps peak By knowing your provider's measurement windows, you could cut your usage bill in half while transfering the same amount of data. A customer with a relatively random usage (user's surfing the web) couldn't do this, but a user transfering batch files on a set schedule may see dramatic differences in their bill. You can make the measurements more complex by using three windows, or choosing three out of five windows, and so forth. Unless providers or users are seeing real billing problems, there is little benefit to the added complexity.

5 5