On 2 Mar 2010, at 07:57, Andy B. wrote: > On Tue, Mar 2, 2010 at 8:07 AM, Aftab Siddiqui <[email protected]> > 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 <[email protected]> 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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
