weird BGP cisco-ism? [problem resolved]

Sat Jul 12 01:05:06 UTC 1997

>
>
>> 	You can build your customer BGP filters off data in the IRR.  Make
>> it a requirement that BGP customers must keep that information up to date
>> (or do it for them).
>
>OK.  So I apply an ingress filter (ideally built from the IRRs) to a customer 
>peer.  Then I have to add the cusomter's AS(s) prefixes to every eBGP peer's 
>egress ACL (including customer peers) so that the networks will be permitted.
>
>The customer begins advertising a newly allocated netblock.  Now virtually 
>*every* BGP peers ACL has to be modified & deployed and the source AS will 
>need to either flap the route or reset the session.
>
>If I had tagged the customer's prefixes with a BGP community when I picked up 
>the routes ..and have filters in place that deny/permit predefined communities 
>to all eBGP peers, all I would need to be concerned with is the customer's 
>ingress ACL.
>
>IMO, ACLs alone won't scale. 
>
>
>-danny
>
>
>

	For any of this to scale it's got to be automated, so building and
deploying the prefix filters on all external/customer peerings shouldn't
be an issue.  Scaling the size of the ACLs might be an issue though, I'm
not sure about that.

	Won't setting soft state on customer peerings avoid the need to
bounce routes after the ACL gets updated?  I haven't actually done this
yet - does anyone know how well it works/if it costs much memory/CPU?
You'd need to make sure that external filters got updated before customer
filters, but that shouldn't be too hard.

	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).

-- 

                                -Chris (cgarner at sni.net)