- Test - lists.nanog.org

BGP issues
by Bret Baptist 18 Sep '03

18 Sep '03

I recently deployed a multihome BGP configuration at our location. Now I am having issues of some of my netblocks not being reachable or not being able to reach certain networks. I am uncertain what the issue might be. Right now I have visi.com as one provider (AS8015), and Qwest (AS3908) as the other. When I look at the as-paths for my netblocks the ones from visi.com look fine, 208.42.20.0/23 and 208.42.104.0/23, the ones from Qwest go through visi.com and then on to us, 65.116.186.0/24, 65.121.8.0/23. The Qwest networks are the ones that I am having problems reaching hosts from or getting to from other networks. Any insight would be greatly appreciated, if anyone needs more information just let me know and I can supply router configs or whatever might be needed. Thank you in advance. -- Bret Baptist Systems and Technical Support Specialist bbaptist(a)iexposure.com Internet Exposure, Inc. http://www.iexposure.com (612)676-1946 x17 Web Development-Web Marketing-ISP Services ------------------------------------------ Today is the tomorrow you worried about yesterday.

4 3

route to behosting.com
by Lou Katz 18 Sep '03

18 Sep '03

Actually, me bad. It is the nameservers they use for their clients: ns5.behosting.com 208.56.139.155 ns6.behosting.com 208.56.138.142 I cannot reach either from many nets on the west coast, and the traceroutes die very early: >From usenix.org: 12-% traceroute -n 208.56.139.155 traceroute to 208.56.139.155 (208.56.139.155), 30 hops max, 40 byte packets 1 131.106.3.254 0.677 ms 0.324 ms 0.310 ms 2 131.106.1.252 0.937 ms 0.971 ms 0.931 ms 3 * * * 4 * normally goes out: 1 gw.usenix.org (131.106.3.254) 0.561 ms 0.296 ms 0.260 ms 2 alternet-gw.usenix.ORG (131.106.1.252) 1.396 ms 1.024 ms 1.324 ms 3 twtwan (206.169.168.45) 235.612 ms 106.793 ms 156.533 ms 4 twtgw (206.169.155.13) 212.983 ms 154.202 ms 213.979 ms 5 ^C dist-02-so-0-0-0-0.okld.twtelecom.net (168.215.55.74) 176.927 ms 217.310 ms 173.318 ms >From other nets available to me: traceroute to 208.56.139.155 (208.56.139.155), 64 hops max, 44 byte packets 1 megapath-gw (192.160.193.1) 3.408 ms 1.670 ms 1.634 ms 2 ip-64-139-1-1.dsl.sca.megapath.net (64.139.1.1) 11.782 ms 11.101 ms 10.642 ms 3 * * * traceroute to 208.56.139.155 (208.56.139.155), 64 hops max, 44 byte packets 1 (10.9.129.35) 3.734 ms 2.450 ms 2.311 ms 2 (10.8.5.73) 89.816 ms 169.081 ms 145.875 ms 3 (10.8.2.1) 210.021 ms 219.102 ms 280.200 ms 4 * * (10.x.x.x internal to my ISP - WCOM) traceroute to 208.56.139.155 (208.56.139.155), 30 hops max, 38 byte packets 1 sonic-gw (209.204.189.1) 14.490 ms 14.470 ms 12.984 ms 2 fast1-0-0.border.sr.sonic.net (208.201.224.194) 16.476 ms 24.872 ms 14.633 ms 3 fast4-1-0.border2.sr.sonic.net (64.142.0.26) 15.193 ms 14.675 ms 16.076 ms 4 serial1-0.gw.focal-sf.sonic.net (64.142.0.2) 17.359 ms 16.794 ms 15.017 ms 5 * * * >From the well: traceroute to 208.56.139.155 (208.56.139.155) 30 hops max, 38 byte packets 1 gw.well.com (206.14.209.1) 2 ms 2 ms 1 ms 2 206.14.211.65 (206.14.211.65) 86 ms 1 ms 1 ms 3 206.14.211.65 (206.14.211.65) 1 ms (ttl=254!) !H * 1 ms (ttl=254!) !H -- -=[L]=-

2 1

RE: Route failures to behosting.com
by McBurnett, Jim 18 Sep '03

18 Sep '03

