August 2002 - Test - lists.nanog.org

AT&T NYC
by Bryan Heitman 04 Sep '03

04 Sep '03

Anyone seeing any problems with ATT in new york? Best regards, Bryan Heitman Interland, Inc.

10 11

Praise to XO's Security/Abuse
by John M. Brown 09 Sep '02

09 Sep '02

Jason at XO's security/abuse staff. Very helpful chap Solved a problem with a downstream client of theirs that was pounding a network I help out.... Yes, I know off topic, but more on topic as this list SHOULD be about people HELPING people do good in these difficult times. YMMV, but I'm happy. Have a great day John Brown Chagres Technologies, Inc

4 3

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

Broadening the IPv6 discussion
by Irwin Lazar 02 Sep '02

02 Sep '02

Since we're on the topic of IPv6, I wanted to gauge the current attitude of the ops. community toward its deployment. We're seeing a lot more interest from our enterprise clients in using v6, especially as things like VoIP and PDAs consume their address pools, and NAT gets in the way of collaborative apps such as netmeeting and business-to-business connectivity. However, the road-block seems to be the lack of ISPs that offer IPv6 services. Given that places like China & Japan are now mandating IPv6 for their ISPs, does anyone see anything resembling a growing momentum toward IPv6 adoption, or is it still a moot issue for you guys? Irwin

9 15

Bad bad routing problems?
by Gerald 01 Sep '02

01 Sep '02

