On Sat, Mar 28, 2009 at 1:13 PM, tt tt <tt_745@yahoo.co.uk> 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, From past experiences, you would be better off by only keeping directly connected networks (as in the netblocks/routes used for the interconnections between your routers, both internal an external). Most should be /30's or the like unless you aggregate the address space between stub areas and area 0). After that, you should tag (via BGP Communities) externally learned routes (mainly from Transit and Peers) and suppress those routes going out to your sub-par aggregation routers. Keep in mind, when you filter these routes you will have to pass a default route, either via iBGP or via your IGP (as the one exception). Also, since you are doing this via BGP Communities when additional routes are learned from your external peers, those routes would not be passed onto your aggregation routers. charles

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