- NANOG - lists.nanog.org

final note on cookreport/ bill woodcock peering discussion
by Gordon Cook 04 Sep '02

04 Sep '02

I am leaving at 6 am in the morning for a small internet meeting in massachusetts. I am unlikely to see my email again until saturday morning. We have had eight different requests to join the discussion since my post this afternoon. Since the mail list is running on bill's woodcock's machine, it is only reasonable that he be the gatekeeper on additions to the list at this point. However he is at APIA in Japan right now and will not be back in the US for a bit more than another week. if I understand the situation correctly he will need to relay list addition requests to a colleague in California. If some folk do get added between now and the weekend please introduce yourselves to the list. Agenda I intend to publish an issue with list discussion around October 1. although since I let list members have a week to review a prepub draft and ask for edits correctionss etc, the current discussion will need to wrap up in the sept 23-25th time frame. But since the subject may change and evolve i am open to keeping the discussion going for a LOT LOT LONGER either on bills server or in another venue. I will be out of the country trekking near mount everest from October 15th until November 10th. The issue published about Oct 1 will be the December issue. I estimate that january will come out about december 1. If a discussion is continuing on line in october and november, it can certainly do so in my absence. I'd like to thank everyone for their help. I hope that we can document in considerable detail the changing economics, policy, politics and technologies of interconnection. -- ======================================================== The COOK Report on Internet, 431 Greenway Ave, Ewing, NJ 08618 USA (609) 882-2572 (phone & fax) cook(a)cookreport.com Subscription info & prices at http://cookreport.com/subscriptions.shtml Summary of content for 10 years at http://cookreport.com/past_issues.shtml Economics of Peering, Transit & IXs Part One - November issue available at http://cookreport.com/11.08.shtml ========================================================

1 0

economics of peering and transit -- long interview with Bill Woodcock and others
by Gordon Cook 03 Sep '02

03 Sep '02

I have just published part one of a two part issue on the economics of peering and transit and IX's. Included is a two part interview with Bill Woodcock who elaborates in great detail on the peering and transit methodology that he has been presenting at the last couple of Nanog meetings. Also included are four tables with January 31 2002 Netflow data from Zocalo. The tables are generated with software done for Zocalo at Agilent by Alex Tudor. Bill goes through each table and explains the meaning of the data. This includes an explanation of Synthetic Path Analysis in tables 3 and 4 which as I understand it is really the first published explanation of this approach. The interviews with Bill explain over all how ISPs can begun to mold tools into a bandwidth cost management system. My November issue also includes a long and detailed over view of the nasty consequences of the current Tier One oligopoly. The overview is an essay by Farooq Hussain in which he identifies the Internet Core backbones (see December 5, 2001 announcement of Equinix's Internet Core Service) as UUNET, Level 3, Qwest, ATT, Sprint, Cable & Wireless and Genuity. Andrew Odlyzko adds comments. Thanks to Zocalo I am running a private mail list where discussion of the Woodcock and related methodology, exchanges, peering, bandwidth cost and the like is on going. In addition to Bill Woodcock active participants include Avi Freedman, Phil Weller (Fast net CTO), Mike Hughes, Alex Tudor, Stephen Stuart, Phillip Smith, Farooq Hussain, Andrew Odlyzko and Keith Mitchell. If there are other Peering Coordinators here (or folk playing that role) who would like to contribute to the discussion (warning ....it is for publication) please email woody@pchnet and cook(a)cookreport.com stating the nature of you interest. Results of these discussions and other data will come out round about October 1. For the table of contents, complete introduction and Andrew Odlyzko's comments please visit http://cookreport.com/11.08.shtml -- ======================================================== The COOK Report on Internet, 431 Greenway Ave, Ewing, NJ 08618 USA (609) 882-2572 (phone & fax) cook(a)cookreport.com Subscription info & prices at http://cookreport.com/subscriptions.shtml Summary of content for 10 years at http://cookreport.com/past_issues.shtml Economics of Peering, Transit & IXs Part One - November issue available at http://cookreport.com/11.08.shtml ========================================================

2 1

RE: AT&T NYC
by Frank Scalzo 03 Sep '02

03 Sep '02

