January 2003 - Test - lists.nanog.org

Cascading(?)Failures Revisited
by sgorman1＠gmu.edu 10 Jan '03

10 Jan '03

Recently came across the paper below on the Los ALamos site and it addresses a topic discussed earlier about how traffic is redistributed when a node is compromised. When the researchers included capacity loads in their equations they find some pretty severe consequences (3000 of 5000 disconnected by one nodal failure in the simulation), but the (real-world) analysis is done on the AS network and I believe there was talk of cascading failures not applying to the Internet in the first place. I was curious what assumptions the folks on NANOG would suggest if you were trying to model how traffic would be redistributed in the event of a node or mulitple node failure. Any input would be greatly appreciated. Cascade-based attacks on complex networks http://xxx.lanl.gov/PS_cache/cond-mat/pdf/0301/0301086.pdf We live in a modern world supported by large, complex networks. Examples range from financial markets to communication and transportation systems. In many realistic situations the flow of physical quantities in the network, as characterized by the loads on nodes, is important. We show that for such networks where loads can redistribute among the nodes, intentional attacks can lead to a cascade of overload failures, which can in turn cause the entire or a substantial part of the network to collapse. This is relevant for real-world networks that possess a highly heterogeneous distribution of loads, such as the Internet and power grids. We demonstrate that the heterogeneity of these networks makes them particularly vulnerable to attacks in that a large-scale cascade may be triggered by disabling a single key node. This brings obvious concerns on the security of such systems.

1 0

US-Asia Peering Research Request
by William B. Norton 10 Jan '03

10 Jan '03

Along a same lines... I'm working on the next white paper on "Peering in Asia" and I'd like to again ask for data points from the community. To start... I remember back at APRICOT in 1999 that some folks (Dave Rand and colleagues maybe?) were talking about an initiative to provide an AP Peering Ring... To help with this research (as before I'll be glad to share the results with anyone who is interested) do any of you have URLs/Research Papers that show: (1) How peering is done in the AP region today? I've heard generally of a) the AP Mesh of 1/2 circuits between countries PTTs, and b) the AP Country Peering Point(s) but I'm curious if anyone has documented down deeper than that generalization. (2) Past Initiatives for AP Region Peering (or AP-US Peering) that have succeeded or (better yet) have failed? (3) Rough #s for Transit Fees in the AP Region. Several of you shared price points of $300-$400USD/Mbps for ~10-50Mbps, maybe $100 for 1+Gbps in Japan. If anyone has done a survey for the AP Region in general as I did in the past in the U.S. markets I'd love to see it. The U.S. curve for example seems to be a stepped function, starting at about $300/Mbps for a few Mbps down to sub $100/Mbps when you get towards the Gbps range. I'd like to hear what AP ISPs are seeing. Thanks in advance and I'll write this up and let you know what I find out. As before, I'll credit the sources that provide the data points and honor anonymity as requested. Hopefully the end result with be of value to the community. Contact information below. Bill --------------------------------------------------------------------------------------------------------------- William B. Norton <wbn(a)equinix.com> 650.315.8635 Co-Founder and Chief Technical Liaison Equinix, Inc. Yahoo Instant Messenger ID: WilliamBNorton

3 2

Peering BOF VI at NANOG
by William B. Norton 10 Jan '03

10 Jan '03

