Route attributes available when using export tables

[Hugo Slabbert]

Hi folks,

On bird 2.0.7. We've been debugging some export behaviour (ref subject
"BIRD continues exporting routes but reports no exports"), and enabled
export tables on ipv4 and ipv6 channels for some of our BGP sessions. When
we did that, we found that the MED we were applying in our export filters
were no longer being stamped on export.

We're setting route preference on locally defined static routes, and then
setting MED at export based on that route preference. Since the preference
order is flipped between MED and BIRD's route preference (higher preference
is better; lower MED is better), we transform that and bank it around 100,
e.g. preference 100 -> MED 100; preference 99 -> MED 110, etc:

```
function preference_to_med ()
int tier;
{
    tier = 100 - preference;
    return 100 + (tier * 10);
}
```

Best I can tell, it appears that the `preference` attribute is not
available on routes when they're passed through export tables.

I tried instead to just stamp igp_metric on the static routes right when
they are defined, to the same value as we would have for the MED, and then
just doing `bgp_med = igp_metric` in the export filter, but that also did
not work as MED was still not being stamped on export.

We can and do also set `bgp_med` on the static routes right at their
initial definition time. But, they are defined in a different table and
being pulled into the source table for the exports through a pipe (so e.g.
defined in MY_CUSTOM_TABLE with bgp_med set, then imported via pipe to
master4, and exported from master4 via BGP), and it appears that operation
means the initial MED defined on the route is not retained on export after
passing through the pipe and needing to be set again explicitly.

Are these types of BIRD "internal" route attributes, e.g. preference,
igp_metric, not present on routes when they're passed through export
tables? I suppose we could instead use BGP communities on the route, and
extract the value portion of the community, but we were trying to keep
things to a native metric type value. I.e. we want to just pass this across
the BGP session as something like MED rather than making the far end apply
a function to extract a value from a community. We could still use
communities purely *within* the local BIRD instance for that, using the
function only locally and still stamping MED on export; I'm just trying to
determine if that's the best path, as it feels a bit clunky to need to use
communities for something that is only locally significant within the local
BIRD instance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20230307/bddc0fa7/attachment.htm>