[c-nsp] route-map IN / OUT deny issue

[Rob Shakir]

On 2 Mar 2010, at 07:57, Andy B. wrote:

> On Tue, Mar 2, 2010 at 8:07 AM, Aftab Siddiqui <aftab.siddiqui at gmail.com> wrote:
>> I have tried the same scenario in lab and its working perfectly fine as you
>> were intended to perform. All iBGP neighbors are intact so as the IGP. I
>> wonder what is wrong in your case. I have tested it on 7206VXR and also on
>> 3640.
> 
> My scenario looks somewhat like this:
> 
> 150 BGP sessions on a public peering exchange
> 10 BGP sessions with customers (full feed out)
> 1 BGP session with transit (full feed in)
> 5 BGP sessions internally (next-hop-self / full mesh)
> 
> What may be interesting is that every single BGP session has its
> dedicated route-map IN / OUT, so the route-map list on the router is
> quite huge (about 10 sequences per neighbor). Would that be an issue?

The SUP720 has a very small CPU that needs to be considered in any deployment. The symptoms you describe are definitely akin to those that I would expect of a box that exhausts it's CPU.

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'd expect that you are going to have a large number of 1 member update-groups. If this is true, this is your issue.

Kind regards,
Rob

-- 
Rob Shakir                      <rjs at eng.gxn.net>
Network Development Engineer    GX Networks/Vialtus Solutions
ddi: +44208 587 6077            mob: +44797 155 4098
pgp: 0xc07e6deb                 nic-hdl: RJS-RIPE

This email is subject to: http://www.vialtus.com/disclaimer.html