We are seeing bad routing problems from outside our network. Can anyone corroborate this or help? We are on AS4276 and all traffic from us to our upstream seems good. Great way to spend holiday weekend. /me wonders if anyone is even awake on the NANOG list. :-) 2 addresses in our network I've tested with are: 216.223.200.14 and 216.223.192.68 Many many traces done, some interesting ones below: Here is a succesful traceroute: traceroute to 216.223.200.14 (216.223.200.14), 30 hops max, 40 byte 1 <10 ms <10 ms <10 ms rt1.altair7.com [209.11.155.129] 2 <10 ms 15 ms 16 ms 209.10.41.130 3 <10 ms 16 ms 15 ms ge-6-1-0.core1.sjc1.globix.net [209.10.2.193] 4 <10 ms 16 ms 16 ms so-4-2-0.core1.sjc4.globix.net [209.10.11.221] 5 63 ms 46 ms 47 ms so-1-0-0.core2.cgx2.globix.net [209.10.10.150] 6 62 ms 63 ms 47 ms so-0-0-0.core1.cgx2.globix.net [209.10.10.157] 7 78 ms 94 ms 94 ms so-1-0-0.core2.nyc8.globix.net [209.10.10.162] 8 78 ms 94 ms 94 ms pos15-0.core2.nyc1.globix.net [209.10.11.169] 9 78 ms 94 ms 94 ms s5-0-peer1.nyc3.globix.net [209.10.12.18] 10 78 ms 94 ms 94 ms nyiix.peer.nac.net [198.32.160.20] 11 78 ms 94 ms 93 ms internetchannel.customer.nac.net [209.123.10.34] 12 78 ms 94 ms 94 ms auth-2.inch.com [216.223.200.14] > These show failures before reaching our network: > > traceroute to 216.223.192.68 (216.223.192.68): 1-30 hops, 38 byte packets > 1 paleagw4.hpl.external.hp.com (192.6.19.2) 1.95 ms 1.95 ms 5.86 ms > 2 palgwb01-vbblpa.americas.hp.net (15.243.170.49) 0.976 ms 0.977 ms > 0.976 ms > 3 svl-edge-15.inet.qwest.net (65.115.64.25) 0.976 ms !H * 0.977 ms !H > 4 * * * > 5 * * * > > > > traceroute to 216.223.192.68 (216.223.192.68), 30 hops max, 40 byte > packets > 1 e3-13.foundry1.cs.wisc.edu (198.133.224.116) 2.195 ms 1.754 ms > 1.663 ms > 2 e15.extreme1.cs.wisc.edu (128.105.1.1) 0.856 ms 0.765 ms 0.737 ms > 3 144.92.128.194 (144.92.128.194) 1.550 ms 1.171 ms 1.264 ms > 4 * * * > 5 * * * > > All global crossing traces seem to loop within their router: > traceroute to 216.223.192.68 (216.223.192.68), 30 hops max, 40 byte > 1 64.214.13.1 (64.214.13.1) 0.695 ms 0.889 ms 0.485 ms 0.453 ms 0.350 ms > 2 64.214.13.1 (64.214.13.1) 4.535 ms !N ms * ms 0.574 ms !N ms > 3 * (64.214.13.1) 64.214.13.1 ms 0.408 ms !N ms * ms 0.425 ms > 4 64.214.13.1 (64.214.13.1) 0.741 ms !N ms * ms 0.542 ms !N ms > > traceroute to 216.223.200.14 (216.223.200.14), 30 hops max, 40 byte > 1 ROUTER6.VINEYARD.NET (204.17.195.236) 0.401 ms 0.342 ms 0.325 ms > 2 bos-edge-01.inet.qwest.net (65.115.97.141) 7.249 ms 7.089 ms 6.943 > ms > 3 * * * > 4 * * bos-edge-01.inet.qwest.net (65.115.97.141) 9.885 ms !H > 5 * * * > 6 * * * > 7 bos-edge-01.inet.qwest.net (65.115.97.141) 7.330 ms !H * * > 8 * * * > 9 * * * > 10 * * * > 11 * * * > 12 * * * > 13 * * * > 14 * * * > 15 * bos-edge-01.inet.qwest.net (65.115.97.141) 7.021 ms !H * > 16 * bos-edge-01.inet.qwest.net (65.115.97.141) 172.856 ms !H * > 17 * * * > 18 * * * > 19 * * bos-edge-01.inet.qwest.net (65.115.97.141) 7.127 ms !H > 20 * * bos-edge-01.inet.qwest.net (65.115.97.141) 6.787 ms !H > 21 * * bos-edge-01.inet.qwest.net (65.115.97.141) 61.972 ms !H > 22 * bos-edge-01.inet.qwest.net (65.115.97.141) 22.525 ms !H * > 23 * bos-edge-01.inet.qwest.net (65.115.97.141) 6.944 ms !H * > 24 bos-edge-01.inet.qwest.net (65.115.97.141) 15.922 ms !H * * > 25 bos-edge-01.inet.qwest.net (65.115.97.141) 11.212 ms !H * 6.895 ms > > This one works: > > traceroute to 216.223.192.68 (216.223.192.68), 30 hops max, 40 byte > 1 tin-V8.cac.washington.edu (140.142.3.1) 1 ms 0 ms 1 ms > 2 uwbr2-GE1-1.cac.washington.edu (140.142.155.24) 1 ms 1 ms 0 ms > 3 cnsp2-wes-GE0-1-0.pnw-gigapop.net (198.107.151.5) 1 ms 1 ms 1 ms > 4 ge-7-2-0.r04.sttlwa01.us.bb.verio.net (129.250.10.77) 0 ms 0 ms 1 ms > 5 p4-1-0-0.r03.sttlwa01.us.bb.verio.net (129.250.2.230) 0 ms 1 ms 0 ms > 6 p16-0-1-0.r20.sttlwa01.us.bb.verio.net (129.250.2.14) 1 ms 0 ms 1 ms > 7 p16-0-1-2.r21.plalca01.us.bb.verio.net (129.250.5.83) 23 ms 23 ms 23 ms > 8 p64-0-0-0.r20.plalca01.us.bb.verio.net (129.250.3.76) 22 ms 23 ms 22 ms > 9 p16-1-1-1.r20.dllstx01.us.bb.verio.net (129.250.4.104) 57 ms 57 ms 57 ms > 10 p64-0-0-0.r21.dllstx01.us.bb.verio.net (129.250.3.41) 57 ms 57 ms 57 ms > 11 p16-2-0-0.r00.stngva01.us.bb.verio.net (129.250.5.35) 87 ms 87 ms 88 ms > 12 p16-0-0-0.r02.stngva01.us.bb.verio.net (129.250.5.15) 87 ms 88 ms 87 ms > 13 p16-7-0-0.r02.mclnva02.us.bb.verio.net (129.250.5.47) 88 ms 88 ms 88 ms > 14 p4-3-0.r00.mclnva02.us.bb.verio.net (129.250.5.249) 88 ms 88 ms 88 ms > 15 mae-east-atm.peer.nac.net (198.32.187.103) 89 ms 89 ms 90 ms > 16 a9-0-1064.msfc1.nyc.nac.net (209.123.11.41) 95 ms 95 ms 96 ms > 17 internetchannel.customer.nac.net (209.123.10.34) 96 ms 96 ms 96 ms > 18 s0-varick-gw.inch.com (216.223.200.206) 100 ms 100 ms 100 ms > 19 rubber-biscuit.inch.com (216.223.192.98) 99 ms 99 ms 99 ms > 20 rubber-biscuit.inch.com (216.223.192.98) 99 ms !H 100 ms !H 98 ms !H

