October 2001 - Test - lists.nanog.org

Re: dns based loadbalancing/failover
by Paul Vixie 07 Oct '01

07 Oct '01

> There obviously is a need for an 'official' method to do global load > balancing using DNS. Ouch! No, there isn't. Not "obvious" to me, that is. > Let's face it, people are doing it now on a not so large scale but that > is rapidly changing because of the introduction of both hardware and > software solutions that (mis)use DNS to overcome it's current limitation. DNS has no current limitation that is relaxed by making it less coherent. People abuse DNS due to limitations in other parts of the TCP/IP stack, but DNS coherency introduces no problems of this kind on its own behalf. > I'm not very interested in the discussion why this behaviour would be > broken. It's for more interesting to talk about improving DNS so that > there will be room for things like load balancing or dynamic DNS. In > such a way that people will not start screaming when they see TTLs of > 30 seconds or non-linear behaviour of load balancers. If your goal is to arrange for global content mirroring, and binding of content clients to whichever content server will give them the best measured performance for any given transaction, then using DNS qualifies for a "you're digging in the wrong place" award. (You won't find what you're looking for but you will make a hell of a mess everyplace else.) Note that if you'd like to debate fine points of DNS, there's a mailing list (namedroppers(a)ops.ietf.org) for it, and that such traffic would be off-topic for this (nanog@) list.

2 1

Re: dns based loadbalancing/failover
by Paul Vixie 07 Oct '01

07 Oct '01

> > or any other criteria, then the name for this is: "broken." > > I suppose you don't do split-horizon DNS, then? Of course I do. With a NAT or firewall box between the different sets of users so that no DNS data can leak between the deviant worldviews.

1 0

Re: dns based loadbalancing/failover
by Paul A Vixie 07 Oct '01

07 Oct '01

> Better tell that to those that have built successful businesses on what > you call "broken." if having a product be "broken" kept folks from making money at it, quite a few companies we can each think of(*) wouldn't exist today. (*) no i'm not going to name names

1 0

Re: dns based loadbalancing/failover
by rs＠seastrom.com 07 Oct '01

07 Oct '01

Paul Vixie <vixie(a)vix.com> writes: > > Hrmm, no, that is called "Akamai", isn't it? :-) > > I wouldn't presume to speak about Akamai's methods. Perhaps Avi's listening. It's reasonable to assume that Akamai is deterministic, and is not dependent on the "Jeopardy Method" (who's-quicker-on-the-buzzer) that Bert Hubert asked in an earlier message. Stating more than that is above my pay grade. If you insist on deploying the Jeopardy Method, please remember to phrase your reply to a DNS query in the form of a question: rs@bifrost [2] % dig @192.148.252.10 19.252.148.192.in-addr.arpa. any ... ;; ANSWER SECTION: 19.252.148.192.in-addr.arpa. 5M IN PTR what.is.dhcp-19.seastrom.com. ... ---Rob

1 0

32 Old Slip
by Sean Donelan 06 Oct '01

06 Oct '01

I'm trying to put together a timeline of events post September 11, and am having a bit of trouble figuring out what happened with 32 Old Slip. There were a several messages about generators not starting, running out of fuel, etc Tuesday evening. If anyone has good first, second or third-hand knowledge about the details, could you send me a note.

1 0

The Cidr Report
by CIDR Report 06 Oct '01

06 Oct '01

This is an auto-generated mail on Fri Oct 5 23:00:01 PDT 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 05Oct01 0) General Status Table History ------------- Date Prefixes 280901 104483 290901 104988 300901 104943 011001 105036 021001 105301 031001 104637 041001 104254 051001 104449 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 11739 Number of ASes announcing only one prefix: 6989 (3974 cidr, 3015 classful) Largest number of cidr routes: 844 announced by AS701 Largest number of classful routes: 1394 announced by AS701 1) Gains by aggregating at the origin AS level --- 05Oct01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1258 958 300 23.8% Telstra Pty Ltd AS4151 302 170 132 43.7% USDA AS16473 201 76 125 62.2% Bell South AS577 307 187 120 39.1% Bell Advanced Communications Inc. AS13999 131 20 111 84.7% Mega Cable S.A. de C.V. AS4293 375 267 108 28.8% Cable & Wireless USA AS2048 215 116 99 46.0% State of Louisiana AS4755 208 131 77 37.0% Videsh Sanchar Nigam Ltd. Autonom AS1239 481 410 71 14.8% Sprint AS3464 163 95 68 41.7% Alabama SuperComputer Network AS12302 98 32 66 67.3% MobiFon S.A. AS11686 192 126 66 34.4% Education Networks of America AS6471 128 63 65 50.8% ENTEL CHILE S.A. AS4200 137 72 65 47.4% Apex Global Information Services, AS17557 124 65 59 47.6% Pakistan Telecom AS16758 63 6 57 90.5% IKON Office Solutions AS209 309 254 55 17.8% Qwest AS306 60 6 54 90.0% National Guard Bureau AS3908 291 238 53 18.2% Supernet, Inc. AS400 137 85 52 38.0% Headquarters Standard Systems Cen AS226 145 93 52 35.9% Los Nettos AS17561 113 62 51 45.1% Internet service provision to Wes AS1 537 486 51 9.5% BBN Planet AS637 106 58 48 45.3% Department of Navy AS4323 246 198 48 19.5% Time Warner Communications, Inc. AS1913 152 104 48 31.6% Defense Logistics Agency AS10620 68 21 47 69.1% TVCABLE BOGOTA AS15290 246 200 46 18.7% AT&T Canada IES AS376 120 76 44 36.7% Reseau Interordinateurs Scientiqu AS5416 51 9 42 82.4% BATELCO-BH For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Summary: SNMPv3 implementations
by RJ Atkinson 06 Oct '01