good from AT&T and Broadwing J > -----Original Message----- > From: Haesu [mailto:haesu@towardex.com] > Sent: Wednesday, September 17, 2003 9:46 PM > To: Henry Yen; nanog(a)merit.edu > Subject: Re: Route failures to behosting.com > > > > Also accessible no problem from Qwest and Nlayer. > > -hc > > -- > Sincerely, > Haesu C. > TowardEX Technologies, Inc. > WWW: http://www.towardex.com > E-mail: haesu(a)towardex.com > Cell: (978) 394-2867 > On Wed, Sep 17, 2003 at 09:35:54PM -0400, Henry Yen wrote: > > > > On Wed, Sep 17, 2003 at 09:29:57AM -0400, Brian Bruns wrote: > > > Attempts to access behosting.com were successful from > several different > > > locations, which included ameritech and sprint. I'm not > going to include > > > traceroutes here (if you would like them, I can email them to you > > > privately). What ISPs are you using to try and get to them? > > > > behosting.com/www.behosting.com (aka 216.121.96.160) also accessible > > without problem from sprint and uunet. > > > > > ----- Original Message ----- > > > From: "Lou Katz" <lou(a)metron.com> > > > To: <nanog(a)merit.edu> > > > Sent: Wednesday, September 17, 2003 9:23 PM > > > Subject: Route failures to behosting.com > > > > > > > I am unable to reach them via several different ISPs. It looks > > > > to my naive eyes like routes to them have vanished. Can anyone > > > > shed any light on this? > > > > -- > > Henry Yen Aegis > Information Systems, Inc. > > Senior Systems Programmer Hicksville, New York > >

1 0

RE: Route failures to behosting.com
by Shawn Jackson 18 Sep '03

18 Sep '03

Behosting.com is accessible from AT&T with no problems. traceroute to behosting.com (216.121.96.160), 30 hops max, 38 byte packets 1 gw (12.22.x.xxx) 1.974 ms 1.939 ms 1.983 ms 2 12.118.156.29 (12.118.156.29) 8.395 ms 6.070 ms 6.015 ms 3 gbr5-p59.sffca.ip.att.net (12.123.195.130) 8.975 ms 8.543 ms 8.453 ms 4 tbr1-p013501.sffca.ip.att.net (12.122.11.73) 9.568 ms 9.286 ms 9.276 ms 5 ggr1-p360.sffca.ip.att.net (12.123.13.65) 8.584 ms 8.544 ms 8.503 ms 6 svl-brdr-02.inet.qwest.net (205.171.1.165) 141.856 ms 142.191 ms 141.599 ms 7 svl-core-03.inet.qwest.net (205.171.14.162) 142.247 ms 144.525 ms 144.658 ms 8 svl-edge-09.inet.qwest.net (205.171.14.98) 142.824 ms 141.505 ms 137.071 ms 9 65.113.32.50 (65.113.32.50) 139.001 ms 148.024 ms 139.999 ms 10 behosting.com (216.121.96.160) 144.550 ms 135.547 ms 138.744 ms Shawn Jackson Systems Administrator Horizon USA 1190 Trademark Dr #107 Reno NV 89521 www.horizonusa.com Email: sjackson(a)horizonusa.com Phone: (775) 858-2338 (800) 325-1199 x338 -----Original Message----- From: Lou Katz [mailto:lou@metron.com] Sent: Wednesday, September 17, 2003 5:23 PM To: nanog(a)merit.edu Subject: Route failures to behosting.com I am unable to reach them via several different ISPs. It looks to my naive eyes like routes to them have vanished. Can anyone shed any light on this? -- -=[L]=-

1 0

RE: Worst design decisions?
by Shawn Solomon 18 Sep '03

18 Sep '03

The 12016 does have handles on the sides, but the documentation states not to use them for lifting purposes. Yeah, I laughed too, just before realizing that bear-hugging a 16 into position takes a bit of motivation. It is definitely one big hunk of iron (300+lbs on the shipping invoice), but I just couldn't understand why in the @%$$ useful handles weren't provided. On a side note, the scissor-jacks that came with them could lift a house. Heh. http://www.cisco.com/en/US/products/hw/routers/ps167/prod_installation_g uide09186a0080188f38.html ------------------------------------------------------------------------ -------- Warning Do not attempt to lift the chassis with the handles on the back and sides of the chassis. These handles are not designed to support the weight of the chassis, and should be used only to steady and guide the chassis while it is being inserted into or removed from an equipment rack. To reduce the risk of damage to the chassis and serious bodily injury, do not use these handles to lift or support the chassis. ------------------------------------------------------------------------ -------- -----Original Message----- From: Matt [mailto:acheron@qwest.net] Sent: Wednesday, September 17, 2003 5:43 PM To: nanog(a)merit.edu Subject: Worst design decisions? Hello all, Was doing some upgrades on a UBR7246 (to a VXR), and I got to thinking about short sighted design considerations. I was curious if any of you had some pet peeves from a design perspective to rant about. I'll start with a couple. 1) Why did Cisco design the I/O controller on the 7246 with screws in the corner, which are very difficult to get at? And worse than that, why did they not include a cheap handle on the blank in this slot? 2) Why did Cisco not include side handles on the 12000 chassis? It's a heavy chassis, and I can imagine how many techs have thrown out their back moving that chassis around. I've got a couple others in my head from 3Com and a couple of others, but I thought I'd get the ball rolling. So, what do you think?

