Circling back here: What's the process for getting this recorded as a bug? https://bird.network.cz/pipermail/bird-users/2022-October/016348.html also confirmed this present in 2.0.10. Stripping MED silently (and without reflecting it in exported route output) when export tables are enabled is incorrect. On Tue, Mar 7, 2023 at 1:33 PM Hugo Slabbert < hugo.slabbert@menlosecurity.com> wrote:
That indeed does mirror my experience, yes, and it does not appear that there was any specific resolution in that thread.
This note from Ondrej at https://bird.network.cz/pipermail/bird-users/2022-October/016352.html seem to line up with my assumptions of this being an artifact of passing "through" the export table:
It is not expected behavior. Note that MED on route exported to EBGP should be removed, unless it is explicitly set in the export filter. I suspect that with export table, the attribute set in the export filter is considered mistakenly as 'old' instead of 'fresh' for the purpose of MED removal test, as the route is stored in the export table in-between.
Though it appears that it's perhaps not an artifact of "internal" route attributes not being present on the export table view of routes for evaluation at the export table stage to the peer, but rather than *regardless* of how you stamp MED that it will be stripped out if passed through an export table.
If that's the case, that strikes me as incorrect behaviour, yea?
On Tue, Mar 7, 2023 at 12:52 PM Alexander Zubkov <green@qrator.net> wrote:
Hi,
I remembered reading this thread. You might have the similar problem: https://bird.network.cz/pipermail/bird-users/2022-October/016348.html <https://isolate-menlo.menlosecurity.com/0/eJwdzFsKgCAQAMC77He5adHDS3SGLCHJUtaVoOjuRd8Dc0MmDxpW5pg0onG0iMPyGWgT84XRRUv75PwvZU6WEqpKqXKcORhLWMm2bnqx8u6hAAqgZQHsli-VzdDB8wKorB_W>
On Tue, Mar 7, 2023 at 9:14 PM Hugo Slabbert via Bird-users < bird-users@network.cz> 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.