- Test - lists.nanog.org

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

Re: building a better route reflector
by bdragon＠gweep.net 02 Sep '02

02 Sep '02

> Running two routing protocols is too much of a hassle. I think I would > rather use static routes, and synchronize routers using rsync, diff, and > patch. Our NOC has several 286s running Xenix that could act as servers > for this. > > This would eliminate the hassle of running OSPF, ISIS, or RIP. Does > anyone know of a Tier-1 for under $30/Mbps that would run something like > this instead of BGP? I'd love it if we didn't need any routing protocols. > > -Dalph *twitch* having seen one of these in the wild (igp=static routes) I will have to say "Abandon all Faith, Ye who enter Here"

1 0

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