Whoops! 2 hours to find routers w/o an IGP tsk tsk. Dear AT&T IP Services Customer, Please be advised of the following: Date: 8/28/02 Customer Care TT#: 1070909 Start of Impairment: 14:56 ET End of Impairment: 16:52 ET On behalf of AT&T, we would like to extend our apologies for any inconveniences to your business caused by the service impairment and delay in restoring your service. AT&T IP Services customers with traffic routed through our Chicago backbone routers may have been affected by this impairment. Our Network Engineers found that OSPF* network statements were missing from two backbone routers, causing the routing issues that customers were experiencing. AT&T Network Engineers manually reloaded the OSPF network statements and then proceeded to reboot the routers in order for the changes to take effect. The network statements were mistakenly deleted during a routine configuration update to our backbone routers. Management has been made aware of these findings and appropriate actions will be taken to ensure this situation does not re-occur. Prior reported information was leading the AT&T Network Engineers to believe that there were issues with the route reflectors being out of synch. However, this was only symptomatic of the problem stated above. In other words, due to the missing network statements, the route reflectors were not advertising certain networks; therefore traffic was not properly routed. It is AT&T’s goal to provide the highest level of service to our customers. We appreciate your business and look forward to continuing our relationship in the future. *Routing protocol (Open Shortest Path First) Depending on the particular IP access services to which you are subscribed you may also find additional information as it becomes available at: AT&T MIS: https://mis-att.bus.att.com/ AT&T VPNS: http://www.vpn.att.net If you require further information, please feel free to contact AT&T at: AT&T MIS: 1-888-613-6330 AT&T VPNS: 1-888-613-6501 Thank you for using AT&T. Sincerely, The AT&T Customer Care Team -----Original Message----- From: Matt Levine [mailto:matt@deliver3.com] Sent: Wed 8/28/2002 6:21 PM To: Mike Tancsa Cc: Wes Bachman; nanog(a)merit.edu Subject: Re: AT&T NYC On Wednesday, August 28, 2002, at 04:17 PM, Mike Tancsa wrote: > > > route-server.ip.att.net is not currently reachable, but AS15290's > router server is for those who want a view on things... Interestingly enough, ATT is announcing 12.0.0.0/23 to BBN (and nobody else, including AS7018 internal).. > > route-server.east.attcanada.com. > and > route-server.west.attcanada.com. > > which come in handy :-) > > ---Mike > > At 04:11 PM 28/08/2002 -0400, Mike Tancsa wrote: > > >> I am seeing this as well. One of my upstreams (AT&T Canada- 15290) >> has connections with AT&T US (7018) in Chicago and Vancouver. >> Chicago seems to have disappeared for me and all traffic bound via >> that path is going via Vancouver now. >> >> ---Mike >> >> At 02:52 PM 28/08/2002 -0500, Wes Bachman wrote: >> >>> Bryan, >>> >>> There is a known AT&T outage in Chicago currently. Could this be >>> effecting you in some way? >>> >>> -Wes >>> >>> On Wed, 2002-08-28 at 14:44, Bryan Heitman wrote: >>> > >>> > Anyone seeing any problems with ATT in new york? >>> > >>> > >>> > Best regards, >>> > >>> > >>> > Bryan Heitman >>> > Interland, Inc. >>> -- >>> Wes Bachman >>> System & Network Administration, Software Development >>> Leepfrog Technologies, Inc. >>> wbachman(a)leepfrog.com > > -- Matt Levine @Home: matt(a)deliver3.com @Work: matt(a)eldosales.com ICQ : 17080004 AIM : exile GPG : http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0D04CF "The Trouble with doing anything right the first time is that nobody appreciates how difficult it was." -BIX

26 63

RE: AT&T NYC
by Frank Scalzo 03 Sep '02

03 Sep '02

Since when is BGP a bug-free protocol? Let's not forget the BGP best path selection algorithm itself is broken (there are circumstances under which it will NEVER converge on a best path see ietf draft on IDR route oscillation). Not to mention the various malformed AS-Path bugs which have shown up over the years. I took a vendor class once where they made us do a lab where we had to run BGP w/o an IGP, in a later revision of the class they removed that lab because they decided it was too much of a nightmare even for a lab environment. -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent: Tuesday, September 03, 2002 10:39 AM To: alex(a)yuriev.com Cc: nanog(a)merit.edu Subject: Re: AT&T NYC On Tue, 3 Sep 2002 alex(a)yuriev.com wrote: > That is why their route is *nailed* via BGP to the router that *always* > provide connectivity to them. If they have to move, BGP injectors are your > friends. Takes seconds. Talking about things that take seconds: would you mind sharing your BGP hold time values with us? Iljitsch van Beijnum

5 6