06 Oct '01

I've received numerous requests for information on which network switch/router systems implement SNMPv3, though my own request was for information on operational deployments of SNMPv3 in networks. Folks interested in an *incomplete* list of implementations with SNMPv3 might want to look at: http://www.ibr.cs.tu-bs.de/ietf/snmpv3/#Implementations A number of network equipment vendors have shipped SNMPv3, but are NOT included from that list. So if SNMPv3 is something you are interested in, ask your vendors directly for more information. Of particular interest is the existence of at least one freely distributable implementation "NetSNMP" (formerly UC Davis SNMP). This works out of the box on most modern UNIX systems, meaning that one can use SNMPv3 on UNIX servers even if the OS vendor didn't include it directly. For more on that implementation, browse the above URL. Ran rja(a)inet.org

2 1

Re: slightly OT : versign complaint department
by beldridg＠best.com 06 Oct '01

06 Oct '01

hi all, an update to my post (i know, bad form). a friend or two has informed me of a few errors. i think, in general, most people don't understand the relationship between the "registry" and the different "registrars." i've asked this person if a FAQ is possible. here is the update: On Sat, 29 Sep 2001 beldridg(a)best.com wrote: > i've been trying to add a pgp key to the verisign/netsol database for > the past two weeks. i've sent four messages, opened three web help > requests, and spent three hours on the phone with their helpdesk. they > know less than their customers about their own procedures and web > documentation for adding keys for PGP guardian auth. i discovered the whole problem is with the verisign _registrar_ and not the _registry_ (i originally thought the registry owned the database of host and contact records and the pgp keyserver). the _registry_ does own the "canonical" host database, but the only way to make changes is through your _registar_. the _registrar_ is responsible for authenticating end users before updating the _registry_ database. after multiple e-mail support questions, 4 key ADD messages and 4 hours of phone calls, i never got another response from the verisign _registrar_. i finally tried adding a PGP key again and it worked. i guess i woke up the mice on the treadmills in the computers at the verisign _registrar_. i guess the only thing i can do is move my one remaining domain record away from the veri$ign _registrar_. of course, they won't refund the unused portion of my $35 even though their customer service is absolutely horrific (so much for a SLA). i recommend that everybody move their money away from the verisign _registrar_ and use any other one - i don't even care which one. :) - brett

1 0

"Virtual" multi-homing providers
by Ng Pheng Siong 05 Oct '01

05 Oct '01

Hello, I'm looking at deploying "POPs" at several IDCs across the globe. Each POP will contain several servers. (At most ten.) I would like each POP to use the same set of IP addresses; connections to these IP addresses will get to the nearest POP by virtue of routing. IOW, I think I'm wanting to have all my POPs belong to one AS, as if said AS multi-homes to each POP/IDC, except that the multi-homing is virtual, because I don't have links from my "enterprise network" to these IDCs. (Well, I don't expect to have much of an enterprise network. ;-) Are there providers of such? Will I be able to get a globally routable IP block for my AS? Or is my best bet to pick one provider which has global presence? (Which such global providers are there? Do people like Exodus or Digital Island count?) TIA for your input. Cheers. -- Ng Pheng Siong <ngps(a)post1.com> * http://www.post1.com/home/ngps

3 2

Seeking clueful salesrep for UUnet/MCI and C&W
by JC Dill 05 Oct '01

05 Oct '01

Thanks for all the VERY helpful replies to my query about the backbone that sucks the least. As a followup, I've been asked to locate clueful sales reps for UUnet, MCI, and C&W. Sales people (and others) from those named organizations are given explicit permission to reply to me directly, and techies are encouraged to contact me with the contact info of any sales rep they trust. I already have contacts for AT&T and Genuity, but still need C&W and UUnet/MCI. This is for a company headquartered near Silicon Valley that needs connectivity at 12 US locations plus London and Tokyo.

1 0