BUG BIRD 2.0.7 & 2.0.10 strips MED if export table is set [ was Re: Route attributes available when using export tables ]

[Hugo Slabbert]

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 at 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 at 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 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/20230315/f4a3de89/attachment.htm>