mailing list archives
Re: weird BGP cisco-ism? [problem resolved]
From: Chris Garner <cgarner () sni net>
Date: Fri, 11 Jul 1997 19:05:06 -0600 (MDT)
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
IMO, ACLs alone won't scale.
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 () sni net)
- Re: weird BGP cisco-ism? [problem resolved], (continued)