September 2002 - Test - lists.nanog.org

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 02 Sep '02

02 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