Limitations of BGP AS confederations?
Hello, in an article [1] (which was one of very few articles which I found about BIRD + BGP AS confederations) it is stated that currently, BGP AS confederations have the following limitation:
Bird won't consider the confederation part while calculating distance, which leads to weird routing results. Bird neither provides a variable for the filter to calculate confederation length and make manual adjustments. * bgp_path.len in Bird doesn't contain the length of Confederation, as stated above;
(citation from section below "But there is some problem when using Confederation in Bird") The article seems to be tested against BIRD version 2.0.7. I'm not sure if that information is really correct, as I wasn't able to find any other source which stated that, but on the other hand, I also found no other source which explains BIRD + BGP AS confederation equally (or at least) that detailed. I (as of now) wasn't able to test it, but maybe I do that soon. (but I have no lab env running here, and didn't want to disrupt my currently working BGP setup, althrough it is not 'extremely' important if it is interrupted for a short amount of time...) ## If this is still an issue in the master branch: I think it would be a good idea to add an config option to conditionally enable "count confederation AS's in bgp_path.len / distance calculations" (or add another "method" on bgp_path and an option to switch the default AS-path-length calculation to that). * The statements above and the documentation combined sound like the confederation AS's are kept inside an aggregated, (unordered?) AS-set inside of bgp_path. Is that true? (I wasn't able to find any concrete documentation about this, and previously just thought that confederation AS's were kept as an sequence.) In BGP protocol terms [2], this would imply that either: * BIRD only uses AS_CONFED_SET's for the "confederation part" (under the assumption that these are treated like AS_SET), or * BIRD uses AS_CONFED_SEQUENCE as expected, but treats AS_SET, AS_CONFED_SET and AS_CONFED_SEQUENCE equally, even though that doesn't seem like a universally practicable choice. * Is there some easier way to fix this (either via configuration which I just missed or via patching of code)? * If not, is it possible to implement a more complex fix for this in a reasonable timeframe (e.g. not an excessive amount of work for a rather niche feature)? * If it is possible, where should I start implementing it (e.g. which parts of the BGP code are probably related to this, as I don't want to read all the BGP code multiple times just to find those places)? Regards, Erik Zscheile [1]: https://lantian.pub/en/article/modify-website/bird-confederation.lantian/ [2]: RFC 5065, page 5; https://www.rfc-editor.org/rfc/rfc5065.txt
On Fri, Nov 06, 2020 at 12:01:20AM +0100, Erik Zscheile (Software Development) wrote:
Hello,
Hello
in an article [1] (which was one of very few articles which I found about BIRD + BGP AS confederations) it is stated that currently, BGP AS confederations have the following limitation:
Bird won't consider the confederation part while calculating distance, which leads to weird routing results.
That is expected behavior per RFC 5065 5.3 (3). The idea is that inside confederation BGP next hops are preserved when paths are propagated from one internal ASN to another, therefore paths are compared based on IGP cost to confederation border (assuming shared IGP routes / metrics within whole confederation).
Bird neither provides a variable for the filter to calculate confederation length and make manual adjustments. * bgp_path.len in Bird doesn't contain the length of Confederation, as stated above;
It is true that bgp_path.len returns AS PATH length without confederation ASNs, to be consistent with AS_PATH length used for best route selection. Seems to me that the best tool for your case might be AIGP option (RFC 7311, implemented in version 2.0.7).
(citation from section below "But there is some problem when using Confederation in Bird")
The article seems to be tested against BIRD version 2.0.7. I'm not sure if that information is really correct, as I wasn't able to find any other source which stated that, but on the other hand, I also found no other source which explains BIRD + BGP AS confederation equally (or at least) that detailed. I (as of now) wasn't able to test it, but maybe I do that soon. (but I have no lab env running here, and didn't want to disrupt my currently working BGP setup, althrough it is not 'extremely' important if it is interrupted for a short amount of time...)
## If this is still an issue in the master branch:
I think it would be a good idea to add an config option to conditionally enable "count confederation AS's in bgp_path.len / distance calculations" (or add another "method" on bgp_path and an option to switch the default AS-path-length calculation to that).
* The statements above and the documentation combined sound like the confederation AS's are kept inside an aggregated, (unordered?) AS-set inside of bgp_path. Is that true?
(I wasn't able to find any concrete documentation about this, and previously just thought that confederation AS's were kept as an sequence.) In BGP protocol terms [2], this would imply that either: * BIRD only uses AS_CONFED_SET's for the "confederation part" (under the assumption that these are treated like AS_SET), or * BIRD uses AS_CONFED_SEQUENCE as expected, but treats AS_SET, AS_CONFED_SET and AS_CONFED_SEQUENCE equally, even though that doesn't seem like a universally practicable choice.
BIRD uses AS_CONFED_SEQUENCE, treats AS_SEQUENCE as length n, AS_SET as length 1 and AS_CONFED_SEQUENCE / AS_CONFED_SET as length 0.
* Is there some easier way to fix this (either via configuration which I just missed or via patching of code)?
* If not, is it possible to implement a more complex fix for this in a reasonable timeframe (e.g. not an excessive amount of work for a rather niche feature)?
* If it is possible, where should I start implementing it (e.g. which parts of the BGP code are probably related to this, as I don't want to read all the BGP code multiple times just to find those places)?
Regards, Erik Zscheile
[1]: https://lantian.pub/en/article/modify-website/bird-confederation.lantian/ [2]: RFC 5065, page 5; https://www.rfc-editor.org/rfc/rfc5065.txt
-- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hello, Am 06.11.20 um 04:56 schrieb Ondrej Zajicek:
On Fri, Nov 06, 2020 at 12:01:20AM +0100, Erik Zscheile (Software Development) wrote:
in an article [1] (which was one of very few articles which I found about BIRD + BGP AS confederations) it is stated that currently, BGP AS confederations have the following limitation:
Bird won't consider the confederation part while calculating distance, which leads to weird routing results.
That is expected behavior per RFC 5065 5.3 (3).
The idea is that inside confederation BGP next hops are preserved when paths are propagated from one internal ASN to another, therefore paths are compared based on IGP cost to confederation border (assuming shared IGP routes / metrics within whole confederation).
Bird neither provides a variable for the filter to calculate confederation length and make manual adjustments. * bgp_path.len in Bird doesn't contain the length of Confederation, as stated above;
It is true that bgp_path.len returns AS PATH length without confederation ASNs, to be consistent with AS_PATH length used for best route selection.
Seems to me that the best tool for your case might be AIGP option (RFC 7311, implemented in version 2.0.7).
This might be a good fit, yes. But from the documentation I wasn't able to conclude how it should be used (e.g. how to set or increment the AIGP value)...
BIRD uses AS_CONFED_SEQUENCE, treats AS_SEQUENCE as length n, AS_SET as length 1 and AS_CONFED_SEQUENCE / AS_CONFED_SET as length 0. Thanks for that information. Maybe this should be mentioned in the documentation, as it is non-obvious.
Regards, Erik Zscheile
On Fri, Nov 06, 2020 at 11:52:11AM +0100, Erik Zscheile (Software Development) wrote:
Hello,
Am 06.11.20 um 04:56 schrieb Ondrej Zajicek:
On Fri, Nov 06, 2020 at 12:01:20AM +0100, Erik Zscheile (Software Development) wrote:
in an article [1] (which was one of very few articles which I found about BIRD + BGP AS confederations) it is stated that currently, BGP AS confederations have the following limitation:
Bird won't consider the confederation part while calculating distance, which leads to weird routing results.
That is expected behavior per RFC 5065 5.3 (3).
The idea is that inside confederation BGP next hops are preserved when paths are propagated from one internal ASN to another, therefore paths are compared based on IGP cost to confederation border (assuming shared IGP routes / metrics within whole confederation).
Bird neither provides a variable for the filter to calculate confederation length and make manual adjustments. * bgp_path.len in Bird doesn't contain the length of Confederation, as stated above;
It is true that bgp_path.len returns AS PATH length without confederation ASNs, to be consistent with AS_PATH length used for best route selection.
Seems to me that the best tool for your case might be AIGP option (RFC 7311, implemented in version 2.0.7).
This might be a good fit, yes. But from the documentation I wasn't able to conclude how it should be used (e.g. how to set or increment the AIGP value)...
You just enable 'aigp originate' on sessions to originate AIGP on local (non-BGP) routes. AIGP values are increased automatically on links that change/reset next hop (e.g. if your intra-confederation inter-AS links have have 'next hop self'); based in IGP values (if you have IGP, e.g. OSPF, inside each AS and use recursive next hop calculation) or link costs can be configured manually (e.g. if each 'AS' is just one router and BGP links use 'direct' mode).
BIRD uses AS_CONFED_SEQUENCE, treats AS_SEQUENCE as length n, AS_SET as length 1 and AS_CONFED_SEQUENCE / AS_CONFED_SET as length 0. Thanks for that information. Maybe this should be mentioned in the documentation, as it is non-obvious.
That is just behavior from RFC 5065 spec, and pretty technical. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Erik Zscheile (Software Development) -
Ondrej Zajicek