Contributed by phessler on from the thats-it? dept.
Almost exclusively, they told me "filter performance."
Many IXP operators made a point to tell me that they liked the syntax and use of OpenBGPd. They were very concerned that there was apparently only a single piece of software that was now being used for Route Servers, and even some of them used multiple versions of it to "satisfy" their desire for divergent implementations. (insert 'eek' here)
So, I decided to look into why the filters were so slow.
Turns out, we were being very naive with the filters and checking every filter against every rule, even when we couldn't match. This is very common in the first implementation of a filter and even showed up in the initial version of PF. Obviously, filter performance in PF is rather critical to having a performant firewall so I looked at its implemetation. Turns out, it was rather simple and straight-forward.
PF's filter performance is known as "skip steps", which exploit the fact that some rules will never match. As an example, if you write a rule like "allow from AS 65111", this can never match if a peer has AS 65333. In such a case, we need to skip all of those rules.
There are two parts to skip-steps. First is when you parse and load the filters, you need to calculate where to skip to, if a group doesn't apply. This happens at load time. The second part is when we are iterating through the filters, is to detect when we get to a rule that can't apply, and skip to the next group. That happens while applying the rules.
Andy from LONAP (the 15th largest IX in the world, according to wikipedia), gave me the last configuration they used with OpenBGPd. This had 314 peers configured, and about 35,000 prefix filters. For additional torture, I added the IRR ruleset for a friend's network, which brought the total prefix rules up to around 600,000 prefixes filters. To this configuration, I sent 65,000 routes.
In OpenBSD 5.8, processing these routes would take approx 35 minutes on my laptop. With the change I committed today (Nov 6), the same processing takes only 30 seconds.
reposted from http://bad.network/openbgpd-and-route-filters.html with permission
CVSROOT: /cvs Module name: src Changes by: email@example.com 2015/11/06 09:23:26 Modified files: usr.sbin/bgpd : bgpd.h rde.c rde.h rde_filter.c Log message: Radically improve the performance of bgpd filters. Based on PF's skip steps (and uses much of the same code). In a torture test of ~600k prefix filters and 65k prefixes, convergance time goes from 35 minutes to 30 seconds. Many thanks to LONAP for providing a base configuration for torture testing. many discussions with claudio@, benno@, sthen@ and the rest of the bgpd crowd OK sthen@ benno@
(Comments are closed)