Route attributes overwritten during reconfiguration

[João Taveira Araújo]

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