September 2001 - Test - lists.nanog.org

Re: Digex and Akamai are raping the ARIN whois database
by brandon＠rd.bbc.co.uk 04 Sep '01

04 Sep '01

> If anyone has any heuristics for ensuring that lists don't have automated > new-domain or SWIP gleanings, I'd appreciate them Apparently not mailing people unless they gave you their address and said you could is effective. brandon

1 0

RE: Digex and Akamai are raping the ARIN whois database
by Smith, Rick 04 Sep '01

04 Sep '01

Did they leave an 800 # ? :) Nothing like autodial & coffee... -----Original Message----- From: Kai Schlichting [mailto:kai@pac-rim.net] Sent: Tuesday, September 04, 2001 3:39 PM To: nanog(a)merit.edu Cc: abuse(a)digex.com; abuse(a)innovyx.com; postmaster(a)innovyx.com; abuse(a)winstar.net; abuse(a)akamai.net; abuse(a)arin.net; hostmaster(a)arin.net Subject: Digex and Akamai are raping the ARIN whois database Nothing like the smell of spam in the morning - coming to you through the "benevolent" acts of Akamai and Digex - sent to POC handles blatantly stolen from ARIN's whois database. Yo, Digex: this just reminds me how much your "sales team" sucked the last time around, when there was a DS3 contract up for grabs on an RFP. This spam certainly cuts you out of any future consideration for a while: You'll find yourself in good company with Savvis, I am sure.

1 0

Digex and Akamai are raping the ARIN whois database
by Kai Schlichting 04 Sep '01

04 Sep '01

Nothing like the smell of spam in the morning - coming to you through the "benevolent" acts of Akamai and Digex - sent to POC handles blatantly stolen from ARIN's whois database. Yo, Digex: this just reminds me how much your "sales team" sucked the last time around, when there was a DS3 contract up for grabs on an RFP. This spam certainly cuts you out of any future consideration for a while: You'll find yourself in good company with Savvis, I am sure. Sep 4 11:4x:xx host sendmail[14500]: LAA14500: from=<bounces(a)bounce.innovyx.com>, size=10198, class=0, pri=40198, nrcpts=1, msgid=<200109041542.LAA14183@host>, bodytype=8BITMIME, proto=ESMTP, relay=shiner.innovyx.com [63.143.186.194] (may be forged) Sep 4 11:4x:xx host sendmail[14500]: LAA14500: to=<CENSORED@TLD>, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Sent > [censored] > Received-Date: Tue, 4 Sep 2001 11:4x:xx -0400 (EDT) > Received: from shiner.innovyx.com (shiner.innovyx.com [63.143.186.194] (may be forged)) > by [censored].com (8.9.3/8.9.3) with ESMTP id LAA14500 > for <ADDRESS-STOLEN-FROM-ARIN-WHOIS-DB@TLD>; Tue, 4 Sep 2001 11:4x:xx -0400 (EDT) > Received: by shiner.innovyx.com (PowerMTA(TM) v1.0); Tue, 4 Sep 2001 08:4x:xx -0700 (envelope-from <bounces(a)bounce.innovyx.com>) > Date: Tue, 4 Sep 2001 08:41 -0700 > From: digexakamai <digexakamai-[censored](a)m2.innovyx.com> > Reply-to: digexakamai <digexakamai-[censored](a)m2.innovyx.com> > Subject: You're Invited > To: ADDRESS-STOLEN-FROM-ARIN-WHOIS-DB@TLD > MIME-Version: 1.0 > Content-Type: multipart/alternative; boundary="-------=_8418644195" > We're sending you this invitation because we received your e-mail > address from one of our marketing partners. If you'd like to receive > future emails, please click here: > http://edge.akamai.com/redir.asp?[censored]&SubscriberID=[censored] > Not confirming your interest automatically leaves you unsubscribed and > we will not send you future emails. Additionally, each issue you receive > as a subscriber will contain unsubscription instructions. > Digex and Akamai Present: Performance!...a Free seminar on enhancing > your Web site performance. > As the strategic value of Web sites has become a critical factor in > the success of many companies, managing performance has become an > ongoing challenge. Fast response time is not just a feature, it is > a requirement for today's transaction oriented Web sites where real > business is conducted online. > Join two industry leaders for a discussion about: > * Architecting your site for maximum performance > * Enhancing your e-business reach > * Speeding content and application delivery > * Eliminating costly and excessive bandwidth > * Maximizing the return on your investment > When & Where [blah cut] > Digex, the proven leader in managed Web and application hosting > since 1996, offers the most comprehensive portfolio of hosting > products and services designed to enhance the performance of your > mission-critical Web operations. Akamai, the leading provider > of distributed application and content delivery services, gives > businesses a distinct competitive advantage by providing the > technology to optimize your customers' Web experience. > If you'd like to receive future Akamai emails, please click here: > http://edge.akamai.com/redir.asp?[censored]&SubscriberID=[censored]

