Re: Superfast internet may replace world wide web
On Apr 7, 2008, at 11:39 AM, Steven M. Bellovin wrote: On Mon, 7 Apr 2008 08:24:54 -0700 (PDT) Lucy Lynch [EMAIL PROTECTED] wrote: http://xkcd.com/401/ Also http://ars.userfriendly.org/cartoons/?id=20080330 and http://ars.userfriendly.org/cartoons/?id=20080406 I love those! I also love the top story here, especially the last sentence: http://bobpark.physics.umd.edu/WN08/wn040408.html -- TTFN, patrick
Re: wanted: server hotel location(s) in SE,GR
On Feb 28, 2008, at 4:29 PM, Marshall Eubanks wrote: On Feb 28, 2008, at 3:58 PM, [EMAIL PROTECTED] wrote: I was wondering if anyone knew of server hotel locations in Sweden I would recommend Netnod in Sweden. Kurtis Lindqvist is a good contact there. NetNod is a secure IX in Sweden, with switches in lots of cities (including two in Stockholm). However, the switches are in hidden bunkers, and you cannot rent colo there, as you could in, say, Equinix or Switch Data. Kurtis will still be able to direct you to colo in the area, though. There are several carrier neutral and other locations. -- TTFN, patrick
Re: ISP's who where affected by the misconfiguration: start using IRR and checking your BGP updates
On Feb 25, 2008, at 11:40 AM, [EMAIL PROTECTED] wrote: I've only dealt with a handful of the bigger networks, but every transit BGP session I've ever been the customer role on has been filtered by the provider. From memory and in no particular order, that's UUNet, Level3, Digex, Intermedia, Global Crossing, Genuity, Sprint, Above.net, Time Warner, CW, MCI, XO, Broadwing, and a few smaller ones nobody's likely to have heard of. There's at least one reasonably big transit provider that does *not* do prefix filtering: TeliaSonera (AS 1299). They *do* perform as-path filtering, but the effectiveness is disputable... No, the effectiveness is not disputable. It is guaranteed to be sub- optimal. This is not in doubt or question. See, as has been quoted many times, as7007. -- TTFN, patrick
Re: YouTube IP Hijacking
On Feb 25, 2008, at 2:27 AM, Hank Nussbacher wrote: At 07:15 PM 24-02-08 -0500, Randy Epstein wrote: More importantly, why is PCCW not prefix filtering their downstreams? Why? - Lack of clue - Couldn't care less - No revenue Take your pick - or add your own reason. PCCW is not alone. They just happen to be the latest in a long line of ISPs that follow the same rules - their own. All good, er, bad reasons. Fixing the filter your downstreams problem is very important. It would also solve 90-something percent of the problems mentioned in this thread. E.g. as7007. :) -- TTFN, patrick
Re: YouTube IP Hijacking
On Feb 25, 2008, at 2:32 AM, Hank Nussbacher wrote: At 05:31 AM 25-02-08 +, Steven M. Bellovin wrote: Seriously -- a number of us have been warning that this could happen. More precisely, we've been warning that this could happen *again*; we all know about many older incidents, from the barely noticed to the very noisy. (AS 7007, anyone?) Something like S-BGP will stop this cold. Yes, I know there are serious deployment and operational issues. The question is this: when is the pain from routing incidents great enough that we're forced to act? It would have been nice to have done something before this, since now all the world's script kiddies have seen what can be done. we've been warning that this could happen *again* - this is happening every day - just look to: http://cs.unm.edu/~karlinjf/IAR/prefix.php?filter=most http://cs.unm.edu/~karlinjf/IAR/subprefix.php?filter=most for samples. Thing is - these prefix hijacks are not big ticket sites like Youtube or Microsoft or Cisco or even whitehouse.gov - but rather just sites that never make it onto the NANOG radar. How many of those would be stopped with transit providers filtering their downstreams? Which doesn't require rolling out a new technology like SBGP. And, I would argue, if we cannot even get transit providers to filter their downstreams, there is no way in hell we can get transit providers to filter on some RR or doing authentication on individual prefixes. Let's start with the easy stuff. Walk before run and all that. -- TTFN, patrick
Re: YouTube IP Hijacking
On Feb 24, 2008, at 7:36 PM, Tomas L. Byrnes wrote: I'm sure we can all find a list of critical infrastructure ASes that could be trusted to peer via the high priority AS. I'd say that the criteria should be: 1: Hosted at a Tier 1 provider. That is a silly requirement. (I am sorry, I tried hard to find a nicer way to say this, but I really feel strongly about this.) 2: Within a jurisdiction where North American operators have a good chance of having the law on their side in case of any network outage caused by the entity. This is also a bit strange. Do your users never attach to a host outside the USofA? 3: Considered highly competent technically. Here we agree. 4: With state of the art security and operations. I think we agree, but I wouldn't have said it like that. -- TTFN, patrick OTOH: I would say that, until today, those who advocate not engaging in any kind of ethnic or political profiling would have considered 17557, as a national telco, a trusted route source. -Original Message- From: Randy Epstein [mailto:[EMAIL PROTECTED] Sent: Sunday, February 24, 2008 4:15 PM To: Tomas L. Byrnes; 'Simon Lockhart' Cc: 'Michael Smith'; [EMAIL PROTECTED]; [EMAIL PROTECTED]; nanog@merit.edu Subject: RE: YouTube IP Hijacking Tomas L. Byrnes wrote: Perhaps certain ASes that are considered high priority, like Google, YouTube, Yahoo, MS (at least their update servers), can be trusted to propagate routes that are not aggregated/filtered, so as to give them control over their reachability and immunity to longer-prefix hijacking (especially problematic with things like MS update sites). Not to stir up a huge debate here, but if I were a day trader, I could live without YouTube for a day, but not e*trade or Ameritrade as it would be my livelihood. If I were an eBay seller, why would I care about YouTube? You get the idea. What makes Google, YouTube, Yahoo, MS, etc more important? More importantly, why is PCCW not prefix filtering their downstreams? Certainly AS17557 cannot be trusted without a filter. Randy -Original Message- From: Simon Lockhart [mailto:[EMAIL PROTECTED] Sent: Sunday, February 24, 2008 2:07 PM To: Tomas L. Byrnes Cc: Michael Smith; [EMAIL PROTECTED]; [EMAIL PROTECTED]; nanog@merit.edu Subject: Re: YouTube IP Hijacking On Sun Feb 24, 2008 at 01:49:00PM -0800, Tomas L. Byrnes wrote: Which means that, by advertising routes more specific than the ones they are poisoning, it may well be possible to restore universal connectivity to YouTube. Well, if you can get them in there Youtube tried that, to restore service to the rest of the world, and the announcements didn't propogate. Simon
Re: YouTube IP Hijacking
On Feb 25, 2008, at 12:31 AM, Steven M. Bellovin wrote: Seriously -- a number of us have been warning that this could happen. More precisely, we've been warning that this could happen *again*; we all know about many older incidents, from the barely noticed to the very noisy. (AS 7007, anyone?) Something like S-BGP will stop this cold. As much as I love to make fun of Avi + Vinny, as7007 was not really the problem, Sprint running custom cisco code which wouldn't let go of prefixes after the router announcing them had been turned off for more than an hour was. Plus, problems which happened over 10 years ago is a bit far back in Internet time. :) Yes, I know there are serious deployment and operational issues. The question is this: when is the pain from routing incidents great enough that we're forced to act? It would have been nice to have done something before this, since now all the world's script kiddies have seen what can be done. I would argue the answer to your question is not yet, as we haven't done anything yet. We can argue whether that is the right answer, but it is still THE answer. -- TTFN, patrick
Re: Question on the topology of Internet Exchange Points
On Feb 15, 2008, at 8:04 AM, Greg VILLAIN wrote: Obvious as it is, if one of your peerings on an IX gets big in terms of in/out volumes, you HAVE to secure it by PNI. You need a way to prevent the IX's equipments from being a SPoFs between you and that peer. HAVE to is such a strong phrase. First, who said the switch is a SPoF? And since when is a PNI not a SPoF? If the peer is that big, you should peer in more than one place. For instance, LINX has two LANs, or you can use PAIX and Equinix. Connecting to a big peer in a single location, whether over PNI or shared switch, creates a SPoF. Peering in multiple locations removes the SPoF, regardless of the method. I'm not saying one should convert every single IX peering into a PNI, as I feel both are pretty much required: your smallest peers shall be secured on as many IXes as possible, your biggest ones via PNI. IX peering is mandatory to keep internet routing diversity up to par - and enable small ASes to grow. Using shared for small peers and direct for big peers is a time honored practice on the Internet. But you can justify this in finance, not just engineering. A fiber x-conn costs less than an IX port (usually). Any peer big enough to take up a significant fraction of the IX port probably justifies the CapEx for a dedicated router port. Does this make things more reliable? Many would argue it does. I would argue that large IXes have amazing uptime these days. The MAEs GigaSwitches are long gone, public IXes are no longer guaranteed to give you problems. Also, it is a wrong assumption to state that IX will make you spare money on transit, from my perspective they should be seen as securing multiple narrower paths to the internet. Do you mean save money on transit when you say make you spare money on transit? Just want to make sure we are on the same page. That is not an assumption, it is a provable - or disprovable! - fact. If you run the numbers and the IX saves you money, well, it saves you money. If it does not, it does not. Where does the word assumption come in? That doesn't mean they are not also additional vectors. But Item #1 does not conflict with Item #2. -- TTFN, patrick
Re: Question on the topology of Internet Exchange Points
On Feb 14, 2008, at 3:44 PM, Andy Davidson wrote: On 14 Feb 2008, at 17:02, Kai Chen wrote: A typical Internet Exchange Point (IXP) consists of one or more network switches, to which each of the participating ISPs connect. We call it the exchange-based topology. My question is if some current IXPs use directly-connected topology, in which ISPs just connect to each other by direct link, not through a network switch?? If so, what's the percentage of this directly-connected case? ISPs use a direct link (PNI) all the time to peer, and they don't need to be a member/customer of an internet exchange point to do so. In fact, the network you want to peer with might not be available at your local IXP even though they're in your local carrier hotel - then it becomes pretty much the only way to peer. In London, the LINX offer switched *and* unswitched connectivity between members - you can rent fibers from them in order to perform PNI with other members. That the exchange offer this is unusual, and it's offered as an additional service, in order to smooth the process of organising interconnection between member organisations. [www.linx.net ] LINX doesn't rent fibers. It's a one-time (NRC) fee for 8 pairs, which are patched to any other member on the service for free for life. (Although I don't know if they promise to keep it free forever, but it's been free for many years with no mention of it changing.) We (LONAP) don't offer PNI services, and only offer the conventional switch ports, which members normally want so that they can get access to our peering lan and swap some traffic. [www.lonap.net] All exchanges offer this connectivity model. We offer private CUG and member-to-member private VLANs, which is similar, but still passes through the switch fabric. I believe Exchange Point offers a PNI-like service over their network. But in general, an Internet eXchange Provider offers a shared switch. Anything else is really just a meet-me room. For instance, I wouldn't call Suite 1515 (formerly NYCC) an IXP. -- TTFN, patrick
Re: Cost per prefix [was: request for help w/ ATT and terminology]
On Jan 21, 2008, at 6:14 PM, David Barak wrote: Wouldn#39;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? The difficulty I have with this discussion is that the cost per prefix is zero until you need to change eigenstate, where there#39;s a big cost, and then it goes back to zero again. Because this isn#39;t really all that new a problem, most vendors try not to make devices which have no headroom at all - so kit in the lower category seems to be qualitatively different. We have a winner. The problem with William's calculation is that he is claiming the _only_ difference between X Y is prefix count. (He said this, more than once.) He is dead wrong. I cannot think of a pair of boxes where one can support a full table and one can't where the _only_ difference is prefix count. (I am excluding things like Box X with 128MB RAM and Box X with 1 GB RAM.) Even the Sup2 3blx have far more differences than just prefix count. If you do not understand why, you clearly aren't competent to post to this thread. For every network, there is equipment that will work, and equipment that will not. At the top end for very large networks, buying less than a CRS1 / T640 is simply not an option. And the amount of engineering going into those boxes to deal with a 1M BGP entry table is essentially _zero_. Many networks buying those boxes have 100s of 1000s of prefixes in their _IGP_, so the FIB / processor / RAM / etc. all have to deal. Near the bottom end, for networks that could get away with a 3750 if they only supported a full table (which I submit is a pretty small fraction of the total boxes sold), they can still buy the 3750 and default to a pair of cheap 2/3/4-port boxes with a gig of RAM and use those for external connectivity. The problem is perfectly solvable without jumping to the 7600/3blx. In between there are more variations than everyone here combined could possibly imagine. And the requirements are _NOT_ all about prefix count. Which means you have no basis for comparison. If you try to force a general comparison, you will be wrong. So stop asking what box would you compare? The answer is whatever I need!, not what YOU think is correct, since you are invariably wrong unless you know everything about MY network. Anyone who thinks differently is either confused or has an agenda they are pushing. Or, possibly, trying to sell you a bigger box. PLEASE, let the thread die. -- TTFN, patrick
Re: An Attempt at Economically Rational Pricing: Time Warner Trial
On Jan 19, 2008, at 4:25 PM, Taran Rampersad wrote: Rod Beck wrote: Ironically, the Net Neutrality debate is about the access providers trying to impose usage-based pricing through the backdor - on the content providers. It goes without saying I oppose it. It's the end users who decide what they view and hence ultimately generate the traffic flows. So the end users should be subject to the usage- based pricing. Concur. However, comma, if governments are charging taxes (such as the EU) it leads to the question of what people pay taxes *for* - and paying more taxes because they use the internet more would mean those that use more would pay more in usage fees and pay more in taxes - which runs completely against the stacks of documents written about equality on the internet. Not taking a side on that, but it is an interesting point to chew on - realistically, a balance would have to be struck. Where are the stacks of documents written about equality on the internet that say customers who use more should pay the same as customers who use less? I am not taking a position on NN here, but I don't believe either side of the debate has said anything remotely to that effect. If one side has, they are being quite silly. Oh, and where do I plug my 10GE port in for $39.99/month? And, as an aside, the Network Neutrality issue affects the globe and is only being debated in one country. Perhaps you should change that? :) -- TTFN, patrick
Cost per prefix [was: request for help w/ ATT and terminology]
On Jan 19, 2008, at 12:55 PM, William Herrin wrote: 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. 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. :) So, given that there are 27206 ASes in the table (latest CIDR report), that means it costs each AS, on average, less than $0.30/year to accept a prefix. I'm thinking that billing each new network with its own prefix would cost more than $0.30/recipient. Let's make it easy. Let's say only 8K ASNs actually take a full table. (Rest have partial tables or two defaults or something.) So each network needs $1/year per prefix. I still think the billing infrastructure would cost more than the bill itself. But then, the telcos have been in that situation for a century. Why shouldn't the Internet follow in their footsteps? 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. :) -- TTFN, patrick
Re: An Attempt at Economically Rational Pricing: Time Warner Trial
On Jan 19, 2008, at 11:37 AM, Joe Greco wrote: Mikael Abrahamsson writes: Customers want control, that's why the prepaid mobile phone where you get an account you have to prepay into, are so popular in some markets. It also enables people who perhaps otherwise would not be eligable because of bad credit, to get these kind of services. However, if you look, all the prepaid plans that I've seen look suspiciously like predatory pricing. The price per minute is substantially higher than an equivalent minute on a conventional plan. Picking on ATT, for a minute, here, look at their monthly GoPhone prepaid plan, $39.99/300 anytime, vs $39.99/450 minutes for the normal. If anything, the phone company is not extending you any credit, and has actually collected your cash in advance, so the prepaid minutes ought to be /cheaper/. I disagree. Ever heard of volume discounts? Picking on att again, a typical iPhone user signs up for 24 months @ ~ $100/month, _after_ a credit check to prove they are good for it or plunking down a hefty deposit. Compare that $2.4 kilo-bux to the $40-one-time payment by a pre-paid user. Or, to be more far, how about $960 ($40/month for voice only) compared to $40 one-time? Hell yes I expect more minutes per dollar on my long-term contract. Hrmm, wonder if someone will offer pay-as-you-go broadband @ $XXX (or $0.XXX) per gigabyte? -- TTFN, patrick
Re: Cost per prefix [was: request for help w/ ATT and terminology]
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. While there are 27K ASes ($0.30/year/AS, remember?), there are many more routers which carry a full table. 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. 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. Interesting thought experiment. Let's assume _ALL_ $21B of revenue you quote above is routers which can do a full table. The numbers you quote say 10% of that revenue is because of DFZ table size. I was unaware so much cost in a router was just table size. And since we all know that revenue is not all DFZ-capable routers (for instance, how much of that $20B is Linksys?), the %-age is much higher. Wow, router member CPU must be very expensive - and optics must be damned cheap. Besides the obvious absurdity in this, it contradicts the point I made to your last paragraph. I guess I'm thinking again: Um, yeah, right. :) 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. Heaven forbid it costs each ASN an average of TWO DOLLARS per year. Eventually, since it will be quite a while before the v6 table is 250K prefixes. Hrmm, I take that back. By the time there are 250K v6 prefixes, there will be far, far more ASNs, so the average cost will be less. 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. -- TTFN, patrick
Re: Cost per prefix [was: request for help w/ ATT and terminology]
Ben, I believe you are correct that PA deaggregation is a huge problem, but some of that could be corporate multi-homing. (I don't know for certain whether it is greater or less than providers just being ninnies.) Lots of companies get a /24 from one upstream and announce it to two or more upstreams. That is, IMHO, a legitimate deaggregation, as opposed to a provider who is just too clueless aggregate. But before we go too far down this road, everyone here should realize that new PI space and PA deaggregation WILL CONTINUE TO HAPPEN. Many corporations paying for Internet access will NOT be tied to a single provider. Period. Trying to tell them you are too small, you should only let us big networks have our own space is a silly argument which won't fly. The Internet is a business tool. Trying to make that tool less flexible, trying to tie the fate of a customer to the fate of a single provider, or trying force them to jump through more hoops than you have to jump through for the same redundancy / reliability is simply not realistic. And telling them it will cost some random network in some random other place a dollar a year for their additional flexibility / reliability / performance is not going to convince them not to do it. The number of these coAt least not while the Internet is still driven by commercial realities. (Which I personally think is a Very Good Thing - much better than the alternative.) Someone will take the customer's check, so the prefix will be in the table. And since you want to take your customers' checks to provide access to that ISP's customer, you will have to carry the prefix. Of course, that doesn't mean we shouldn't be thrifty with table space. We just have to stop thinking that only the largest providers should be allowed to add a prefix to the table. At least if we are going to continue making money on the Internet. -- TTFN, patrick On Jan 20, 2008, at 7:08 AM, Ben Butler wrote: Hi, Out of curiosity was the reasoning also to charge the PA who are deagregating? To restate there are 113,220 extra routes smaller than RIR minimums out of the /24:126,450 in the table. The today reality seems to be that 113K of that 126K is probably being caused by existing networks de-aggregating PA. While I would I would agree that corporate multihoming with PI has a huge potential problem on the table in terms of number of prefixes. Further more as BGP skills are becoming more common place and Linux/Quagga skills the barrier to entry for a corporate is reducing at the same time their commercial reliance on and use of the Internet is increasing. Corporate multihoming - if permitted - has the inevitable consequence of an extra prefix. PA deagreagtion - has the avoidable consequence of lots of extra prefixes. I know who I would be charging first and maybe it would give the much need incentive for them to clean house. We could then have some number up to 113K new multihomed corporate before we got back to where we are today in terms of route table size. An interesting question to gauge the size of the corporate multihoming potential problem is to guess how many there may be worldwide that would bother / try - I have no idea. I believe (possibly wrongly) that IPv6 doesn't really have a solution for multihoming corporate with multiple allocations and weird shims and NAT configurations to get it to work - or have the RIRs decided on a policy change yet and issuing PI blocks of IPv6 as well? Am I correct on my interpretation of the numbers for PA:PI smaller prefix origins? Kind Regards Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William Herrin Sent: 20 January 2008 11:06 To: Patrick W. Gilmore Cc: nanog@merit.edu Subject: 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
Re: Massive ATT outage?
Good thing neither pizzahut.com or any other single-homed att customer injected an extra prefix into the table and raised everyone's cost by multi-homing! :) -- TTFN, patrick On Jan 20, 2008, at 2:53 AM, Paul Ferguson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The oddball aspect of this for me was that a friend was wondering why he couldn't reach the Pizza Hut online ordering site [quikorder.pizzahut.com] which is directly attached to ATT: %tracert quikorder.pizzahut.com Tracing route to quikorder.pizzahut.com [129.41.62.29] over a maximum of 30 hops: [snip] 665 ms66 ms69 ms tbr1.sffca.ip.att.net [12.123.12.49] 761 ms64 ms63 ms cr1.sffca.ip.att.net [12.122.19.1] 884 ms64 ms62 ms cr1.cgcil.ip.att.net [12.122.4.122] 962 ms66 ms62 ms tbr2.cgcil.ip.att.net [12.122.17.210] 1062 ms66 ms64 ms gar1.chail.ip.att.net [12.123.4.65] 1172 ms64 ms65 ms 12.119.137.58 1273 ms63 ms66 ms 10.22.2.5 1373 ms64 ms63 ms 129.41.62.29 Trace complete. It seems to have crapped out earlier somewhere [various places actually] in the ATT routing infrastructure. Pizza ordering apparently is now available. ;-) - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHkv3Kq1pz9mNUZTMRAjZsAJwPafDM2qBv3vbO91MJNkfgfVGPuQCgxAgS bdPsLZFfmDVwiVG28b5OTVE= =G4iq -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Cost per prefix [was: request for help w/ ATT and terminology]
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: Your calculation is in error. 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. Difference between the two: The switch stack can't handle the DFZ prefix count. 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? Etc. In short, if the table were 50K prefixes instead of 250K, would these pieces of equipment be equivalent? The answer is a blatant no. I can cook stats as well as the next guy, but I try to be painfully obvious about my bias. Given that you say the thread doesn't include more than the number here, I don't even think I need to read the thread. The cost (billions of dollars per year) is clearly in error. -- TTFN, patrick 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, at 3:34 PM, William Herrin wrote: 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. We still disagree. 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 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. To be clear, of course there are some people who could use either if the table were 50K prefixes. But the majority of routers in the DFZ cannot be replaced by cheap 1U (or whatever) switches which can do a few 10s of 1000s of prefixes. (Besides, the people who _can_ use them can use them today with properly configured filters, perhaps on the upstream router's side. Which, of course, means the upstream router cannot be one of those cheap switches. :) Perhaps you should justify numbers with nine zeros a little better before asking me to justify why they are wrong. -- TTFN, patrick
Re: Cost per prefix [was: request for help w/ ATT and terminology]
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. 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. As I said before, your calculation is in error. I very clearly explained why, but you threw out my explanation below. Apparently I assumed you had knowledge you did not. Please forgive me for not assuming you were ignorant. I shall not repeat my mistake. 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%. Unfortunately, I have to run real packets through a real router in the real world, not design a network off CDW's website. As a simple for-instance, taking just a few thousand routes on the 3750 and trying to do multipath over, say 4xGigE, the 'router' will fail and you will see up to 50% packet loss. This is not something I got off CDW's website, this is something we saw in production. And that's without ACLs, NetFlow, 100s of peering sessions, etc. None of which the 3750 can do and still pass gigabits of traffic through a layer 3 decision matrix. Have you ever configured a 3750 to do BGP with a few gigabits running through it? A 7600? I submit that you probably have not. And you certainly have not done it in any but the most basic of configurations or you would not have posted this silliness. Or you can keep swimming in that river in Egypt. Its up to you. William, if that's the best flame you can come up with, perhaps I should stop reading your posts. Then again, given you honestly believe the only difference between a 3750 a 7600 is the # of prefixes it can take, I'm not sure why I am still reading your posts. 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. We disagree. What's more, this thing called the real world disagrees as well. 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. Drop it to 8K prefixes, then see example above. Drop it to 2 prefixes (local LAN + default), the two routers are still not equivalent. 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. Have you ever seen the requirements put on a peering or customer aggregation router at a large network? I really do not have time to explain why if you do not already know. I've spent too much time trying to explain it to you already, yet I seem to be failing at explanations, and you just send me (pathetic) flames back anyway. Perhaps some other poster can explain it to you. 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. -- TTFN, patrick
Re: An Attempt at Economically Rational Pricing: Time Warner Trial
On Jan 18, 2008, at 4:01 PM, Patrick W. Gilmore wrote: On Jan 18, 2008, at 3:11 PM, Michael Holstein wrote: My guess is the market will work this out. As soon as it's implemented, you'll see ATT commercials in that town slamming cable and saying how DSL is really unlimited. P.S. Perhaps they picked that market specifically because they were the only broadband provider there? :) -- TTFN, patrick
Re: An Attempt at Economically Rational Pricing: Time Warner Trial
On Jan 18, 2008, at 3:11 PM, Michael Holstein wrote: The problem is the inability of the physical media in TWC's case (coax) to support multiple simultaneous users. They've held off infrastructure upgrades to the point where they really can't offer unlimited bandwidth. TWC also wants to collect on their unlimited package, but only to the 95% of the users that don't really use it, and it appears they don't see working to accommodate the other 5% as cost-effective. I seriously doubt it the coax that is the problem. And even if that is a limitation, upgrading the last mile still will not allow for unlimited use by a typical set of users these days. Backhaul, peering, colocation, etc., are not free, plentiful, or trivial to operate. My guess is the market will work this out. As soon as it's implemented, you'll see ATT commercials in that town slamming cable and saying how DSL is really unlimited. I do not doubt that. But do you honestly expect the att DSL line to provide faster / more reliable access? Hint: Whatever your answer, it will be right or wrong for a given time in the near future. -- TTFN, patrick
Re: An Attempt at Economically Rational Pricing: Time Warner Trial
On Jan 18, 2008, at 3:06 PM, Tomas L. Byrnes wrote: I always find it interesting that people with a telco background keep trying to go back to the ma bell days and ways, even as the telcos themselves are abandoning those models for phone service. I am not at all certain that is what is happening. One of the things about usage based pricing in the Internet is that the system doesn't have the facilities to do that built into it by design, so you have to add a lot of equipment and software to do it. This tends to cost more than the incremental revenue, especially when you consider the additional customer service costs and churn (there's always a competitor who pops up offering flat-rate pricing). The problem in the ISP industry isn't lack of usage based pricing. It's that the going rate for basic connectivity was driven below that which is economically sustainable by the ILECs when they engaged in predatory pricing to drive the CLECs out of business in the late 90s. Now that they own the market, they find that, having driven the prices down, they can't raise them, so they are engaging in various subterfuges that are designed to cover up the basic thing they are doing: trying to charge more for the exact same service. I disagree. Pick a number. Any number. Offer broadband flatrate service at that number. I will show you at least 5% of your customer base who is either paying an order of magnitude too much, or getting an order of magnitude more than they paid for. And usually a lot more than 5%. The problem is flat rate doesn't work when the thing being offered is a shared resource _and_ a single or a few users can use all the resources. On phone networks, flat rate kinda works because a single phone call is a very tiny fraction of the shared resource. No small set of users can harm the rest of the users. (It is still possible for a medium set of users to harm the rest, but the danger is low.) That is not true for Internet access, unless you plan to go back to Kbps speeds. I think that would be less well received than usage- based billing. IOW: Usage-based billing makes sense commercially, whether you are a propeller-head or a bell-head. And since Internet providers tend to be for-profit businesses, doing what makes sense commercially is kinda required. Then again, I Am Not An Isp, so what do I know? If you think things are out of whack, sounds like a business opportunity to me! You should be able to take your superior knowledge and make a killing implementing a proper network. -- TTFN, patrick
Re: An Attempt at Economically Rational Pricing: Time Warner Trial
On Jan 18, 2008, at 1:57 PM, Mikael Abrahamsson wrote: On Fri, 18 Jan 2008, Rod Beck wrote: http://www.ecommercetimes.com/rsstory/61251.html So, anyone but me think that this will end in disaster? Possibly. But I do not think it for the same reason you do. I think the model where you get high speed for X amount of bytes and then you're limited to let's say 64kilobit/s until you actually go to the web page and buy another token for more Y more bytes at high speed? We already have this problem with metered mobile phones, which of course is even more complicated for users due to different rates depending on where you might be roaming. Right. And mobile phones, which you admit are more difficult to understand and manage, have clearly been a disastrous failure. By your analogy, we should expect this to be a slightly less disastrous failure. (Would that Time Warner were so lucky. :) Customers want control, that's why the prepaid mobile phone where you get an account you have to prepay into, are so popular in some markets. It also enables people who perhaps otherwise would not be eligable because of bad credit, to get these kind of services. This seems like a non sequitor to me. What has bad credit got to do with the discussion at hand? I'm also looking forward to the pricing, all the per-byte plans I have seen so far makes the ISP look extremely greedy by overpricing, as opposed to we want to charge fairly for use that is what they say in their press statements. Well, at least let them price it before you damn them for being greedy. Anyway, I think it will end in disaster because the customers in that small town have friends who are not in that small town. If they talk to each other, the test subjects will be jealous of the unlimited plans in other areas. Of course, there are ways around this, such as pricing the base GB below the unlimited plans. Then parents who surf the web for 20 minutes a day might beat their kids into turning off eDonkey and save some cash. Suddenly _everyone_ is happy - except the kids. But since they don't pay cable bills, no one cares. -- TTFN, patrick
Re: request for help w/ ATT and terminology
On Jan 16, 2008, at 4:37 PM, Mike Donahue wrote: Hi. I'm by no means an ip/networking expert, and we're having some difficulty communicating with the boffins at ATT. Any input/advice/translation would be appreciated. We own our own class C netblock. Our previous provider, Sprint, had no problem adding it to their network/advertising it (that circuit is now disconnected). We've started using an ATT colo facility, and we're having a lot of trouble trying to get ATT to do the same thing there that Sprint was able to do for us. ATT is refusing to advertise our netblock/path it to our cabinet unless we have an AS number. ARIN has refused to give us one on the grounds (rightly so) that we're not multi-homed. ATT says they'll give us a temporary ASN, and want us to do eBGP for our netblock. They sent the technical information over today, and they want two distinct routers to act as the bgp peers... Anyway, it's all getting (for us) pretty complicated. We're a fairly small firm and just want an Ethernet handoff with our IP block on it. Sprint didn't blink at the request, but ATT... We're getting a good rate from ATT for the IP services because it's at their colo. Switching back to Sprint would definitely be more costly. Questions: [EMAIL PROTECTED]@merit.edu 1. Is what we're asking for unusual/uncalled for? It's att's network. They should be allowed to run it as they please. So it's hard to say anything (other than abuse) is uncalled for. Unusual? Hell yes. 2. What's the technical terminology for the request for ATT to simply start advertising our netblock called? I'm wondering if they're not understanding our request. Ask for att to originate my /24, and route it to my rack. If they don't get that, find another provider. -- TTFN, patrick
Re: request for help w/ ATT and terminology
On Jan 16, 2008, at 4:55 PM, Darryl Dunkin wrote: If you want connectivity from both ATT and Sprint with your one block, you have plenty of justification from ARIN to get your AS assigned assuming both feeds come into one location. However, it looks like you are asking two providers to announce the same block at two different locations (different origin AS on each). If this is the case, it won't happen, you'd be better off justifying an allocation of the additional space from ATT. 1) It can, has, and continues to happen all the time. It's a perfectly valid way to route on the Internet. Although not what I would do personally. 2) He said he killed the Sprint line. He also said ARIN (correctly) denied him an ASN because he was not multi-homed. -- TTFN, patrick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Donahue Sent: Wednesday, January 16, 2008 13:37 To: nanog@merit.edu Subject: request for help w/ ATT and terminology Hi. I'm by no means an ip/networking expert, and we're having some difficulty communicating with the boffins at ATT. Any input/advice/translation would be appreciated. We own our own class C netblock. Our previous provider, Sprint, had no problem adding it to their network/advertising it (that circuit is now disconnected). We've started using an ATT colo facility, and we're having a lot of trouble trying to get ATT to do the same thing there that Sprint was able to do for us. ATT is refusing to advertise our netblock/path it to our cabinet unless we have an AS number. ARIN has refused to give us one on the grounds (rightly so) that we're not multi-homed. ATT says they'll give us a temporary ASN, and want us to do eBGP for our netblock. They sent the technical information over today, and they want two distinct routers to act as the bgp peers... Anyway, it's all getting (for us) pretty complicated. We're a fairly small firm and just want an Ethernet handoff with our IP block on it. Sprint didn't blink at the request, but ATT... We're getting a good rate from ATT for the IP services because it's at their colo. Switching back to Sprint would definitely be more costly. Questions: 1. Is what we're asking for unusual/uncalled for? 2. What's the technical terminology for the request for ATT to simply start advertising our netblock called? I'm wondering if they're not understanding our request. Any other comments/input/suggestions welcomed. Thanks in advance, Mike Donahue WATG
Re: Looking for geo-directional DNS service
On Jan 15, 2008, at 12:00 PM, Bill Woodcock wrote: On Tue, 15 Jan 2008, Hank Nussbacher wrote: The Ultradns (now Neustar) Directional DNS service is based on statically defined IP responses at each of their 14 sites so there is no proximity checking done. Yes, and that's how anycast works: it directs traffic to the _topologically nearest_ server. So as long as there's a DNS server topologically near your data server, your users will get the topologically nearest of your servers. Which is why so many content folks _do_ roll their own: to ensure fate-sharing between the DNS traffic which effectively selects the data server, and the eventual data traffic. If you're doing things on the Internet, instead of the physical world, topological distance is presumably of much greater interest than whatever geographic proximity may coincidentally obtain. Except Hank is asking for true topological distance (latency / throughput / packetloss). Anycast gives you BGP distance, not topological distance. Say I'm in Ashburn and peer directly with someone in Korea where he has a node (1 AS hop), but I get to his node in Ashburn through my transit provider (2 AS hops), guess which node anycast will pick? -- TTFN, patrick
Re: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
On Jan 8, 2008, at 8:45 AM, Joshman at joshman dot com wrote: As a general rule, is it best practice to assign x.x.x.0 and x.x.x. 255 as host addresses on /23 and larger? I realize that technically they are valid addresses, but does anyone assign a node or server which is a member of a /22 with a x.x.x.0 and x.x.x.255? Is it just a manner of preference on whether or not to use them, or are there functional reasons you shouldn't; either with rfc 1918 addresses or public addresses. I like to use them for critical service machines, since many versions of Windows will not send packets to them, so they are protected from most (but not all!) botnets. -- TTFN, patrick
Re: South America Peering
On Dec 27, 2007, at 9:44 PM, Robert Boyle wrote: At 07:39 PM 12/27/2007, AD wrote: does anyone have any experience with peering in S. America? I am looking to move a lot of data between NewYork/LA and a few south american countries and looking for some ISPs that have reliable peering into those countries. Any recommendations would be appreciated. The one i did find was Terremark, but no others yet. Adam, If you want connectivity to Latin America (inc. S. America) from the US (LA NY), then you probably want to be at NOA in Miami. That is a Terremark facility, but lots of carriers are there. Look at their carrier customer list and you will see all of the carriers connected to them in Miami: Most people (including the facility itself) call it NotA. :) Terremark runs an IX in Miami with lots of south of the border networks, as well as the one in São Paulo, which is probably the one you found. Other than that, there's another IX in São Paulo just a few miles from the Terremark facility with some additional, as well as some duplicate, carriers. Besides São Paulo, I do not know any IXes in SA with lots of good peering, but would love to be educated. -- TTFN, patrick
Re: DNS servers
On Nov 6, 2007, at 3:06 PM, J. Oquendo wrote: Nice to get news third string... // Last week, ICANN setup a new IP address for one of the thirteen root name servers that oversee DNS queries across the net, and it plans on retiring the old address as soon as the late spring. http://www.theregister.co.uk/2007/11/06/icann_rolls_out_new_root_name_server_address/ It was posted to DNS-Operations. Which is where, uh, DNS Operations are discussed Plus, as long as one of the IP addresses in your hints file is good, it doesn't really matter after launch. The SOA from one of the roots will override the hints file. -- TTFN, patrick
Re: DNS servers
On Nov 6, 2007, at 3:24 PM, Patrick W. Gilmore wrote: On Nov 6, 2007, at 3:06 PM, J. Oquendo wrote: Nice to get news third string... // Last week, ICANN setup a new IP address for one of the thirteen root name servers that oversee DNS queries across the net, and it plans on retiring the old address as soon as the late spring. http://www.theregister.co.uk/2007/11/06/icann_rolls_out_new_root_name_server_address/ It was posted to DNS-Operations. Which is where, uh, DNS Operations are discussed It was pointed out to me that the sarcasm in this post is not clear. I was not disagreeing, it should have been posted to NANOG (as well as other places). I simply didn't notice it 'cause I saw it elsewhere. Mostly I wanted to give out the info below, which somehow escaped my personal knowledgebase until a very nice person from VeriSign explained it to me at RIPE a couple weeks ago. -- TTFN, patrick Plus, as long as one of the IP addresses in your hints file is good, it doesn't really matter after launch. The SOA from one of the roots will override the hints file. -- TTFN, patrick
Re: Hey, SiteFinder is back, again...
On Nov 5, 2007, at 7:40 AM, Joe Greco wrote: Reinventing the DNS protocol in order to intercept odd stuff on the Web seems to me to be overkill and bad policy. Could someone kindly explain to me why the proxy configuration support in browsers could not be used for this, to limit the scope of damage to the web browsing side of things? I realize that the current implementations may not be quite ideal for this, but wouldn't it be much less of a technical challenge to develop a PAC or PAC-like framework to do this in an idealized fashion, and then actually do so? Because that would require user intervention. Even with a willing userbase, you will never get 100% adoption, and that will affect your revenues. IOW: Because it won't make as much $$. In general, I don't think make more money is a bad motivation. (Hell, it's one of my main motivations.) But it has to be tempered by the greater good, or we end up with an unworkable system, and then everyone makes less money in the long run. IMHO, of course. -- TTFN, patrick
Re: Hey, SiteFinder is back, again...
On Nov 5, 2007, at 10:54 AM, Andrew Sullivan wrote: On Sun, Nov 04, 2007 at 08:32:25AM -0500, Patrick W. Gilmore wrote: A single provider doing this is not equivalent to the root servers doing it. You can change providers, you can't change . in DNS. This is true, but Verisign wasn't doing it on root servers, IIRC, but on the .com and .net TLD servers. Not that that's any better. Touché. Guess I wasn't awake when I wrote that. But .com/.net is still bad (as you say). The last time I heard a discussion of this topic, though, I heard someone make the point that there's a big difference between authority servers and recursing resolvers, which is the same sort of point as above. That is, if you do this in the authority servers for _any_ domain (., .com, .info, or .my.example.org for that matter), it's automatically evil, because of the meaning of authority. One could argue that it is less evil to do this at recursive servers, because people could choose not to use that service by installing their own full resolvers or whatever. I don't know that I accept the argument, but let's be clear at least in the difference between doing this on authority servers and recursing resolvers. I would argue against such a blanket statement. Doing this in an authority for a TLD is bad, because most people don't have a choice of TLD. (Or at least think they don't.) But if I want to put in a wildcard for *.ianai.net, then there is nothing evil about that. In fact, I've been doing so for years (just 'cause I'm lazy), and no one has even noticed. It is my domain, I should be allowed to do whatever I want with it as long as I pay my $10/year and don't use it to abuse someone else. Hijacking user requests on caching name servers is very, very bad, because 1) the user probably doesn't know they are being hijacked, and 2) even if the user did, most wouldn't know how to get around it. So you're back to the TLD authority problem, there is no choice in the matter. -- TTFN, patrick
Re: Hey, SiteFinder is back, again...
On Nov 4, 2007, at 1:52 AM, Christopher Morrow wrote: On 11/3/07, Allan Liska [EMAIL PROTECTED] wrote: I know this is just anecdotal, but I have Verizon FIOS in Northern Virginia and I have not seen sitefinder pop up. I just verified with a few sites to make sure. http://www.irbs.net/internet/nanog/0607/0139.html oops, I was right (kinda). Verizon != VeriSign, despite what people think. A single provider doing this is not equivalent to the root servers doing it. You can change providers, you can't change . in DNS. Plus lots of providers do this, in the US and abroad. Lastly, it's trivial to get around, unless your provider is transparently intercepting / redirecting port 53. -- TTFN, patrick
Re: How Not to Multihome
On Oct 9, 2007, at 8:15 AM, Jamie Bowden wrote: On Oct 8, 2007, at 6:45 PM, Justin M. Streiner wrote: On Mon, 8 Oct 2007, Patrick W. Gilmore wrote: If you do you have permission from the owner of the block, you Should Not Announce it. Agreed. I stated above that you should not announce another provider's space without their permission, and you specifically agreed. Here you are talking about that space being announced without the owner's knowledge. Make up your mind. We both agree that announcing another provider's space without their consent is a Very Bad Thing. I doubt you will find people willing to post here to the contrary. If the owner _does_ know the space is being announced, the edge filters are no different whether it is originated in the second upstream's ASN or an ASN owned by the customer. So again, I ask, how is that different? You'll note that you left a word out above. He's agreeing that even if you do have permission, you shouldn't announce space from another provider. Type-o's suck. Thanx for pointing it out. Sorry for the confusion. Justin, if Provider A _has_ permission from Provider B to announce a prefix, do you believe Provider A should be allowed to announce the prefix? -- TTFN, patrick
Re: How Not to Multihome
On Oct 9, 2007, at 1:53 PM, [EMAIL PROTECTED] wrote: There are currently ~1500 prefixes with inconsistent origin AS. These are trivially identifiable: http://www.cymru.com/BGP/incon_asn_list.html Some of them are obvious mistakes (I doubt HKSuper is supposed to originate 4/8). But many of them are not, and the Internet works just fine. And as Justin said, some sizable fraction of those 1500 prefixes are quite possibly *appearing* to Work Just Fine currently, but if something breaks, that will be 1500 NOC monkeys facing some difficult-to-debug routing issues Considering the number of inconsistently originated prefixes has been non-trivial for at least a decade, I have trouble believing this is a huge threat to the internet. Or even those 1500 NOC monkeys. (And wouldn't it be 3K - at least 2 ASNs per prefix? :) -- TTFN, patrick
Re: How Not to Multihome
On Oct 8, 2007, at 5:43 PM, [EMAIL PROTECTED] wrote: I have a client that wants us to advertise an IP block assigned by another ISP. I know that the best practice is to have them request an AS number from ARIN and peer with us, etc. However, I cannot find any information that states as law. Does anyone know of a document or RFC that states this? There is nothing wrong with both of your originating the prefix, as long as the owner gives you permission. Plus it saves an ASN. If the link between you the customer dies, things get far more interesting, but that doesn't mean you can't or shouldn't do it. Of course, you can probably still find documentation against it. (You can find documentation for or against just about anything.) -- TTFN, patrick
Re: How Not to Multihome
On Oct 8, 2007, at 5:55 PM, Justin M. Streiner wrote: On Mon, 8 Oct 2007, [EMAIL PROTECTED] wrote: I have a client that wants us to advertise an IP block assigned by another ISP. I know that the best practice is to have them request an AS number from ARIN and peer with us, etc. However, I cannot find any information that states as law. Does anyone know of a document or RFC that states this? It's not 'law' per se, but having the customer originate their own announcements is definitely the Right Way to go. That is not at all guaranteed. Some providers take a pretty dim view of seeing chunks of their address space show up in advertisements originating from someone who isn't one of their customers. It can make troubleshooting connectivity problems for that customer (from the provider's point of view) very painful, i.e. Hey, this AS, who isn't one of our customers, is hijacking IP space assigned to one of our customers! The provider could then contact your host's upstream (s) and ask them to drop said announcement under the impression they're stopping someone from doing something bad. If you do you have permission from the owner of the block, you Should Not Announce it. If the owner gives you permission and can't figure out why their block is originated by another ASN as well, they need help. (Yes, I realize the latter part of the last sentence is probably true for the majority of providers, but whatever.) In either case, your hypothetical question should not hold. Also, if some network out there aggregates prefixes in an aggessive/ odd manner, the disjoint announcement, and the reachability info it contains could be washed out of their routing tables, causing connectivity problems. How is this different than if the customers gets their own ASN and announces a sub-block from one of the providers? Or are you suggesting they should get PI space? -- TTFN, patrick
Re: How Not to Multihome
On Oct 8, 2007, at 6:19 PM, Justin M. Streiner wrote: On Mon, 8 Oct 2007, [EMAIL PROTECTED] wrote: That brings up an interesing point. My biggest fear was that one of my other customers could possible be closer to me that the ISP that provides the primary link and it would cause them to favor the backup link because of AS path. I think they are going to fight me on this and telling them to multihome to their original ISP would probably be frowned upon at this point. I was hoping that there was an RFC for multihoming that I could use to bail myself out. If you went ahead and did this, the more specific route being announced by you on behalf of your customer would be more likely to attract traffic back to you. Prefix length is checked in the BGP route selection process before AS path length. This would work in normal everything works fine situations, but when things break, troubleshooting the source of the customer's reachabilit woes will get very interesting. You have made an assumption that the original upstream would not originate a prefix equivalent to the one you are originating. -- TTFN, patrick
Re: How Not to Multihome
On Oct 8, 2007, at 6:45 PM, Justin M. Streiner wrote: On Mon, 8 Oct 2007, Patrick W. Gilmore wrote: It's not 'law' per se, but having the customer originate their own announcements is definitely the Right Way to go. That is not at all guaranteed. I never said it was. My experience, both in my previous life as the operator of a regional ISP and since then in other capacities is that having disjoint origins for a chunk of some provider's address space is basically asking for trouble, and it's the kind of trouble that may ony pop up when something breaks. I'm afraid your experience is not the same as many, many people. There are currently ~1500 prefixes with inconsistent origin AS. These are trivially identifiable: http://www.cymru.com/BGP/incon_asn_list.html Some of them are obvious mistakes (I doubt HKSuper is supposed to originate 4/8). But many of them are not, and the Internet works just fine. My experience has also been that if a customer has a need to multihome and is willing to invest both in the equipment and the expertise to do so, then so be it. That statement does not say anything. If you do you have permission from the owner of the block, you Should Not Announce it. Agreed. If the owner gives you permission and can't figure out why their block is originated by another ASN as well, they need help. (Yes, I realize the latter part of the last sentence is probably true for the majority of providers, but whatever.) In either case, your hypothetical question should not hold. Also, if some network out there aggregates prefixes in an aggessive/odd manner, the disjoint announcement, and the reachability info it contains could be washed out of their routing tables, causing connectivity problems. How is this different than if the customers gets their own ASN and announces a sub-block from one of the providers? In the case you described, the provider who holds the parent address block should expect to see an advertisement for a chunk of that block come in as part of the BGP feeds they receive from their upstreams, and they need to accept traffic accordingly. The customer would need to tell the provider of their intentions to multihome. If the provider in question employs some type of ingress/egress filtering, that filter would need to be updated to recognize that traffic sourced from that sub-block as legitimate, even if it comes in over their normal transit pipes. In the case I described, where the end user requested that a third party provide transit for their PA space, without that provider necessarily being aware of it is when things can break in strange and spectacular ways. I stated above that you should not announce another provider's space without their permission, and you specifically agreed. Here you are talking about that space being announced without the owner's knowledge. Make up your mind. We both agree that announcing another provider's space without their consent is a Very Bad Thing. I doubt you will find people willing to post here to the contrary. If the owner _does_ know the space is being announced, the edge filters are no different whether it is originated in the second upstream's ASN or an ASN owned by the customer. So again, I ask, how is that different? Or are you suggesting they should get PI space? PI space, while nice, is not an option for many end users. Which is why I was assuming you did not mean PI space, but wanted to ask in case you were going to suggest it. -- TTFN, patrick
Re: How Not to Multihome
On Oct 8, 2007, at 9:46 PM, Justin M. Streiner wrote: On Mon, 8 Oct 2007, Patrick W. Gilmore wrote: If you went ahead and did this, the more specific route being announced by you on behalf of your customer would be more likely to attract traffic back to you. Prefix length is checked in the BGP route selection process before AS path length. This would work in normal everything works fine situations, but when things break, troubleshooting the source of the customer's reachabilit woes will get very interesting. You have made an assumption that the original upstream would not originate a prefix equivalent to the one you are originating. Internally or externally? A /24 would exist in the provider's IGP to point traffic to that customer. Well, internally is kinda useless to this discussion, wouldn't you think? I get the feeling that you are trying to ask a clever question there, but it didn't come across that way. Off the top of my head, I don't see why the provider who holds the parent block would do this externally. If the provider has, say, a /18 and they assign a /24 of that to this customer, there would be no legitimate reason to originate that /24 and propagate it out to the rest of the Internet. Note that I don't consider breaking that /18 up into 64 /24s and announcing them all separately to accomplish some sort of poor-man's traffic engineering to be a legitimate reason :) Interesting. Did you not read the first paragraph in this e-mail? In fact, I seem to recall that you wrote it (attribution is missing, so I can't be 100% certain). Personally, I'd call that a legitimate reason. To be clear, I am not suggesting de-aggregating every CIDR down to / 24s. But the global table doesn't grow any more whether the customer announces the /24 from their own ASN, or if you muti-originate it from two upstreams - or just one upstream for that matter. So there is no legitimate reason to _not_ announce it, but there is a reason to announce it. -- TTFN, patrick
Re: Upstreams blocking /24s? (was Re: How Not to Multihome)
On Oct 8, 2007, at 10:28 PM, David Conrad wrote: The argument, as I understand it (and those who argue this direction feel free to correct me if I misstate), is that as the IPv4 free pool exhausts, there will be a natural pressure to increase address utilization efficiency. This will likely mean longer prefixes will begin to be put (back) into use, either from assignments and allocations that were rediscovered or from unused portions of shorter prefixes. Customers will approach ISPs to get these long prefixes routed, shopping through ISPs until they find one that will accept their money and propagate the long prefix. Now, of course announcing a route doesn't mean anyone will accept it, but as I understand the theory, larger ISPs will agree to accept and propagate longer prefixes from other larger ISPs if those other ISPs will be willing to accept and propagate transmitted long prefixes (scratch my back and I'll scratch yours), particularly if this encourages the smaller ISPs to 'look for other employment opportunities' when they can't afford the router upgrades. We know this is not the case from history. For instance, look at Sprint ACL112. Also, we know from history that smaller ISPs sometimes are better able to do router upgrades than large ones. Personally, I fully expect the first part to happen. Where I'm having trouble is the second part (the accepting longer prefixes part). However, a few prominent members of the Internet operations community whom I respect have argued strongly that this is going to happen. I thought I'd ask around to see what other folk think... I'd bet against the first part happening, so the second part is moot. -- TTFN, patrick
Re: Extreme congestion (was Re: inter-domain link recovery)
On Aug 17, 2007, at 6:57 AM, Stephen Wilcox wrote: On Thu, Aug 16, 2007 at 09:07:31AM -0700, Hex Star wrote: How does akamai handle traffic congestion so seamlessly? Perhaps we should look at existing setups implemented by companies such as akamai for guidelines regarding how to resolve this kind of issue... and if you are a Content Delivery Network wishing to use a cache deployment architecture you should do just that ... but for networks with big backbones as per this discussion we need to do something else Ignoring Akamai and looking at just content providers (CDN or otherwise) in general, there is a huge difference between telling a web server do not serve more than 900 Mbps on your GigE port, and a router which simply gets bits from random sources to be forwarded to random destinations. IOW: Steve is right, those are two different topics. -- TTFN, patrick
Re: inter-domain link recovery
On Aug 15, 2007, at 12:06 AM, Chengchen Hu wrote: I find that the link recovery is sometimes very slow when failure occures between different ASes. The outage may last hours. In such cases, it seems that the automatic recovery of BGP-like protocol fails and the repair is took over manually. We should still remember the taiwan earthquake in Dec. 2006 which damaged almost all the submarine cables. The network condition was quit terrible in the following a few days. One may need minutes to load a web page in US from Asia. However, two main cables luckly escaped damage. Furthermore, we actually have more routing paths, e.g., from Asia and Europe over the trans-Russia networks of Rostelecom and TransTeleCom. With these redundent path, the condition should not be that horrible. And here is what I'd like to disscuss with you, especially the network operators, 1. Why BGP-like protocol failed to recover the path sometimes? Is it mainly because the policy setting by the ISP and network operators? Why do you think BGP was supposed to find the remaining path? Is it possible that the remaining fibers were not owned or leased by the networks in question? Or are you suggesting that any capacity should be available to anyone who needs it, whether they pay or not? BGP cannot find a path that the business rules forbid. -- TTFN, patrick 2. What is the actions a network operator will take when such failures occures? Is it the case like that, 1)to find (a) alternative path(s); 2)negotiate with other ISP if need; 3)modify the policy and reroute the traffic. Which actions may be time consuming? 3. There may be more than one alternative paths and what is the criterion for the network operator to finally select one or some of them? 4. what infomation is required for a network operator to find the new route? Thank you. C. Hu
Re: Content Delivery Networks
On Aug 10, 2007, at 12:46 PM, John Levine wrote: Very interesting. We've all heard and probably all passed along that little bromide at one time or another. Is it possible that at one time it was true (even possibly for AOL) but with the rise of CDNs, policies of not honoring TTL's have fallen by the wayside? I think you'll still see it in spam zombies, some of which have the DNS info pre-loaded into them in order to avoid split-horizon anti-spam techniques. Not much we can do about that until we get sufficient backbone to deal with the zombie problem and its software enablers. Actually, I think the fact Zombies do not honor TTLs is a feature. :) -- TTFN, patrick
Re: large organization nameservers sending icmp packets to dns servers.
On Aug 8, 2007, at 6:20 PM, william(at)elan.net [EMAIL PROTECTED] wrote: On Tue, 7 Aug 2007, Donald Stahl wrote: All things being equal (which they're usually not) you could use the ACK response time of the TCP handshake if they've got TCP DNS resolution available. Though again most don't for security reasons... Then most are incredibly stupid. Several anti DoS utilities force unknown hosts to initiate a query via TCP in order to be whitelisted. If the host can't perform a TCP query then they get blacklisted. How is that an anti DoS technique when you actually need to return an answer via UDP in order to force next request via TCP? Or is this techinque based on premise that an attacker will not spoof packets and thus will send flood of DNS requests to server from same IP (set of ips)? If so the result would be that attacker could in fact use TCP just as well as UDP. The anti-ddos box sends back a UDP reply with the TCP bit sent and no data. Which, I believe, violates the RFC. (But it is too hard to look up on my iPhone. :) If so, guess that makes those boxes 'stupid'. -- TTFN, patrick
Re: Content Delivery Networks
On Aug 7, 2007, at 3:59 AM, Michal Krsek wrote: 5) User redirection - You have to implement a scalable mechanisms that redirects users to the closes POP. You can use application redirect (fast, but not so much scalable), DNS redirect (scalable, but not so fast) or anycasting (this needs cooperation with ISP). What is slow about handing back different answers to the same query via DNS, especially when they are pre-calculated? Seems very fast to me. Application redirection is far, far slower. (I am assuming you are talking about something like HTTP level redirects. Did you mean something else?) As for anycast, with your own backbone, you don't need any cooperation. Even if you don't, the cooperation you need from your providers peers is minimal at worst. (At least relative to writing the code for, say, DNS redirection.) But anycast assumes BGP knows best, and we all know that is not even close to the truth. -- TTFN, patrick
Re: large organization nameservers sending icmp packets to dns servers.
On Aug 7, 2007, at 4:33 PM, Donald Stahl wrote: [...] If you don't like the rules- then change the damned protocol. Stop just doing whatever you want and then complaining when other people disagree with you. I think this last part is the key. Remember the old adage: My network, My rules? Have we forgotten that? Should I not block ports for MS protocols when a new worm spreads because it would break the E-2-E principal? What about spam filtering? Or a myriad of other things. Everyone here is breaking some RFC somehow. And most of us don't give a rats ass. Which is the way it should be. But when you decide that YOUR violation is MY problem to fix, then you are just being silly. And worse, annoying. Let's all just agree to run our own networks the way we damned well please, as long as we are not hurting anyone else. We just have to define omplaining to you about things I b0rk'ed by myself as hurting you. Which isn't a stretch, support costs money, and costing me money because you screwed up is definitely hurtful. -- TTFN, patrick P.S. To be clear, no, your pr0n site not resolving because I don't support TCP does not qualify as hurting you unless I call you to complain about it, even if it loses you revenue.
Re: Content Delivery Networks
On Aug 6, 2007, at 5:10 PM, Rod Beck wrote: Can anyone give a breakdown of the different kinds of content deliver networks? For example, we have Akamai, which appears to be a pure Layer 3 network that is tailored to pushing relatively small files like web pages and we have Lime Light Networks, which is a mix of Layer 1 and Layer 3, that focuses on bigger files like video streams. I am not sure why you would say Akamai is tailored to pushing relatively small files, since I do not believe they say that anywhere. LLNW does say they are focused on larger files. (I believe LLNW claims Akamai is focused on smaller files, but do you believe what Akamai says about LLNW?) I can confirm that Akamai does not have a backbone. Neither does Panther Express, CacheFly, or Mirror Image. While Level 3 (who owns Digital Island, which they bought from Savvis, who got that when they acquired Exodus, who bought way DI back when), LLNW, and att all have their own backbones. Any insights out there? And what are the major challenges in making scalable content delivery networks? Myriad. Some are hard to overcome, some are very hard. Keyword here being scalable - which you failed to define. What is scalable to you? 100 Gbps? 500 Gbps? The latter is medium-hard in the US, the former is nearly impossible in South Africa. Which brings us to geography. Are you US-centric? European? Asian? Six continents? Just a few specific countries? Plus, as you mention above, there's file size. How about streaming vs. HTTP? Optimize for latency or throughput? Did I mention cost? Etc., etc. If someone asked what are the major challenges in making scalable backbones?, how would you answer? -- TTFN, patrick
Re: large organization nameservers sending icmp packets to dns servers.
On Aug 6, 2007, at 4:43 PM, [EMAIL PROTECTED] wrote: On Mon, 06 Aug 2007 16:11:36 EDT, Matthew Crocker said: But you could, it isn't hard to dump a BGP view into a box from a border router and use that map to determine the proper DNS records to return. It's harder than it looks, given the number of people who pop up on this list and ask how to get BGP to Do The Right Thing when 2 paths are the same length but vastly differing in bandwidth, number-of-actual-hops, and/or latency Plus you are assuming BGP knows the right answer. People here are arguing ICMP Echo is a bad metric. BGP makes ICMP look like the gold standard. -- TTFN, patrick
Re: Why do we use facilities with EPO's?
On Jul 25, 2007, at 2:03 PM, Tuc at T-B-O-H.NET wrote: If they can be avoided, why do we put up with them? Do we really want our colo in downtown San Francisco bad enough to take the risk of having a single point of failure? How can we, as engineers, ask questions about how many generators, how much fuel, and yet take for granted that there is one button on the wall that makes it all turn off? Is it simply that having colo in the middle of the city is so convenient that it overrides the increased cost and the reduced redundancy that are necessitated by that location? You forgot the default Single Point of Failure in anything.. HUMANS. The earth is a SPoF. Let's put DCs on the moon. Besides, safety always overrides convenience. And I don't think that is a bad trade off. -- TTFN, patrick
Port 587 vs. 25 [was: DNS Hijacking by Cox]
On Jul 23, 2007, at 2:18 AM, Florian Weimer wrote: * Sean Donelan: On Sun, 22 Jul 2007, William Allen Simpson wrote: 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. MSA port 587 is only 9 years old. I guess it takes some people longer than others to update their practices. You missed the to their servers part (I don't think it's singular they 8-). At the intra-ISP level, submission vs. SMTP does not really matter because it's all local policy. If they block her on 25/TCP on their own servers, they can easily block her on 587/TCP, too. They can, but they do not. AFAIK, not a single ISP redirects port 587 to their own servers. Which is a good thing, since port 587 is usually backed by authentication. Which means you know who sent the mail (or at least which password was stolen to do so). And that is all people are looking for at this level - some way to tell who sent the mail so it can be stopped. IOW: ISPs have no real reason to stop port 587, they do have a reason (whether you agree it is sufficient or not) to filter port 25. -- TTFN, patrick
Re: DNS Hijacking by Cox
On Jul 22, 2007, at 9:29 PM, Steven M. Bellovin wrote: On Sun, 22 Jul 2007 14:56:13 -0700 Andrew Matthews [EMAIL PROTECTED] wrote: It looks like cox is hijacking dns for irc servers. And people wonder why I support DNSsec Steve, One of us is confused. It might be me, but right now I think it's you. To be clear, here is the situation as I understand it: Cox has configured their recursive name servers such that when an end user queries the recursive server for a specific host name (names?), the recursive server responds with an IP address the host's owner did not configure. How exactly is DNSSEC going to stop them from doing this? -- TTFN, patrick
dual-stack [was: NANOG 40 agenda posted]
On May 30, 2007, at 3:40 PM, Randy Bush wrote: This is a grand game of chicken. The ISPs are refusing to move first due to lack of content pure bs. most significant backbones are dual stack. you are the chicken, claiming the sky is falling. I guess we have different definitions for most significant backbones. Unless you mean they have a dual-stack router running _somewhere_, say, for instance, at a single IX or a lab LAN or something. Which is not particularly useful if we are talking about a significant backbone. That said, I certainly don't think content is doing well either. Nor am I trying to say which is at fault. In fact, not even sure I care who is at fault, if fault can even be apportioned. -- TTFN, patrick P.S. Don't suppose people could change the subject when, well, the subject changes?
Re: IPv4 multihomed sites statistics
On May 15, 2007, at 5:23 AM, Masafumi Watari wrote: I'm looking for statistics that may provide hints on the number of IPv4 multihomed sites that exist today. Are there any pointers? Perhaps start with the number of ASNs? Also, is there a way to find the average number of peers that these sites multihome with? If not, how large is it in general? Difficult to say, and lots of people have tried. Route-Views @ Oregaon, CAIDA, RIPE RIS, and many others has some data you might be able to morph into that. -- TTFN, patrick
Re: BOGON Announcement question
On Apr 30, 2007, at 11:11 AM, Randy Bush wrote: Collector: CIXP Prefix: 128.0.0.0/2 Last update time: 2007-04-27 07:36:30Z Peer: 192.65.185.140 Origin: 29222 My question is, why am I not seeing more issues because of the announcement? because everyone with enough clue to watch what they receive has filters in place to prevent their hearing it? And even if they didn't, what important IP space in that /2 is not covered by more specifics? -- TTFN, patrick
Re: IP Block 99/8 (DHS insanity - offtopic)
On Apr 23, 2007, at 4:36 PM, Kradorex Xeron wrote: On Monday 23 April 2007 14:40, J. Oquendo wrote: Marcus H. Sachs wrote: If we had clean registries and signed/verifiable advertisements this would not be an issue. Most of you know that DHS was pushing the Secure Protocols for the Routing Infrastructure initiative (http://www.cyber.st.dhs.gov/spri.html). Due to budget cuts this program is on the shelf for now. However, we are still interested in making it happen. I think that the discussion about 7.0.0.0/24 several days ago could also have been avoided if we had already implemented some of the SPRI ideas. Marc Out of utter curiousness (not arrogance)... Why in the world should the DHS be given control to the routing infrastructure when they can't even secure their own networks. That is rediculous... The DHS should have no juristictional power over an international and collective entity (The Internet), Why? Because the USA does not own the internet, no country does. it's just as I posted in the former: an international and collective entity. I do not want any particular gov't (US or otherwise) to be in charge of the Internet any more than the next person. And good thing too, because it simply cannot happen, political pipe-dreams not withstanding. But what has that got to do with the DHS promoting an idea to sign IP space allocations and/or annoucements? The idea in-and-of-itself doesn't sound wholly unreasonable. (I am not advocating this, just saying the idea shouldn't be rejected without consideration simply because the DHS said it.) Why not take the idea and see if it is useful, then implement it properly if there is any use? All this vitriol over the US gov't trying to take over the Internet is silly - sillier than the USG thinking it can actually do so. They're politicians, they're ignorant of reality and therefore can be excused for not understanding how stupid they sound. All of you should know better. -- TTFN, patrick
Re: IP Block 99/8 (DHS insanity - offtopic)
On Apr 23, 2007, at 5:04 PM, Mike Tancsa wrote: At 04:52 PM 4/23/2007, Patrick W. Gilmore wrote: I do not want any particular gov't (US or otherwise) to be in charge of the Internet any more than the next person. And good thing too, because it simply cannot happen, political pipe-dreams not withstanding. But what has that got to do with the DHS promoting an idea to sign IP space allocations and/or annoucements? The idea in-and-of-itself doesn't sound wholly unreasonable. (I am not advocating this, just saying the idea shouldn't be rejected without consideration simply because the DHS said it.) The question is who would do the signing and revocations. Whoever does that would indeed have a great amount of control over the internet. A single government agency should not have that sort of power to make a (for lack of better term), no surf list of IP space... Which is fine. Besides, no gov't _can_ have the single authority. You can always ignore what other people sign or do not sign. That said, I completely agree the DHS shouldn't have even the modicum of power holding the keys would give it. -- TTFN, patrick
Re: UK ISP threatens security researcher
well-deserved criminal record for his stupidity. Where is the criminal record for the idiot who allowed remote access with a single username and password to every single cable modem? That's pretty damned stupid. Honetly- when did we all become such vindictive assholes? Had the guy caused any real damage then you might have an argument. He didn't. We need to stop letting companies abuse the law instead of performing due dilligence. AOL Well Deserved Criminal Record For His Stupidity? I'm thinking that if stupidity qualifies one for a criminal record, the original poster must have a long rap-sheet. -- TTFN, patrick
Re: Number of BGP routes a large ISP sees in total
On Apr 18, 2007, at 2:43 AM, Mikael Abrahamsson wrote: On Tue, 17 Apr 2007, Yi Wang wrote: sense about the average (e.g., about 5? 10? 20?), as for a large ISP. Well, if you're interconnecting with other large ISPs in 5 places then you'll get each prefix at least 5 times. Having 5 eBGP sessions between two ASes is quite common if both are large ISPs. So yes, I'd say that between 5-10 is quite common. At least 5, and more than 10 for many prefixes, inside very, very large networks. -- TTFN, patrick
Re: Number of BGP routes a large ISP sees in total
On Apr 17, 2007, at 8:20 PM, Yi Wang wrote: I guess what I see there is the lower bound of the path diversity? Because even though an edge router received more than one path for a prefix, it'll only export the best route to the other edge routers of the ISP. Depends on the route server. If the route server has sessions with lots of edges, it will have lots of prefixes. If not, then it's generally got the same number of prefixes as you see in the CIDR report. But you said: if the RIB of all routers in the ISP were merged, how many distinctive routes would there be?. Define distinctive? Are you including things like same prefix path, but different next hop? If my guess is correct, the answer is it varies. Some networks have literally a dozen or more interconnection points. If the networks are large, then you have 10s of 1000s of prefixes, with dozens of next hops, and perhaps multiple that by multiple networks. Then realize that many of the prefixes are duplicated across multiple peers and Anyway, the number is very difficult to determine. And it is highly dependent on the network you look at. Mind if I ask why you want to know? Perhaps there are some simplifying assumptions we can make, depending upon your application? -- TTFN, patrick On Apr 17, 2007, at 8:02 PM, Ricardo V. Oliveira wrote: Telnet to any of these route servers: http://www.bgp4.net/wiki/doku.php?id=tools:ipv4_route_servers and do show ip bgp --Ricardo On Apr 17, 2007, at 4:45 PM, Yi Wang wrote: I should have said I'm interested in the merged size of RIB-In (which contains all the raw routes received). I couldn't find information about the number of different routes for the same prefix a (large) AS typically receives/learns. Hints? Yi On Apr 17, 2007, at 7:29 PM, Jeroen Massar wrote: Yi Wang wrote: Hi, Could anyone give me a sense how many BGP routes a large ISP typically sees in total? Here by in total, I mean if the RIB of all routers in the ISP were merged, how many distinctive routes would there be? Google(route bgp) I am feelink lucky aka first hit, and just look around there. Greets, Jeroen
Re: IPv6 Finally gets off the ground
On Apr 10, 2007, at 11:13 AM, Joseph S D Yao wrote: On Tue, Apr 10, 2007 at 03:54:39PM +0200, Stephane Bortzmeyer wrote: On Sun, Apr 08, 2007 at 06:15:34PM -0500, J. Oquendo [EMAIL PROTECTED] wrote a message of 24 lines which said: was successfully configured by NASA Glenn Research Center to use IPsec and IPv6 technologies in space. ... We're taking 10 gigabytes of the most popular adult entertainment videos from one of the largest subscription websites on the internet, and giving away access to anyone who can connect to it via IPv6. ... *sigh* Off the ground, then into the gutter, eh? From the heights to the depths ... First, I find it interesting that you are applying your personal morals to a technical discussion. Actually, I find it sad too. Second, who said v6 was the heights? Many people would argue this actually _lifts_ v6, not drags it down. (And most of those people would further argue v6 should have stayed down.) Third, where do you work? I work on the Internet. If you are opposed to pr0n, and you work on the Internet, you need to change jobs, FAST. Unless you enjoy self delusion. And don't even think about saying not on MY network. I don't care if you work for a .gov, there is plenty of nekkid-flesh-bits flying on your network. To think otherwise only proves you are delusional or ignorant. The only good thing I can say about this proposal is that 10GB is not NEARLY enough to get your typical luser to think about changing their configuration. Therefore, it probably won't have an impact on v6 adoption. (That ghod.) -- TTFN, patrick
Re: IPv6 Finally gets off the ground
On Apr 10, 2007, at 1:24 PM, Joseph S D Yao wrote: On Tue, Apr 10, 2007 at 12:10:59PM -0400, Patrick W. Gilmore wrote: ... Second, who said v6 was the heights? ... My, aren't we serious? Too serious to realize that satellites are a little higher than I, at least, can reach. Guess I missed that reference. Silly of me. Fine imagery. Just like the stuff you can get for free if you use a v6 stack :) As for being serious, I do believe you were the one who claimed v6 was going into the gutter, and the depth. Pot, kettle, black? Actually, you went beyond being serious by implying some type of moral superiority. Which is fine, you packets can be morally superior to mine -- TTFN, patrick
Re: single homed public-peer bandwidth ... pricing survey ?
On Mar 6, 2007, at 4:51 PM, Jason Arnaute wrote: I am currently hosted in a small, independent datacenter that has 4 or 5 public peers (L3, Sprint, UUnet, ATT and ... ?) Those are not public peers, those are transit providers. They are a very nice facility, very technical and professional, and have real people on-site 24 hours per day ... remote hands, etc. All very high end and well managed. But, I am charged between $150 and $180 per megabit/s for non-redundant, single-homed bandwidth (not sure which provider they put it on) and even if I commit to 20 or 30 megabits/s it still only drops down to $100 - $120 per megabit/s. That is not single-homed bandwidth. You listed 4 transit providers yourself, so they obviously have more than a single path to the Internet. So naturally, I am very interested when I see HE.NET offering bandwidth for $20/mb/s, and it looks like Level3 is selling for $30/mb/s... Have you checked on volume. L3 will not give you $30/Mbps for one megabit. How much are you buying now? Are there two classes of bandwidth in the world ? Is it reasonable and expected that single homed public peered bandwidth is, circa Jan 2007, going for above $100/mb/s while private peered bandwidth like L3 and HE.NET is $30 and below ? Private peered bandwidth? That is a new term I've never heard. What makes you think L3 HE are different from the place selling you transit now? Care to define your terms? Or am I just getting ripped off ? Entirely possible. -- TTFN, patrick
Re: single homed public-peer bandwidth ... pricing survey ?
On Mar 6, 2007, at 6:00 PM, Jason Arnaute wrote: --- Patrick Giagnocavo [EMAIL PROTECTED] wrote: Jason Arnaute wrote: I am currently hosted in a small, independent datacenter that has 4 or 5 public peers (L3, Sprint, UUnet, ATT and ... ?) They are a very nice facility, very technical and professional, and have real people on-site 24 hours per day ... remote hands, etc. All very high end and well managed. But, I am charged between $150 and $180 per megabit/s for non-redundant, single-homed bandwidth (not sure which provider they put it on) and even if I commit to 20 or 30 megabits/s it still only drops down to $100 - $120 per megabit/s. Are you sure that you are connected to only one provider? You mean that they are not doing BGP so that if one connection goes down, another path to the Internet is available? Yes, that's what I am saying - one pipe only, and if it goes down, I go down. I am confused. You list 4 very, very large providers, yet say the datacenter has one pipe. Those two statements are in conflict - you can't get all 4 of them on one pipe. Also, you have not mentioned your volume. You say L3 is $30/Mbps, but they are no where near that for 1-5 Mbps of traffic. -- TTFN, patrick So ... I am wondering if roughly $150/mb/s is just way off the charts for something like that, or if I am only overpaying by roughly 10-30% or so ... And then, of course, I'd like to be pointed to where I can learn why HE.NET and L3 are so cheap compared to that, and what my cost/benefit would be to switching... (as for racks and power, it is on the high average side. Roughly $1000/mo for a full cabinet) __ __ Don't get soaked. Take a quick peek at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather
Re: meeting in the Dominican Republic
On Feb 26, 2007, at 1:05 PM, Martin Hannigan wrote: What reason would NANOG have for holding a meeting in DR? Not a lot of context. DR is also in the LACNIC region. LACNIC has meetings similiar to RIPE in content i.e. policy and ops. http://lacnic.net/en/eventos/lacnicix/index.html LACNIC is not the equivalent of NANOG any more than ARIN is. According to http://lacnic.net/en/sobre-lacnic/cobertura/ index.html, LACNIC covers Mexico. If a meeting were suggested in Mexico, would you say NANOG should not meet there because LACNIC has meetings there? Perhaps the DR is not considered North America, but I thought it was. It is closer to Florida than Puerto Rico, which is part of the US. If the DR is not in NA, then we can have a discussion about the applicability of NANOG meeting there. Since it is part of North America, and it has Internet networks, I don't see anything wrong with having the North American Network Operators Group meeting there. IMHO, YMMV, etc. -- TTFN, patrick
Re: meeting in the Dominican Republic
On Feb 26, 2007, at 2:38 PM, Martin Hannigan wrote: On Feb 26, 2007, at 1:05 PM, Martin Hannigan wrote: What reason would NANOG have for holding a meeting in DR? Not a lot of context. DR is also in the LACNIC region. LACNIC has meetings similiar to RIPE in content i.e. policy and ops. http://lacnic.net/en/eventos/lacnicix/index.html LACNIC is not the equivalent of NANOG any more than ARIN is. According to http://lacnic.net/en/sobre-lacnic/cobertura/ index.html, LACNIC covers Mexico. If a meeting were suggested in Mexico, would you say NANOG should not meet there because LACNIC has meetings there? One of the reasons why these spots are in the LACNIC region is language. They don't speak english. I would say that if LACNIC has a meeting in a non english speaking location that we should seriously consider NOT holding meetings in locations that duplicate effort. There has to be a better reason than a warm body willing to pay. One could make this argument for much of Canada. :) It would make far more sense to hold a meeting in Jamaica[1], or the rest of the english speaking Caribbean. Sounds good. I like Aruba personally. Can we do it the week before the poker tournament? :) -- TTFN, patrick
Re: meeting in the Dominican Republic
On Feb 26, 2007, at 11:42 PM, Martin Hannigan wrote: Incorrect. I think that there are more than just philanthropic considerations and language is one, as well as financials being another. I believe the majority of the list is in agreement. We all agree that there is more to this than going there to help out a poor country. But your arguments about financial considerations are, in your own words, a straw-man. The _very_first_post_ in this thread said: It appears that we can expect hotel costs to be quite a bit lower than than at most recent NANOG meetings (perhaps as low as $100 per night). Flights might cost a little more than they would for a mainland meeting, but non-scientific poking at the usual travel web sites doesn't seem to indicate that they would be ridiculous. The proposal we have accommodates the networking requirements of NANOG meetings. It then asked things like whether you were more or less likely to go to the DR than Canada. These are perfectly valid questions. You've brought up some counter-points, but I think we all get the point. I just don't think we all agree with your PoV. Which is what makes NANOG so great. :) Back on topic, I've already said I don't believe the DR will be a problem vis-a-vis travel policies, and I would like to go to the DR for NANOG. Anyone else wanna answer the questions which were asked? -- TTFN, patrick
Re: Do routers prioritize control traffic?
On Feb 12, 2007, at 8:55 AM, Christos Papadopoulos wrote: I know routers today have the ability to prioritize traffic, but last I heard, these controls are not often used for user traffic (let's not discuss net neutrality here). Are they used for control (e.g., routing) traffic? Please say a bit more than It depends! :-) Our students are interested in real-world practices. Real world answer: It depends. :) For instance, Juniper routers auto-police all traffic destined for the main CPU. Cisco routers (usually) do not. You can configure it, though. Newer ciscos have very nice policing options for traffic to the main CPU. Older ones still have options, but the policing can hurt the router in its own way. There is also some auto-policing in ciscos, e.g. only one ICMP echo request per second per source IP address will be allowed to hit the CPU. Hope that helps. -- TTFN, patrick
Re: i wanna be a kpn peer
On Jan 10, 2007, at 10:54 PM, Chris L. Morrow wrote: On Wed, 10 Jan 2007, Randy Bush wrote: route-views.oregon-ix.netsh ip bg 203.10.63.0 BGP routing table entry for 0.0.0.0/, version 2 do most folks setup route-views peers as a 'standard customer' or are they generally on a special purpose box with special (easy to forget about and screw up) box? Or even a special purpose box that intentionally gives an unfiltered view? I don't think a spurious prefix directly injected into route-views is proof a network is broken. -- TTFN, patrick
Re: i wanna be a kpn peer
On Jan 10, 2007, at 11:28 PM, Randy Bush wrote: I don't think a spurious prefix directly injected into route-views is proof a network is broken. we've had this discussion 42 times. it is not proof of anything and no one has said it is. but if it was one of my areas of responsibility leaking something strange, i sure would not mind folk mentioning it here. in fact, i would be greatful. It is not proof. No one said it was. And no one said you said it was. :) That said, I would be grateful if someone showed me I screwed up too - in private. In public, I'm not so sure. Especially if someone only -thought- I screwed up. One could argue that it is difficult to reach the proper people privately (although noc@ might be a start, or iNOC-DBA, or ...). One could also argue that public notification is better than no notification. But then one would might want to mention that private channels had been exhausted in one's public notification. Anyway, this one is sorry if that one thought one was being curmudgeonly. :) -- TTFN, patrick
Re: Network end users to pull down 2 gigabytes a day, continuously?
On Jan 7, 2007, at 8:59 AM, Alexander Harrowell wrote: 1) Just unicasting it over the radio access network is going to use a lot of capacity, and latency will make streaming good quality tough. I'm confused why high latency makes streaming good quality tough? Perhaps this goes back to the streaming vs. downloading problem, but every player I've ever seen on a personal computer buffers the content for at least a second, and usually multiple seconds. Latency is measured in, at most, 10th of a second, and jitter another order of magnitude less at least. High latency links with stable throughput are much better for streaming than low latency links with any packet loss, even without buffering. IOW: Latency is irrelevant. -- TTFN, patrick
Re: Network end users to pull down 2 gigabytes a day, continuously?
On Jan 7, 2007, at 3:17 PM, Brandon Butterworth wrote: The real problem with P2P networks is that they don't generally make download decisions based on network architecture. Indeed, that's what I said. Until then ISPs can only fix it with P2P aware caches, if the protocols did it then they wouldn't need the caches though P2P efficiency may go down It'll be interesting to see how Akamai co. counter this trend. At the moment they can say it's better to use a local Akamai cluster than have P2P taking content from anywhere on the planet. Once it's mostly local traffic then it's pretty much equivalent to Akamai. It's still moving routing/TE up the stack though so will affect the ISPs network ops. ISPs don't pay Akamai, content owners do. Content owners are usually not concerned with the same things an ISP's newtork ops are. (I'm not saying that's a good thing, I'm just saying that is reality. Life might be much better all around if the two groups interacted more. Although one could say that Akamai fills that gap as well. :) Anyway, a content provider is going to do what's best for their content, not what's best for the ISP. It's a difficult argument to make to a content provider that putting their content on millions of end user HDs depending on grandma to provide good quality streaming to Joe Smith down the street. At least in my experience. -- TTFN, patrick
Re: Collocation Access
On Dec 27, 2006, at 3:42 PM, Jim Popovitch wrote: On Wed, 2006-12-27 at 09:06 -0800, Owen DeLong wrote: Savvis wants to retain your ID if they issue a cage-key to you. If they (or others) asked you to let them hold $50 cash to cover their key/lock replacement costs would you feel more comfortable? Very much so. I realize this may not be a universally held preference. I also realize the trouble in having low-paid security guards, frequently outsourced so they are not even your employees, handling cash from random people at all hours of the day, night, and weekends. But I'd much rather lose $50 and argue about getting that back than my passport. ESPECIALLY since I would only be giving my passport when I am out of the country. To open a totally separate can-of-worms, why not take my driver's license? Easier to replace than a passport and much less trouble when crossing borders. And before someone says they don't know what a DL from $COUNTRY looks like, realize that they really don't know what a passport looks like either. -- TTFN, patrick
Re: Collocation Access
On Dec 27, 2006, at 6:13 PM, Leo Vegoda wrote: On Dec 27, 2006, at 11:20 PM, Patrick W. Gilmore wrote: [...] To open a totally separate can-of-worms, why not take my driver's license? Easier to replace than a passport and much less trouble when crossing borders. And before someone says they don't know what a DL from $COUNTRY looks like, realize that they really don't know what a passport looks like either. My driving license doesn't have a photograph on it, so using it as an identity document is pointless. Some organisations use it that way, but... Sorry, I thought we were discussing something to be held by the staff to ensure you return an access card. That does not have to be the same document used to verify identity. Last time I checked, the $50 (or £20, or ¥5000 or whatever) bill didn't have my picture on it either. Although I admit the $50 bill gets me into more places than my DL. ;) -- TTFN, patrick
Re: Reasons for attendance drop off
On Nov 30, 2006, at 5:01 PM, Christian Nielsen wrote: If the issue is to save costs for the attendees, IMHO the best place would be Las Vegas during the non-peak travel dates. Nanog Starts on Sundays and goes to Wednesdays. Flights into and out of Vegas are not as full going in on Sunday and out on Wednesday. As much as I respect your opinion, Christian, I have to disagree. There is no off time for Vegas, it is always full. Yes, flights are always cheap too, but I still do not think it is a good idea. The NANOG held Vegas was the least useful in my memory, and I have attended every NANOG now for ... well, forever in Internet terms. Usually NANOG comes to a hotel and takes over that hotel. Or is at least a very significant fraction of the hotel bar / meeting rooms / etc. In Vegas, we were a fly-speck. There was no real place to meet. It was hard to find participants at all, and impossible find them by just wondering the halls or lobby bar. And when you did find someone, it was harder to find a quiet place to talk. I love Vegas, go there multiple times a year, and even own a time- share there. So this is not an anti-Vegas rant. But I -STRONGLY- suggest that we not hold another NANOG in Vegas. I could possibly be persuaded otherwise if we did not use one of the strip hotels, but something off-the-beaten-path where NANOG was not overwhelmed by the sound of slot machines. -- TTFN, patrick
Re: problem with BGP or I am an Idiot
On Nov 17, 2006, at 9:57 AM, Bruce Pinsky wrote: Probabaly the the latter; however here is the situation. I am advertising a rte 1.1.1.1 via BGP to the Internet via ISP_A via my location in NJ. At my other location in CA where I am advertising another rte 2.2.2.2 via BGP to the Internet via the same ISP_A. I am using the same AS for both routes. For some reason on my rtr advertising the 2.2.2.2 rte I am unable to see the 1.1.1.1 rte % Network not in table. I know 1.1.1.1 rte is valid it shows up in looking glass and ISP_A has it on the peer 2.2.2.2 recevies full Internet rtes from. Further verification: I add a static rte on 2.2.2.2 rtr to 1.1.1.1 and its routable??? How is this possible? I have the following filters but I removed them and it seems to not make a diff. OUTBOUND - ip as-path access-list 1 permit ^$ ip as-path access-list 1 deny .* INBOUND - ip as-path access-list 2 permit .* Loop protection. Throw away any route I hear from someone else with my AS. As long as you are hearing default your transit providers (you do have at least two, right? if you only have one, you don't need BGP and are just polluting the routing table), it won't matter if you can hear the prefix from your other location. -- TTFN, patrick
Re: Cogent now peering with Sprint?
On Oct 31, 2006, at 2:12 AM, Bob Collie wrote: That looks like a transit connection that Cogent bought at Ashburn, VA, not SFI peering connection. Hrmm, I can't tell by looking at a traceroute who paid whom, if anyone. Care to explain your magic? Is there a code in the in- addrs? Perhaps sl-$FOO means something in Sprint-speak? Secondly, does anyone really give a rat's ass who is SFI any longer? There are at least 2 fully SFI networks who can't route half as well as a whole slew of non-SFI networks these days. If [Cogent|Sprint] [buying|peering|whatever] [from|with] [Cogent| Sprint] makes their network better (i.e. lower latency, lower packet loss, higher throughput, and, if you care, lower jitter), I applaud them. Anyone who thinks X pays Y is more important than any of the metrics above needs to reevaluate their priorities. (At least from a customer / engineering PoV. I wouldn't suggest $NETWORK's bean counters have the same priorities as their network engineers customers. :) IMHO, of course. -- TTFN, patrick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Ray Sent: Tuesday, October 31, 2006 12:11 AM To: nanog@merit.edu Subject: Cogent now peering with Sprint? I never thought Sprint would ever renew its relationship with Sprint: Tracing the route to portus.netsecdesign.com (66.6.208.6) 1 sl-bb24-rly-9-0.sprintlink.net (144.232.14.122) 0 msec 0 msec 0 msec 2 sl-st22-ash-6-0.sprintlink.net (144.232.20.189) 0 msec 4 msec 0 msec 3 p15-2.core01.iad01.atlas.cogentco.com (154.54.13.61) [AS 174] 4 msec 4 msec 0 msec 4 v3492-mpd01.iad01.atlas.cogentco.com (154.54.3.222) [AS 174] 16 msec 80 msec 196 msec 5 v3497.mpd01.dca01.atlas.cogentco.com (154.54.5.65) [AS 174] 4 msec 4 msec 4 msec 6 t9-3.mpd01.iah01.atlas.cogentco.com (154.54.2.222) [AS 174] 44 msec 44 msec 48 msec 7 t2-3.mpd01.lax01.atlas.cogentco.com (154.54.3.186) [AS 174] 72 msec 72 msec 72 msec 8 g2-0-0.core01.lax01.atlas.cogentco.com (154.54.2.101) [AS 174] 72 msec 72 msec 72 msec 9 g49.ba01.b002698-1.lax01.atlas.cogentco.com (66.250.12.130) [AS 174] 72 msec 72 msec 72 msec 10 PAJO-Networks.demarc.cogentco.com (38.112.9.190) [AS 174] 72 msec 76 msec 72 msec 11 dcap04.pcap.lax01.tierzero.net (216.31.128.14) [AS 11509] 72 msec 76 msec 72 msec 12 mmic-gw.dcap6.lax.us.tierzero.net (216.31.188.94) [AS 11509] 76 msec 80 msec 80 msec 13 dazedandconfused.netsecdesign.com (66.6.208.4) [AS 11509] 84 msec 84 msec 88 msec 14 portus.netsecdesign.com (66.6.208.6) [AS 11509] 84 msec 84 msec 88 msec Next I will see pigs flying :) Wonder how long it will last based on Cogent's past behavior as noted here. Edward Ray - This mail was scanned by BitDefender For more informations please visit http://www.bitdefender.com -
Re: register.com down sev0?
On Oct 28, 2006, at 10:52 AM, Donald Stahl wrote: I submitted both spams to spamcop and the appropriate abuse addresses would have been notified in both cases. I got no response from either of my submissions. As for a reason for ignoring my complaint I really couldn't say since, well they ignored me. Did you ever send a complaint to [EMAIL PROTECTED] and [EMAIL PROTECTED] personally (so that you could actually verify it was sent and delivered)? I've never dealt with a company that didn't at least acknowledge receipt of a complaint. Then you must not deal with very many companies. (Not a comment on Register.com, 'cause I don't, and will never, know if they respond since I block their mail to avoid bogus renewal notices.) -- TTFN, patrick
DNS DDoS [was: register.com down sev0?]
On Oct 26, 2006, at 1:31 AM, [EMAIL PROTECTED] wrote: It is essentially impossible to distinguish end-user requests from (im)properly created DoS packets (especially until BCP38 is widely adopted - i.e. probably never). Since there is no single place - no 13 places - which can withstand a well crafted DoS, you are guaranteed that some users will not be able to reach any of your listed authorities. Yeah - I know it hard-to-impossible to do that, and it is a tug-of-war between worm writers (to generate queries indistinguishable from real client-resolver-generated queries) and trying-to-detect-malformed- queries (such as duplicated qid, or from IP space that shouldn't be hitting this specific node). You probably dealt with more ddos than rest of us combined, so I bow to your superior knowledge. First, thanx for the nod, but there are some here who have dealt with more than I have. But I think I've seen enough to know something about it. You can try things like filter IP addresses which should not be going to node X, but what happens if the DDoS changes the network topology enough that you can't be certain users are going where you did not? If the DDoS is large, this is pretty much guaranteed. Worse, suppose the topology changes for reasons unrelated to a DDoS. You could end up DoS'ing end users without an attack! (You could theoretically only put the filters in place when an attack is happening, but that has other problems - which may or may not be worse.) Filtering on things like duplicated query IDs is not possible on router hardware doing 10s of Gbps or millions of PPS. And doing it on the server is not useful if there are more bits / pps than the router can process. Remember, servers can't answer packets that are dropped before they get to the servers. Etc., etc., etc. Overall, we are losing the war. What good providers, like the roots, Ultra, etc., do is to minimize the effect of any attack. If a miscreant fires the DDoS of biblical proportions and only 5% of users are affected, I consider that a success. Unfortunately, those 5% don't think so, but one can only do what one can do. Besides, if it truly is an attack of biblical proportion, those 5% are probably having much larger problems than name resolution. Couple other comments: From all indications I've seen (and most are not authoritative, but it's all the info I have), this was not a DDoS of biblical proportions. There were no whole networks to go offline, there were no massive swaths of address space flapping, there were no entire peering points being congested, etc. A few Gbps does not count as biblical any more. Whether this attack used spoof-source or not, BCP38 is _VITAL_, IMHO, to helping curb these things. It guarantees, at the very least, that you know where the attack is sourced. Filtering become much easier. Reaching the right operators to help with the problem becomes orders of magnitude easier. And if the miscreants just start using BotNets with real IP address, GOOD. It's not the End All Be All answer, but it is a _huge_ step in the right direction. Unfortunately, as Jared has pointed out, the equipment vendors have to help the operators support this. So let's all call your favorite router vendor and ask them when they will have the ip bcp38 config option. :) -- TTFN, patrick
Re: BCP38 thread 93,871,738,435 (was Re: register.com down sev0?)
On Oct 26, 2006, at 9:33 AM, Steven M. Bellovin wrote: Put another way, anti-spoofing does three things: it makes reflector attacks harder, it makes it easier to use ACLs to block sources, and it helps people track down the bot and notify the admin. Are people actually successfully doing either of the latter two? I'd be surprised if there were much of either. That leaves reflector attacks. Are those that large a portion of the attacks people are seeing? I disagree. As someone who has been attacked by spoof-source packets, and not-spoof-source packed, I can say, from personal experience, that the former is much, much easier to mitigate. And, as I posted before, even if all universal adoption of BCP38 means is that DDoS attacks move to botnets with 100% real source IP addresses, that would still be a Very Good Thing, IMHO. But perhaps others feel differently. Or perhaps they just haven't been attacked enough. :) -- TTFN, patrick
Re: register.com down sev0?
On Oct 26, 2006, at 11:24 AM, Randy Bush wrote: the case for which we know bcp 38 is useful, is the dns reflector attack. so far, botnets seem to have no need to spoof, they just overwhelm you with zombies from real space. Incorrect. While that is one mode of attack from a botnet, it is not the only mode. And there are reasons for even botnets to spoof source addresses. And reasons that the attack-ee would prefer they did not. Randy, are you REALLY arguing -against- BCP38? Or just yanking Fergie's chain 'cause it wouldn't have helped in this particular instance? -- TTFN, patrick
Re: register.com down sev0?
On Oct 26, 2006, at 12:14 AM, [EMAIL PROTECTED] wrote: On 26 Oct 2006, Paul Vixie wrote: i wonder if that's due to the spam they've been sending out? Paul, this isn't nanae. Let's not sling accusations like that wildly. Accusations and objective facts are two separate things. there is no zone anywhere, including COM, the root zone, or any other, that is immune from worst-case DDoS. anycast all you want. diversify. build a name service infrastructure larger than the earth's moon. none of that will matter as long as OPNs (the scourge of internet robustness) still exist. This isn't 2001, and, I will argue that it *is*, in fact, possible to be protected from a worst case ddos, and not at obscene price. You are mistaken. However, even if you argue that point, there's no excuse for not being prepared at all, and not following the BCP. While we all may be guilty of not having topologically/geographically diverse DNS - for someone whose core business is DNS, that's unexcusable. We agree. Given that register.com is/was public (I think?) - I wonder what are their sarbox auditors saying about it now ;) that's an easy but catty criticism, and baseless. i'm sure that some way could be found to improve register.com's infrastructure, and i don't just mean by stopping the spamming they've been doing. but it's not trivial and in the face of well-tuned worst-case DDoS, nothing will help. Well, let's talk about worst-case ddos. Let's say, 50mpps (I have not heard of ddos larger that that number). Let's say, you can sink/filter 100kpps on each box (not unreasonable on higher-end box with nsd). That means, you should be able to filter this attack with ~500 servers, appropriately place. Say, because you don't know where the attack will come in, you need 4 times more the estimated number of servers, that's 2000 servers. That's not entirely unreasonable number for a large enough company. Even assuming your numbers, which I do not grant, you are still mistaken. There is no single appropriately[sic] place which can absorb 50Mpps. If you meant appropriately placed (as in topologically dispersed locations), a well crafted attack could still guarantee _at least_ a partial DoS from an end user PoV. It is essentially impossible to distinguish end-user requests from (im)properly created DoS packets (especially until BCP38 is widely adopted - i.e. probably never). Since there is no single place - no 13 places - which can withstand a well crafted DoS, you are guaranteed that some users will not be able to reach any of your listed authorities. This is not speculation, this is fact. All a good provider can do, even with 1000s of server, is minimize the impact of any DoS. Oh, and putting 2K servers into the right places is not a trivial expense, even for a large company. Last time I checked, 10GE pipes were not handed out for free. And you can't just rack these things in mom-and-pop colo saying well, it has a GigE on the motherboard when the colo has an OC3 to the 'Net. The Cap- and Op-Ex involved in doing what you suggest properly is large enough to probably be prohibitively expensive for a company like register.com. I know that the above was just rough back-of-the-envelope, and things are far more complicated than that, but this discussion does not really belong to nanog-l. We disagree. Keeping large name servers running is _absolutely_ a network operations topic. Not only is the defense mostly network based (since the network is the most likely thing to break), network operators are the people who get the phone calls when DNS does break. -- TTFN, patrick
Re: Did Cogent L3 de-peer again?
On Oct 23, 2006, at 3:42 PM, chuck goolsbee wrote: We've had a few customers report issues. We don't see anything too bad from here, but Keynote scoreboard has been showing some ugly between those two networks for the past hour or so. It has been about a year since the last time hasn't it? Apparently not: HOSTLOSS RCVD SENTBEST AVG WORST [...] cogent-level3-ge.NewYork1.Level3.net 0%10 101.12 13.67 63.39 p4-0.core02.dca01.atlas.cogentco.com 0%10 106.88 7.298.70 [...] -- TTFN, patrick
Re: Refusing Pings on Core Routers??? A new trend?
On Oct 19, 2006, at 10:14 PM, Rubens Kuhl Jr. wrote: template response -- I hear is Well, you can't rely on traceroute because of ICMP prioritisation. When you start to explain how traceroute actually works (both ICMP-based and UDP-based (which still relies on ICMP responses, of course!)), and that ICMP prio should only affect the IP of which the router listens on (and not hops beyond or at the dest), most NOCs fire back with another If I recall well, Cisco GSRs impose low priority and/or limits for all ICMP traffic flowing thru the box, not just packets to/from router itself, and there's not a knob to adjust that. You don't recall well. Although there is a knob if you want to tweak it. But there's a knob for just about everything - it's just not tweaked by default. -- TTFN, patrick
Re: Boeing's Connexion announcement
On Oct 15, 2006, at 5:44 PM, Rich Fulton wrote: and you will NEVER see this service again until there is a monetary incenctive to offer said service. So.. why is this still a discussion? I seem to recall someone (Rodney?) saying it was already generating positive cash flow on high-tech-city-to-high-tech-city routes, and mentioning HK Seattle. Seem to me supporting Internet access is on topic. (Although I admit things like seat-power might be considered a bit too tangential. :) -- TTFN, patrick
Re: Boeing's Connexion announcement
On Oct 14, 2006, at 9:04 PM, Todd Underwood wrote: I disagree. i disagree with your disagreement. You are welcome to your opinion. Seat power is ubiquitous on some airlines (e.g. American), and available in all but coach on others (e.g. Virgin, Luftansa). It's all but coach? seriously? hilarious. democracy is available to all but the majority wealth is available for all but the middle class and poor come on. In Virgin, BA, etc., there are frequently -four- classes on an international flight. You can get premium economy just by having status on some airlines, or buying a full-fare coach ticket on others (e.g. BA). It really ain't that hard, or expensive. Especially for biz travelers who can't always make plans a month in advance. That said, yeah, I mostly fly coach. seat power is not ubiquitous on american, either. it's on every 3rd seat or some nonense and there's no way to figure out whether you are in such a seat. i identified this early on as one of th emajor factors causing this service to fail. Interestingly, I fly over 50K miles per year on AA on average and have very, very rarely not had seat power. Guess I've been lucky. BTW: Jet Blue, whom I love otherwise, says they will not install seat power. Something about the cabling for the TV. They were very nice about my request, but very firm about not having any plans for seat power any time in the future. I guess TVs make more money than laptops. AC power is not required. Bigger seats might be. :) bigger seats may not be required. ac power is. This is where we disagree. My G4 PB gives me 4 hours of use with a new batter, and over 2 hours with a 3 year old battery. I hear the new Intel ones give 5+ hours. How much do you need? SJC - IAD is only 5/6 hours, and you can't use your laptop the whole time (take off, landing, snacks, toilet breaks, etc.). However, that same 12 PB (not a large laptop by any definition) on Luftansa is close unusable in coach if the person in front of you leans back. I had to contort pretty horribly to use it. (Which I did, 'cause I -had- to send e-mail from the plane. :) Lack of seat power was not an issue, I just had two batteries. And this was BOS - MUC, which ain't a short flight. Using a 15 or larger laptop on that flight is essentially unthinkable. I could not have opened the laptop enough to see the screen. During meals, the flight attendants made everyone sit up, otherwise the people behind them wouldn't have been able to eat. Yes, it was that bad. Summary: Bigger seats are required, seat power may not be. Maybe this is how they get you to upgrade so you can use seat power. :) P.S. I used it for 4 hours on Luftansa in coach, without seat power. And would happily pay $27.95, perhaps more, to use it again. /me too. the price is well-worth it. At least we agree on something. -- TTFN, patrick
Re: Boeing's Connexion announcement
On Oct 14, 2006, at 2:13 AM, Roland Dobbins wrote: On Oct 13, 2006, at 1:52 PM, Rodney Joffe wrote: Maybe the Connexion folks on the list could tell us what is needed to make it work on the network side - I'm sure we have enough resources between us to handle that. And there are a number of aircraft that already have the equipment... The biggest obstacles to success for a service of this type are a) high cost and b) the lack of AC power throughout most commercial airliners. Some folks are willing to put up with a), but not for just a couple of hours due to b). Until AC power is prevalent throughout the cabins of commercial airliners, it's unclear whether such a service will attract sufficient subscribers to become economically viable, IMHO. I disagree. Seat power is ubiquitous on some airlines (e.g. American), and available in all but coach on others (e.g. Virgin, Luftansa). It's useful and requested enough that Virgin actually uses it as a reason to fly premium economy (or whatever they call it). iGo's their cousins are available at every major airport, as well as most electronics computer shops, and sell millions upon millions per year. Add to that laptops with 5 7 hour life spans becoming more common, and even seat power is not as necessary. AC power is not required. Bigger seats might be. :) -- TTFN, patrick P.S. I used it for 4 hours on Luftansa in coach, without seat power. And would happily pay $27.95, perhaps more, to use it again.
Re: Aggregation path information [was: 200K prefixes - Weekly Routing Table Report]
On Oct 14, 2006, at 11:09 AM, Paul Vixie wrote: [EMAIL PROTECTED] (Patrick W. Gilmore) writes: Obviously the table contains kruft. But I know we could not shrink it to 109K prefixes without losing something from where I sit. Are you sure there's no additional path info? before we could be sure that an aggregation proposal was nondestructive, we'd have to model it from where a lot of people sit, not just patrick. I do believe that was the point of my second third sentence. on the one hand this seems to be a useful endeavour. in addition to measuring the total number of routes, we probably ought to measure the number of non-TE-related routes, and focus our attention on those routes and also the ratio (global TE cost borne by the routing system.) I'm not sure you could separate TE routes from $FOO routes externally. Unless you classify everything that doesn't go the way - you- think it should go as TE. (Possibly a valid assumption.) on the other hand i dispair of finding a set of observation posts and metrics that will abstract TE out of the observed routes in a way that wouldn't be seen as controversial or useless by most of the community. Since we are discussing putting pressure on people who do stupid thing, not shooting them in the head, we do not need to be 100% accurate. A list of provider who most likely are filling the table, and then allowing people to filter, prod, annoy, e-mail, call, etc., those providers is enough. Right now we just have these people could -theoretically- aggregate, without actually knowing if path info is lost. -- TTFN, patrick
200K prefixes - Weekly Routing Table Report
On Oct 13, 2006, at 2:02 PM, Routing Analysis Role Account wrote: Routing Table Report 04:00 +10GMT Sat 14 Oct, 2006 Analysis Summary BGP routing table entries examined: 200339 Prefixes after maximum aggregation: 108814 Shall we all have a moment of silence for 200K prefixes in the global table. Maybe reboot all our routers at once or something? -- TTFN, patrick
Aggregation path information [was: 200K prefixes - Weekly Routing Table Report]
On Oct 13, 2006, at 3:04 PM, Philip Smith wrote: I was kinda hoping that it would hit 200K on Tuesday, then I could have added the announcement to my aggregation recommendations lightning talk! ;-) Bit sad that a 200K table can be aggregated down to 109k prefixes with no loss of path information (in my BGP table view). I find this interesting. Obviously the table contains kruft. But I know we could not shrink it to 109K prefixes without losing something from where I sit. Are you sure there's no additional path info? If there were a way to guarantee certain prefixes are completely superfluous, we could make a hit list of just those providers, then ridicule or filter or cause them pain in some way to make them stop causing us pain. I haven't seen that type of report posted publicly, just this CIDR can fit in that one without actual guarantees that _paths_ are equivalent. (Usually the origin AS is matched as well as the prefixes, but that's not the same as guaranteeing the path is equivalent.) Of course, this is non-trivial. But then neither is aggregating the global table. :) -- TTFN, patrick
Re: Aggregation path information [was: 200K prefixes - Weekly Routing Table Report]
On Oct 13, 2006, at 3:26 PM, Jared Mauch wrote: On Fri, Oct 13, 2006 at 03:14:38PM -0400, Patrick W. Gilmore wrote: Obviously the table contains kruft. But I know we could not shrink it to 109K prefixes without losing something from where I sit. Are you sure there's no additional path info? If there were a way to guarantee certain prefixes are completely superfluous, we could make a hit list of just those providers, then ridicule or filter or cause them pain in some way to make them stop causing us pain. I haven't seen that type of report posted publicly, just this CIDR can fit in that one without actual guarantees that _paths_ are equivalent. (Usually the origin AS is matched as well as the prefixes, but that's not the same as guaranteeing the path is equivalent.) Of course, this is non-trivial. But then neither is aggregating the global table. :) how much of this could be mitigated if people properly announced aggregates and used a provider-local no-export to balance their links with them? it does make those policies more complicated than the simple cut+paste examples that they've likely used in the past, but could possibly allow the traffic-eng with their upstream without the global pollution. Sorry if I wasn't clear before, but I consider path info _just for your first hop upstream_ superfluous for the rest of the Internet. Does anyone think this is an unreasonable restriction? More important question: How many people are doing TE or something and not applying no-export when they could? If you need help fixing that, or even figuring out if you need to fix it, I guarantee you several people on this list would help you, many for free. This is one of the reasons things become non-trivial. How do you prove that a disgregate prefix is useless to anyone except that one network? I do not think it is impossible. But it certain ain't easy. -- TTFN, patrick
Re: icmp rpf
On Sep 26, 2006, at 11:57 AM, Mark Kent wrote: I asked: Who among AS1239, AS701, AS3356, AS7018, AS209 does loose RPF (not just strict RPF on single-homed customers)? and Patrick answered: I'm wondering why that is relevant. It's relevant because it was suggested that loose RPF should be a best common practice so I was curious which of those ASes decided that the benefits outweighed the negatives and actually do it. Don't worry, those were randomly chosen AS. I didn't intend to make any suggestion that the answer would be more important to me for that set of ASes than any other. The actual practices of a network are not necessarily a way to look at what best common practices should be. For instance, how many networks are in full compliance with BCP38? Or are you arguing that since essentially no one is compliant, we should scrap the BCP? But, you were correct that I wasn't asking the question I really wanted answered. What I wanted to know was, among the attentive nanog membership, which of you think and/or know that any/all of those AS do loose RPF? The motivation here is that, if asked last week, I would have guessed that none of them run loose RPF. But at least one of them does. The two answers, how many actually do plus whether everyone knew it, will help me decide if I need to spend more time reading nanog email and nanog proceedings (or actually go to a meeting), or not... Good question. waits for answers -- TTFN, patrick
New router feature - icmp error source-interface [was: icmp rpf]
On Sep 25, 2006, at 9:06 AM, Ian Mason wrote: ICMP packets will, by design, originate from the incoming interface used by the packet that triggers the ICMP packet. Thus giving an interface an address is implicitly giving that interface the ability to source packets with that address to potential anywhere in the Internet. If you don't legitimately announce address space then sourcing packets with addresses in that space is (one definition of) spoofing. Who thinks it would be a good idea to have a knob such that ICMP error messages are always source from a certain IP address on a router? For instance, you could have a loopback99 which is in an announced block, but filtered at all your borders. Then set ip icmp error source-interface loopback99 or something. All error messages from a router would come from this address, regardless of the incoming or outgoing interface. Things like PMTUD would still work, and your / 30s could be in private space or non-announced space or even imaginary^Wv6 space. :) Note I said error messages, so things like TTL Expired, Port Unreachable, and Can't Fragment would come from here, but things like ICMP Echo Request / Reply pairs would not. Perhaps that should be considered as well, but it is not what I am suggesting here. Obviously there's lots of side effects, and probably unintended consequences I have not considered, but I think the good might out- weigh the bad. Or not. Which is why I'm offering it up for suggestion. (Unless, of course, I get 726384 you are off-topic replies, in which case I withdraw the suggestion.) -- TTFN, patrick
Re: icmp rpf
On Sep 25, 2006, at 12:22 PM, Mark Kent wrote: Jared Mauch wrote: I would hope they're doing it for more than just ICMP packets. yes, loose RPF, but I just care about ICMP. I would argue should be, or is a current best practice. OK, so I must have missed the memo :-) It's been all the rage. :) Who among AS1239, AS701, AS3356, AS7018, AS209 does loose RPF (not just strict RPF on single-homed customers)? I'm wondering why that is relevant. If all those ASNs only filtered on ASN instead of prefix for customer announcements (for instance), would that mean no one should? -- TTFN, patrick
Re: New router feature - icmp error source-interface [was: icmp rpf]
On Sep 25, 2006, at 5:26 PM, Berkman, Scott wrote: Might this not be a bad idea if the router has interfaces on multiple, separate paths? Such a case may be where one customer or set of traffic routes over a link to ISP A, and other traffic over a link to ISP B, and not all related addresses are portable. In that case the loopback address for the ICMP errors might show from an address that seems to belong to a block from ISP A, but is really traffic that was transported on ISP B. Just trying to come up with possible issues, not saying that's a best practice or anything... I doubt it is possible to make a rule / knob / idea / feature / whatever that cannot be misused, or that is applicable to all corner cases. That's why it's a knob. :) If it is applicable to your situation, you should use it. If not, not. But if the knob has enough use in enough situations, then it is probably something we want to push the vendors to implement. -- TTFN, patrick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick W. Gilmore Sent: Monday, September 25, 2006 9:23 AM To: nanog@merit.edu Cc: Patrick W. Gilmore Subject: New router feature - icmp error source-interface [was: icmp rpf] On Sep 25, 2006, at 9:06 AM, Ian Mason wrote: ICMP packets will, by design, originate from the incoming interface used by the packet that triggers the ICMP packet. Thus giving an interface an address is implicitly giving that interface the ability to source packets with that address to potential anywhere in the Internet. If you don't legitimately announce address space then sourcing packets with addresses in that space is (one definition of) spoofing. Who thinks it would be a good idea to have a knob such that ICMP error messages are always source from a certain IP address on a router? For instance, you could have a loopback99 which is in an announced block, but filtered at all your borders. Then set ip icmp error source-interface loopback99 or something. All error messages from a router would come from this address, regardless of the incoming or outgoing interface. Things like PMTUD would still work, and your / 30s could be in private space or non-announced space or even imaginary^Wv6 space. :) Note I said error messages, so things like TTL Expired, Port Unreachable, and Can't Fragment would come from here, but things like ICMP Echo Request / Reply pairs would not. Perhaps that should be considered as well, but it is not what I am suggesting here. Obviously there's lots of side effects, and probably unintended consequences I have not considered, but I think the good might out- weigh the bad. Or not. Which is why I'm offering it up for suggestion. (Unless, of course, I get 726384 you are off-topic replies, in which case I withdraw the suggestion.) -- TTFN, patrick
Re: New router feature - icmp error source-interface [was: icmp rpf]
On Sep 25, 2006, at 5:40 PM, Richard A Steenbergen wrote: On Mon, Sep 25, 2006 at 09:22:34AM -0400, Patrick W. Gilmore wrote: On Sep 25, 2006, at 9:06 AM, Ian Mason wrote: ICMP packets will, by design, originate from the incoming interface used by the packet that triggers the ICMP packet. Thus giving an interface an address is implicitly giving that interface the ability to source packets with that address to potential anywhere in the Internet. If you don't legitimately announce address space then sourcing packets with addresses in that space is (one definition of) spoofing. Who thinks it would be a good idea to have a knob such that ICMP error messages are always source from a certain IP address on a router? You know I was just having this discussion with someone else a couple days ago. It turns out, much to my surprise, that the RFC actually calls for the ICMP error-message packet (as you said, the things that aren't ping etc which require a specific source-address) to originate from the OUTGOING interface used to return the ICMP message to the original sender. After much googling, I can't find any document where this has ever been officially updated either. The defacto industry standard on the other hand has been to use the primary address of the inbound interface, which serves exactly one function: it makes traceroute work. I have not read the RFC in full, but after chatting with Daniel offline (see, some people actually do talk without posting! :), I believe this only applies to packets addressed to the router. Since packets going -through- the router have absolutely no guarantee what source will be used coming back, I don't seen an issue here. Just change the idea such that it only is used for error messages to packets where the dest addy is not an interface on the router. Also, this makes traceroute -easier- to use. Suddenly all interfaces on the same router have the same IP address, thereby making it easy to tell if two traceroutes intersect, even if they use different interfaces. Oh, and who said RFCs can't be updated? :-) (Unless, of course, I get 726384 you are off-topic replies, in which case I withdraw the suggestion.) Please stop talking about networking on NANOG, you're confusing people. :) I knew someone would flame me for it. :) -- TTFN, patrick
Re: icmp rpf
[Can we all have a moment of silence for a useful, interesting, and on-topic post?] On Sep 24, 2006, at 5:59 PM, Mark Kent wrote: A smaller North American network provider, with a modest North American backbone, numbers their internal routers on public IP space that they do not announce to the world. One of the largest North American network providers filters/drops ICMP messages so that they only pass those with a source IP address that appears in their routing table. As a result, traceroutes from big.net into small.net have numerous hops that time out. Traceroutes from elsewhere that go into small.net but return on big.net also have numerous hops that time out. We do all still think that traceroute is important, don't we? If so, which of these two nets is unreasonable in their actions/ policies? Who said either was? First: Your network, your rules. Don't expect others to play by your rules. But more importantly, there is nothing that says two perfectly reasonable, rational rules cannot create a problem when intersecting in interesting ways. But if forced, I'd say Small.Net gets my vote for needing correction. I see less wrongness in a networking running what is essentially loose RPF than a network who expects supposedly bogon- sourced packets to be forwarded. (One could argue that non-announced space is bogus.) Just remember, I would only say that if pushed. Normally I would say neither is wrong. Please note that we're not talking about RFC1918 space, or reserved IP space of any kind. Also, think about the scenario where some failure happens leaving big.net with an incomplete routing table, thus breaking traceroute when it is perhaps most needed. In such an instance, I would suggest Big.Net will have far, far larger problems than whether pings get returned from prefixes it can't reach anyway. -- TTFN, patrick
Re: Removal of my brain
On Sep 20, 2006, at 4:35 PM, Richard Irving wrote: [EMAIL PROTECTED] wrote: Hrmm How many of you realize who Bill Manning is ? While you are at it, go flame Vinton Cerf... I am sure he will learn from you, too.. I have known Bill for years, and respect him for a lot of what he has done. But if he is wrong, I have zero trouble calling him on it. Who you are doesn't change facts. That said, I admit I probably hesitate a bit longer before flaming Dr. Cerf. :) If you've ever met them both, you would understand why. -- TTFN, patrick
Re: [routing-wg]BGP Update Report
On Sep 8, 2006, at 10:57 AM, Hank Nussbacher wrote: On Fri, 8 Sep 2006, [EMAIL PROTECTED] wrote: Strike me as curious, but this seems as if Connexion by Boeing is handing off a /24 from ASN to ASN as a certain plane moves over certain geographic areas. Or is there some other explanation? They presented at NANOG saying they would be re-announcing a /24 per plane as it crosses the ocean. I can't recall if the originating (or transit) ASNs were going to change, but it doesn't seem wholly unreasonable. IMHO, of course. -- TTFN, patrick
Re: AW: ams-ix - worth using?
On Aug 25, 2006, at 8:10 AM, Gunther Stammwitz wrote: Without getting in the middle of the eternal contest over who is better, LINX or AMS-IX (each has its own advantages and disadvantages), the AMS-IX website says 165Gbps, the LINX website says 95Gbps (actual publicly switched traffic), and the DECIX website says 71Gbps. Some portion of the AMS-IX traffic seems to be Dutch-specific content that stays in the country, but there is plenty of global traffic there too. I've just been in touch with a colleague of mine and he has to add the following: Hey a biased analysis, IIRC AMS-IX allows all kind of traffic including upstream, not only peering traffic. DE-CIX is peering only. I assume the CIXes in US behave similar. Besides that, I wonder what kind of hardware will they be using in the future, assuming they grow like all other CIXes There is no fair stat, since you cannot quantify an IX into a single dimension. Equinix Ashburn almost certainly carries more traffic through the building than AMS-IX carries, probably by many times, but that stat is not published as most of the traffic is over PI. The AMS-IX member list includes people hooking up for VoIP peering and other things at Kbps instead of Mbps or Gbps. There is a building in Seoul, South Korea, which some claim passes multiple terabits per second over private peering. (Honestly, I don't believe that number, but it's been claimed.) Etc., etc. The numbers mean what the numbers mean. AMS-IX has more traffic flowing over their public switch infrastructure than any other public exchange in the world. This means only and exactly that AMS-IX has more traffic flowing over their public switch infrastructure than any other public exchange in the world - nothing more, nothing less. If you base your buying / peering requirements on one dimension of an n-dimensional decision matrix, you are probably not choosing optimally. All that said, AMS-IX is an outstanding IX. A network with significant European traffic is almost certain to find peering at AMS-IX beneficial. But the same is true for other exchanges (e.g. LINX). -- TTFN, patrick