6 6

RE: Bad bad routing problems?
by Malayter, Christopher 31 Aug '02

31 Aug '02

I'm not receiving that network at all. I looked at our border to sprint, genuity, c&w, PSI, and our AADS peers. Sorry to not be of more assistance. -Chris -----Original Message----- From: Mike Tancsa [mailto:mike@sentex.net] Sent: Saturday, August 31, 2002 11:14 AM To: Gerald Cc: nanog(a)merit.edu Subject: Re: Bad bad routing problems? Strange, from my network I see you via GT and via Telus but not via AT&T From me (as11647) BGP routing table entry for 216.223.192.0/19 Paths: (2 available, best #2, table Default-IP-Routing-Table) Not advertised to any peer 852 174 8001 4276 209.115.141.1 from 209.115.141.1 (209.115.137.196) Origin IGP, localpref 100, valid, external Last update: Sat Aug 31 08:47:55 2002 6539 8001 4276 64.7.143.42 from 64.7.143.42 (64.7.143.42) Origin IGP, localpref 100, valid, internal, best Community: 6539:30 Last update: Sat Aug 31 08:47:30 2002 From the AT&T CANADA routeserver (route-server.east.attcanada.com) AT&T route server route-server.east>show ip bgp 216.223.192.0/19 % Network not in table route-server.east> AT&T Canada gets to 8001 via Williams, but I dont see your /19 through them. route-server.east>show ip bgp regex _8001_ BGP table version is 2266132, local router ID is 216.191.65.118 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i12.129.128.0/24 216.191.64.253 80 0 7911 8001 22420 i *>i63.74.146.0/23 216.191.64.253 80 0 7911 8001 23368 i At 10:54 AM 8/31/2002 -0400, Gerald wrote: >We are seeing bad routing problems from outside our network. Can anyone >corroborate this or help? > >We are on AS4276 and all traffic from us to our upstream seems good. Great >way to spend holiday weekend. /me wonders if anyone is even awake on the >NANOG list. :-) > >2 addresses in our network I've tested with are: > >216.223.200.14 >and 216.223.192.68 > >Many many traces done, some interesting ones below: > >Here is a succesful traceroute: >traceroute to 216.223.200.14 (216.223.200.14), 30 hops max, 40 byte > 1 <10 ms <10 ms <10 ms rt1.altair7.com [209.11.155.129] > 2 <10 ms 15 ms 16 ms 209.10.41.130 > 3 <10 ms 16 ms 15 ms ge-6-1-0.core1.sjc1.globix.net [209.10.2.193] > 4 <10 ms 16 ms 16 ms so-4-2-0.core1.sjc4.globix.net > [209.10.11.221] > 5 63 ms 46 ms 47 ms so-1-0-0.core2.cgx2.globix.net > [209.10.10.150] > 6 62 ms 63 ms 47 ms so-0-0-0.core1.cgx2.globix.net > [209.10.10.157] > 7 78 ms 94 ms 94 ms so-1-0-0.core2.nyc8.globix.net > [209.10.10.162] > 8 78 ms 94 ms 94 ms pos15-0.core2.nyc1.globix.net [209.10.11.169] > 9 78 ms 94 ms 94 ms s5-0-peer1.nyc3.globix.net [209.10.12.18] > 10 78 ms 94 ms 94 ms nyiix.peer.nac.net [198.32.160.20] > 11 78 ms 94 ms 93 ms internetchannel.customer.nac.net > [209.123.10.34] > 12 78 ms 94 ms 94 ms auth-2.inch.com [216.223.200.14] > > > These show failures before reaching our network: > > > > traceroute to 216.223.192.68 (216.223.192.68): 1-30 hops, 38 byte packets > > 1 paleagw4.hpl.external.hp.com (192.6.19.2) 1.95 ms 1.95 ms 5.86 ms > > 2 palgwb01-vbblpa.americas.hp.net (15.243.170.49) 0.976 ms 0.977 ms > > 0.976 ms > > 3 svl-edge-15.inet.qwest.net (65.115.64.25) 0.976 ms !H * 0.977 ms !H > > 4 * * * > > 5 * * * > > > > > > > > traceroute to 216.223.192.68 (216.223.192.68), 30 hops max, 40 byte > > packets > > 1 e3-13.foundry1.cs.wisc.edu (198.133.224.116) 2.195 ms 1.754 ms > > 1.663 ms > > 2 e15.extreme1.cs.wisc.edu (128.105.1.1) 0.856 ms 0.765 ms 0.737 ms > > 3 144.92.128.194 (144.92.128.194) 1.550 ms 1.171 ms 1.264 ms > > 4 * * * > > 5 * * * > > > > All global crossing traces seem to loop within their router: > > traceroute to 216.223.192.68 (216.223.192.68), 30 hops max, 40 byte > > 1 64.214.13.1 (64.214.13.1) 0.695 ms 0.889 ms 0.485 ms 0.453 ms 0.350 ms > > 2 64.214.13.1 (64.214.13.1) 4.535 ms !N ms * ms 0.574 ms !N ms > > 3 * (64.214.13.1) 64.214.13.1 ms 0.408 ms !N ms * ms 0.425 ms > > 4 64.214.13.1 (64.214.13.1) 0.741 ms !N ms * ms 0.542 ms !N ms > > > > traceroute to 216.223.200.14 (216.223.200.14), 30 hops max, 40 byte > > 1 ROUTER6.VINEYARD.NET (204.17.195.236) 0.401 ms 0.342 ms 0.325 ms > > 2 bos-edge-01.inet.qwest.net (65.115.97.141) 7.249 ms 7.089 ms 6.943 > > ms > > 3 * * * > > 4 * * bos-edge-01.inet.qwest.net (65.115.97.141) 9.885 ms !H > > 5 * * * > > 6 * * * > > 7 bos-edge-01.inet.qwest.net (65.115.97.141) 7.330 ms !H * * > > 8 * * * > > 9 * * * > > 10 * * * > > 11 * * * > > 12 * * * > > 13 * * * > > 14 * * * > > 15 * bos-edge-01.inet.qwest.net (65.115.97.141) 7.021 ms !H * > > 16 * bos-edge-01.inet.qwest.net (65.115.97.141) 172.856 ms !H * > > 17 * * * > > 18 * * * > > 19 * * bos-edge-01.inet.qwest.net (65.115.97.141) 7.127 ms !H > > 20 * * bos-edge-01.inet.qwest.net (65.115.97.141) 6.787 ms !H > > 21 * * bos-edge-01.inet.qwest.net (65.115.97.141) 61.972 ms !H > > 22 * bos-edge-01.inet.qwest.net (65.115.97.141) 22.525 ms !H * > > 23 * bos-edge-01.inet.qwest.net (65.115.97.141) 6.944 ms !H * > > 24 bos-edge-01.inet.qwest.net (65.115.97.141) 15.922 ms !H * * > > 25 bos-edge-01.inet.qwest.net (65.115.97.141) 11.212 ms !H * 6.895 ms > > > > This one works: > > > > traceroute to 216.223.192.68 (216.223.192.68), 30 hops max, 40 byte > > 1 tin-V8.cac.washington.edu (140.142.3.1) 1 ms 0 ms 1 ms > > 2 uwbr2-GE1-1.cac.washington.edu (140.142.155.24) 1 ms 1 ms 0 ms > > 3 cnsp2-wes-GE0-1-0.pnw-gigapop.net (198.107.151.5) 1 ms 1 ms 1 ms > > 4 ge-7-2-0.r04.sttlwa01.us.bb.verio.net (129.250.10.77) 0 ms 0 ms 1 ms > > 5 p4-1-0-0.r03.sttlwa01.us.bb.verio.net (129.250.2.230) 0 ms 1 ms 0 ms > > 6 p16-0-1-0.r20.sttlwa01.us.bb.verio.net (129.250.2.14) 1 ms 0 ms 1 ms > > 7 p16-0-1-2.r21.plalca01.us.bb.verio.net (129.250.5.83) 23 ms 23 ms 23 ms > > 8 p64-0-0-0.r20.plalca01.us.bb.verio.net (129.250.3.76) 22 ms 23 ms 22 ms > > 9 p16-1-1-1.r20.dllstx01.us.bb.verio.net (129.250.4.104) 57 ms 57 ms 57 ms > > 10 p64-0-0-0.r21.dllstx01.us.bb.verio.net (129.250.3.41) 57 ms 57 ms 57 ms > > 11 p16-2-0-0.r00.stngva01.us.bb.verio.net (129.250.5.35) 87 ms 87 ms 88 ms > > 12 p16-0-0-0.r02.stngva01.us.bb.verio.net (129.250.5.15) 87 ms 88 ms 87 ms > > 13 p16-7-0-0.r02.mclnva02.us.bb.verio.net (129.250.5.47) 88 ms 88 ms 88 ms > > 14 p4-3-0.r00.mclnva02.us.bb.verio.net (129.250.5.249) 88 ms 88 ms 88 ms > > 15 mae-east-atm.peer.nac.net (198.32.187.103) 89 ms 89 ms 90 ms > > 16 a9-0-1064.msfc1.nyc.nac.net (209.123.11.41) 95 ms 95 ms 96 ms > > 17 internetchannel.customer.nac.net (209.123.10.34) 96 ms 96 ms 96 ms > > 18 s0-varick-gw.inch.com (216.223.200.206) 100 ms 100 ms 100 ms > > 19 rubber-biscuit.inch.com (216.223.192.98) 99 ms 99 ms 99 ms > > 20 rubber-biscuit.inch.com (216.223.192.98) 99 ms !H 100 ms !H 98 ms !H -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike(a)sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike

