Hello! I'm quite confused by what you're trying to achieve. How would you choose the routes that are likely to be exported? If there is something that you repetitively count in export filters, you may move this check into the import filters (these are run only once) and store the result using a custom attribute: attribute int whatever; ... import filter { ... whatever = something; } ... export filter { if whatever > otherthing then ... } Anyway, in the complete picture, you are always going to run an export filter at least once for all routes combined with all exporting channels in some form. Maria On 6/18/21 7:11 PM, Asbjørn Sloth Tønnesen wrote:
Hi,
We have an internet router setup where we have a few customer connections, and hundreds of peering sessions.
A lot of CPU time is wasted running the export filters over the entire internet routing table per peer, in order to find the relatively few prefixes to actually export.
I know we could try to work around it, by having a complicated system of tables and pipes, like one table per peer per family.
However I would prefer to keep things simple, so if I could just keep a small table containing the few prefixes that are likely to match the export filter, and use that as export table, while still importing prefixes from peers into the master table.
Since BGP already has "(import|export) table <switch>", then maybe "table [import|export] <table>" could work.
Before I try to implement this, are there any support/comments/ objections to this approach?