...

The problem with tagging everything a BGP customer passes to you with the "export it" tag is that customers have been known to export routes they shouldn't. The ACL provides a sanity check without costing much (if you've already got the database/distribution tools built).

that's why you build customer ingress filters based on IRR info, as i've mentioned several times now....

-danny

Dawn breaks....I missed that, but rereading your earlier messages I get it. So we agree that everyone should have an ACL somewhere between the customer and any exterior connection. You are saying that building egress ACLs that include the routes from all the ingress filters doesn't scale. If you've got them built off a database of some sort (internal, IRR, whatever) building and keeping them consistent should be straightforward. So any scaling problems are related to CPU/memory/BGP slowdown due to the size of the lists or to propagation delay of changes (waiting for database updates to propagate out). Does anyone know how large an ACL can be before it causes performance problems? My egress filters are in the hundreds of lines - does anyone run ciscos with 1000 line distribute-lists in BGP? 10K lines? Without the egress ACLs you still aren't protected if you forget to add an ingress ACL or have some bogus route you've generated internally. And I've seen both of those happen to NSPs. If you've got ingress and egress filters you do have better protection. I guess I'm just paranoid about routing information, so I filter at every access point. -- -Chris (cgarner@sni.net)