2 1

Re: Praise to XO's Security/Abuse
by JC Dill 31 Aug '02

31 Aug '02

On 02:14 AM 8/31/02, Simon Lyall wrote: >At least with RFC-ignorant you know who to contact Since rfc-ignorant *uses* rfc-ignorant, I can't directly contact him/them (as the bounce below shows). I refuse to jump thru hoops to inform them of the errors of their ways. If they want to play games pretending that a large ISP with an efficient and responsive abuse desk somehow doesn't get abuse email addressed to one of their many domains, they can stick their head(s) in the sand and pretend. It doesn't mean I have to silently go along with it. Derek, please don't send me private email unless you are going to accept replies from the address you are sending to (see bounce, below). Sending, but refusing replies, that's rude. Note on cnchost: When we launched this service (I worked for Concentric and was the product manager for this service during its development and beta in 1996, and launch in 1997), we offered customers the option of a default mailbox for anyone@theirdomain (with additional restricted mailboxes as desired), or restricting their mailboxes where only email addressed to actual usernames was delivered, all other email bounces. However, an exception was made for the role accounts of abuse, postmaster, and webmaster. If the customer creates user accounts with those names, email is delivered to the appropriate email box. If the customer does not create these accounts, and elects to only receive email addressed to the customer's named accounts, email addressed to postmaster, abuse, and webmaster is still delivered to the primary user account for that domain (while other "non-existant" usernames will still bounce). We did this in 1996, years before rfc-ignorant thought up their listing idea, and when other webhosts were allowing these role accounts to bounce, or hijacking (and then badly handling) all email to those usernames for every hosted domain (no matter what the domain name was) due to less configurable virtual hosting schemes. So the idea that someone believes that cnchost is "rfc-ignorant" REALLY rubs me the wrong way. jc >From: Mail Delivery Subsystem <MAILER-DAEMON(a)tonnant.cnchost.com> >Subject: Returned mail: User unknown >Message-ID: <200208310927.FAA08746(a)tonnant.cnchost.com> >Errors-To: <MAILER-DAEMON(a)tonnant.cnchost.com> >To: <jcdill(a)vo.cnchost.com> >Auto-Submitted: auto-generated (failure) >X-UIDL: 30537 > >The original message was received at Sat, 31 Aug 2002 05:27:57 -0400 (EDT) >from adsl-208-201-244-240.sonic.net [208.201.244.240] > > ----- The following addresses had permanent fatal errors ----- ><dredd(a)megacity.org> > > ----- Transcript of session follows ----- >... while talking to mail.megacity.org.: >>>> RCPT To:<dredd(a)megacity.org> ><<< 550 5.7.1 <dredd(a)megacity.org>... Message rejected because the >connecting host (tonnant.concentric.net) does not have abuse contact - see >www.rfc-ignorant.org >550 <dredd(a)megacity.org>... User unknown > > ----- Original message follows ----- > >Return-Path: <jcdill(a)vo.cnchost.com> >Received: from Erwin.vo.cnchost.com (adsl-208-201-244-240.sonic.net >[208.201.244.240]) > by tonnant.cnchost.com > id FAA08735; Sat, 31 Aug 2002 05:27:57 -0400 (EDT) > [ConcentricHost SMTP Relay 1.14] >Errors-To: <jcdill(a)vo.cnchost.com> >Message-Id: <5.0.0.25.2.20020831022838.040be1f0(a)pop3.vo.cnchost.com> >X-Sender: jcdill%vo.cnchost.com(a)pop3.vo.cnchost.com >X-Mailer: QUALCOMM Windows Eudora Version 5.0 >Date: Sat, 31 Aug 2002 02:29:27 -0700 >To: "Derek J. Balling" <dredd(a)megacity.org> >From: JC Dill <jcdill(a)vo.cnchost.com> >Subject: Re: Praise to XO's Security/Abuse >In-Reply-To: <F7DD5CF3-BC85-11D6-A43D-00039384A830(a)megacity.org> >References: <Pine.LNX.4.41.0208302149180.3717-100000(a)amethyst.nstc.com> >Mime-Version: 1.0 >Content-Type: text/plain; charset="us-ascii"; format=flowed > >On 07:04 PM 8/30/02, Derek J. Balling wrote: > >I don't show a listing at all for cnchost.com ... (or vo.cnchost.com, > >which we wouldn't list anyway). > > > >what hostname does your mail server's IP address in-addr to? > > cnchost runs off a server cluster, you can get different IP addresses >each time you query (or at least, you are supposed to), as it does >automatic load balancing. <snip>

1 0

Do ATM-based Exchange Points make sense anymore?
by William B. Norton 31 Aug '02

31 Aug '02

Hi all - I've been working with a number of ISPs on a research paper that builds on the previous peering research papers (Internet Service Providers and Peering, A Business Case for Peering, The Art of Peering, Interconnection Strategies for ISPs, etc.) that applies the Peering Modelling tools in a comparison of ATM and Ethernet-based Internet Exchanges. Both of these IXes are compared against each other and against the cost of buying transit. The paper applies recent price quotes for transport and transit, costs for ATM and Ethernet-based IX participation, to answer the question: Do ATM-based Exchange Points make sense anymore? I'd like to speak with additional ISP Peering Coordinators and Network Architects (preferable ones that have experience with peering across both ATM and Ethenet-based IXes) to walk through this paper and help me check that I have the technical and business details right. I would need about 20 minutes or so on the phone to walk you through the paper, the financial models, the cost points, and get feedback on the conclusions...preferably sometime in the next couple weeks. If you are a Peering Coordinator I think you will find at least a couple of findings in this research *very* interesting. In any case, if you can help, please send me an e-mail at wbn(a)equinix.com and let me know when we could chat. Thanks - Bill PS - As with any these Peering White Papers, this white paper will be freely available once enough folks have walked through it and verify that we have things right. ------------------------------------------ Abstract --------------------------------------------------- During the NSFNET transition from the Authorized Use Policy Internet to the Commercial Internet, several Network Access Points (NAPs) were created to facilitate the traffic exchange between the Internet Service Providers, two of which were ATM-based. Internet Service Providers were initially required to connect to three of the four NAPs in order to receive NSF funds (indirectly through their NSF-sponsored customers) during this transition period. During the years that followed, this requirement was dropped and the costs models of Internet Operation have changed dramatically. Technologies such as Wave Division Multiplexing and Long Haul Fiber Improvements have led to radical a decrease in the cost of transport and a corresponding drop in the price of transit. At the same, the cost of peering at ATM-based exchange points has not substantially dropped in cost, leading to the question in the Peering Coordinator Community: "Do ATM-based Internet Exchange Points make sense anymore?" In this paper we apply the peering financial models to this question, using current market prices to compare the price of transit against the costs of peering at ATM-based NAPs and Ethernet-based Internet Exchange Points. We build upon the previous research on Peering by introducing the notion of an Effective Peering Range (EPR) to describe the "useful life" of an Internet Exchange. We also highlight a potentially costly EPR Gap, an interim range between Peering Capacity points where peering is more expensive than transit. The financial models presented that produced the graphs are included in the Appendix so that ISPs can apply these cost models to their specific situation.

5 6

looking for benchmarks for campus and metropolitan networks
by Miles Fidelman 31 Aug '02

31 Aug '02

Hi Folks, I do an increasing amount of work with municipal electric utilities and local governments that are building community-wide MANS. The technology of choice is starting to be gigabit ethernet. I'm trying to pull together some benchmarks, or at least rules of thumb, for capacity planning - and I figure that large campus networks are a good place to start. So... to those of you who manage large campus or corporate networks, and particularly those of you running gigE as a campus backbone, do you have any rules of thumb regarding: - average/peak bandwidth per desktop - average/peak bandwidth per workgroup-level switch - how much bandwidth to provision between your campus network and your backbone POP(s) - etc. And... can you suggest any reference sources (books, web sites, email lists, etc.) that focus on design issues for very large campus networks? Thanks very much, Miles Fidelman ************************************************************************** The Center for Civic Networking PO Box 600618 Miles R. Fidelman, President & Newtonville, MA 02460-0006 Director, Municipal Telecommunications Strategies Program 617-558-3698 fax: 617-630-8946 mfidelman(a)civicnet.org http://civic.net/ccn.html Information Infrastructure: Public Spaces for the 21st Century Let's Start With: Internet Wall-Plugs Everywhere Say It Often, Say It Loud: "I Want My Internet!" **************************************************************************

1 0

Re: building a better route reflector
by dalph＠hush.com 30 Aug '02

30 Aug '02

> Why don't we dump IP routeing and have one big supernet on one big > bridge peice of ethernet? Wouldn't life be simple! It would still be difficult to tune traffic without my /24 annoucements being heard. It could work if we used global 802.1q tags instead of ASN's, although it probably would help if we add a couple octets to the VLAN ID. The equivalent of as_path could be stored similar to IP RR, moving processing overhead to a lower layer. We would also need a global tag registry, which I would be happy to host in our world-class NOC. It's a great place to work, and stays toasty warm even on cold winter days. Dalph "Wiggum" Roncaster principal, WiggumwerksGhostNetwork.com div. of Mad Clue Consulting Group Get your free encrypted email at https://www.hushmail.com

1 0