Route attributes available when using export tables
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.
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@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.
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.
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.
Hello, I recently joined an IXP and now I get some routes. Among others the following: 2401:a400::/32 unicast [grc_rs1 07:07:17.427 from 2001:7f8:2:1::ca6a] * (100) [AS7477i] via 2001:7f8:2:1::1b1b on enp6s19 Type: BGP univ BGP.origin: IGP BGP.as_path: 6939 7477 BGP.next_hop: 2001:7f8:2:1::1b1b fe80::4288:2fff:febf:2662 BGP.med: 0 BGP.local_pref: 100 BGP.community: (0,714) (0,2906) (0,6939) (0,12876) (0,12989) (0,13335) (0,15133) (0,15169) (0,16265) (0,16276) (0,16509) (0,20940) (0,22822) (0,32590) (0,48641) (0,49029) (0,57363) (51818,12) BGP.large_community: (202952, 6, 2) (202952, 1, 1) (202952, 2, 4) (202952, 3, 1) (202952, 5, 2) BGP.23 [t]: 00 00 ca 6a What does `BGP.23 [t]: 00 00 ca 6a` mean? I have never seen this before in bird. I would appreciate an answer. Greetings Marek Küthe
Hello!
What does `BGP.23 [t]: 00 00 ca 6a` mean? I have never seen this before in bird.
This should be a Path Attribute with ID 23, marked as transitive, therefore RFC 9012 Tunnel Encapsulation Attribute, yet I fail to interpret it in any reasonable way. We haven't implemented these yet, anyway it's in this year's plan. The display code for the unimplemented attributes is almost untested as we haven't found any reasonable way to inject them in our testing setup. Thus the only reliable thing is the attribute ID. I suggest asking the other side what they intended to send. Sorry for the inconvenience caused. Maria
Hello Marek, On Fri, Mar 17, 2023 at 08:23:36AM +0100, Marek Küthe wrote:
What does `BGP.23 [t]: 00 00 ca 6a` mean? I have never seen this before in bird.
That's a Only to Customer (OTC) BGP attribute[1] set by AS51818 (which is I assume the ASN of the RS you're getting the route from): BGP.23 : Attribute 0x23 (35)[2] 0x0000CA6A : 51818 Kind regards, Benjamin --- [1] https://www.rfc-editor.org/rfc/rfc9234.html#prevention_attribute [2] https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml -- Benjamin Collet
Hello!
On Fri, Mar 17, 2023 at 08:23:36AM +0100, Marek Küthe wrote:
What does `BGP.23 [t]: 00 00 ca 6a` mean? I have never seen this before in bird.
BGP.23 : Attribute 0x23 (35)[2] 0x0000CA6A : 51818
Oopsie, I didn't realize that we write the attribute ID in hex as there is not 0x prefix in there … this is confusing, we should fix it. Thank you for finding the right answer! Maria
participants (5)
-
Alexander Zubkov -
Benjamin Collet -
Hugo Slabbert -
Marek Küthe -
Maria Matejka