July 2006 - Test - lists.nanog.org

Huawei Routers in the Core
by Kim Onnel 06 Jul '06

06 Jul '06

Hello, We have been looking at Huawei line of routers recently and i was kind of surprised to see they have Core stuff, that are able to handle Gigs of traffic and MPLS, i cant seem to find anyone around that have used any of these, i wonder if anyone here has, i'd love to hear what he/she has to say, positive or negative feedback. Offline messages are welcomed. Thanks, Kim

1 1

re: NANOG Spam?
by Etaoin Shrdlu 05 Jul '06

05 Jul '06

Joe Johnson wrote: > Am I the only one to get this email? Headers say merit.edu sent it. I > have NANOG whitelisted, though, so it came to my mailbox. You do realize that by including the whole email, that anyone who had it blocked, will not have seen your message either. I have multiple spam filtering, and that message was trapped at my first line of defense. Only because I have the habit of grepping From headers, did I see your message... What was funny is that you got a higher score with spamassassin than the original spam did;-) -- No matter how much you want to try and spin it, MySpace is the Paris Hilton of the internet. (http://www.digg.com/users/ArcaneDevice)

1 0

RE: DNS Based Load Balancers
by Joseph Jackson 05 Jul '06

05 Jul '06

What would be a better solution then? -----Original Message----- From: Lincoln Dale [mailto:ltd@interlink.com.au] Sent: Tue Jul 04 18:30:00 2006 To: 'Rodrick Brown'; 'Sam Stickland' Cc: 'Matt Ghali'; 'Patrick W. Gilmore'; nanog(a)merit.edu Subject: RE: DNS Based Load Balancers > As someone who has also deployed GSLB's with hardware applicances I > would also like to know real world problems and issues people are > running into "today" on modern GSLB implementations and not > theoretical ones, as far as I can tell our GSLB deployment was very > straight forward and works flawlessly. GSLB based on DNS have one significant shortcoming that moone here has yet mentioned: they are performing their magic on the location of the _nameserver_ that issued the query. this can be VERY different to that of the ACTUAL location of the client. for example, Akamai always sends to off to a serverfarm in Northern California, because that's where my DNS query is originating from. that is almost the exact opposite side of the planet from where I'm coming from....... irony is that there is an akamai cluster about 10 feet away from where my [subsequent] http requests originate from... sure - perhaps this isn't the norm - split-tunnel VPNs being what they are - but it's a perfect example of why GSLB based on DNS ain't perfect. cheers, lincoln.

6 5

Wanna hold a brick on your dick? Try our Soft Cialis Tabs. (Warning: don�t try it).
by nanog＠enterzone.net 05 Jul '06

05 Jul '06

2 1

Fanless x86 Server Recommendations
by Ray Van Dolson 05 Jul '06

05 Jul '06

We're looking to acquire a couple small servers that can act as routers for us at remote locations. To minimize hardware issues, I'd love to get something that has no fans, can still run a fairly decent processor and preferably no hard drive (easy with an IDE CF adapter). It would need a couple PCI slots for quad port ethernet cards and a fairly robust tolerance to temperature variations. I like what I see at Advantech -- anyone have any testimonies as to what they've had success/problems with? Ray

11 14

RE: DNS Based Load Balancers
by Brandon Butterworth 05 Jul '06

05 Jul '06

> GSLB based on DNS have one significant shortcoming that moone here has yet > mentioned: they are performing their magic on the location of the > _nameserver_ that issued the query. > > this can be VERY different to that of the ACTUAL location of the client. Systems that infer stuff make errors, at least DNS GSLB fails working I've seen problems with DRM that assumed the IP requesting http would be the same as that requesting rtsp, neither of which were the actual client after some ISP caching. > for example, Akamai always sends to off to a serverfarm in Northern > California, because that's where my DNS query is originating from. > > that is almost the exact opposite side of the planet from where I'm coming > from....... That's more a failure of your systems than Akamai, depending on something the other side of the planet for something best done locally > irony is that there is an akamai cluster about 10 feet away from where my > [subsequent] http requests originate from... yes, like a free ride when you've already paid I don't see any point arguing over DNS GSLB. It exists, it can work, and no surprise some products aren't well designed. We've used a DNS GSLB system since 1997, it does the job we designed it to, it has the edge cases we expected, we're happy with it. Don't try using one without adult supervision The hardware SLB products we've tried have caused more down time than our DNS LB brandon

1 0

IP failover/migration question.
by Andrew Warfield 05 Jul '06

05 Jul '06

I've got a bit of a network reconfiguration question that I'm wondering if anyone on NANOG might be able to provide a bit of advice on: I'm working on a project to provide failover of entire cluster-based (and so multi-host) applications to a geographically distinct backup site. The general idea is that as one datacentre burns down, a live service may be moved over to an alternate site without any interruption to clients. All of the host-state migration is done using virtual machines and associated magic; I'm trying to get a more clear understanding as to what is involved in terms of moving the IPs, and how fast it can potentially be done. I'm fairly sure that what I would like to do is to arrange what is effectively dual-homing, but with two geographically distinct homes: Assuming that I have an in-service primary site A, and an emergency backup site B, each with a distinct link into a common provider AS, I would configure B's link as redundant into the stub AS for A -- as if the link to B were the redundant link in a (traditional single-site) dual-homing setup. B would additionally host it's own IP range, used for control traffic between the two sites in normal operation. When I desire to migrate hosts to the failover site, B would send a BGP update advertizing that the redundant link should become preferred, and (hopefully) the IGP in the provider AS would seamlessly redirect traffic. Assuming that everything works okay with the virtual machine migration, connections would continue as they were and clients would be unaware of the reconfiguration. Does the routing reconfiguration story here sound plausible? Does anyone have any insight as to how long such a reconfiguration would reasonably take and/or if it is something that I might be able to negotiate a SLA for with a provider if I wanted to actually deploy this sort of redundancy as a service? Is anyone aware of similar high-speed failover schemes in use on the network today? Thoughts appreciated, I hope this is reasonably on-topic for the list. best, a.

12 23

IP Delegations for Forum Spammers and Invalid Whois info
by Mark Foster 05 Jul '06

05 Jul '06

I assume the ongoing problems that forum administrators have with people randomly signing up to forums - even closed ones requiring admin approval for all accounts - for the purpose of spamming their web urls around the place is an old one. I run such a forum and have started implementing /16 level bans to try to slow them down. Obviously not the best solution. The forum in question is phpBB (I know - whos isn't) and i'm yet to have time to actually start digging into whether there are better ways of responding to this issue. (Volume isnt prohibitive - yet.) In the most recent case the IP address space that the website concerned points back to is in the Ukraine and the listed abuse contact is on a domain which is canned due to invalid contact details provided. My question then is - what happens now? The IP address space is essentially 'untraceable' except perhaps through bandwidth-supplier-agreements or somesuch. Shouldn't IP's with similarly invalid contact details be 'suspended' after being given opportunity to provide updated, correct details? The IP range in question is 195.225.176.0 - 195.225.179.255 and a snippet of the whois info provided is as follows: remarks: **************************************** remarks: * Abuse contacts: abuse(a)netcathost.com * remarks: **************************************** person: Vsevolod Stetsinsky address: 01110, Ukraine, Kiev, 20Á, Solomenskaya street. room 206. phone: +38 050 6226676 e-mail: vs(a)netcathost.com nic-hdl: VS1142-RIPE source: RIPE # Filtered Forgive the relative noobishness of the question, but I've not had to deal with this sort of situation before. Should I be forwarding to RIPE?

4 4

Re: ICANN at risk
by Fergie 04 Jul '06

04 Jul '06

Interesting timing, indeed, considering the UK is beginning (again?) to examine alternatives -- and Nominet playing a role there, too: http://technology.guardian.co.uk/news/story/0,,1812343,00.html - ferg -- Tony Finch <dot(a)dotat.at> wrote: The timing is interesting, given that DENIC and Nominet have recently come to an agreement of sorts with ICANN. Tony. -- f.a.n.finch <dot(a)dotat.at> http://dotat.at/ SOUTH FITZROY: NORTHWEST 4 OR 5. SHOWERS. GOOD. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

2 1

Call for Volunteers for Mailing List Administration Panel
by Randy Bush 03 Jul '06

03 Jul '06

There is an opening on the NANOG Mail List Administration Panel. According to the draft charter[1]: "... The NANOG list will be administered and minimally moderated by a panel selected by the Steering Committee." Accordingly, the Steering Committee is soliciting nominations for this open position, from now through 17:00 GMT Thursday, August 13, 2006. ** Procedure ** To volunteer yourself or nominate someone else, please send mail to steering(a)nanog.org with the following information, no later than 17:00 GMT Sunday August 13, 2006. - Your name - Nominee's name (if not you) - Nominee's email address - Nominee's phone number - Nominee's employer - Reasons why you believe the nominee is qualified to serve on the Mail List Panel. We will contact each of the nominees to verify interest and possibly request additional information. Once all nominations have been received, the Steering Committee, in cooperation with the Mailing List Panel, will select the new member from among the nominees. The result will be announced on the nanog-announce mailing list. ** Eligibility ** Anyone actively reading the nanog(a)nanog.org mailing list is eligible. A nominee may not be a member of the NANOG Program Committee or of the NANOG Steering Committee. ** Duties ** Basic duties include reading the mailing list and assisting with keeping things on-topic. The team also deals with abuse issues as they arise. ** Length of term ** The charter does not specify ML Panel member term lengths. Open discussion of this is being led by the NANOG Steering Committee. If you have any questions, please post to the meta-discussion list, nanog-futures(a)nanog.org, or email nanog-admin(a)nanog.org and steering(a)nanog.org. Finally, on behalf of the Mailing List Panel and the Steering Committee, we would like to thank everyone for their help in making NANOG a useful environment for operators. randy for the SC & Chris Malayter, for the MLC

1 0