On Mon, Jul 24, 2006 at 09:43:19PM -0400, Valdis.Kletnieks@vt.edu wrote:

On Mon, 24 Jul 2006 13:18:42 EDT, Richard A Steenbergen said:

...

Actually they just leaked some routes this morning, and blew out max prefixes to most peers. Pretty typical as far as accidental leaks go, those folks with sensible filtering and running routers which trip on max prefixes accepted not prefixes received probably weren't even affected. Another day on the internet.

If I didn't know better, I'd say you were implying that your best bet for a survivable design is to plan as if your peers listened to Randy Bush on network design?

Not sure what you're referencing there. If Randy said something to the effect of "all peers will screw up and leak something to you eventually, no matter how large or generally well run, so plan accordingly", I would agree with it though. I was suggesting that if even if you don't have the ability to fully prefix or as-path filter every peer (which, face it, most of us with large numbers of interesting peers don't have), you can still filter the really obvious stuff and prevent a large amount of the impact from common fat finger events. I can't tell you the number of problems that are prevented by applying a simple set of as-path filters matching large networks you know you should never hear from your peers (or most of your peers). Something simple like: deny _209_ deny _701_ deny _1239_ deny _1299_ deny _1668_ deny _3320_ deny _3356_ deny _3549_ deny _3561_ deny _5511_ deny _6453_ deny _7018_ Catches a huge amount of "stupid stuff", especially when the event isn't a full blown leak which trips max prefixes, but is an isolated set of prefixes leaked by someone not directly connected to you. On a Cisco, the leaked 7018 routes from 7132 this morning would have been gone splash harmlessly with such a filter, and sessions wouldn't even trip max prefixes and bounce. Unfortunately Juniper has a bit of a backwards take on the use of prefix limits. They believe that the reason to have a prefix limit is to protect a router against memory exhaustion (for example, someone sending you a few million routes that you are rejecting filling up your adj rib in), rather than as a policy tool (shutting down a wildly broken session that is sending you stuff it shouldn't). Juniper applies the max prefixs to routes received from a session rather than routes accepted, so even if the routes are filtered the prefix limit will still trip and shut down the session. This is particularly bad if for example you have a customer session which is fully prefix list filtered, and the customer accidentally leaks you a table. In reality, both types of limits are probabaly a "good idea". I've talked to a lot of people from a lot of companies who say they have requested Juniper add a seperate accepted-prefixes limit (or more likely, convert the existing limits to accepted-prefixes, and add a new received-prefixes knob), but so far it hasn't been implemented. If you are a Juniper customer who is reading this and you think having prefix limits which only count accepted prefixes is a good idea, please use this as an opportunity to submit an enhancement request so we can get this behavior improved. Feel free to throw in a request for "outbound prefix limits" as a last ditch safety net too. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)