On 10/Jun/16 19:34, Leo Bicknell wrote:
> It does mean the provider creating the leak has already lost, but > that doesn't mean it still isn't vital to protecting the larger > internet. A good example of this is fire code. Most fire codes > do not do much to prevent you from starting a fire in your own > house/condo/apartment, but rather prevent it from spreading to your > neighbors. I've found communities to be robust at filtering very effectively. I have heard of software issues that may cause filters to stop working, but I have not yet encountered any such issues myself that had nothing to do with a mis-configuration or lack of understanding about how policies are evaluated by the router. > > For instance, if you filter Customer A to A's Prefix list on ingress, > B to B's, C to C's, it may also be prudent to filter outbound to > your peers based on A+B+C's prefix list. When the ingress filter > to A fails (typo, bug, bad engineer), your own network is hosed by > whatever junk A ingested, but at least you won't pass it on to peers > and spoil the rest of the Internet. That does not scale, and was probably one of the primary reasons communities were developed. > > Basically both ingress and egress filtering have weaknesses, and > in some cases doing both can provide some mitigation. It's the old > adage "belt and suspenders". We've been operating purely community-based filtering on border and peering routers for years. I've never ran into an issue with the software that broke that. The folk I know who have suffered this either mis-configured their policies, did not understand BGP and did not get a good handle on how their router OS implements filtering and filter evaluation. Mark.
signature.asc
Description: OpenPGP digital signature
