[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

iBGP Scaling

On Sat, Mar 28, 2009 at 1:13 PM, tt tt <tt_745 at 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?


     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.