Hi, I've run into a bug which manifests itself during reconfiguration. Unfortunately, the bird config in question is extremely large and I can't easily cut it down to something replicable. I'm running into this particular issue in bird6, but have no reason to believe IPv4 would fair any better. All results are using bird 1.6.2. My setup is as follows: - a static protocol, in which the import stanza adds extended communities: route 2001:db8::/48 via "lo" { bgp_ext_community.add((ro, 2, 0)); bgp_ext_community.add((ro, 3, 0)); ... } - based on these communities, the static route makes its way through a pipe from the master table, to an external table Typically all is fine - we export the route to our transits. Since we have multiple egress devices, a "show route" will show our local, static route, as well as the same route learnt through our providers: sudo birdc6 show route for 2001:db8::/48 BIRD 1.6.2 ready. 2001:db8::/48 dev lo [static_protocol 04:42:26] * (200) via xxx on et1 [transit_1 03:44:07] (100) via xxx on et2 [transit_2 03:44:07] (100) We actually have three transits, but one of our transits does not export any routes we happen to be exporting to them. Such a case happens on reconfiguring BIRD. During a reconfiguration, the static protocol gets reloaded: <TRACE> static_protocol > 2001:db8::/48 added [best] dev lo in this brief moment, a window of opportunity arises for our thus far silent transit to make an unwanted appearance: sudo birdc6 show route for 2001:db8::/48 BIRD 1.6.2 ready. 2001:db8::/48 dev lo [static_protocol 05:44:07] * (200) via xxx on et3 [transit_3 05:44:07] (100) via xxx on et1 [transit_1 03:44:07] (100) via xxx on et2 [transit_2 03:44:07] (100) This, it turns out, is tragic, because somehow the extended communities we apply to the route learnt from transit_3 clobber the ones we apply in static_protocol. I'm pretty sure something screws up the rta associated to the static route, but I'm also confused as to why the static protocol seems to get reloaded at all given there is no configuration change in the first place. We definitely want to allow local as: since the routes are potentially anycast, it is useful to have an alternate route in case we shut down the static announcement. Thanks, - j