iBGP Scaling

Sun Mar 29 14:57:09 UTC 2009

On Sat, Mar 28, 2009 at 05:13:54PM +0000, tt tt wrote:
> 
> Hi List,
> 
> We are looking to move our non infrastructure routes into iBGP
> to help with our IGP scalability (OSPF).  We already run full BGP
> tables on our core where we connect to multiple upstream and
> downstream customers.  Most of our aggregation and edge routers
> cannot hold full tables and it's certainly not possible to upgrade
> them. Is there any reason why we shouldn't filter iBGP routes between
> our core and aggregation layers (we plan to use route reflectors)
> or should we be look at using a private AS number per POP?

Dave,

This isn't an either/or.  If you are memory-starved then even with 
a confederation model you'd need to be filtering or summarizing at
the core/aggregation boundary.  The decision axis there has to do
with the number of routers, fluidity VS rigidity of your core/agg
relationships, restrictions or capabilities of your equipment, etc.
The only reason not to limit the aggregation-heard routes in your 
situation is if there are downstream customers (or internal servers/
services) which need the data.  For manageability, follow cgucker's 
advice and tag everything with various communities to describe them:
customer/peer/transit, your transit's customer VS truly remote, 
internal pop heard, geographic region, et al.  Based upon a good
set of tags, it will be easy to see what data can be reduced from
your memory-starved sites with a limited pathway to the rest of 
your net.

Cheers,

Joe

-- 
             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE