- Test - lists.nanog.org

DNS Hijacking by Cox
by Andrew Matthews 26 Jul '07

26 Jul '07

It looks like cox is hijacking dns for irc servers. bash2-2.05b$ nslookup > server 68.6.16.30 Default server: 68.6.16.30 Address: 68.6.16.30#53 > irc.vel.net Server: 68.6.16.30 Address: 68.6.16.30#53 Name: irc.vel.net Address: 70.168.71.144 > server ns1.vel.net Default server: ns1.vel.net Address: 207.182.224.10#53 > irc.vel.net Server: ns1.vel.net Address: 207.182.224.10#53 Name: irc.vel.net Address: 64.161.255.2 it looks like they are using it to clean drones, when you connect to their fake irc server you get forced joined into a channel. #martian_ [INFO] Channel view for "#martian_" opened. -->| YOU (andrew.m) have joined #martian_ =-= Mode #martian_ +nt by localhost.localdomain =-= Topic for #martian_ is ".bot.remove" =-= Topic for #martian_ was set by Marvin_ on Sunday, July 22, 2007 2:55:02 PM =-= Topic for #martian_ is ".remove" =-= Topic for #martian_ was set by Marvin_ on Sunday, July 22, 2007 2:55:02 PM =-= Topic for #martian_ is ".uninstall" =-= Topic for #martian_ was set by Marvin_ on Sunday, July 22, 2007 2:55:02 PM =-= Topic for #martian_ is "!bot.remove" =-= Topic for #martian_ was set by Marvin_ on Sunday, July 22, 2007 2:55:02 PM =-= Topic for #martian_ is "!remove" =-= Topic for #martian_ was set by Marvin_ on Sunday, July 22, 2007 2:55:02 PM =-= Topic for #martian_ is "!uninstall" =-= Topic for #martian_ was set by Marvin_ on Sunday, July 22, 2007 2:55:02 PM <Marvin_> .bot.remove <Marvin_> .remove <Marvin_> .uninstall <Marvin_> !bot.remove <Marvin_> !remove isn't there a law against hijacking dns? What can i do to persue this?

33 111

AS209 peering contact
by Lasher, Donn 26 Jul '07

26 Jul '07

Unable to find peering contact information for AS209 Qwest. Any off-list help would be appreciated. Thank you -donn

1 0

Re: Why do we use facilities with EPO's?
by George William Herbert 26 Jul '07

26 Jul '07

Barry wrote: >I worked three years with the boston fire dept, albeit quite a few >years ago, and rode into many fires and don't generally remember them >being much concerned about hitting *anything* with a high-pressure >stream of water if it's on fire. > >Remember all those rules you know about not using water on electrical >or chemical fires? Doesn't really count if you have charged fire hoses >and know what you're doing except in some special circumstances (they >did foam things occasionally, very occasionally, foam costs money!) Around here (Silli Valley) the firefighters I know are pretty aware of the risks of electricity. They say that some of them have been fried by UPSes. And hazmat; we have the large containers of WMD-grade-toxic silicon fab gases being shipped around. -george william herbert gherbert(a)retro.com

1 0

RE: Level3 / Qwest routing issues earlier today?
by David Hubbard 26 Jul '07

26 Jul '07

From: Chris Riling > > Hi Guys, > > Was anyone else seeing anything weird going on today? I > have an OC-3 to Qwest, and another OC-3 to Level3, (among 2 > others to different providers) and when all was well, I was > receiving a little over 221,000 prefixes from L3. Then, > intermittently I would start losing prefixes from L3 and it > would get down to a little over 220,000. When this happened, > I noticed I was having intermittent connectivity issues > (atleast to one IP I was trying to get to). Doing a > traceroute during the "outage" the packets would hit Qwest's > network, then L3's, then drop, or sometimes not. I have since > admin downed my BGP peer to L3 and everything has > stabilized, but I was wondering if anyone else saw anything going on? I think there was something going on between Qwest and L3, I saw the same thing with traffic coming from a network I have equipment on which is connected with Qwest and tracing to our home AS which has L3 amongst others. I set a community for L3 to not advertise my prefixes to Qwest to get around it. It appears back to normal now though, I just tested. Dave

1 0

Level3 / Qwest routing issues earlier today?
by Chris Riling 26 Jul '07