Hi all - If you are not a Peering Coordinator attending NANOG 27 then you needn't read any further. The 6th Peering BOF at NANOG will be held Monday night and focuses on helping Peering Coordinators make contact with other Peering Coordinators using "Peering Personals." We solicit Peering Coordinators (via this e-mail), asking them to characterize their networks and peering policies in general ways ("content heavy" or "access (eyeball) -heavy," "Multiple Points Required" or "Will Peer anywhere," "Peering with Content OK," etc.). From the answers we will select a set of ISP Peering Coordinators to present a 2-3 minute description of their network, what they look for in a peer, etc., allowing the audience to put a face with the name of the ISP. At the end of the Peering BOF, Peering Coordinators will have time to speak with Peering Coordinators of ISPs they seek to interconnect with. The expectation is that these interactions will lead to the Peering Negotiations stage, the first step towards a more fully meshed and therefore resilient Internet. If you are a Peering Coordinator and wish to participate in this BOF, please fill out the following form and e-mail it to wbn(a)equinix.com with Subject: Peering BOF VI . -------------------------------------------------------------------------------- Name: Title: Company: AS#: Check each that applies: ___ We are an ISP (sell access to the Internet) -- OR -- ___ We are a Non-ISP (content company, etc.) ___ We are Content-Heavy -- OR -- ___ We are Access-Heavy ___ Peering with Content Players or Content Heavy ISPs is OK by us ___ We generally require peering in multiple locations ___ We will peer with anyone in any single location ___ We have huge volumes of traffic (lots of users and/or lots of content) (huge: > 1 Gbps total outbound traffic to peers and transit providers) ___ We have a global network ___ We require Contracts for Peering Current Peering Locations: _______________________ Planned (3-6 mos) Peering Locations: _______________________________ See you in Phoenix! Bill PS - This form is also on the NANOG web page at: http://www.nanog.org/mtg-0302/norton.html --------------------------------------------------------------------------------------------------------------- William B. Norton <wbn(a)equinix.com> 650.315.8635 Co-Founder and Chief Technical Liaison Equinix, Inc.

1 0

Re: Puerto Rico Peering Point, or existence thereof. (fwd)
by Haesu 10 Jan '03

10 Jan '03

Hey, Your best bet is to go with Miami, although it may be a bit expensive to get longhaul circuits to there.. Miami is the closest major bandwidth place from your location.. They even have internet exchange over there on behalf of South and Central American based ISP's. -hc > > ---------- Forwarded message ---------- > Date: Fri, 10 Jan 2003 06:00:57 -0500 > From: Ray Burkholder <ray(a)oneunified.net> > To: nanog(a)merit.edu > Subject: Puerto Rico Peering Point, or existence thereof. > > > I work for an ISP in St. Thomas, US Virgin Islands. (If you happen to > pass through, drop by for a visit). > > Anyway, ATT has undersea fibre to Puerto Rico. We want to get a DS3 > into a Puerto Rico peering center where we can get connectivity to some > combo of ATT, Sprint, Worldcom, and T-Data. Is anyone familiar with > such a location in PR? > > If not there, how about Florida? > > Ray Burkholder > >

2 1

RE: frame relay to atm conversion tool?
by Brennan_Murphy＠NAI.com 10 Jan '03

10 Jan '03

I came across a decent Cisco article that discusses how to calculate traffic shaping parameters for links that are on one end ATM and the other Frame relay. http://www.cisco.com/warp/public/121/frf8_shaping.html The second to the last paragraph in that article suggests that ATM SCR's should be shaped at 15-20% higher than Frame CIR's. But there is no corresponding conclusion about how to equate burst space. There's been a few responses from people interested in helping get a tool together to make these calculations simpler and more accurate. I'm still seeking comments on this though so if you've got something to add, please do! Once I feel like we've choked out enough comments to get to work on this, I'll contact those interested parties offline about next steps. Thanks, BM -----Original Message----- From: Peter E. Fry [mailto:pfry@swbell.net] Sent: Thursday, January 09, 2003 10:46 PM To: nanog(a)merit.edu Subject: RE: frame relay to atm conversion tool? On 9 Jan 2003 at 17:45, Swaminathan, Sekar wrote: > Instead of Frame Relay frames, you have to look at the > payload which is usually IP packets. Here is the formula > that I would use: [...] Specifying an "average packet size" is rough: I've observed that on an "average Internet connection" around 35% of packets are 64 bytes, 35% 1500 bytes, and the remainder scattered about. The average is guaranteed to be a poor match for at least 70% of your traffic. Not that it matters. Most carriers configure FRATM VCCs as "1536kbps frame relay = 4500cps", treating fractions accordingly. The last thing you want to do is exceed this cell rate (around 1710kbps at a 1500-byte packet size), as on a policed link you'll lose nonconforming cells. (Actually, a 1536kb frame relay seems to be closer to a 1705kb ATM VCC. Eh, the IWF has to buffer some anyway.) If you increase your cell rates you potentially oversubscribe your frame link (and the IWF may disallow it in any case). So if you're tempted to exceed this ratio be very certain of your link characteristics. Add to that: when a sustained rate is defined (VBR service category) the ATM peak rate probably doesn't mean what you would expect, so I recommend sustained = peak. (ABR is the best match for data, but isn't often used.) As to the original question, I wouldn't recommend translating a burstable frame to ATM unless you can order an ABR VCC or get UPC and/or frame discard disabled on your link (don't bet on it). It's not likely you can match parameters, so without flow control you're essentially looking at reduced performance or packet loss under load. Whatever you do get, I recommend you ask your carrier for a spec. You have plenty of variables and relatively robust protocols, meaning you could take a shot, miss, and only find out for certain that you had when you'd really rather not. Get it reasonably right, though, and it'll do right by you. Huh. Now that I look at it, I need to rethink my own figures yet again (I haven't even implemented the last rethink) as I appear to have tended toward the conservative in some areas. Grrr. Take it easy. Peter E. Fry

