[PATCH] Add 'preferred' route attribute for selective add-path
Hi all, The attached patch adds a 'preferred' route attribute to check whether the route being processed has been selected as the best-path for the network it belongs to. This attribute does not take in a value, and returns a boolean. This is useful for allowing selection in an add-path enabled BGP session. The motivation behind selective add paths is to reduce the number of routes that are shared in an add-path enabled BGP session on a per-prefix basis. Instead of sending all paths to all destinations for an add-path session, we would like to specify prefixes (and/or other route attributes) for which all paths are to be shared. Further, if there are thousands of ways to reach a destination, simply negotiating add paths for a prefix would result in sharing all additional paths to the peer. This in turn would result in a flood of advertisements to be sent between the nodes, and a high memory footprint on the peer. To avoid this, we are considering a filter-based selection criteria that would unlock the potential of purposefully sending additional paths when desired. Adding the 'preferred' keyword allows us to always send the best-path whether or not other criteria in the export filter match. In the following example, a route is exported when it is either the best route or one of 172.16.0.0/16, 10.0.0.0/8{16,24} (regardless of best route status). In the case of 8.8.8.0/24, we export it if it's the best route, or if it additionally has the specified extended community attached to the route. protocol bgp { [....] add paths tx; export filter { if preferred || (net = [172.16.0.0/16, 10.0.0.0/8{16,24}]) then accept; if preferred || (net = 8.8.8.0/24 && (ro, 1, 2) ~ bgp_ext_community) then accept; #remaining filter code reject; } } Cheers, Trisha -- *Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly>
On Fri, Feb 26, 2021 at 01:56:42PM -0800, Trisha Biswas wrote:
Hi all,
The attached patch adds a 'preferred' route attribute to check whether the route being processed has been selected as the best-path for the network it belongs to. This attribute does not take in a value, and returns a boolean. This is useful for allowing selection in an add-path enabled BGP session.
Hi I agree this may be a useful feature, but there are two issues with the approach used in the patch: First, we would like not to access rte->net from the filters (outside of net_addr). We plan to remove this ptr and instead have ptr from rte directly to net_addr. Second, RA_ANY mode of route announcement (which is used by BGP add-path and pipes) would not really work with this change in a way how you expect - consider this scenario: route A is added, preferred and accepted for export, then route B is added, not-preferred and not-accepted for export. Then route A is withdrawn and B is selected as preferred. Protocols with RA_OPTIMAL received update with route B as new-preferred (as they accept only preferred one and that changed), but protocols with RA_ANY receive just withdraw for route A (as they accept all routes and only route A was changed, while route B is the same as was announced before), so they do not get notification that route B became preferred and export filter for B is not re-evaluated. The one approach that avoids the first issue is to add REF_BEST flag (in rte->flags) that would be added to mark preferred routes, and this flag can be accessed from the filter code. But that does not fix the second issue. We can add RA_ANY announcement for routes that changed their REF_BEST, but that would add plenty of unnecessary announcements (that are propagated as BGP updates) for BGP add-path that do not use or care about this flag. In general, BGP add-path in BIRD was developed with assumption that routes within one network are handled independently and would need some deeper redesign for other cases. That might be useful (in order to be able to implement things like 'announce best 4 routes for given network'), but i do not see an easy solution to this. -- 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."
Hi Ondrej, Thanks for evaluating the patch. It makes sense to use rte->flags to store the preferred path and access that from the filter code to get around the first issue. For the second issue, it almost feels like there should be a separate mode of route announcement called RA_SELECTIVE. This would be exactly the same as RA_ANY, but in addition it would announce when routes change their REF_BEST. The RA_SELECTIVE mode could be enabled with a config option such as 'add paths tx selective;', so that we don't end up with lots of unnecessary announcements for BGP add-path. Previously, we had tried this by making RA_SELECTIVE a clone of RA_OPTIMAL, but that did not work well. Do you see issues with this approach up front? Thanks, Trisha -- *Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly> On Fri, Feb 26, 2021 at 3:53 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Fri, Feb 26, 2021 at 01:56:42PM -0800, Trisha Biswas wrote:
Hi all,
The attached patch adds a 'preferred' route attribute to check whether the route being processed has been selected as the best-path for the network it belongs to. This attribute does not take in a value, and returns a boolean. This is useful for allowing selection in an add-path enabled BGP session.
Hi
I agree this may be a useful feature, but there are two issues with the approach used in the patch:
First, we would like not to access rte->net from the filters (outside of net_addr). We plan to remove this ptr and instead have ptr from rte directly to net_addr.
Second, RA_ANY mode of route announcement (which is used by BGP add-path and pipes) would not really work with this change in a way how you expect - consider this scenario: route A is added, preferred and accepted for export, then route B is added, not-preferred and not-accepted for export. Then route A is withdrawn and B is selected as preferred. Protocols with RA_OPTIMAL received update with route B as new-preferred (as they accept only preferred one and that changed), but protocols with RA_ANY receive just withdraw for route A (as they accept all routes and only route A was changed, while route B is the same as was announced before), so they do not get notification that route B became preferred and export filter for B is not re-evaluated.
The one approach that avoids the first issue is to add REF_BEST flag (in rte->flags) that would be added to mark preferred routes, and this flag can be accessed from the filter code. But that does not fix the second issue. We can add RA_ANY announcement for routes that changed their REF_BEST, but that would add plenty of unnecessary announcements (that are propagated as BGP updates) for BGP add-path that do not use or care about this flag.
In general, BGP add-path in BIRD was developed with assumption that routes within one network are handled independently and would need some deeper redesign for other cases. That might be useful (in order to be able to implement things like 'announce best 4 routes for given network'), but i do not see an easy solution to this.
-- 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."
On Fri, Feb 26, 2021 at 1:56 PM Trisha Biswas <tbiswas@fastly.com> wrote:
Hi all,
The attached patch adds a 'preferred' route attribute to check whether the route being processed has been selected as the best-path for the network it belongs to. This attribute does not take in a value, and returns a boolean. This is useful for allowing selection in an add-path enabled BGP session.
The motivation behind selective add paths is to reduce the number of routes that are shared in an add-path enabled BGP session on a per-prefix basis. Instead of sending all paths to all destinations for an add-path session, we would like to specify prefixes (and/or other route attributes) for which all paths are to be shared. Further, if there are thousands of ways to reach a destination, simply negotiating add paths for a prefix would result in sharing all additional paths to the peer. This in turn would result in a flood of advertisements to be sent between the nodes, and a high memory footprint on the peer. To avoid this, we are considering a filter-based selection criteria that would unlock the potential of purposefully sending additional paths when desired.
Adding the 'preferred' keyword allows us to always send the best-path whether or not other criteria in the export filter match. In the following example, a route is exported when it is either the best route or one of 172.16.0.0/16, 10.0.0.0/8{16,24} <http://10.0.0.0/8%7B16,24%7D> (regardless of best route status). In the case of 8.8.8.0/24, we export it if it's the best route, or if it additionally has the specified extended community attached to the route.
protocol bgp { [....] add paths tx; export filter { if preferred || (net = [172.16.0.0/16, 10.0.0.0/8{16,24} <http://10.0.0.0/8%7B16,24%7D>]) then accept; if preferred || (net = 8.8.8.0/24 && (ro, 1, 2) ~ bgp_ext_community) then accept; #remaining filter code reject; } }
Cheers, Trisha --
*Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly>
Hello! I have recently done some substantial changes in route exports (in separate branches). I'd like to summarize what we are looking for. 1) have 'primary' in the filter and decide based on it 2) export 'first N routes' with sorted table I suppose this may be possible in the new code which is currently placed into the guernsey branch. I'll try to implement something of that while refactoring exports. Maria On February 27, 2021 2:26:48 AM GMT+01:00, Trisha Biswas <tbiswas@fastly.com> wrote:
Hi Ondrej,
Thanks for evaluating the patch. It makes sense to use rte->flags to store the preferred path and access that from the filter code to get around the first issue.
For the second issue, it almost feels like there should be a separate mode of route announcement called RA_SELECTIVE. This would be exactly the same as RA_ANY, but in addition it would announce when routes change their REF_BEST. The RA_SELECTIVE mode could be enabled with a config option such as 'add paths tx selective;', so that we don't end up with lots of unnecessary announcements for BGP add-path. Previously, we had tried this by making RA_SELECTIVE a clone of RA_OPTIMAL, but that did not work well. Do you see issues with this approach up front?
Thanks, Trisha --
*Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly>
On Fri, Feb 26, 2021 at 3:53 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Fri, Feb 26, 2021 at 01:56:42PM -0800, Trisha Biswas wrote:
Hi all,
The attached patch adds a 'preferred' route attribute to check whether the route being processed has been selected as the best-path for the network it belongs to. This attribute does not take in a value, and returns a boolean. This is useful for allowing selection in an add-path enabled BGP session.
Hi
I agree this may be a useful feature, but there are two issues with the approach used in the patch:
First, we would like not to access rte->net from the filters (outside of net_addr). We plan to remove this ptr and instead have ptr from rte directly to net_addr.
Second, RA_ANY mode of route announcement (which is used by BGP add-path and pipes) would not really work with this change in a way how you expect - consider this scenario: route A is added, preferred and accepted for export, then route B is added, not-preferred and not-accepted for export. Then route A is withdrawn and B is selected as preferred. Protocols with RA_OPTIMAL received update with route B as new-preferred (as they accept only preferred one and that changed), but protocols with RA_ANY receive just withdraw for route A (as they accept all routes and only route A was changed, while route B is the same as was announced before), so they do not get notification that route B became preferred and export filter for B is not re-evaluated.
The one approach that avoids the first issue is to add REF_BEST flag (in rte->flags) that would be added to mark preferred routes, and this flag can be accessed from the filter code. But that does not fix the second issue. We can add RA_ANY announcement for routes that changed their REF_BEST, but that would add plenty of unnecessary announcements (that are propagated as BGP updates) for BGP add-path that do not use or care about this flag.
In general, BGP add-path in BIRD was developed with assumption that routes within one network are handled independently and would need some deeper redesign for other cases. That might be useful (in order to be able to implement things like 'announce best 4 routes for given network'), but i do not see an easy solution to this.
-- 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."
On Fri, Feb 26, 2021 at 1:56 PM Trisha Biswas <tbiswas@fastly.com> wrote:
Hi all,
The attached patch adds a 'preferred' route attribute to check whether the route being processed has been selected as the best-path for the network it belongs to. This attribute does not take in a value, and returns a boolean. This is useful for allowing selection in an add-path enabled BGP session.
The motivation behind selective add paths is to reduce the number of routes that are shared in an add-path enabled BGP session on a per-prefix basis. Instead of sending all paths to all destinations for an add-path session, we would like to specify prefixes (and/or other route attributes) for which all paths are to be shared. Further, if there are thousands of ways to reach a destination, simply negotiating add paths for a prefix would result in sharing all additional paths to the peer. This in turn would result in a flood of advertisements to be sent between the nodes, and a high memory footprint on the peer. To avoid this, we are considering a filter-based selection criteria that would unlock the potential of purposefully sending additional paths when desired.
Adding the 'preferred' keyword allows us to always send the best-path whether or not other criteria in the export filter match. In the following example, a route is exported when it is either the best route or one of 172.16.0.0/16, 10.0.0.0/8{16,24} <http://10.0.0.0/8%7B16,24%7D> (regardless of best route status). In the case of 8.8.8.0/24, we export it if it's the best route, or if it additionally has the specified extended community attached to the route.
protocol bgp { [....] add paths tx; export filter { if preferred || (net = [172.16.0.0/16, 10.0.0.0/8{16,24} <http://10.0.0.0/8%7B16,24%7D>]) then accept; if preferred || (net = 8.8.8.0/24 && (ro, 1, 2) ~ bgp_ext_community) then accept; #remaining filter code reject; } }
Cheers, Trisha --
*Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly>
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hi Maria, I had a question on (1). By 'primary' did you mean something similar to the 'preferred' keyword described on this thread? If so, does this include surrounding logic to take of scenarios where routes might not get advertised because of RA_ANY behavior? Any idea of when these changes might get merged into master? Thanks! Trisha -- *Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly> On Sat, Feb 27, 2021 at 2:05 AM Maria Matějka <maria.matejka@nic.cz> wrote:
Hello! I have recently done some substantial changes in route exports (in separate branches). I'd like to summarize what we are looking for.
1) have 'primary' in the filter and decide based on it 2) export 'first N routes' with sorted table
I suppose this may be possible in the new code which is currently placed into the guernsey branch. I'll try to implement something of that while refactoring exports.
Maria
On February 27, 2021 2:26:48 AM GMT+01:00, Trisha Biswas < tbiswas@fastly.com> wrote:
Hi Ondrej,
Thanks for evaluating the patch. It makes sense to use rte->flags to store the preferred path and access that from the filter code to get around the first issue.
For the second issue, it almost feels like there should be a separate mode of route announcement called RA_SELECTIVE. This would be exactly the same as RA_ANY, but in addition it would announce when routes change their REF_BEST. The RA_SELECTIVE mode could be enabled with a config option such as 'add paths tx selective;', so that we don't end up with lots of unnecessary announcements for BGP add-path. Previously, we had tried this by making RA_SELECTIVE a clone of RA_OPTIMAL, but that did not work well. Do you see issues with this approach up front?
Thanks, Trisha --
*Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly>
On Fri, Feb 26, 2021 at 3:53 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Fri, Feb 26, 2021 at 01:56:42PM -0800, Trisha Biswas wrote:
Hi all,
The attached patch adds a 'preferred' route attribute to check whether the route being processed has been selected as the best-path for the network it belongs to. This attribute does not take in a value, and returns a boolean. This is useful for allowing selection in an add-path enabled BGP session.
Hi
I agree this may be a useful feature, but there are two issues with the approach used in the patch:
First, we would like not to access rte->net from the filters (outside of net_addr). We plan to remove this ptr and instead have ptr from rte directly to net_addr.
Second, RA_ANY mode of route announcement (which is used by BGP add-path and pipes) would not really work with this change in a way how you expect - consider this scenario: route A is added, preferred and accepted for export, then route B is added, not-preferred and not-accepted for export. Then route A is withdrawn and B is selected as preferred. Protocols with RA_OPTIMAL received update with route B as new-preferred (as they accept only preferred one and that changed), but protocols with RA_ANY receive just withdraw for route A (as they accept all routes and only route A was changed, while route B is the same as was announced before), so they do not get notification that route B became preferred and export filter for B is not re-evaluated.
The one approach that avoids the first issue is to add REF_BEST flag (in rte->flags) that would be added to mark preferred routes, and this flag can be accessed from the filter code. But that does not fix the second issue. We can add RA_ANY announcement for routes that changed their REF_BEST, but that would add plenty of unnecessary announcements (that are propagated as BGP updates) for BGP add-path that do not use or care about this flag.
In general, BGP add-path in BIRD was developed with assumption that routes within one network are handled independently and would need some deeper redesign for other cases. That might be useful (in order to be able to implement things like 'announce best 4 routes for given network'), but i do not see an easy solution to this.
-- 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."
On Fri, Feb 26, 2021 at 1:56 PM Trisha Biswas <tbiswas@fastly.com> wrote:
Hi all,
The attached patch adds a 'preferred' route attribute to check whether the route being processed has been selected as the best-path for the network it belongs to. This attribute does not take in a value, and returns a boolean. This is useful for allowing selection in an add-path enabled BGP session.
The motivation behind selective add paths is to reduce the number of routes that are shared in an add-path enabled BGP session on a per-prefix basis. Instead of sending all paths to all destinations for an add-path session, we would like to specify prefixes (and/or other route attributes) for which all paths are to be shared. Further, if there are thousands of ways to reach a destination, simply negotiating add paths for a prefix would result in sharing all additional paths to the peer. This in turn would result in a flood of advertisements to be sent between the nodes, and a high memory footprint on the peer. To avoid this, we are considering a filter-based selection criteria that would unlock the potential of purposefully sending additional paths when desired.
Adding the 'preferred' keyword allows us to always send the best-path whether or not other criteria in the export filter match. In the following example, a route is exported when it is either the best route or one of 172.16.0.0/16, 10.0.0.0/8{16,24} <http://10.0.0.0/8%7B16,24%7D> (regardless of best route status). In the case of 8.8.8.0/24, we export it if it's the best route, or if it additionally has the specified extended community attached to the route.
protocol bgp { [....] add paths tx; export filter { if preferred || (net = [172.16.0.0/16, 10.0.0.0/8{16,24} <http://10.0.0.0/8%7B16,24%7D>]) then accept; if preferred || (net = 8.8.8.0/24 && (ro, 1, 2) ~ bgp_ext_community) then accept; #remaining filter code reject; } }
Cheers, Trisha --
*Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly>
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Yes, I currently think about something like preexport limit <expr>; export <filter>; postexport limit <expr>; Current secondary policy would be preexport limit any, postexport limit 1. Current RA_OPTIMAL would be preexport limit 1. In the filter, you would have a new readonly attribute 'order'. In case of unsorted table, it would be 0 for best, 1 for others, in case of sorted table it would be the higher order the worse route. If the filter uses the order, it is re-evaluated in each case when the order changes. Don't take me much seriously for now, I'm definitely not promising this. Anyway for now, this seems to be doable. Merge to master? I don't know. If implemented, it is going to be in the first multithreaded version. I have no estimate when we say that the multithreaded version is stable enough to be a master. Maria On March 4, 2021 7:32:16 PM GMT+01:00, Trisha Biswas <tbiswas@fastly.com> wrote:
Hi Maria,
I had a question on (1). By 'primary' did you mean something similar to the 'preferred' keyword described on this thread? If so, does this include surrounding logic to take of scenarios where routes might not get advertised because of RA_ANY behavior?
Any idea of when these changes might get merged into master?
Thanks! Trisha --
*Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly>
On Sat, Feb 27, 2021 at 2:05 AM Maria Matějka <maria.matejka@nic.cz> wrote:
Hello! I have recently done some substantial changes in route exports (in separate branches). I'd like to summarize what we are looking for.
1) have 'primary' in the filter and decide based on it 2) export 'first N routes' with sorted table
I suppose this may be possible in the new code which is currently placed into the guernsey branch. I'll try to implement something of that while refactoring exports.
Maria
On February 27, 2021 2:26:48 AM GMT+01:00, Trisha Biswas < tbiswas@fastly.com> wrote:
Hi Ondrej,
Thanks for evaluating the patch. It makes sense to use rte->flags to store the preferred path and access that from the filter code to get around the first issue.
For the second issue, it almost feels like there should be a
separate
mode of route announcement called RA_SELECTIVE. This would be exactly the same as RA_ANY, but in addition it would announce when routes change their REF_BEST. The RA_SELECTIVE mode could be enabled with a config option such as 'add paths tx selective;', so that we don't end up with lots of unnecessary announcements for BGP add-path. Previously, we had tried this by making RA_SELECTIVE a clone of RA_OPTIMAL, but that did not work well. Do you see issues with this approach up front?
Thanks, Trisha --
*Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly>
On Fri, Feb 26, 2021 at 3:53 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Fri, Feb 26, 2021 at 01:56:42PM -0800, Trisha Biswas wrote:
Hi all,
The attached patch adds a 'preferred' route attribute to check whether the route being processed has been selected as the best-path for the network it belongs to. This attribute does not take in a value, and returns a boolean. This is useful for allowing selection in an add-path enabled BGP session.
Hi
I agree this may be a useful feature, but there are two issues with the approach used in the patch:
First, we would like not to access rte->net from the filters (outside of net_addr). We plan to remove this ptr and instead have ptr from rte directly to net_addr.
Second, RA_ANY mode of route announcement (which is used by BGP add-path and pipes) would not really work with this change in a way how you expect - consider this scenario: route A is added, preferred and accepted for export, then route B is added, not-preferred and not-accepted for export. Then route A is withdrawn and B is selected as preferred. Protocols with RA_OPTIMAL received update with route B as new-preferred (as they accept only preferred one and that changed), but protocols with RA_ANY receive just withdraw for route A (as they accept all routes and only route A was changed, while route B is the same as was announced before), so they do not get notification that route B became preferred and export filter for B is not re-evaluated.
The one approach that avoids the first issue is to add REF_BEST flag (in rte->flags) that would be added to mark preferred routes, and this flag can be accessed from the filter code. But that does not fix the second issue. We can add RA_ANY announcement for routes that changed their REF_BEST, but that would add plenty of unnecessary announcements (that are propagated as BGP updates) for BGP add-path that do not use or care about this flag.
In general, BGP add-path in BIRD was developed with assumption that routes within one network are handled independently and would need some deeper redesign for other cases. That might be useful (in order to be able to implement things like 'announce best 4 routes for given network'), but i do not see an easy solution to this.
-- 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."
On Fri, Feb 26, 2021 at 1:56 PM Trisha Biswas <tbiswas@fastly.com> wrote:
Hi all,
The attached patch adds a 'preferred' route attribute to check whether the route being processed has been selected as the best-path for the network it belongs to. This attribute does not take in a value, and returns a boolean. This is useful for allowing selection in an add-path enabled BGP session.
The motivation behind selective add paths is to reduce the number of routes that are shared in an add-path enabled BGP session on a per-prefix basis. Instead of sending all paths to all destinations for an add-path session, we would like to specify prefixes (and/or other route attributes) for which all paths are to be shared. Further, if there are thousands of ways to reach a destination, simply negotiating add paths for a prefix would result in sharing all additional paths to the peer. This in turn would result in a flood of advertisements to be sent between the nodes, and a high memory footprint on the peer. To avoid this, we are considering a filter-based selection criteria that would unlock the potential of purposefully sending additional paths when desired.
Adding the 'preferred' keyword allows us to always send the best-path whether or not other criteria in the export filter match. In the following example, a route is exported when it is either the best route or one of 172.16.0.0/16, 10.0.0.0/8{16,24} <http://10.0.0.0/8%7B16,24%7D> (regardless of best route status). In the case of 8.8.8.0/24, we export it if it's the best route, or if it additionally has the specified extended community attached to the route.
protocol bgp { [....] add paths tx; export filter { if preferred || (net = [172.16.0.0/16, 10.0.0.0/8{16,24} <http://10.0.0.0/8%7B16,24%7D>]) then accept; if preferred || (net = 8.8.8.0/24 && (ro, 1, 2) ~ bgp_ext_community) then accept; #remaining filter code reject; } }
Cheers, Trisha --
*Trisha Biswas* | Sr. Software Engineer, Network Systems fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn <http://www.linkedin.com/company/fastly>
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
participants (3)
-
Maria Matějka -
Ondrej Zajicek -
Trisha Biswas