Route attributes available when using export tables

Alexander Zubkov green at qrator.net
Tue Mar 7 21:51:49 CET 2023


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 <
bird-users at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20230307/823667c0/attachment.htm>


More information about the Bird-users mailing list