On Tue, Mar 2, 2010 at 10:35 AM, Rob Shakir <[email protected]> wrote: > In order to scale BGP on this platform, it's advantageous to be able to > ensure that the number of BGP update-groups is minimised. This is done by > having common egress policy. The best approach for this is therefore to use a > single route-map for each function that you're performing - e.g. > transit/peering/customer etc. > > You can see how your update-groups are laid out by running 'sh ip bgp up'. >
I have 181 update-groups. The reason why I am having this is that I want to allow my transit customers to send us BGP communities that will allow them to control the announcements to individual peers, rather than to regional peering groups. I only can see 1 route-map per peer as a solution here. Or is there a better way (regexp?) to handle this? The BGP communities we are getting from the customer would be 6500x:ASN (x = number of prepends: 0-4, ASN = peer ASN). Andy _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
