Hi, I remembered reading this thread. You might have the similar problem: https://bird.network.cz/pipermail/bird-users/2022-October/016348.html
On Tue, Mar 7, 2023 at 9:14 PM Hugo Slabbert via Bird-users < [email protected]> wrote: > 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. > >
