On Mon, Nov 07, 2016 at 09:18:46PM -0800, João Taveira Araújo wrote:
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. ... 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)
I don't understand this. Even if the route from transit_3 appears during the window of opportunity, it should disappear as the static route is propagated again to transit_3 and transit_3 selected it (assuming that it is the reason why it was not propagated before).
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.
How does this ext community clobbering is expressed? Could you document it by appropriate 'show route all'?
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.
That is true, it should not. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."