1 0

ICANN - Formal Complaint re Verisign
by Jerry Eyers 18 Sep '03

18 Sep '03

One thing I haven't seen mentioned in all this is the incredible business monopolizing effect this move will have on the TLD's in question. It dramatically shifts the domain playing field in Verisign's favor by pointing millions of potential customers to their site(s) specifically, giving them millions of dollars in free advertising eye-time over any of the competition Jerry

5 4

OT: Interesting visuals. interesting message, 560 kb, 5 min to run (if you have a moment)
by Dr. Jeffrey Race 18 Sep '03

18 Sep '03

Interesting diversion from quotidian banalities <http://www.fdnylodd.com/BloodofHeroes.html> Jeffrey Race

1 0

VeriSign responds to complaints via press release
by Jeff Wasilko 18 Sep '03

18 Sep '03

----- Forwarded message from Dave Farber <dave(a)farber.net> ----- If this was Microsoft issuing a statement like this we would really go through the roof. Since when in the Internet do we talk with technical people AFTER the fact and AFTER the disruption. In other words BULL. Can we sue them for email disruption? Dave >Delivered-To: dfarber+(a)ux13.sp.cs.cmu.edu >Date: Wed, 17 Sep 2003 19:27:49 -0400 >From: "Wingfield, Nick" <Nick.Wingfield(a)wsj.com> >Subject: VeriSign update >To: "'dave(a)farber.net'" <dave(a)farber.net> > > >Dave, >In case it's of interest to IP... >Nick > > >=WSJ: VeriSign Responds To Complaints About New Service > >Dow Jones News Service via Dow Jones > > > By Nick Wingfield > Of THE WALL STREET JOURNAL > > > SAN FRANCISCO (Dow Jones)--VeriSign Inc. (VRSN), responding to an >outpouring >of complaints about a new service that exploits the typing errors users make >when surfing the Web, said it plans to work with technologists to remedy >disruptions the service has caused to some Internet applications like >e-mail. > > At the same time, the VeriSign service triggered a huge increase in the >amount >of traffic flowing to the Mountain View, Calif., company's Web site, a >portion >of which may be the result of a hacker attack against the company, VeriSign >said. > > (This story and related background material are available on the Journal's >Web >site, WSJ.com.) > > VeriSign on Monday introduced the service, dubbed Site Finder, which >steers >users who attempt to reach nonexistent Web addresses to a site operated by >VeriSign. The company is able to take control of the traffic because it >operates >the master list, or "registry," for all Internet addresses ending in ".com" >and >".net." > > VeriSign said it designed Site Finder as a navigational aid for Web users. >It >also receives revenue from the additional traffic through relationships with >Overture Services Inc. (OVER) and Yahoo Inc.'s (YHOO) Inktomi, which guide >users >to Web sites. > > The new VeriSign service infuriated many network operators, though, who >say it >has disrupted the functioning of e-mail and other applications. Among the >complaints about the VeriSign service is that it hurts the ability of >Internet >service providers to block "spam" sent from Internet addresses that don't >exist >- a common technique normally used to stem the flow of junk e-mail. Internet >service providers and software groups have developed patches that prevent >the >VeriSign service from working on their networks. > > In a statement Tuesday, VeriSign said it would release technical >information >on its Web site that would help network operators adapt their software so >they >could block unwanted e-mail again. "In the course of implementation, various >users asked us to modify the service to accommodate anti-spam applications," >the >company said in the statement. "Because VeriSign strongly supports >appropriate >technical measures designed to reduce unwanted spam, we are reaching out to >users and the community to make appropriate adjustments to the service." > > "We remain committed to ensuring that Site Finder improves Web navigation >and >the user experience," VeriSign added. > > Despite the controversy, VeriSign's efforts to nab control of typo-prone >Internet users appears to be having a sizable impact on the volumes of users >visiting its site. Traffic to the company's Web site on Tuesday skyrocketed >to >about 1.3 million visitors from an average of about 100,000 visitors on the >previous four Tuesdays, according to measurement firm ComScore Networks Inc. > > > Some of that may have been due to malicious - not typo - traffic. A >VeriSign >spokesman said the company experienced a "denial of service" attack on its >Web >site on Tuesday, in which hackers use computers to bombard Web sites with >traffic in hopes of overloading them. The attack appeared to subside by >Wednesday, the spokesman said. A ComScore spokesman said it's "very >unlikely" >that a denial of service attack on VeriSign had a significant impact on the >ComScore traffic figures.

3 2

Re: Root Server Operators (Re: What *are* they smoking?)
by Paul Vixie 17 Sep '03

17 Sep '03

> > i don't think so. verisign is on public record as saying that the > > reason they implemented the wildcard was to enhance the services > > offered to the internet's eyeball population, who has apparently > > been clamouring for this. > > My question is, if this was to serve some need of internet users, why > does port 25 work and not port 80? i wouldn't speak for verisign on that point even if i knew the facts (which i don't) but i'm guessing that the internet today has mostly just got web browsers on it, and verisign is principally concerned with those people. > So, I'm curious as to your opinion about the bigger issue. Maybe it > has been stated somewhere else, and if it has, please direct me to > it. I've read all of your posts about this on nanog, and you do an > excellent job of staying neutral. You point out that what Verisign is > doing is technically valid and therefore shouldn't be addressed with a > technical "solution", but you also release a patch for Bind to > accomodate obvious demand (and to save users the hassle of > implementing half-assed patches with hardcoded A records). However, > you do so without actually stating whether or not you think the > wildcards are a (policy) problem or not. let me be clear on that point, then. i've now heard some people from icann's various committees and boards say that they either were not consulted, or that they were consulted and they advised against this, and they feel rather strongly that these wildcards should not have been put in. so, there is a policy problem, which is that folks don't agree as to whether verisign is the owner or the steward for .com and .net, and folks don't agree on whose permission is needed for what. i would like to see that policy problem resolved, but i have no part in it, and i don't actually care which way it's resolved, so long as it is resolved. we all need to know whether verisign is the owner or steward, and we all need to know whose permission is needed for what, and we all need to know what to expect. resolving the policy problems will give us all those things. so, i hope that someone (else) resolves those policy problems. (if y'all need me i'll be out washing my cat.) > You point out that there is high-level ambiguity about the > relationship between DOC, ICANN, and Verisign, and about whether or > not Verisign should have the public's interest in mind. speaking as an individual, and not as a party to policy discussions between the people who need to set and follow policies in this arena, i can say: > Do you think > they should have the public's interest in mind? yes. because any tld who does not do this gives ammo to the kooks who want to set up their own alternative namespace. that would be bad for the public since it would be even more chaotic than what we have now, and chaos is expensive and painful. > And do you think the > wildcards are in the public's interest? no. i liked it better when vix.com's parent domain (com) had no wildcard, so that if someone mistyped my domain name they got a hard dns error rather than a verisign search page or mail error. > I can certainly empathize with wanting to stay neutral, but I think we > need somebody who carries substantial influence in the name resolution > community to have strong opinions about such a poor policy decision. i sure hope you find her (or him). good luck with that. see you all in san diego (usenix) next month, when i shall joyously lampoon all of this bitrot during my invited talk on the subject of internet governance.

