Really, it's got to be something dead stupid. Hoping to borrow 5 minutes of someone's time. Replies on or off list are fine.
I've reduced it to a simple config:
BIRD:
protocol bgp {
description "ExaBGP-local";
local as 12345;
allow local as 1;
neighbor 10.0.0.2 as 12345;
next hop keep;
start delay time 5;
import all;
export all;
}
Exactly… It’s not an issue, it’s expected behavior.
If you move the static up within the neighbor definition, it becomes an Anchor Route and Exa knows you want it announced.
If you leave it in the static routes section, then you either need a redistribution policy from static to bgp (not recommended) or you need some other sort of policy that tells exa that you want to announce the route.
I think you overestimated exabgp's dead simplicity.
After some more testing, I found moving the route higher in the config file (before the neighbor definition rather than inside it), it propagates. So order matters more than anything. You have to define routes either BEFORE or WITHIN neighbors in each group scope.
I also do not believe exa supports any sort of routing policy. It's a dumb tool for manually injecting routes and piping updates to external apps.
The current configuration parser is currently progressive: what exists when the neighbor is created (or in the neighbor group) is what will be associated (which is not really ideal) hence why I have passed the last three weeks totally rewriting it in view of version 4.0. This is still serious WIP tho.
ExaBGP is indeed “dumb” (outch, it hurts :p) when it comes to route filtering, advanced features are “left as an exercise for the end user” using the API. I did not see an immediate need to re-invent BIRD which covers this part of the ecosystem more than well.