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?