1 0

Re: Change to .com/.net behavior
by Paul Vixie 17 Sep '03

17 Sep '03

> > ... shouldn't they get to decide this for themselves? > > Returning NXDOMAIN when a domain does not exist is a basic > requirement. Failure to do so creates security problems. It is > reasonable to require your customers to fix known breakage that > creates security problems. that sounds pretty thin. i think you stretched your reasoning too far. > VeriSign has a public trust to provide accurate domain > information for the COM and NET zones. They have decided to put their > financial interest in obscuring this information ahead of their public > trust. i'm not sure how many people inside verisign, us-DoC, and icann agree that COM and NET are a public trust, or that verisign is just a caretaker. but, given that this is in some dispute, it again seems that your customers should decide for themselves which side of the dispute they weigh in on. > Microsoft, for example, specifically designed IE to behave in a > particular way when an unregistered domain was entered. Verisigns > wildcard record is explicitly intended to break this detection. The > wildcard only works if software does not treat it as if the domain > wasn't registered even though it is not. then microsoft should act. and if it matters to you then you should act. but this is not sufficient justification to warrant a demand by you of your customers that they install a patch (what if they don't run bind?) or that they configure delegation-only for particular tld's (which ones and why not others?) > Verisign has created a business out of fooling software through > failure to return a 'no such domain' indication when there is no such > domain, in breach of their public trust. As much as Verisign was > obligated not to do this, others are obligated not to propogate the > breakage. ISPs operate DNS servers for their customers just as > Verisign operates the COM and NET domains for the public. the obligations you're speaking of are much less clear than you're saying.

6 6