26 Jul '07

Hi Guys, Was anyone else seeing anything weird going on today? I have an OC-3 to Qwest, and another OC-3 to Level3, (among 2 others to different providers) and when all was well, I was receiving a little over 221,000 prefixes from L3. Then, intermittently I would start losing prefixes from L3 and it would get down to a little over 220,000. When this happened, I noticed I was having intermittent connectivity issues (atleast to one IP I was trying to get to). Doing a traceroute during the "outage" the packets would hit Qwest's network, then L3's, then drop, or sometimes not. I have since admin downed my BGP peer to L3 and everything has stabilized, but I was wondering if anyone else saw anything going on? Thanks, Chris

1 0

Re: An Internet IPv6 Transition Plan
by James R. Cutler 26 Jul '07

26 Jul '07

Cost of operating v4/v6 combined for some time includes, among other things: 1. Help Desk calls resulting from confused customers wanting configuration help. 2. Memory for Routing Information for IPv4 plus IPv6. 3. Help Desk calls resulting from errors by confused engineers trying to work both protocols on too many devices. 4. Cost of documentation and training for Help Desk personnel. 5. Cost of "Linksys WRT54G-IP6" or equivalent because of increased memory and programming requirements. 6. Cost of software maintenance for network core router software -- didn't we just go through getting rid of DECnet, SNA, IPX/SPX, and AppleTalk because of this, among other reasons?? 7. Marketing cost of being perceived as "obsolete". 8. Opportunity cost due to more complex delivery configurations slowing down sales. 9. Cost of "IP Naming and Addressing Management" due to multiple protocol complexity -- didn't we just go through getting rid of DECnet, SNA, IPX/SPX, and AppleTalk because of this, among other reasons?? Of course, this is just a smattering. Note also that, although hardware costs for the router core are driven primarily by speed and port count, memory costs can be substantial. At 7/24/2007 11:50 AM -0400, Chad Oleary wrote: <snip/> However, what I'm trying to understand is why the motivation to rapidly go from v4 to v6 only? What are the factors I'm missing in operating v4/v6 combined for some time? Chad - James R. Cutler james.cutler(a)consultant.com

3 2

Re: An Internet IPv6 Transition Plan
by Robert Boyle 26 Jul '07

26 Jul '07

At 01:22 PM 7/26/2007, you wrote: Let us not forget that network vendors are now capitalising on the requirement to purchase expensive licensing for such features as native IPv6 routing and 6PE, on their mid to high end kit. >I dont feel this sort of behaviour is helpful, I can understand >asking for licensing fees for L2VPN/L3VPN technologies since these >are products that service providers can levvy a reasonable charge >for, but to charge for IPv6 routing capability alone, at the time >where the discussion of which has never been so serious, leaves a >bit of a bad taste in one's mouth. This is one reason we moved to the Foundry XMR. Their purchase price includes all features such as ISIS, BGP, MPLS, IPv6, etc. Since other vendors charge too much (imho) for licensing, some projects like MPLS enabling a network or moving to IPv6 will not happen right away. New services will not be added which will not lead to new gear being purchased to help keep up with the growth of new services. If a few engineers want to play with some features or add a new service for a single client or two as a trial, but it is a multi-million dollar exercise in licensing, it won't happen until there is a business case and by then you are following the herd and not leading it. By that time your people are 2-3 years behind their peers in learning how to implement and support the new technology and you've lost potential clients and services too. Just my $.02. -R Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211 "Well done is better than well said." - Benjamin Franklin

1 0

TWTC issue with Foundry routers?
by David Hubbard 26 Jul '07

26 Jul '07

