- Test - lists.nanog.org

Re: MAE-W worse than normal?
by Sean Butler 29 Aug '98

29 Aug '98

>Anyone seeing worse than normal drops at MAE-W ? We are seeing 5-10% >drops from our connection off giga2 to anything on giga1, while giga2 to giga3 >and giga4 seems to be ok... > >We're contacting MFS now to see if this is know. It seems to have started last >night some... MFS ticket is 284300, and there is blocking going towards giga 1. MFS states at least 48 hours (from last night) to contact all involved, and perhaps as late as Wednesday to correct... Here's a list of connections off giga 1: > giga1/4 198.32.136.55+198.32.184.55 maewest-sjose-fddi.cerf.net > giga1/10 198.32.136.23 mae-west.psi.com > giga1/11 198.32.136.118+198.32.184.38 mae-west-2.px.concentric.net > giga1/11 198.32.136.26 mae-west.pch.net > giga1/11 198.32.136.38+198.32.184.118 mae-west.px.concentric.net > giga1/12 198.32.136.33 mae-west.exodus.net > giga1/14 198.32.136.37+198.32.184.37 mae-west.good.net > giga1/18 198.32.184.42 Fddi9-0.San-Jose9-gw.CA.Alter.Net > giga1/19 198.32.136.56 f6.peer1.sjc1.genuity.net > giga1/21 198.32.136.15+198.32.184.15 mae-west.netcom.net > giga1/22 198.32.136.96 fddi0-0.enss221.t3.ans.net > giga1/23 198.32.136.40 fddi0-0.br4.SJC.globalcenter.net > giga1/26 198.32.136.60+198.32.184.60 > sjc2-core1-fddi-3-0-0.atlas.digex.net If you are off giga 1, you are probably seeing 5-10% loss at high use times. We noticed it starting around 15:00 - 16:00 EDT yesterday and continuing until 02:00 - 03:00 EDT.... This happened on Thursday as well. Sean __________________________________ Sean Butler, CCIE #3897 IBM Global Services -- OpenNet Support Phone: 8-631-9809, 813-523-7353 Fax: 8-427-5475 813-878-5475 Internet email: sebutler(a)us.ibm.com

1 0

Using NAT for best-exit routing
by Brian Dickson 29 Aug '98

29 Aug '98

The following is a suggestion for a scalable solution to the best-exit problem (hot-potato requests to a web farm, best-exit data return). (This was prompted by thinking about the original problem which induced the most-popular topic of late.) As far as I know it's original, so if you use it, let me know how it works, and maybe give me some credit. :-) The idea is basically this: the web farm provider uses a NAT device (or configures NAT on a router) for every peering point with a given peer who wants best-exit. Separate address pools (in private address space) are used for each such NAT (and distinct such pool sets amongst multiple such peer networks). Ingress traffic to the web farm provider has it's *source* address NAT'd, and internal routing points return traffic to the *same* NAT through which the request traffic came. Thus, return (data) traffic is best-exit. This scales as the number of flows, not as the number of addresses announced, so the MEDs scaling issue goes away. Performance may be an important factor, so it is advised that anyone trying this test it in a lab first. ;-) Pictorially ,-------- provider "G" -------. / \ | | NAT1 NAT2 | | \ / `------- web farm "E" -------' Traffic flows: West coast, G -> NAT 1 (closest)-> web farm -> NAT1 -> west coast, G (best exit) East coast, G -> NAT 2 (closest)-> web farm -> NAT2 -> east coast, G (best exit) (Also works for NATs 3,4,5,...) If the NAT can handle #flows seen, at wire speed, all is well. Limits would be the total number of simultaneous flows, and max speed of NAT. Side benefits are that the unique address pools allow for much easier per-peer and per-region collection of stats, eg netflow (at some place other than NATs). Comments? -- Brian Dickson, Email: briand(a)teleglobe.net Teleglobe USA, Inc., Tel : +1 703 821 4818 Suite 400, 8251 Greensboro Drive, Fax : +1 703 821 4885 McLean, Virginia, USA, 22102 http://www.teleglobe.com

3 2

Re: Transaction Based Settlements Encourage Waste (was Re: BBN /GTEI)
by Sean M. Doran 29 Aug '98

29 Aug '98

Someone not worth replying to wrote: > [nothing important] Typical, really. Sean.

1 0

Re: Transaction Based Settlements Encourage Waste (was Re: BBN /GTEI)
by Brett_Watson＠enron.net 28 Aug '98

28 Aug '98

