RFC: Separate import/export tables
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? -- Best regards Asbjørn Sloth Tønnesen
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?
On Sat, Jun 19, 2021 at 09:22:35AM +0200, Maria Matejka wrote:
Hello!
I'm quite confused by what you're trying to achieve. How would you choose the routes that are likely to be exported?
Hello I understood it that as small AS, you have small set of 'your' (or customers') prefixes (say 10) in prefix set which you want to export to all your peers and upstreams. If you have hundred of peers and few millions of global routes, you may want to avoid few 10E8 of route matching of that prefix set for export, when you can just have secondary table connected to master table by pipe with prefix set filter and containing these 10 routes, while peer BGP sessions could be configured to import to master table and export from secondary table (so only ~10E4 route processing would be done for export). It could be thought as a pair of separate unidirectional channels for import and export, connected to different tables. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hello!
I'm quite confused by what you're trying to achieve. How would you choose the routes that are likely to be exported?
Hello
I understood it that as small AS, you have small set of 'your' (or customers') prefixes (say 10) in prefix set which you want to export to all your peers and upstreams. If you have hundred of peers and few millions of global routes, you may want to avoid few 10E8 of route matching of that prefix set for export, when you can just have secondary table connected to master table by pipe with prefix set filter and containing these 10 routes, while peer BGP sessions could be configured to import to master table and export from secondary table (so only ~10E4 route processing would be done for export).
It could be thought as a pair of separate unidirectional channels for import and export, connected to different tables.
Aha! I'm getting it now. Well, this is almost something I have been working on last week – splitting channels to the import and export part. Soon to be seen in alderney branch as it is also a prerequisite to make pipes work well in parallel. It will be trivial then to allow for import to and export from different tables. Maria
participants (3)
-
Asbjørn Sloth Tønnesen -
Maria Matejka -
Ondrej Zajicek