Re: Deaggregation Disease
[EMAIL PROTECTED] schrieb: On Fri, 21 Jul 2006 09:51:33 +0200, Fredy Kuenzler said: Prefixes Change ASnum AS Description 3263 0-3263 AS4151USDA-1 - USDA so I wonder what's wrong with them. I'm not sure which is more weird - a jump of over 3K routes, or the fact that the starting point is zero Just to make it clear: AS4151 was 9 month ago. Now we see history again with new actors. (I guess the actual increase was done by various ASN of RENATER). I wonder why aggregating is that difficult. F.
Re: Deaggregation Disease
On Fri, Jul 21, 2006 at 02:42:04PM +0200, Fredy Kuenzler wrote: [EMAIL PROTECTED] schrieb: On Fri, 21 Jul 2006 09:51:33 +0200, Fredy Kuenzler said: Prefixes Change ASnum AS Description 3263 0-3263 AS4151USDA-1 - USDA so I wonder what's wrong with them. I'm not sure which is more weird - a jump of over 3K routes, or the fact that the starting point is zero Just to make it clear: AS4151 was 9 month ago. Now we see history again with new actors. (I guess the actual increase was done by various ASN of RENATER). I wonder why aggregating is that difficult. It's not, people are just lazy and since nobody owns the internet man, or maybe it's all a bunch of tubes there's nobody to force people to be good actors. Perhaps it's time to bring back the old /19 filters that were started by sprint such. -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Deaggregation Disease
Just to make it clear: AS4151 was 9 month ago. Now we see history again with new actors. (I guess the actual increase was done by various ASN of RENATER). I'm curious how you reach the conclusion that RENATER has contributed to many of the prefixes over the last week. They do seem to have announced a bunch of prefixes that could be aggregated, but look at the following report: http://www.cidr-report.org/as-prefixes.txt There seem to be a whole load of ASNs that have deaggregated. AS5416, AS5639, AS6140, AS9121, AS13049, AS16130, AS17849, AS18049 (that's as far as I got before getting bored). Some of these are advertising the covering prefix too, so they're certainly aware of how to aggregate. Rob
Re: Deaggregation Disease
-- Jared Mauch [EMAIL PROTECTED] wrote: On Fri, Jul 21, 2006 at 02:42:04PM +0200, Fredy Kuenzler wrote: [EMAIL PROTECTED] schrieb: On Fri, 21 Jul 2006 09:51:33 +0200, Fredy Kuenzler said: Prefixes Change ASnum AS Description 3263 0-3263 AS4151USDA-1 - USDA so I wonder what's wrong with them. I'm not sure which is more weird - a jump of over 3K routes, or the fact that the starting point is zero Just to make it clear: AS4151 was 9 month ago. Now we see history again with new actors. (I guess the actual increase was done by various ASN of RENATER). I wonder why aggregating is that difficult. It's not, people are just lazy and since nobody owns the internet man, or maybe it's all a bunch of tubes there's nobody to force people to be good actors. Perhaps it's time to bring back the old /19 filters that were started by sprint such. I was just thinking the same thing. :-) - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Deaggregation Disease
On Fri, 21 Jul 2006, Fergie wrote: to be good actors. Perhaps it's time to bring back the old /19 filters that were started by sprint such. I was just thinking the same thing. :-) Maybe with a central feed ala the bogons, where those clueful enough can get their smaller blocks punched through --- david raistrickhttp://www.netmeister.org/news/learn2quote.html [EMAIL PROTECTED] http://www.expita.com/nomime.html
Re: Deaggregation Disease
Rob Evans schrieb: Just to make it clear: AS4151 was 9 month ago. Now we see history again with new actors. (I guess the actual increase was done by various ASN of RENATER). I'm curious how you reach the conclusion that RENATER has contributed to many of the prefixes over the last week. Actually I thought this morning I've read RENATER several times at http://www.cidr-report.org/ - but I might be wrong (it's 34 degrees in Switzerland, just too hot to make assumptions). However the prefixes are gone again: http://www.cidr-report.org/#General_Status and we see 189980 in our LG as before. F.
Re: Deaggregation Disease
On 21-Jul-2006, at 09:17, Rob Evans wrote: There seem to be a whole load of ASNs that have deaggregated. AS5416, AS5639, AS6140, AS9121, AS13049, AS16130, AS17849, AS18049 (that's as far as I got before getting bored). Some of these are advertising the covering prefix too, so they're certainly aware of how to aggregate. Sometimes this is done intentionally -- the long-prefix (covered) prefixes might be TE routes designed to draw traffic to particular sinks through specific external providers. People have been known to stamp NO_EXPORT on those and get some measure of TE without polluting the global table, but if the AS whose exit you're trying to influence isn't adjacent that doesn't work. As it happens, Tony Li, Rex Fernando and I wrote up a proposal for a new attribute which might help in some of these situations. (It's a crude mechanism, but not as crude as NO_EXPORT). http://www.ietf.org/internet-drafts/draft-ietf-idr-as- pathlimit-02.txt Under that proposal you could stamp an AS_PATHLIMIT=2 or AS_PATHLIMIT=3 on TE routes and have them automatically dropped by routers when the AS_PATH length exceeded 2 or 3. For some people this would work (for others, for whom 90% of the Internet is less than 2 or 3 hops away it wouldn't do much). It would help immensely with getting that document published if people could read that draft, and let me know if it looks like something they would implement if it was implemented. Private mail would be great. Joe
Re: Deaggregation Disease
On 21-Jul-2006, at 10:48, Joe Abley wrote: It would help immensely with getting that document published if people could read that draft, and let me know if it looks like something they would implement if it was implemented. Private mail would be great. Uh, something they would deploy if it was implemented. Fridays. Words.
Re: Deaggregation Disease
On (2006-07-21 10:48 -0400), Joe Abley wrote: As it happens, Tony Li, Rex Fernando and I wrote up a proposal for a new attribute which might help in some of these situations. (It's a crude mechanism, but not as crude as NO_EXPORT). http://www.ietf.org/internet-drafts/draft-ietf-idr-as- pathlimit-02.txt I'm sure I'm not first one to to think about 'TTL' to AS hops (http://www.merit.edu/mail.archives/nanog/2002-10/msg00394.html), of course different reason at that time :). Other thing I was thinking about was ability to have include/exclude AS#'s community/attribute. -- ++ytti
Re: Deaggregation Disease
On 21-Jul-2006, at 11:20, Saku Ytti wrote: On (2006-07-21 10:48 -0400), Joe Abley wrote: As it happens, Tony Li, Rex Fernando and I wrote up a proposal for a new attribute which might help in some of these situations. (It's a crude mechanism, but not as crude as NO_EXPORT). http://www.ietf.org/internet-drafts/draft-ietf-idr-as- pathlimit-02.txt I'm sure I'm not first one to to think about 'TTL' to AS hops (http://www.merit.edu/mail.archives/nanog/2002-10/msg00394.html), of course different reason at that time :). Other thing I was thinking about was ability to have include/exclude AS#'s community/attribute. That seems to me like another perfectly valid approach, and one that already exists to some extent (e.g. by pre-poisoning AS_PATH attributes with AS numbers of remote networks that you don't want to accept particular routes). I'm told that IDRP has inclusion and exclusion lists which provide more exhaustive implementation of this kind of idea, too. However, for some applications those mechanisms rely on knowing the topology one or more AS hops away from your network; AS_PATHLIMIT doesn't. To my eye the two approaches seem complementary. [To be clear, incidentally, Tomy, Rex and I made no claim to be the original authors of the idea we were documenting in this draft: 8. Acknowledgements The editors would like to acknowledge that they are not the original initiators of this concept. Over the years, many similar proposals have come our way, and we had hoped that self-discipline would cause this type of mechanism to be unnecessary. We were overly optimistic. The names of those who originally proposed this are now lost to the mists of time. This should rightfully be their document. We would like to thank them for the opportunity to steward their concept to fruition.] Joe
Re: Deaggregation Disease
On (2006-07-21 11:38 -0400), Joe Abley wrote: That seems to me like another perfectly valid approach, and one that already exists to some extent (e.g. by pre-poisoning AS_PATH attributes with AS numbers of remote networks that you don't want to accept particular routes). I'm told that IDRP has inclusion and exclusion lists which provide more exhaustive implementation of this kind of idea, too. Oh, cool idea, indeed 'as exclude' mechanism is there, but I'm sure I'd be frowned upon advertising such routes today. 'as include' otoh. is not there. However, for some applications those mechanisms rely on knowing the topology one or more AS hops away from your network; AS_PATHLIMIT doesn't. To my eye the two approaches seem complementary. Absolutely complementary. The 'original' problem I was thinking, really needed both, as point was to find how 'deep' in Internet your DoS sources are, then as you've indentified the depth, you have smaller subset of AS#'s that you could iterate with include/exclude to pinpoint source of certain traffic, even if they were spoofing. But that idea has several problems that might make it unfeasible, nevertheless the traffic engineering applications remain. [To be clear, incidentally, Tomy, Rex and I made no claim to be the original authors of the idea we were documenting in this draft: ACK, I did notice that, I'm sure most people have thought about it at one point or another in their networking career :). I hope it'll be implemented. Thanks, -- ++ytti
Re: Deaggregation Disease
On Fri, 21 Jul 2006, Fergie wrote: It's not, people are just lazy and since nobody owns the internet man, or maybe it's all a bunch of tubes there's nobody to force people to be good actors. Perhaps it's time to bring back the old /19 filters that were started by sprint such. I was just thinking the same thing. :-) As we push closer to the ipv4 route table limits of cisco's 6500/7600 series (with anything less than Sup720-3bxl), I suspect lots of networks are going to be forced to start doing some sort of filtering of routes beyond just refusing 24-bit networks or cisco's going to sell a lot more Sup720-3bxl's, FAN2 trays, and power supplies in the next year or two. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Deaggregation Disease
On Fri, 21 Jul 2006 13:59:35 EDT, Jon Lewis said: As we push closer to the ipv4 route table limits of cisco's 6500/7600 series (with anything less than Sup720-3bxl), I suspect lots of networks are going to be forced to start doing some sort of filtering of routes beyond just refusing 24-bit networks or cisco's going to sell a lot more Sup720-3bxl's, FAN2 trays, and power supplies in the next year or two. The big question is, of course, whether to upgrade a 6500 and keep it on life support, or bite the bullet and go for a whole new box. How much time a -3bxl and careful filtering will buy you does depend heavily on where in the Internet you are - but I'm willing to bet that a good number of sites will go for the fork lift upgrade because there are *other* pressing things coming up that the 6500 won't do either. Remember - it only takes *one* truly mission-critical must do that a 6500 can't, and it's off to a less stressful corner of your network for that long slide into retirement (on the other hand, I'm sure in 2016, there will *still* be 6500's installed, just like I'm sure there's still 1996-vintage gear still out there now...) I'll concede that Jon is at least partially right - *somebody* is going to be selling gear... ;) pgpOiYCpd2yJV.pgp Description: PGP signature
Re: Deaggregation Disease
On Fri, 21 Jul 2006 [EMAIL PROTECTED] wrote: The big question is, of course, whether to upgrade a 6500 and keep it on life support, or bite the bullet and go for a whole new box. How much time a -3bxl and careful filtering will buy you does depend heavily on where in the Internet you are - but I'm willing to bet that a good number of sites will go for the fork lift upgrade because there are *other* pressing things coming up that the 6500 won't do either. With a 3bxl, you won't need careful filtering. All the lower Sups top out at or slightly below 256k routes. IIRC, the 3bxl claims to support 1M ipv4 routes. Anyone else care to guess at how far off 235k routes is? I'll concede that Jon is at least partially right - *somebody* is going to be selling gear... ;) Yeah...I posted recently on cisco-nsp that I think cisco's making a huge mistake not producing a Sup32-3bxl. When the Sup2 can't cope with full routes anymore, I suspect the Sup720-3bxl will already have been obsoleted by some higher end Sup. Then networks that would have bought Sup32-3bxl's for the route capacity, and don't really need the traffic capacity of the Sup720-3bxl will snap up Sup720-3bxl (and the required fan2s and power supplies) off the used market while bigger/richer networks upgrade to the Sup720-3bxl replacement. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Deaggregation Disease
On Fri, Jul 21, 2006 at 01:59:35PM -0400, Jon Lewis wrote: As we push closer to the ipv4 route table limits of cisco's 6500/7600 series (with anything less than Sup720-3bxl), I suspect lots of networks are going to be forced to start doing some sort of filtering of routes beyond just refusing 24-bit networks or cisco's going to sell a lot more Sup720-3bxl's, FAN2 trays, and power supplies in the next year or two. It should be noted that the sup720-3a/3b tcam allocations (cef maximum-routes) only gives 190k of the 256k theoretical max to IPv6 routes by default. Anyone running a sup720 non-3bxl who has not manually adjusted those cef maximum-routes is either blowing up or about to blow up any day now, depending on how many internal routes they have and how much filtering their upstreams are doing. Of course this isn't a new problem, many of us are still running old Foundry ironcore boxes with 700+ day uptimes and software so old it came with 120k or 140k default maximum routes. Similiarly, cam aggregation on such platforms (without enough cam to hold even close to enough routes for a full table) is nothing new either. Cisco could easily implement cam aggregation where they do not install a cef route entry if there is a covering less-specific route pointing to the same nexthop(s). It is hardly rocket science, and could extend the life of a 256k route tcam platform for many years to come. But clearly Cisco would rather just sell 3bxl's. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
