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.