On 08/25/98 03:48:29 PM Sean M. Doran wrote: >> What about netflow ? > >[to Vadim Antonov who said that _metering_ traffic is intractable] > >Dear ISP - you have made an accounting error that I am able to demonstrate >in my copious traffic logs. Please credit $x to my account. > >or > >Dear Customer - our copious traffic logs indicate that you generated x traffic >last month. Please pay $x net 30 days. Thank you. > >Dispute resolution -- it's fun! i think this point is the single largest barrier to doing proper billing. isp billing needs to be as bullet-proof as telco/voice billing. i suspect that with many isp's (and certainly from some of my past experience) if customers would ever have disputed an invoice we wouldn't have had a leg to stand on. i'm sure some providers have good billing systems but i know many that don't yet they do some kind of usage based billing. also, as useful as netflow can be, at oc-3 speeds and higher the sheer amount of data exported can be overwhelming both to routers and trunks (in agreement with vadim). -brett

2 1

Re: Using NAT for best-exit routing
by owen＠DeLong.SJ.CA.US 28 Aug '98

28 Aug '98

> The following is a suggestion for a scalable solution to the best-exit > problem (hot-potato requests to a web farm, best-exit data return). > (This was prompted by thinking about the original problem which induced > the most-popular topic of late.) > As far as I know it's original, so if you use it, let me know how it > works, and maybe give me some credit. :-) > Depends on your definition of scalable. Please show me a NAT box that can keep up with 1.5Gbps sustained with peaks in excess of 1.9. > The idea is basically this: the web farm provider uses a NAT device > (or configures NAT on a router) for every peering point with a given peer > who wants best-exit. Separate address pools (in private address space) > are used for each such NAT (and distinct such pool sets amongst multiple > such peer networks). Ingress traffic to the web farm provider has it's > *source* address NAT'd, and internal routing points return traffic to > the *same* NAT through which the request traffic came. > Thus, return (data) traffic is best-exit. > An interesting idea, but the address management alone becomes a nightmare. Then, when you add the sheer number of customers some of the content providers have, it becomes even more complex. It would be really cool if such a system could be made to work without turning address management into an unmitigated nightmare for the content provider, but I don't see that as being too likely. > This scales as the number of flows, not as the number of addresses announced, > so the MEDs scaling issue goes away. Performance may be an important factor, > so it is advised that anyone trying this test it in a lab first. ;-) > Yeah, performance would be a BIG factor in a large content network. > Pictorially > ,-------- provider "G" -------. > / \ > | | > NAT1 NAT2 > | | > \ / > `------- web farm "E" -------' > > Traffic flows: > West coast, G -> NAT 1 (closest)-> web farm -> NAT1 -> west coast, G (best exit) > East coast, G -> NAT 2 (closest)-> web farm -> NAT2 -> east coast, G (best exit) > > (Also works for NATs 3,4,5,...) > > If the NAT can handle #flows seen, at wire speed, all is well. Limits would be > the total number of simultaneous flows, and max speed of NAT. > > Side benefits are that the unique address pools allow for much easier > per-peer and per-region collection of stats, eg netflow (at some place > other than NATs). > Could be interesting, but I don't think it scales. Owen

1 0

Re: Transaction Based Settlements Encourage Waste (was Re: BBN /GTEI)
by owen＠DeLong.SJ.CA.US 28 Aug '98

28 Aug '98

> On 08/25/98 03:48:29 PM Sean M. Doran wrote: > > >> What about netflow ? > > > >[to Vadim Antonov who said that _metering_ traffic is intractable] > > > >Dear ISP - you have made an accounting error that I am able to demonstrate > >in my copious traffic logs. Please credit $x to my account. > > > >or > > > >Dear Customer - our copious traffic logs indicate that you generated x > traffic > >last month. Please pay $x net 30 days. Thank you. > > > >Dispute resolution -- it's fun! > > i think this point is the single largest barrier to doing proper billing. > isp billing needs to be as bullet-proof as telco/voice billing. i suspect > that with many isp's (and certainly from some of my past experience) if > customers would ever have disputed an invoice we wouldn't have had a leg to > stand on. i'm sure some providers have good billing systems but i know > many that don't yet they do some kind of usage based billing. > > also, as useful as netflow can be, at oc-3 speeds and higher the sheer > amount of data exported can be overwhelming both to routers and trunks (in > agreement with vadim). > > -brett > > > NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Please NOT that!!! I've spent the last 6 months trying to get my home phone bill straightened out with MCI and PacBell has been overbilling me for PVC's on my Frame Relay for 18 months. Please, let's not drop the internet to the level of service we all complain about from the Telcos. Owen

1 0

MAE-W worse than normal?
by Sean Butler 28 Aug '98

28 Aug '98

Anyone seeing worse than normal drops at MAE-W ? We are seeing 5-10% drops from our connection off giga2 to anything on giga1, while giga2 to giga3 and giga4 seems to be ok... We're contacting MFS now to see if this is know. It seems to have started last night some.... Sean ___________________________________ Sean Butler, CCIE #3897 IBM Global Services -- OpenNet Support Phone: 8-631-9809, 813-523-7353 Fax: 8-427-5475 813-878-5475 Internet email: sebutler(a)us.ibm.com

1 0

The Cidr Report
by Tony Bates 28 Aug '98

28 Aug '98

This is an auto-generated mail on Fri Aug 28 12:00:00 PDT 1998 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 28Aug98 0) General Status Table History ------------- Date Prefixes 210898 52842 220898 52964 230898 52773 240898 53047 250898 53127 260898 53242 270898 53089 280898 53151 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 3922 Number of ASes announcing only one prefix: 1901 (987 cidr, 914 classful) Largest number of cidr routes: 346 announced by AS3561 Largest number of classful routes: 1175 announced by AS701 1) Gains by aggregating at the origin AS level --- 28Aug98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS3602 552 320 232 42.0% Sprint Canada Inc. AS701 1175 949 226 19.2% Alternet AS271 351 153 198 56.4% BCnet Backbone AS4293 444 258 186 41.9% IMCI AS2493 384 227 157 40.9% iSTAR Internet, Inc. AS3749 223 67 156 70.0% TECNET AS174 701 576 125 17.8% Performance Systems International AS4200 193 99 94 48.7% AGIS (Apex Global Information Ser AS5668 131 42 89 67.9% Century Telephone Inc. AS2685 242 161 81 33.5% IBM Global Network - US AS4755 124 47 77 62.1% Videsh Sanchar Nigam Ltd. India AS4740 421 346 75 17.8% Ozemail Pty Ltd (ASN-OZEMAIL) AS3221 112 42 70 62.5% EENet Autonomous System AS7046 234 168 66 28.2% UUNET-CUSTOMER AS3493 242 176 66 27.3% INTERLINK AS3804 215 157 58 27.0% Bell Solutions AS3403 182 127 55 30.2% TIAC AS10928 101 46 55 54.5% UNKNOWN AS549 205 151 54 26.3% ONet Backbone AS8517 124 72 52 41.9% ULAKNET-ASN AS719 464 415 49 10.6% LANLINK autonomous system AS6335 69 20 49 71.0% NTRNET AS72 87 39 48 55.2% Schlumberger Information Network AS1239 551 503 48 8.7% SprintLink Backbone AS803 78 34 44 56.4% SaskNet Backbone AS4539 68 27 41 60.3% NETROPOLIS AS852 158 118 40 25.3% AGT Advance Communication AS6181 66 26 40 60.6% FUSE-NET AS7122 119 80 39 32.8% MTS ADVANCED Network Policy AS4614 68 32 36 52.9% Asiaonline Hong Kong 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: Using NAT for best-exit routing
by Jeff Mayzurk 28 Aug '98

28 Aug '98

Brian Dickson wrote: > such peer networks). Ingress traffic to the web farm provider has it's > *source* address NAT'd, and internal routing points return traffic to > the *same* NAT through which the request traffic came. > Thus, return (data) traffic is best-exit. > Side benefits are that the unique address pools allow for much easier > per-peer and per-region collection of stats, eg netflow (at some place > other than NATs). As you point out, stats collection is easier--but only from a network ops point of view, and even then, only if you're simply concerned with symmetric flow of traffic to your upstreams/peers. However, your web server logs are now useless, because all the requests come from a static pool of local addresses. If you're a big web farm like Exodus, your customers aren't going to buy this. -Jeff -- Jeff Mayzurk Manager, Systems/Network Engineering <jeffm(a)eonline.com> E! Online 150 Chestnut Street 415.772.3555 x4496 San Francisco, CA 94111 415.984.0322 FAX

1 0

Re: Generation of traffic in "settled" peering arrangement
by Brett_Watson＠enron.net 28 Aug '98

28 Aug '98

On 08/25/98 03:05:40 PM steve wrote: >On Tue, Aug 25, 1998 at 03:50:37PM -0400, Alec H. Peterson wrote: >> Owen DeLong wrote: >> > >> > Where do you get your data? It seems to me that the bulk of the largest web >> > sites with which I am familiar are located in at least two datacenters. >> >> Most of the busy sites I frequent are hosted on the west coast (not just >> Exodus-hosted sites, but sites in general). > > That's just how the internet plays, there are probably more sights >phisically in the silicon valley then anywhere else on the west coast. It's >where the busniness's are, and since they want to have their machines as >close to them as possible, they put them here. in my opinion, if hosting is done correctly, and managed with the right tools, the hosting provider should be able to dictate where the servers are placed (which city or data center) to balance load in the network (thus balancing some of the load offered to the external peers). while i was at genuity, the distribution of servers was very skewed. most customers were either in the bay area or phoenix, and thus wanted their servers placed there. engineering wanted to decide where servers were placed but sales always said "no no, the customer wants the server in city X" thus we had terrible traffic distribution and serverely overloaded routers and circuits between phoenix, san jose, and mae-west. -brett

1 0