1 0

Standard naming scheme, or lookup system
by Roy Hockett 04 Sep '01

04 Sep '01

Is there a standard naming convention for troubleshooting tools like looking glass servers? Thanks, -Roy -- /********************************************************************/ /* Roy Hockett * Telephone: (734) 763-7325 */ /* Network Engineer, * FAX: (734) 763-2180 */ /* ITD, * Internet: royboy(a)umich.edu */ /* University of Michigan * */ /********************************************************************/

2 1

RE: Is anyone using GILAT's "Spacenet" service
by Dennis Hartmann 03 Sep '01

03 Sep '01

Oops! The link is as follows: http://www.starbandusers.com/performance.htm Keep in mind that this information is based on the 180 system. The 360 system is out and some of this information may have changed (web caching, etc.). The new 360 system has an Ethernet port which is a great improvement over the USB port that the 180 system came with. The beta systems started out as 2 PCI cards. Sincerely, Dennis J. Hartmann White Pine Consulting Global Knowledge-MPLS Course Director http://www.globalknowledge.com/training/course.asp?PageID=9&courseid=1571 dennisjhartmann(a)hotmail.com AOL IM: dennisjhartmann -----Original Message----- From: Simon Lyall [mailto:simon.lyall@ihug.co.nz] Sent: Saturday, September 01, 2001 12:40 AM To: Dennis Hartmann Subject: RE: Is anyone using GILAT's "Spacenet" service On Fri, 31 Aug 2001, Dennis Hartmann wrote: > Is Spacenet one of their business satellite services? I'm a user of the > Starband service and I get pretty good speeds and feeds on the satellite, > although telnet is a drag. Starband uses a page accelerator technology that > greatly increases performance. The following link has a good technical > explanation of the HPA host page acceleration and the RPA remote page > acceleration. What link? The one in you signature is a MPLS course. Simon. -- Simon Lyall. | Newsmaster | Work: simon.lyall(a)ihug.co.nz Senior Network/System Admin | Postmaster | Home: simon(a)darkmere.gen.nz ihug, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz

2 1

Re: multi-homing fixes
by Paul A Vixie 02 Sep '01

02 Sep '01

> Understand [1] well, but not [2]. Care to elaborate? > > I'd have thought there were trivial counterexamples (i.e. when > it 'is so'), f'rinstance when one path has both huge delay and > large packet loss. sorry. yes, it's possible to construct a scenario which makes udp seem like a fine predictor of tcp performance. necessary constraints for the experiment include the number of simultaneous tcp sessions going over the probed path, and also the average and maximum size of the sessions, and so on. but for observed traffic over observed paths, neither measured DNS RTT nor anycast DV show any similarity to the "time to last byte" of any known TCP implementation, especially not the bad (and dominant) ones. the example we used back at vayu was to compare a 56K serial link to a 1Gb/s satellite link. anycast DNS says that one of them is better. TCP says that the other is better, but only if the file is larger than 16KB. "you pick." (i'm trying to decide whether vayu is dead enough that it would be safe to publish any of the whitepapers we did on this general topic.)

1 0

Re: multi-homing fixes
by Paul Vixie 02 Sep '01

02 Sep '01