Hosting NANOG - your chance for fame and fortune
by Susan Harris 03 Sep '02

03 Sep '02

Greetings NANOG fans - Merit is looking for an organization to host the winter NANOG meeting, sometime in Feb. '03. The host's main responsibilities would be to provide: * Connectivity to the conference site (at least 10M bps) * ~12 workstations for the terminal room * Staff to help with local logistics (locating a hotel) and conference setup (wire the terminal room and main meeting room) All hotel costs (catering, A/V, cookies, etc.) are covered by NANOG registration fees. Merit supplies hubs and switches and sets up the wireless network. Benefits of hosting include: * Your company name forever emblazened on the official NANOG t-shirt * Lifetime, official membership in NANOG * Fame and riches You'll find more info here: http://www.nanog.org/intro.html#host Please send email to nanog-support(a)nanog.org if you're interested in hosting a future meeting. Thanks! --Susan

1 0

hotel internet connectivity provider portscans port 6000
by Jun-ichiro itojun Hagino 03 Sep '02

03 Sep '02

inter-touch.com (an internet connectivity provider for hotels in australia, it seems) portscans customer device. this is way too weird, and the repsonse from them does not make any sense. i'm not sure if it is widely practiced, i really hope not. (the most stupid choice of port number!) itojun

1 0

Anyone home at SBC Security group ??
by John M. Brown 03 Sep '02

03 Sep '02

Just as I post "good jobs" to those that have respond quickly to active security issues (read NOT spam), I'll post those that stall and are less than responsive. Calling any security person at SBC. Your customer 65.71.193.155 is currently performing actions against networks we help manage and those actions are impacting their ability to provide service. over 8 hours ago, an email was sent to your published abuse@ address an there has been no reponse, yet the traffic continues. A call to the NOC number listed for the IP block, yielded a " can't help you, send email to abuse@, they will get to it when they do. With no ability to escalate given email failure" The attack has been underway for over 12 hours. If you have valid, helpful (solves this attack problem), and are from SBC, please reply PRIVATELY, so as not to invalidate the NANOG S/N ratios. We now return you to heavy discusions about SMTP headers, there legality, and other such standard NANOG topics. cheers john brown

2 1

employment legalities
by dalph＠hush.com 03 Sep '02

03 Sep '02

As long as we are discussing legalities, can anyone help me out with an employment-related question? My company is Canadian and I wish to hire a young American citizen. Our rapid growth has left me holding a network of five routers, which is a bit rough to manage. I'd like to employ the brilliant Nick Catalano but am concerned about child labor laws. Suggestions? -Dalph P.S. - What recourse against him would I have if he is unable to work because he gets grounded from the computer? Get your free encrypted email at https://www.hushmail.com

2 1

Re: Brad's Mail (was: Paul's Mailfrom)
by Brad Knowles 03 Sep '02

03 Sep '02

At 12:36 AM -0400 2002/08/30, Jim Popovitch wrote: > I'm not sure what it is that you are doing when you send email, but see the > attached jpg to see the error that Outlook displays when viewing your > emails. ;) That's exactly what Outlook users are supposed to see. Check the full headers of my messages to see how it's done. -- Brad Knowles, <brad.knowles(a)skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

3 2

Re: AT&T NYC
by Stephen J. Wilcox 02 Sep '02

02 Sep '02

On Mon, 2 Sep 2002, Petri Helenius wrote: > "Stephen J. Wilcox" wrote: > > > > On Mon, 2 Sep 2002, Petri Helenius wrote: > > > > > > > > bdragon(a)gweep.net wrote: > > > > With link-state, one interface flap can mean doing SPF on every route. > > > > > > Only if you learned every one of your routes from different neighbor. > > > If you have two exits and 100000 routes, you calculate twice and > > > apply the results to the prefixes. > > > > > > Note that this does not apply to a proprietary, "hybrid", semi-link > > > state protocol marketed with name "EIGRP" where all routes need > > > per-prefix calculation. (OSPF and IS-IS work fine) but.. with SPF you need to run the algorithm on all paths for each flap and then see what that does to your routes with eigrp you only need to apply the algorithm to any route on the link that flapped and then only on the attached router (which will propogate much like bgp if it requires other routers to recalculate) yes thats bad if yuo have 100000 routes but you shouldnt have! assuming a smaller routing table yuo get quicker convergence and much much less CPU requirement on your rotuers Steve > > Pete > > > > Steve > > > > > > > > Pete > > > >

3 2