1 0

The Cidr Report
by cidr-report＠potaroo.net 10 Jan '03

10 Jan '03

This report has been generated at Fri Jan 10 21:49:53 2003 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 03-01-03 117672 85180 04-01-03 117848 85149 05-01-03 117767 85091 06-01-03 117793 85127 07-01-03 117802 85131 08-01-03 117947 85108 09-01-03 118044 85215 10-01-03 118118 85385 AS Summary 14310 Number of ASes in routing system 5626 Number of ASes announcing only one prefix 1606 Largest number of prefixes announced by an AS AS701 : ALTERNET-AS UUNET Technologies, Inc. 73048064 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 10Jan03 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 118165 85303 32862 27.8% All ASes AS3908 1175 684 491 41.8% SUPERNETASBLK SuperNet, Inc. AS18566 422 5 417 98.8% COVAD Covad Communications AS7018 1450 1035 415 28.6% ATT-INTERNET4 AT&T WorldNet Services AS701 1606 1193 413 25.7% ALTERNET-AS UUNET Technologies, Inc. AS4323 526 188 338 64.3% TW-COMM Time Warner Communications, Inc. AS7843 628 291 337 53.7% ADELPHIA-AS Adelphia Corp. AS6197 458 150 308 67.2% BATI-ATL BellSouth Network Solutions, Inc AS1221 1145 844 301 26.3% ASN-TELSTRA Telstra Pty Ltd AS1239 968 679 289 29.9% SPRINTLINK Sprint AS6347 369 85 284 77.0% DIAMOND SAVVIS Communications Corporation AS4355 406 135 271 66.7% ERMS-EARTHLNK EARTHLINK, INC AS7046 554 286 268 48.4% UUNET-CUSTOMER UUNET Technologies, Inc. AS22927 289 22 267 92.4% AR-TEAR2-LACNIC TELEFONICA DE ARGENTINA AS705 426 186 240 56.3% ASN-ALTERNET UUNET Technologies, Inc. AS4814 251 15 236 94.0% CHINANET-BEIJING-AP China Telecom (Group) AS1 661 439 222 33.6% GNTY-1 Genuity AS6198 422 200 222 52.6% BATI-MIA BellSouth Network Solutions, Inc AS17676 229 24 205 89.5% GIGAINFRA XTAGE CORPORATION AS22291 227 29 198 87.2% CHARTER-LA Charter Communications AS690 513 319 194 37.8% MERIT-AS-27 Merit Network Inc. AS4151 328 136 192 58.5% USDA-1 USDA AS209 518 330 188 36.3% ASN-QWEST Qwest AS6140 314 126 188 59.9% IMPSAT-USA ImpSat AS4134 290 107 183 63.1% ERX-CHINALINK Data Communications Bureau AS852 627 445 182 29.0% ASN852 Telus Advanced Communications AS2048 260 87 173 66.5% LANET-1 State of Louisiana AS2386 381 222 159 41.7% INS-AS AT&T Data Communications Services AS6327 185 34 151 81.6% SHAWFIBER Shaw Fiberlink Limited AS17557 323 179 144 44.6% PKTELECOM-AS-AP Pakistan Telecom AS3215 315 175 140 44.4% AS3215 France Telecom Transpac Total 16266 8650 7616 46.8% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)lists.apnic.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0