pete(a)kruckenberg.com (Pete Kruckenberg) writes: > ... Customers pay for the network to work end-to-end. More choices mean > better performance, more reliability. ... Not necessarily. Sure, the potential is there. But more than half the time in my experience of multihoming, the pessimal path is chosen. This includes a lot of anycast DNS experiences where each DNS server gives its own close-by mirror server's address as an answer to www.$FOO.com, thus using UDP performance into a predictor of TCP performance. Not only ain't it nec'ily so, it is nec'ily not so. The trivial case of multihoming is inside a campus where a file server, say, might be connected to more than one LAN. Unless you're very careful, your clients will end up talking to the file server through a gateway, that is, to some connection that it has to some LAN other than the client's LAN. This pessimality scales amazingly well to the larger Internet. Don't leave Murphy's Law out of your reliability calculations. More choices can simply mean more points of failure or more opportunities to make bad choices. -- Paul Vixie <vixie(a)eng.paix.net> President, PAIX.Net Inc. (MFNX.O)

2 1

RE: multi-homing fixes
by Roeland Meyer 01 Sep '01

01 Sep '01

|> From: Randy Bush [mailto:randy@psg.com] |> Sent: Monday, August 27, 2001 4:58 PM |> |> >>> The whole problem seems to me to be a lack of a |> micro-allocation policy, |> >>> and an agreement from providers that they will not |> filter that space. |> >> judicious use of this might be helpful. the problem is |> the 'judge' in |> >> judicious. |> > indeed. but it would still disassociate the space conservation and |> > table growth problems to some extent; the "judge" being the same |> > as today. |> |> ahhh, somebody understood the comment. |> |> the problem is that there is no obvious detent on the knob. |> to start the |> usual posturing and flamage, i propose min 2xDS3 multihomed. I would sincerely like to know why not 2xDS1 multi-homed. Most businesses can't cost-justify dual DS3's and many (UNited Airlines) gate their entire company through a T1 (not counting the ecommerce stuff, which is colo'd as it should be).

14 20

Re: multi-homing fixes
by smd＠clock.org 01 Sep '01

01 Sep '01

| > I'm pretty sure I need further explanation to "get it"./ I probably still don't get it, but let me see if I understand the mechanism. First, assign a prefix to a particular non-topological "locus", such as a metropolitan area, or a continent. Second, networks inside that locus will announce only the prefix, but with these exception bits. [Implied, but not stated: third, all these networks will exchange full information so as to be able to generate these exception bits]. Fourth, receivers of these prefixes, with the exception bits, will expand the longest-match trie (a Patricia tree is a compact representation of a trie, in common use when you have data with many nodes with just one child) so that lookups will only match in the case where there is no exception. If I understand you, what you are trying to do is to reduce the requirement for EVERY network operating within the aggregate to carry traffic to the ENTIRE aggregate at all times. This ordinarily would require announcing more specifics. So you propose a scheme where you use an attribute instead of the more specifics. Unfortunately, your attribute will cause the same behaviour in a receiver as would the list of more specifics, and therefore is merely a compression of the representation on the line that is somewhat better than, say, gzip. IOW, I think you are solving the wrong problem. We really have nearly zero experience with aggregates containing disjoint topology (i.e., non-provieder-based aggregation), largely because there is no obvious way to contain an explosion of more specifics when complete internal connectivity and complete transit break down. Steve Deering does propose a (partial) solution for this, but (in my opinion) it involves a complete reversal of current financial arrangements to work, in that a sender would have to compensate a transit network for carrying its traffic to anything within that aggregate, rather than the transit network collecting from the other (or both) parties. This is only a partial solution, since even where there is an incentive to maintain complete interconnectivity and carry traffic to all the consitituent subnets of the aggregate, failures will still cause black holes to arise even though other valid paths exist. Your scheme does let one warn of black holes in this eventuality, takes a bit less bandwith on the line, probably allows for the "slosh" to happen all at once rather than in dribs and drabs, and so forth, but it represents the same amount of work for the routers processing the attribute. That is, those routers are effectively brought inside the abstraction boundary of the "locus", and as a result the goal of hiding information from those routers is not met. My gut feeling is that for any sizable "locus", almost all of what we consider the core of the global routing system would be contained within the new abstraction boundary, so we're no better off than not aggregating in the first place. That is, we are MUCH better off with PA addressing. Sean.

5 8

RE: multi-homing fixes
by Martin, Christian 01 Sep '01

01 Sep '01

> but this is not really necessary either, if you use an IGP. (But some > networks use iBGP rather than an IGP to carry customer routes > internally.) I think it is more than 'some.' Carrying anything in your IGP aside from the links that make up the network and the nodes themselves presents several scaling issues, IMHO. --chris >

1 0