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.
Your netblock might be a standard /19 or just a modest /30 or you are just deploying IPv6 and therefore applied for one of the most recent RIPE assigments.
Do you have different AS private/public numbers running on your network?
filtering IGP routes ....part pf the OSPF design would be to find out how many areas you need to have LSA types ...or just one area O all part of your routing policy or LCR policy in place. Or just go for ISIS ....and then you have to think about L2/L1 bounderies.
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.
Interesting post. Couple things you touched on; firstly is your IGP having a scaling issue? I have seen networks with > 500 routers in area 0.0.0.0, however the LSDB was limited to links and loopbacks. Using route reflectors may help to some degree on memory, in that only the best route will be reflected to clients. If you are looking to do some things like MPLS IPVPNS or other TE stuff, you might want to stick with one AS / one IGP. It just makes things easier.
If your routers can support MPLS VPNs, you may be able to leverage route target filtering on each PE device. If you are just memory starved and plan to continue with a standard Internet routing domain, I would look at tagging all routes on ingress and figuring out which routes can be summarized or filtered out on the border / aggregation routers.
or you are just deploying IPv6 and therefore applied for one of the most recent RIPE assigments.