OpenBSD Journal

g2k18 hackathon report: Claudio Jeker on OpenBGPD developments

Contributed by Paul 'WEiRD' de Weerd on from the dynamically-routing-through-ljubljana dept.

Claudio Jeker (claudio@) is next up with his report from Ljubljana:

I arrived in Ljubljana late on Sunday. At that time I knew I will spend most of my time on making bgpd(8) fast since this is actually my day job for the next year.

Currently I'm working on smaller incremental diffs to change the internal data structures of bgpd -- the so called RIB or router information base -- to reduce the amount of cross links between the various data structures. The plan is that in the end most lookups and traversal will happen only on one data structure, the prefix. With this, other resources like the path attributes become shareable between RIBs and peers and so less copying will happen. Working on this change has been somewhat slow because many initial tries turned out to be too big of a change at once and after 5 or 6 failed tries I kind of knew which parts needed to be refactored first.

My primary goal was to clean up the interaction between the filters and the RIB database by introducing a filter state that will hold all needed information. Since I was sitting next to benno@, henning@ and phessler@ I had a few people in poking distance to look at my diffs and get them in one after another. At the same time benno@ was looking at the interaction of bgpd with rdomains and the fact that even though it is possible to start a bgpd in a different rdomain, some things were not quite correct. One of benno@'s changes caused strange things to happen on reloads and after he spent too much time trying to track it down he asked me for help. Together we started looking into it and slowly realising that something was strange. Some of the RIBs in the route decision engine were not right after a reload.

After a lot of head scratching we finally found the problem in a memset call that was using the wrong sizeof parameter as the length in some code that has not been touched in ages. At the same time this uncovered a second copy-paste error in the reload code where a comparison was done against the wrong variable. After fixing those things benno@ was able to finish his work and bgpd is now running well in other rdomains even running multiple ones on the same box is now working the way it should.

Next to bgpd hacking I spent some time on cleaning up the route and pfkey socket codes further in the hope to make unlocking of them easier. One morning I poked henning@ about the low default limits of pf(4) and soon after those got bumped to a more reasonable limit for the year 2018. Running into the default state limit will now happen less and only on big firewalls that need extra tuning anyway. Most regular systems will be fine with the 100'000 states limit.

Another thing I noticed on busy servers was the large amount of RTM_LOSING routing messages generated. Those trigger when TCP does too many retransmits and decides to change PMTU parameters -- which can happen for example with mobile phones having bad network. Since the message has no use in today's Internet I retired it but made sure that at the same time dynamic routes are properly announced and withdrawn on the route socket. I also spent some time talking with rob@ about the BER code used by LDAP and SNMP programs in our base. Explaining to him some of the decisions I took long long time ago when I wrote the initial code for what ended being ypldap(8).

As usual I had a great time. The trip to the cave was great and allowed to recharge the batteries a bit for more hacking before burning out on the last day. Thanks to Mitja and his friends for organising and providing us with such a great location and infrastructure.

Thanks to Claudio for his report and of course his work on OpenBGPD!

(Comments are closed)


Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]