Hello!
I'm still trying to find a convincing argument for why the bad case can never happen though. Can you think of a codepath that calls rt_notify with one of our own routes outside of us calling into rte_update*? I'm having a hard time reading the rt-table code, it just has so many twists and turns :)
This is definitely possible, think about this case:
protocol babel { preference 150; ... }
protocol static { preference 200; ... }
$ show route
X/Y via A, preference 200, protocol static [*]
X/Y via B, preference 150, protocol babel
When Babel imports the route, it gets back (rt_notify) the static route
which is best.
Then the admin requests "disable static1" and Babel gets (rt_notify) its own route without doing anything.
And you should also be aware that in BIRD 3, you never get rt_notify while calling rte_update(); route updates are always asynchronous and you get them always in a clean context.
I should definitely put some time into writing a "how to write a protocol" guide.Let me know if/when you need a clueless dummy to bounce drafts off of ;)
Thank you for volunteering! Maria
smime.p7s
Description: S/MIME Cryptographic Signature
