On Mon, Oct 23, 2017 at 08:35:42AM +0200, Job Snijders wrote:
or it could compare each additional prefix received to already learned prefixes and decide to drop one to make room for the new one. For example you could drop the most specific routes before less specific routes.
The moment a BGP implementation can do such RIB compression, it may indeed make sense to offer two types of limits: a 'pre-policy maximum prefix limit' and a 'post-policy maximum prefix limit'. The former type of limit would be useful in context of route leaks, the latter in context of protecting against overflow of the FIB capability.
Apparently this already exists and is widely available, Saku Ytti gave me some additional information. There are various keywords available, and they operate at different attachment points in the conceptual model. | IOS XR | Junos =============================================================== pre-policy keyword | ???? | prefix-limit --------------------+------------------+------------------------ post-policy keyword | maximum-prefix | accepted-prefix-limit (????? means the keyword does not exist) Now I wonder what Arista EOS, Nokia SR-OS, etc offer in this regard. :-) (screenshot here http://instituut.net/~job/screenshots/baf76f9c29a31d2e55454ddd.png for those of you who can't easily view ASCII tables) Kind regards, Job