Anyone know of any changes that were made with TWTC (AS 4323) last night that may have affected those running Foundry routers? We peer with a number of providers and last night our TWTC connection went down with: Jul 25 15:57:22:N:BGP Peer 1.2.3.49 DOWN (Attribute Flags Error) Jul 25 15:57:14:N:BGP Peer 1.2.3.49 UP (ESTABLISHED) If I debug updates on that session I get: (Lines added for readability) Jul 25 15:57:21 BGP: 1.2.3.49 rcv UPDATE 142.166.102.0/24 Jul 25 15:57:21 BGP: 1.2.3.49 rcv UPDATE w/attr: Origin=IGP AS_PATH=AS_SEQ(2) 4323 8881 8881 8881 30915 NextHop=1.2.3.49 COMMUNITY=4323:51 4323:501 4323:1003 4323:2001 4323:2503 4323:34510 4323:50000 65101:1003 65102:4 65103:1 65104:301 Jul 25 15:57:21 BGP: 1.2.3.49 rcv UPDATE 193.27.220.0/23 Jul 25 15:57:21 BGP: 1.2.3.49 rcv UPDATE w/attr: Origin=IGP AS_PATH=AS_SEQ(2) 4323 2828 19092 14188 14188 14188 14188 14188 NextHop=1.2.3.49 COMMUNITY=4323:51 4323:501 4323:1015 4323:2503 4323:36410 4323:50000 65101:1015 65102:4 65103:1 65104:301 Jul 25 15:57:21 BGP: 1.2.3.49 rcv UPDATE 64.13.0.0/22 Jul 25 15:57:21 BGP: 1.2.3.49 rcv invalid COMMUNITY attribute flag d0 Jul 25 15:57:21 BGP: 1.2.3.49 rcv UPDATE w/attr: Origin=IGP AS_PATH=AS_SEQ(2) 4323 12956 3352 NextHop=1.2.3.49 ATOMIC_AGGREGATE AGGREGATOR AS=3352 Speaker=81.46.63.133 The router is a Foundry NetIron 400 running their 7.8 code. We have two of these talking to Level 3, TWTC, Cogent, Uunet and AT&T and only the TWTC had an issue. They sent me a default route instead of full routes and the session came up and was stable; go back to full routes and error. They admitted to me this afternoon that three other customers are having the same issue. That's when we started wondering if they changed something that the Foundry code doesn't like. Interesting though is that they claim to not be sending me communities while the output above indicates they are. Any ideas; be nice to get the link back up. :-) Thanks, David

3 2

Re: San Francisco Power Outage
by George William Herbert 26 Jul '07

26 Jul '07

Seth wrote: >Jonathan Lassoff wrote: >> >> Just a heads up to anyone on list that PG&E has just sustained a large >> outage in San Francisco that has caused a few hiccups (both network, >> electrical, infrastructural, etc.) around the city. >> >> I've confirmed that both customers in 365 Main and parts of telecom 1 >> have both sustained brief blackouts. No word yet form 200 Paul. >> >> Anyone in the area that could use a hand with anything, I'll probably >> be wrapping up fixes for my stuff soon, and would be glad to help >> however I can. > >I have a question: does anyone seriously accept "oh, power trouble" as a >reason your servers went offline? Where's the generators? UPS? Testing >said combination of UPS and generators? What if it was important? I >honestly find it hard to believe anyone runs a facility like that and >people actually *pay* for it. > >If you do accept this is a good reason for failure, why? Unfortunate real-world lesson: there is a functional difference between pushing the UPS test cutover button, and some of the stuff that can happen out on the power lines (including rapid voltage swings, harmonics, etc). I know 365 Main has the equipment and tests it, I've been standing outside when the generators spool up. I've had generator firmware upgrades generate reporting info on the serial uplink that flipped the UPSes into permanent error state until the Liebert guys got off the plane with the replacement mainboard. I've had grid voltage fluctuations that toasted VSDs in chillers. I watched a building's electrical service go "pop" when a transformer blew and ran 10kv into the 220 mains for a fraction of a second as it arced. I was at home but called in after a 5 MW generator popped under a sufficiently badly harmonic UPS and PDU load of only about 2.4 MW. I had a client who forgot to wire the A/C into the UPS, and nearly melted a whole server room. And the stories that the power guy I'm working with tells about foreign facilities, particularly in middle east war zones, are really scary... We fundamentally do not have the facilities problem completely nailed down to the point that things will never drop. Level 4 datacenters can, and will, fail. Nothing you can do including just doing 48V DC for everything are truly foolproof solutions. -george williiam herbert gherbert(a)retro.com

4 3

Reliance / Flag telecom buys Yipes - $300m
by Suresh Ramasubramanian 26 Jul '07

26 Jul '07

http://www.thehindubusinessline.com/2007/07/18/stories/2007071850650400.htm -- Suresh Ramasubramanian (ops.lists(a)gmail.com)

1 0