Re: Can P2P applications learn to play fair on networks?
Sean Donelan wrote: So what about the other 490 people on the node expecting it to work? Do you tell them sorry, but 10 of your neighbors are using badly behaved applications so everything you are trying to use it for is having problems. Maybe Comcast should fix their broken network architecture if 10 users sending their own data using TCP (or something else with TCP-like congestion control) can break the 490 other people on a node. Or get on their vendor to fix it, if they can't. If that means traffic shaping at the CPE or very near the customer, then perhaps that's what it means, but installing a 3rd-party box that sniffs away and then sends forged RSTs in order to live up to its advertised claims is clearly at the wrong end of the spectrum of possible solutions. Maybe Comcast should just tell the other 490 neighbors the 10 names and addresses of poorly behaved P2P users and let the neighhood solve the problem. Maybe Comcast's behavior will cause all 500 neighbors to find an ISP that isn't broken. We can only hope. Is it reasonable for your filesharing of your family photos and video clips to cause problems for all the other users of the network? Is that fair or just greedy? It isn't fair or greedy, it is a bug that it does so. Greedy would be if you were using a non-congestion-controlled protocol like most naive RTP-based VoIP apps do. Matthew Kaufman [EMAIL PROTECTED]
Re: what the heck do i do now?
Brian Wallingford wrote: ... Considering the time passed since maps went defunct, Paul is entirely justified in doing whatever is necessary to cluebat the offending networks, imho. That's my opinion too. But I do have some domain name server addresses that get a lot of traffic due to historical misconfiguration by people who are likely too clueless to adjust it properly. And I tried some interesting experiments around providing wrong wildcard answers to queries that were received. And then, after getting some nasty complaints (including threats of legal action) from people who, for instance, didn't like that whenever their PC tried to use me as a resolver, they couldn't get to their favorite web sites any more and who weren't interested in removing me from their resolver list... I talked to my lawyer. And while I am not a lawyer, I can tell you that my lawyer pointed out several interesting legal theories under which I could have some serious liability, and so I don't do that any more. (As an example, consider what happens *to you* if a hospital stops getting emailed results back from their outside laboratory service because their email firewall is checking your server, and someone dies as a result of the delay) So while I think you'd be justified in doing it, I think you'd find that 1) lots of people wouldn't change their configs at all, and 2) you might find that your liability insurance doesn't cover deliberate acts. Matthew Kaufman [EMAIL PROTECTED]
RE: Sitefinder II, the sequel...
Joe Greco: I don't really think it is entirely appropriate that a child who is looking for information on the White House could land somewhere obscene through entering a web address that appears obvious and logical. Personally, I don't really think it is entirely appropriate that a child who is looking for obscentiy could land on the White House site inadvertantly. Matthew Kaufman [EMAIL PROTECTED]
RE: BGP Security and PKI Hierarchies
Michael Dillon: Do you suppose that if a Microsoft salesman had given me a free copy of Windows back in 1990, I would have a right to use any version of Windows for free forever? Any version? No. That version, particularly its fixed representation as an unchanged string of binary digits? Probably, but maybe not.. But that's because Microsoft can copyright long strings of binary digits as software and sell you a restricted license to use it. Note that small integers, unlike software, aren't easy to copyright, trademark, or own in any of the other traditional senses. Back in the early 1990s, I proposed to number my machines that I planned to attach to the Internet with small integers chosen from a small range. Conveniently, at the time, there was an organization that helped, at no charge to the end users, to make sure that no two people chose the same numbers, and so I allowed them to help make sure there was no conflict. Since that time, I've arranged to have those numbers listed in one or more BGP announcements on the global Internet. And, over that time, nobody else that I've noticed has also tried to use and announce the same numbers... I suppose if that sort of thing happened a lot, the Internet would be much less stable and useful (and filled with lawyers, no doubt, arguing over their proposed solutions to the problem), so it is nice that nobody has chosen to do so. If there ever comes a time when there's an actual shortage of unique numbers that are routable, I suspect things will get more Interesting. Matthew Kaufman [EMAIL PROTECTED]
RE: (What If?) ccTLD Delegation Question
Joe Johnson: Call it Monday Boredom, if you will, but a funny DNS question just popped into my head: if I were to, say, win the lotto and buy my own Island (which, of course, would technically be its own country) Premise false. Parsing of question terminated. All islands you might buy are parts of existing countries (with existing country codes) A better plan might be to incite a country-dividing civil war somewhere, and fund it sufficiently with your lottery winnings that a new independent country is formed in the aftermath. You might not want to live there during the process, though. Matthew Kaufman [EMAIL PROTECTED]
RE: Katrina could inundate New Orleans
Dave Stewart: Y'know... I do have to wonder whether Internet access is nearly as important as power and communications (traditional comms, such as the PTSN). Granted, it'll be interesting to see how things shake out - but I just can't buy that getting the Internet working should/will be a really high priority. Back when I was running ISPs, we had several county and city Emergency Operations Centers as customers... Either on T1 or frame relay for their primary service, or as their backup dial-on-demand ISDN provider. These connections were how the EOC got river gauge data for planning flood evacuations (at the time, no other source other than having the numbers read off from the state-level agency office over the phone if they weren't too busy), USGS earthquake epicenter (also available over EDIS) and shake map (Internet only) data, weather service radar and satellite images (backup was TV broadcasts, if still on the air), and in some counties, the only access to the hospital emergency room status tracking system used for multi-casualty incidents... While there's more private data networks online now, there's also more Internet-available data that the EOCs would like to have access to, I'm sure (I know that some cities are using Internet-connected webcams to do security monitoring, look at shorelines, etc.) In many incident scenarios (and a few actual incidents), the priority was that the radio system stayed up, then Internet access, *then* PSTN (and having cellphone access to people in the field to supplement the radio system was more important than landline calls to anywhere else). And power, of course, is easily generated locally, so not a big priority at all. Interestingly, almost none of the agencies told sales what the connection was going to be used for... Only when engineering made a followup inquiry would we learn that, yes, in an emergency, they'd like theirs fixed first please, and yes, they'd need first dibs on the backup power if we didn't have enough to run everything. Matthew Kaufman [EMAIL PROTECTED]
RE: outage/maintenance window opinion
My opinion: For the customer, the outage starts when their service stops working* and ends when their service starts working again. Your goal should be to make that all happen during the maintenance window. If it doesn't, then the part that was during the window is planned outage and the part that wasn't is unplanned outage. Good ISPs have good explanations for, and sometimes even monetary credit, for unplanned outages. Planned outages can simply be explained by pointing at the announced maintenance interval policy. Matthew Kaufman [EMAIL PROTECTED] *Note that this can be different times for different customers, and stops working means different things to different people... Some customers are unhappy if their traffic is taking the slightly longer alternate path, others are happy as long as they can reach CNN, even if the rest of the net disappears.
RE: Smallest Transit MTU
David Schwartz: IMO, it's negligent to configure a firewall to pass traffic whose meaning is not known. I see. Can you suggest a firewall that supports block all traffic not unencrypted and in American English? That'd probably stop the kids who insist on substituting numbers for letters, at the very least. Matthew Kaufman [EMAIL PROTECTED] Ps. For my overseas deployments, I'll need some other languages supported as well.
RE: APNIC Privacy of customer assignment records - implementation update
Ok, I'll bite... I find the idea that an ISP must publish customer information offensive. There is no reason why a guy who wants to get a T-1 into his house and a /24 to support all the stuff he's doing at home should be forced to publish his full name and home address to the world (or worse, should have that information published to the world by his ISP without his knowledge). Didn't we already have this discussion back when it was about static /32s, /29s, and the like? And didn't those people get to keep their privacy? You can always track down the actual registrant and talk to them if you have a problem, and as has already been pointed out, they're a lot more likely to respond than the person listed in the assignment record. Believing that the spam problem would be solved if only the source IP addresses of the spam could be tracked to a physical address is a fallacy anyway. Matthew Kaufman [EMAIL PROTECTED] Ps. The legitimate business reason of trying to keep your customer list private so your competitors don't spend all day calling your customers should apply too, but I'm a lot less worried about that than the simple privacy issues for the end users.
RE: APNIC Privacy of customer assignment records - implementation update
The truth is, it doesn't even need to be a case of grandma listed in the whois (though that is a legitimate issue these days). If as an ISP, I list Bob's Flower Market (which has a DSL line and IP addresses for every cash register and order-fulfillment machine) in whois, all that does is: A) Cause Bob's Flower Market to get spam at the address harvested from whois, and B) Cause people who have issues with virus-infected machines to call Bob (who doesn't know jack about viruses) instead of calling me (I can remotely shut him off until I can drive over there with a CD full of anti-virus software), and C) Gives my competition Bob's name and phone number, so they can try to sell him their DSL service instead. (Imagine the response if you asked any other local business to post their complete customer list, with the names and unlisted phone numbers of buyers, on the front door) What it does NOT do is: 1) Reduce the amount of virus traffic accountable to Bob (might make it worse, if people call him instead of me), or 2) Reduce the amount of spam in the world (probably increases it, at least from Bob's point of view), or 3) Make the world a better place to live (there's much better avenues to pursue if that's your goal) Matthew Kaufman [EMAIL PROTECTED]
RE: Current street prices for US Internet Transit
Mikael Abrahamsson: Well, with the GSR (and alike) you're paying for high MTBF, large buffers and quick re-routing when something happens, so yes, this is a quality issue and that's why you should care and make an informed decision. For some of us large buffers is exactly what we don't want. Actually, for most of us, but most people haven't figured that out yet. Matthew Kaufman [EMAIL PROTECTED]
RE: Current street prices for US Internet Transit
Mikael Abrahamsson: Well, with the GSR (and alike) you're paying for high MTBF, large buffers and quick re-routing when something happens, so yes, this is a quality issue and that's why you should care and make an informed decision. For some of us large buffers is exactly what we don't want. Actually, for most of us, but most people haven't figured that out yet. Matthew Kaufman [EMAIL PROTECTED]
RE: Open Source BGP Route Optimization?
So you never run any production code that was compiled with gcc? And, let me guess, your web servers all run IIS? Matthew Kaufman [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Drew Weaver Sent: Tuesday, May 25, 2004 1:22 PM To: 'Noel Montales'; [EMAIL PROTECTED] Subject: RE: Open Source BGP Route Optimization? Not sure I'd trust something that was truly open source to handle something so important. But I guess I trust nagios for my service availability so shame on me ;-) -Drew
does your ISP need more peering?
A nationwide ISP I work with has decided to switch to all-transit, no-peering. They are interested in finding someone to buy or take over: an AS number, routers (and in some cases rack space) at MAE ATM East, PAIX Virginia, NYIIX, AADS NAP, MAE ATM West, and PAIX Palo Alto, along with the existing peering that is up at those (close to 200 BGP sessions total). If you're interested, please contact me directly and I will forward your inquiry in the correct direction. Note that my mailbox is protected by TMDA. Matthew Kaufman [EMAIL PROTECTED] ps. Please also direct flames about this being non-operational content directly to me as well... there's just not a lot of lists where names of NAPs and the concept of existing peers makes sense to anyone.
RE: MS is vulnerable
This MS v Unix debate is a very interesting discussion. To some of you. To others of us, it is a long-dead horse. However, I'd like to take a moment to inject my observations. I'd like the NANOG list to be restricted to Network Operations issues, or at the very least, Network Operations plus the politics and ranting thereof. Matthew Kaufman [EMAIL PROTECTED]
RE: more on filtering
Tell that to Cisco, Nortel, and any other vendor that can handle huge rates of traffic that conform to typical but, when the pattern of addresses (or options) in the packets cause the flow cache to thrash, die under loads far below line rate. (See Cisco's http://www.cisco.com/warp/public/63/ts_codred_worm.shtml as an example) Tell that to any router, switch, or end system vendor who recently found out what happened when a worm forces near-simultaneous arp requests for every possible address on a subnet. I'm afraid that those of us building actual networks are forced to do so using actual hardware that actually exists today, and using actual hardware that was actually purchased several years ago and which cannot be forklifted out. You call the network obviously broken, I call it the only one that can be built today. Matthew Kaufman [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Maxwell Sent: Thursday, October 30, 2003 7:48 PM To: Chris Parker Cc: Alex Yuriev; [EMAIL PROTECTED] Subject: Re: more on filtering On Thu, 30 Oct 2003, Chris Parker wrote: The source of the problem of bad packets is where they ingress to my network. I disconnect the flow of bad packets thorugh filtering. What is the difference, other than I do not remove an entire interconnect, only the portion of packets that is affecting my ability to provide services? If the *content* of the packets is breaking your network: Your network is obviously broken.
RE: more on filtering
It's interesting that many rather sizable networks have weathered these events without relying on filtering, NAT, or other such behavior. What's more interesting is how many big networks have implemented 98-byte ICMP filters, blocks on port 135, and other filters on a temporary basis on one or more (but not all) interfaces, without anyone really noticing that they're doing that. It isn't something that's well-publicized, but I know several major ISPs/NSPs which have had such filters in place, at least briefly, on either congested edge interfaces or between core and access routers to prevent problems with devices like TNTs and Shastas. Even if you're right, that doesn't make me wrong. True enough. Any IP network conformant to Internet standards should be content transparent. Any network which isn't is broken. Then they're all broken, to one extent or another. Even a piece of wire can be subjected to a denial of service attack that prevents your content from transparently reaching the far end. Breaking under abnormal conditions is unacceptable. I am well aware of reality, but the reality is: some things need to be improved. That some thing need to be improved has been true since the very first day the Internet began operation. Of course, the users of the end systems were somewhat better behaved for the first few years, and managed to resist the temptation to deploy widespread worms until 1988. This isn't some fundamental law of nature causing these limits. We are simply seeing the results of the internet boom valuation of rapid growth and profit over correctness and stability. True. As the purchasers of this equipment we have the power to demand vendors produce products which are not broken. One can demand all one wants. Getting such a product can be nearly or totally impossible, depending on which features you need at the same time. Doing so is our professional duty, settling on workarounds that break communications and fail to actually solve the problems is negligent. But not using the workarounds that one has available in order to keep the network mostly working, and instead standing back and throwing up one's hands and saying well, all the hardware crashed, guess our network is down entirely today is even more negligent. It may also be a salary-reducing move. Suggesting that breaking end-to-endness is a long term solution to these kind of issues is socially irresponsible. Waiting until provably-correct routers are built, and cheap enough to deploy, may be socially irresponsible as well. There's a whole lot of good that has come out of cheap broadband access, and we'd still be waiting if we insisted on bug-free CPE and bug-free aggregation boxes that could handle any traffic pattern thrown at them. Do you actually believe that it was a BAD idea for Cisco to build a router that is more efficient (to the point of being able to handle high-rate interfaces at all) when presented with traffic flows that look like real sessions? Matthew Kaufman [EMAIL PROTECTED]
RE: [arin-announce] IPv4 Address Space (fwd)
I remember GM saying something like that about this car that put Nader on political arena. Are we that dumb that we need to be taught the same lessons? GM seems to still be building cars and trucks, and Nader lost a presidential election. Which lesson were we supposed to learn? Matthew Kaufman [EMAIL PROTECTED]
RE: more on filtering
Well, interestingly, in our network, Juniper makes all of our new core routers. Specifically because Cisco routers were melting down at an unacceptable rate. But there was no such thing as Juniper when we started building (so we still have a lot of Cisco routers in the network), and they don't make DSLAMs or DSL/ATM customer aggregation boxes, so we still get to deal with traffic-dependent performance. And I'm sure we're not the only network in this situation. Should I replace every box in the network with a Juniper and pass the cost along to the customers? (New line item on the bills: we won't filter worm traffic tax) Even if I had an all-Juniper network, I'd still need to decide what to do about DDOS attacks... Do I just call my circuit vendors and keep adding OC48s until the problem goes away? Matthew Kaufman [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Yuriev Sent: Friday, October 31, 2003 6:29 AM To: Matthew Kaufman Cc: 'Greg Maxwell'; 'Chris Parker'; [EMAIL PROTECTED] Subject: RE: more on filtering Do you actually believe that it was a BAD idea for Cisco to build a router that is more efficient (to the point of being able to handle high-rate interfaces at all) when presented with traffic flows that look like real sessions? Why buy something that works well only sometimes (we are very efficient when it looks like 'real' traffic from Cisco) when you can buy (no one told us that we should have issues with some specific packets) Juniper? Alex
MetroPAIX -- 55 Market San Jose
If anyone on the list is connected to PAIX via the MetroPAIX product from 55 Market St. in San Jose, I'd like to hear about your experience. Please contact me off-list. Matthew Kaufman [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: [arin-announce] IPv4 Address Space (fwd)
End-to-end requires that people writing the software at the end learn about buffer overruns (and other data-driven access violations) or program using tools that prevent such things. It is otherwise an excellent idea. Unfortunately, the day that someone decided their poorly-designed machine and operating system would be safer sitting behind a firewall pretty much marked the end of universal end-to-end connectivity, and I don't see it coming back for a long long time. Probably not on this Internet. IPv6 or not. Combine that with ISP pricing models (helped by registry policy) that encourage =1 IP address per household, and the subsequent boom in NAT boxes, and the fate is probably sealed. Matthew Kaufman [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Maxwell those who do not understand end-to-end are doomed to reimplement it, poorly.
RE: VeriSign SMTP reject server updated
One piece of feedback we received multiple times after the addition of the wildcard A record to the .com/.net zones concerned snubby, our SMTP mail rejection server. Did you miss the other pieces of feedback about how wildcard records in .com and .net are simply a bad idea for numerous reasons? We would like to state for the record that the only purpose of this server is to reject mail immediately to avoid its remaining in MTA queues throughout the Internet. We are specifically not retaining, nor do we have any intention to retain, any email addresses from these SMTP transactions. Right. We can't trust you to do the right thing with regard to the wildcards themselves, so now we have to trust you when you tell us what your SMTP server does. Why should we trust you, again? I would welcome feedback on these options sent to me privately or the list; I will summarize the former. I'll take the list, even though I'm sure it'll get beaten to death by the time I check my mailbox again. Matthew Kaufman [EMAIL PROTECTED] Ps. Are you planning on operating servers which reject, with proper status codes, every other common service that might be found at an Internet address?
RE: Providers removing blocks on port 135?
I agree entirely with this. You shouldn't call yourself an ISP unless you can transport the whole Internet, including those bad Microsoft ports, between the world and your customers. On the other hand, what's a provider to do when their access hardware can't deal with a pathological set of flows or arp entries? There isn't a good business case to forklift out your DSLAMs and every customer's matching CPE when a couple of ACLs will fix the problem. For that matter, there isn't a very good business case for transporting Nachi's ICMP floods across an international backbone network when you can do a bit of rate-limiting and cut your pipe requirements by 10-20%. Matthew Kaufman [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Owen DeLong Sent: Friday, September 19, 2003 10:03 AM To: Jack Bates; Adam Hall Cc: '[EMAIL PROTECTED]' Subject: Re: Providers removing blocks on port 135? FWIW, my opinion is that blocking this at the customer edge per customer request is fine. Any other blocking by an ISP is damage and should be routed around like any other internet damage. Owen
RE: Providers removing blocks on port 135?
Well, we could start by having every ISP do what we do, which is to find worm-infected customers inside our network and get them patched or turned off. But that's a lot of work. (Especially when you've got a new worm to track down every week) The scary/unfortunate part to me is that these things never seem to go away... Check your web server's log for the last hit from Code Red, for instance. (6 minutes ago, from 203.59.48.139, on the server I just checked) Matthew Kaufman [EMAIL PROTECTED] -Original Message- From: Owen DeLong [mailto:[EMAIL PROTECTED] Sent: Friday, September 19, 2003 10:23 AM To: Matthew Kaufman; 'Jack Bates'; 'Adam Hall' Cc: [EMAIL PROTECTED] Subject: RE: Providers removing blocks on port 135? OK... Obviously, you need to do what you need to do to keep things running. However, that should be a temporary crisis response. If your equipment is getting DOS'd for more than a few months, we need to find a way to fix a bigger problem. Permanently breaking some service (regardless of what we think of it. Personally, I'll be glad to see M$ go down in flames) is _NOT_ the correct answer. Owen
RE: What *are* they smoking?
And then Verisign starts using multiple IP addresses and rotating through them. And then they stop giving any other clues that it is a wildcard record. Great. Just what we need... To be in an escalating war with the people running the root nameservers. Since it is clearly in Verisign's business interest to make it impossible for you to tell when you've been handed one of the wildcard replies, I don't see this stopping any time soon. Matthew Kaufman [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomas Lund Sent: Monday, September 15, 2003 6:14 PM To: Chris Adams Cc: [EMAIL PROTECTED] Subject: Re: What *are* they smoking? On Mon, 15 Sep 2003, Chris Adams wrote: It appears that the most reliable way to detect a wildcard response for 'somedomain.tld' is to query for '*.tld'; if the results match, then 'somedomain.tld' doesn't really exist. Just make up a number of fake domains and resolve them. If they return the same answer, thats the answer to change back into NXDOMAIN. //tlund
RE: What do you want your ISP to block today?
I just read the paper... Sounds like as an ISP, I should offer a new product The Internet Minus Four Port Numbers Microsoft Can't Handle. What I can't tell is whether this should cost more or less than The Internet Matthew Kaufman On Behalf Of Johannes Ullrich: I just summarized my thoughts on this topic here: http://www.sans.org/rr/special/isp_blocking.php Overall: I think there are some ports (135, 137, 139, 445), a consumer ISP should block as close to the customer as they can.
RE: Sobig.f surprise attack today
I wish all surprise attacks came at preannounced times from known locations. Matthew Kaufman
RE: To send or not to send 'virus in email' notifications?
Absolutely not. SoBig.F, like many others, forges the sender address. That means that your notifications: 1) Don't make it back to the person with the infection 2) Simply add more clutter to the mailbox of the person whose address was used (in addition to all the bounce messages) In the enterprise, this is a great argument for scanning outbound email with positive identification of whose outbound mail you're scanning. Matthew Kaufman [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Maimon Sent: Wednesday, August 20, 2003 7:25 AM To: [EMAIL PROTECTED] Subject: To send or not to send 'virus in email' notifications? Considering the amount of email traffic generated by responding to forged virus laden email from culprits like sobig should email virus scanning systems be configured to send notifications back to sender or not?
RE: Port blocking last resort in fight against virus
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of McBurnett, Jim ... I really can not image legitimate traffic on 135.. My problem with this approach is that, in 1985, you could have said I really cannot imagine legitimate traffic on port 80. (On the other hand, you could probably say that today and be mostly right) Matthew Kaufman [EMAIL PROTECTED]
RE: Fixed IOS datestamps?
I had the same problem, with no resolution from any of my contacts yet either (perhaps they're busy?)... In my case, 12.2(14)S is a recommended option for 7200s (but built a while back), but that leaves me wondering about 12.2(14)S2 and 12.2(14)S3 (the last of which was at least built recently). Perhaps someone on the list has already compiled a quick here's a good set of releases for ISPs list that covers the obvious router choices? I'm also having trouble deciphering whether or not there's an old enough release that isn't affected by the bug for 2511 and 2611, since the bug tool data isn't the same as the vulnerability announcement list. Matthew Kaufman [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Call Sent: Thursday, July 17, 2003 11:52 AM To: [EMAIL PROTECTED] Subject: Fixed IOS datestamps? I started collecting the new IOS files for tonight's reboot of the Internet, and I had a quick question. The datestamps on a lot of the maintainence releases are months old, and I just want to make sure I'm getting the right stuff, as they say, so we don't have to do this dance again tomorrow. For example, 12.0S users are recommended to go to 12.0(25)S, which at least for the GSR is dated April 14, 2003. Do I have the right build of 12.0(25)S or will there be one with a date closer to the revelation of the exploit showing up on the cisco FTP site? Thanks -Scott
RE: Looking for advice on datacenter electrical/generator
I'm in Santa Cruz County. Since I've been here, natural gas has been off for multiple days in a row twice. Once because of an earthquake, the second time because a winter storm put a lot of water in a hillside and the slide severed the (only) high pressure gas feed for the county. In both cases, electricity wasn't stable either. So for the last datacenter I built, I went with diesel. I've also been told, though I don't know how true it is, that diesel generators can go longer between service intervals, though for a datacenter I wouldn't skimp on routine maintenance anyway. Matthew Kaufman [EMAIL PROTECTED] -home [EMAIL PROTECTED] -work -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Woodcock ... Why? In what case is it still not preferable to diesel? The _only_ reason I've ever heard an informed person state for going with diesel is that the fire marshal wouldn't allow them to store anything else. -Bill
RE: Looking for advice on datacenter electrical/generator
Oh. I guess I missed the reasonably-priced natural gas generator that has an on-board compressor and tank system for storing natural gas. If such a beast exists, then yes, that makes even more sense. Matthew
Re: I need help finding SAN-FRANCISCO.CA.US Registrar
Was scruz.net, is now sonic.net, per the DNS. Matthew Kaufman, DSL.net-formerly-Tycho.net-formerly-scruz.net [EMAIL PROTECTED] (home) [EMAIL PROTECTED] (work) On Mar 14, 0:18, Paul Vixie wrote: } Subject: Re: I need help finding SAN-FRANCISCO.CA.US Registrar scruz.net X-Original-To: [EMAIL PROTECTED] From: Gio Sico [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: I need help finding SAN-FRANCISCO.CA.US Registrar Date: Fri, 14 Mar 2003 09:52:26 +1000 X-Mailer: Microsoft Outlook, Build 10.0.4510 Sorry to bother you guys but I can not find a place to register a name off of SAN-FRANCISCO.CA.US . Any help would be greatly appreciated, John }-- End of excerpt from Paul Vixie
RE: Level3 routing issues?
We are also seeing this traffic at AS4436. Appears to be coming from IP addresses all over the space. Here's a box that traps all of 165.227.0.0/16: 23:08:13.257197 165.194.123.131.1227 165.227.92.176.1434: udp 376 23:08:13.259778 129.187.150.78.2667 165.227.84.186.1434: udp 376 23:08:13.276695 61.40.143.242.3794 165.227.21.48.1434: udp 376 23:08:13.284191 128.218.133.213.1078 165.227.198.96.1434: udp 376 23:08:13.286648 169.229.141.44.1065 165.227.255.90.1434: udp 376 23:08:13.294512 218.232.109.22.3302 165.227.146.129.1434: udp 376 23:08:13.300412 137.79.10.100.2478 165.227.5.230.1434: udp 376 23:08:13.302869 128.143.100.86.1397 165.227.41.248.1434: udp 376 23:08:13.317327 203.226.64.220.3081 165.227.216.188.1434: udp 376 23:08:13.319908 209.41.170.8.4033 165.227.252.85.1434: udp 376 23:08:13.322365 64.71.177.201.2439 165.227.128.21.1434: udp 376 23:08:13.327937 216.120.60.154.3005 165.227.125.156.1434: udp 376 23:08:13.330435 64.239.145.3.3231 165.227.4.161.1434: udp 376 23:08:13.333016 204.228.229.106.4049 165.227.238.69.1434: udp 376 23:08:13.335350 212.209.231.186.52703 165.227.38.136.1434: udp 376 23:08:13.337930 207.46.200.162.2343 165.227.96.170.1434: udp 376 23:08:13.340388 61.178.83.30.4525 165.227.77.119.1434: udp 376 23:08:13.342887 62.250.16.28.1385 165.227.119.91.1434: udp 376 23:08:13.345468 66.155.116.10.1041 165.227.106.35.1434: udp 376 23:08:13.362506 207.226.255.124.2331 165.227.189.42.1434: udp 376 23:08:13.364964 63.241.139.196.1150 165.227.135.221.1434: udp 376 23:08:13.367422 66.109.239.200.1117 165.227.67.250.1434: udp 376 23:08:13.370042 194.100.187.36.2342 165.227.103.27.1434: udp 376 23:08:13.372501 158.38.141.86.3269 165.227.239.113.1434: udp 376 23:08:13.374959 212.71.66.23.2019 165.227.232.118.1434: udp 376 23:08:13.377417 158.38.141.65.1382 165.227.169.58.1434: udp 376 23:08:13.379915 130.127.8.157.2980 165.227.107.122.1434: udp 376 23:08:13.382496 207.46.200.146.2718 165.227.49.107.1434: udp 376 23:08:13.386100 80.237.200.171.1198 165.227.93.216.1434: udp 376 23:08:13.388557 64.71.180.135.1915 165.227.38.41.1434: udp 376 23:08:13.394660 211.117.60.188.2806 165.227.49.12.1434: udp 376 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Scott Granados Sent: Friday, January 24, 2003 10:41 PM To: Alex Rubenstein Cc: hc; [EMAIL PROTECTED] Subject: Re: Level3 routing issues? We just had a box inside one of my customers networks start sending tons of small packets not sure what kind yet. On Sat, 25 Jan 2003, Alex Rubenstein wrote: I dunno about that. But, I am seeing, in the last couple hours, all kinds of new traffic. like, customers who never get attacked or anything, all of a sudden: http://mrtg.nac.net/switch9.oct.nac.net/3865/s witch9.oct.nac.net-3865. html We are seeing this on ports all across out network -- nearly 1/2 our ports are in delta alarm right now. Anyone else? I will dig more to look at the traffic. On Sat, 25 Jan 2003, hc wrote: Anyone seeing routing problems with Level3 at this hour? I just witnessed tons of prefixes behind level3's network withdraw. Any information on what is happening (if you know) would be great. Thanks! -hc -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben -- --Net Access Corporation, 800-NET-ME-36, http://www.nac.net --
Re: Level3 routing issues?
I've seen various references to this worm firing off and saturating networks worldwide within 1 minute... if *that* isn't scary, I don't know what is. It shows that someone, with the right tools and enough vulnerable servers can take out a good portion of the Internet in seconds. And how can we predict *every* possible issue and block it? The good news with this worm was that the ports it used had low real utility for inter-provider traffic. Compare and contrast to Code Red, where block TCP port 80 isn't such a great way to slow down the worm if you have any customers who like to use the web A combination of the speed at which this spread and a port nobody wants to block will undoubtedly happen in the future, and be ugly, both. Matthew Kaufman [EMAIL PROTECTED] (home) [EMAIL PROTECTED] (work)
How do I get host records deleted?
I have IP address space. An address in that address space is listed as a host record for a fair number of domains that are not mine. Hence, DNS requests come to that address. But I cannot delete the host record, because there are domains using it. Is there a magic contact somewhere at Network Solutions that can fix this? Matthew Kaufman [EMAIL PROTECTED]