Re: Trends in network operator security
by Sean Donelan 10 Jan '03

10 Jan '03

On Wed, 8 Jan 2003 todd.glassey(a)att.net wrote: > Arent these more the attack trends of tier-3 providers and not network > operators. Maybe. I don't see too many tier-1 network operators attacking other tier-1 network operators. The trend I continue to see affecting network operators is customer security incidents, i.e. compromised end-user applications. > Seems to me that The the real issues is when the tier-2 and tier-1 > infrastructure come under attack. Otherwise these others are all at the > applications layer - which so few on this list are interested in. There are lots of interesting problems, but I don't know if 2003 is the year. DOS is just too much fun. Route hijacks/bogus origins Compromised infrastructure MLPS alteration Authentication attacks Physical intrusion

6 6

Re: Trends in network operator security
by David Lesher 09 Jan '03

09 Jan '03

Unnamed Administration sources reported that John Fraizer said: > > Does anyone know the answers to the following: > > (1) Why was this datacenter unmanned? Why are CO's unmanned Saturday nights? ISP's? Could the cost of manpower having anything to do with it? > (2) If it was manned, how did the perps get physical access to steal the > drives? Once in the building, one article mentioned they'd found an access card to the machine room in a PHB's office. No PINs? > (3) Has the contractor been removed from the list of authorized vendors? > (4) If not, why on earth NOT? The vender peddles aspirin, not data services. You propose to now deny those 500K families medical care, after raping their privacy? -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

RE: frame relay to atm conversion tool?
by Swaminathan, Sekar 09 Jan '03

09 Jan '03

Instead of Frame Relay frames, you have to look at the payload which is usually IP packets. Here is the formula that I would use: BW = IP bandwidth in bits per second (bps) PS = average IP packet size; typically 256 bytes AO = AAL5 Overhead = 8 bytes OH = overhead factor Ceiling((PS+AO)/48) * 53 = ------------------------ PS Ceiling((256+8)/48) * 53 6 * 53 = ------------------------ = ------ = 1.24 (for our 256B example) 256 256 EBW = effective ATM bandwidth in cells per second BW * OH = ------- 53*8 Thus for 512 Kbps IP bandwidth, you need 1497 cps ATM bandwidth assuming 256 byte average packet size. SCR should be at least this. The PCR could be the line rate or equal to SCR. The MBS could be 32 cells (1 MTU packet size at least) for low jitter applications and as high as 256 cells for bursty applications. -Sekar -----Original Message----- From: Brennan_Murphy(a)NAI.com [mailto:Brennan_Murphy@NAI.com] Sent: Thursday, January 09, 2003 3:08 PM To: nanog(a)merit.edu Subject: frame relay to atm conversion tool? I'm trying to locate a tool (eg, spreadsheet) to convert throughput on a frame circuit to an ATM circuit. So, for example if you have a 512k CIR with burst to 1024k and 80% of the time you get your burst bandwidth and you want to convert that link to ATM, what corresponding SCR/PCR/MBS values would you need. I'm less concerned with Frame vs ATM protocol overhead than I am with calculating the difference in the way the burst bandwidth is meted out. Any recommendations? Supposing no one knows of such a tool. Would anyone be interesting in helping me put one together? Best Regards, -BM

2 1

frame relay to atm conversion tool?
by Brennan_Murphy＠NAI.com 09 Jan '03

09 Jan '03

I'm trying to locate a tool (eg, spreadsheet) to convert throughput on a frame circuit to an ATM circuit. So, for example if you have a 512k CIR with burst to 1024k and 80% of the time you get your burst bandwidth and you want to convert that link to ATM, what corresponding SCR/PCR/MBS values would you need. I'm less concerned with Frame vs ATM protocol overhead than I am with calculating the difference in the way the burst bandwidth is meted out. Any recommendations? Supposing no one knows of such a tool. Would anyone be interesting in helping me put one together? Best Regards, -BM

1 0