[PATCH,RFC] Allow exchanging LOCAL_PREF with eBGP peers.
Hello! I've attached a patch that allows (selectively) exchanging LOCAL_PREF with eBGP peers. The BGP RFC (RFC4271) says that you shouldn't send LOCAL_PREF to eBGP peers, but most modern BGP implementations have an override to allow doing this anyway, and it is very useful in some scenarios, for example if you have a network topology a la RFC7938. This patch enables this functionality by the 'ebgp localpref' clause in a bgp protocol statement, for example: protocol bgp mypeer { [...]; ebgp localpref rx; } This option works like 'add paths', in that the possible arguments are "rx" or "tx" or a bool (where "yes" means both rx and tx). RFC4271 also specifies that if LOCAL_PREF is received from an eBGP speaker, it should be ignored (and you should not reply with a NOTIFICATION), so it should be safe to send LOCAL_PREF to eBGP peers that are not expecting it, and it's safe to send it to another bird -- but there are various reasons why you might not want to do that, of course. I'm not submitting this patch for inclusion yet at this point (which is why there is no documentation), but this kind of functionality is useful for us, and I'd like to hear from people whether they think this could be useful for them, too. And of course, there will have to be a lot of bikeshedding about the name of the config option! :-) Cheers, Lennert Signed-off-by: Lennert Buytenhek <lbuytenhek@fastly.com> diff --git a/proto/bgp/attrs.c b/proto/bgp/attrs.c index 9d23374..3730021 100644 --- a/proto/bgp/attrs.c +++ b/proto/bgp/attrs.c @@ -307,7 +307,7 @@ static struct attr_desc bgp_attr_table[] = { bgp_check_next_hop, bgp_format_next_hop }, { "med", 4, BAF_OPTIONAL, EAF_TYPE_INT, 1, /* BA_MULTI_EXIT_DISC */ NULL, NULL }, - { "local_pref", 4, BAF_TRANSITIVE, EAF_TYPE_INT, 0, /* BA_LOCAL_PREF */ + { "local_pref", 4, BAF_TRANSITIVE, EAF_TYPE_INT, 1, /* BA_LOCAL_PREF */ NULL, NULL }, { "atomic_aggr", 0, BAF_TRANSITIVE, EAF_TYPE_OPAQUE, 1, /* BA_ATOMIC_AGGR */ NULL, NULL }, @@ -822,8 +822,13 @@ bgp_get_bucket(struct bgp_proto *p, net *n, ea_list *attrs, int originate) code = EA_ID(a->id); if (ATTR_KNOWN(code)) { - if (!bgp_attr_table[code].allow_in_ebgp && !p->is_internal) - continue; + if (!p->is_internal) + { + if (!bgp_attr_table[code].allow_in_ebgp) + continue; + if (code == BA_LOCAL_PREF && !(p->cf->ebgp_local_pref & EBGP_LOCAL_PREF_TX)) + continue; + } /* The flags might have been zero if the attr was added by filters */ a->flags = (a->flags & BAF_PARTIAL) | bgp_attr_table[code].expected_flags; if (code < 32) @@ -1777,8 +1782,13 @@ bgp_decode_attrs(struct bgp_conn *conn, byte *attr, uint len, struct linpool *po { errcode = 5; goto err; } if ((desc->expected_flags ^ flags) & (BAF_OPTIONAL | BAF_TRANSITIVE)) { errcode = 4; goto err; } - if (!desc->allow_in_ebgp && !bgp->is_internal) - continue; + if (!bgp->is_internal) + { + if (!desc->allow_in_ebgp) + continue; + if (code == BA_LOCAL_PREF && !(bgp->cf->ebgp_local_pref & EBGP_LOCAL_PREF_RX)) + continue; + } if (desc->validate) { errcode = desc->validate(bgp, z, l); diff --git a/proto/bgp/bgp.c b/proto/bgp/bgp.c index 0f1c944..fae4be5 100644 --- a/proto/bgp/bgp.c +++ b/proto/bgp/bgp.c @@ -1556,7 +1556,7 @@ bgp_show_proto_info(struct proto *P) (c->peer_add_path & ADD_PATH_RX) ? " add-path-rx" : "", (c->peer_add_path & ADD_PATH_TX) ? " add-path-tx" : "", c->peer_ext_messages_support ? " ext-messages" : ""); - cli_msg(-1006, " Session: %s%s%s%s%s%s%s%s", + cli_msg(-1006, " Session: %s%s%s%s%s%s%s%s%s%s", p->is_internal ? "internal" : "external", p->cf->multihop ? " multihop" : "", p->rr_client ? " route-reflector" : "", @@ -1564,7 +1564,9 @@ bgp_show_proto_info(struct proto *P) p->as4_session ? " AS4" : "", p->add_path_rx ? " add-path-rx" : "", p->add_path_tx ? " add-path-tx" : "", - p->ext_messages ? " ext-messages" : ""); + p->ext_messages ? " ext-messages" : "", + (p->cf->ebgp_local_pref & EBGP_LOCAL_PREF_RX) ? " ebgp-localpref-rx" : "", + (p->cf->ebgp_local_pref & EBGP_LOCAL_PREF_TX) ? " ebgp-localpref-tx" : ""); cli_msg(-1006, " Source address: %I", p->source_addr); if (P->cf->in_limit) cli_msg(-1006, " Route limit: %d/%d", diff --git a/proto/bgp/bgp.h b/proto/bgp/bgp.h index d028bef..6e68d35 100644 --- a/proto/bgp/bgp.h +++ b/proto/bgp/bgp.h @@ -49,6 +49,7 @@ struct bgp_config { int interpret_communities; /* Hardwired handling of well-known communities */ int secondary; /* Accept also non-best routes (i.e. RA_ACCEPTED) */ int add_path; /* Use ADD-PATH extension [draft] */ + int ebgp_local_pref; /* Exchange LOCAL_PREF with eBGP peers */ int allow_local_as; /* Allow that number of local ASNs in incoming AS_PATHs */ int gr_mode; /* Graceful restart mode (BGP_GR_*) */ int setkey; /* Set MD5 password to system SA/SP database */ @@ -79,6 +80,9 @@ struct bgp_config { #define ADD_PATH_TX 2 #define ADD_PATH_FULL 3 +#define EBGP_LOCAL_PREF_RX 1 +#define EBGP_LOCAL_PREF_TX 2 + #define BGP_GR_ABLE 1 #define BGP_GR_AWARE 2 diff --git a/proto/bgp/config.Y b/proto/bgp/config.Y index 32ae88a..5db122d 100644 --- a/proto/bgp/config.Y +++ b/proto/bgp/config.Y @@ -27,7 +27,8 @@ CF_KEYWORDS(BGP, LOCAL, NEIGHBOR, AS, HOLD, TIME, CONNECT, RETRY, INTERPRET, COMMUNITIES, BGP_ORIGINATOR_ID, BGP_CLUSTER_LIST, IGP, TABLE, GATEWAY, DIRECT, RECURSIVE, MED, TTL, SECURITY, DETERMINISTIC, SECONDARY, ALLOW, BFD, ADD, PATHS, RX, TX, GRACEFUL, RESTART, AWARE, - CHECK, LINK, PORT, EXTENDED, MESSAGES, SETKEY, BGP_LARGE_COMMUNITY) + CHECK, LINK, PORT, EXTENDED, MESSAGES, SETKEY, BGP_LARGE_COMMUNITY, + EBGP, LOCALPREF) CF_GRAMMAR @@ -126,6 +127,9 @@ bgp_proto: | bgp_proto ADD PATHS RX ';' { BGP_CFG->add_path = ADD_PATH_RX; } | bgp_proto ADD PATHS TX ';' { BGP_CFG->add_path = ADD_PATH_TX; } | bgp_proto ADD PATHS bool ';' { BGP_CFG->add_path = $4 ? ADD_PATH_FULL : 0; } + | bgp_proto EBGP LOCALPREF RX ';' { BGP_CFG->ebgp_local_pref = EBGP_LOCAL_PREF_RX; } + | bgp_proto EBGP LOCALPREF TX ';' { BGP_CFG->ebgp_local_pref = EBGP_LOCAL_PREF_TX; } + | bgp_proto EBGP LOCALPREF bool ';' { BGP_CFG->ebgp_local_pref = $4 ? (EBGP_LOCAL_PREF_RX | EBGP_LOCAL_PREF_TX) : 0; } | bgp_proto ALLOW LOCAL AS ';' { BGP_CFG->allow_local_as = -1; } | bgp_proto ALLOW LOCAL AS expr ';' { BGP_CFG->allow_local_as = $5; } | bgp_proto GRACEFUL RESTART bool ';' { BGP_CFG->gr_mode = $4; }
Hi Lennert, On Sat, Feb 18, 2017 at 05:41:07AM +0200, Lennert Buytenhek wrote:
Hello!
I've attached a patch that allows (selectively) exchanging LOCAL_PREF with eBGP peers.
a perfect timing. Yesterday i thought about that ..
The BGP RFC (RFC4271) says that you shouldn't send LOCAL_PREF to eBGP peers, but most modern BGP implementations have an override to allow doing this anyway, and it is very useful in some scenarios, for example if you have a network topology a la RFC7938.
[ ... ]
I'm not submitting this patch for inclusion yet at this point (which is why there is no documentation), but this kind of functionality is useful for us, and I'd like to hear from people whether they think this could be useful for them, too. And of course, there will have to be a lot of bikeshedding about the name of the config option! :-)
I thought about it yesterday as it could be helpfull in my situation, i then come to the solution to use MED and/or an Community Setting which will trigger the LOCAL_PREF in the foreign AS (eBGP Peering). I think that is today a common way to do this. So i see the need but there exists some ways which will be more standardized within BGP!? If i had all eBGP AS Peerings under my control, it may be usefull to do it directly with a LOCAL_PREF spreaded over the ASN, if not i think you want enable it, as the foreign AS can set it to any value it want/think. And you had to filter it again to not clash it with internal AS usage of LOCAL_PREF?! So for general implementations i think it isn't needed/usefull, but for some special purposes it would be great to had the possibility to send LOCAL_PREF towards eBGP borders. just my thoughts, tim -- Tim Weippert http://weiti.org - weiti@weiti.org GPG Fingerprint - E704 7303 6FF0 8393 ADB1 398E 67F2 94AE 5995 7DD8
On Sat, Feb 18, 2017 at 12:27:22PM +0100, Tim Weippert wrote:
Hi Lennert,
Hello!
I've attached a patch that allows (selectively) exchanging LOCAL_PREF with eBGP peers.
a perfect timing. Yesterday i thought about that ..
The BGP RFC (RFC4271) says that you shouldn't send LOCAL_PREF to eBGP peers, but most modern BGP implementations have an override to allow doing this anyway, and it is very useful in some scenarios, for example if you have a network topology a la RFC7938.
[ ... ]
I'm not submitting this patch for inclusion yet at this point (which is why there is no documentation), but this kind of functionality is useful for us, and I'd like to hear from people whether they think this could be useful for them, too. And of course, there will have to be a lot of bikeshedding about the name of the config option! :-)
I thought about it yesterday as it could be helpfull in my situation, i then come to the solution to use MED and/or an Community Setting which will trigger the LOCAL_PREF in the foreign AS (eBGP Peering).
I think that is today a common way to do this. So i see the need but there exists some ways which will be more standardized within BGP!?
If i had all eBGP AS Peerings under my control, it may be usefull to do it directly with a LOCAL_PREF spreaded over the ASN, if not i think you want enable it, as the foreign AS can set it to any value it want/think. And you had to filter it again to not clash it with internal AS usage of LOCAL_PREF?!
So for general implementations i think it isn't needed/usefull, but for some special purposes it would be great to had the possibility to send LOCAL_PREF towards eBGP borders.
Thanks for your feedback! The idea here is that all eBGP peers are under control of one organisation, but you want to speak eBGP and not iBGP between them because eBGP gives you certain benefits over iBGP, such as a more sensible loop detection algorithm. RFC7938 documents some cases where you would want to do this and our use case is roughly similar to this, and it's a fairly common design pattern in datacenter networks. It's generally a bad idea to accept LOCAL_PREF from an eBGP peer that is not under your control, for reasons you mentioned and others. My patch doesn't accept LOCAL_PREF from an eBGP peer unless you specifically configure bird to do so (using 'ebgp localpref rx'), and if you don't enable that option, bird will do what it always did, which is to ignore the peer's value and fill in default_local_pref (which will be 100 if you didn't change it). Cheers, Lennert
Hi, Can you make the LOCAL_PREF something that can be matched on? Example: if ! bgp_path.local_pref = 80 then { bgp_local_pref = 100; } This way one can limit the influence of the adjacent neighbor to either 80 or 100 (default). Kind regards, Job On 18 Feb 2017, 17:07 +0100, Lennert Buytenhek <buytenh@wantstofly.org>, wrote:
On Sat, Feb 18, 2017 at 12:27:22PM +0100, Tim Weippert wrote:
Hi Lennert,
Hello!
I've attached a patch that allows (selectively) exchanging LOCAL_PREF with eBGP peers.
a perfect timing. Yesterday i thought about that ..
The BGP RFC (RFC4271) says that you shouldn't send LOCAL_PREF to eBGP peers, but most modern BGP implementations have an override to allow doing this anyway, and it is very useful in some scenarios, for example if you have a network topology a la RFC7938.
[ ... ]
I'm not submitting this patch for inclusion yet at this point (which is why there is no documentation), but this kind of functionality is useful for us, and I'd like to hear from people whether they think this could be useful for them, too. And of course, there will have to be a lot of bikeshedding about the name of the config option! :-)
I thought about it yesterday as it could be helpfull in my situation, i then come to the solution to use MED and/or an Community Setting which will trigger the LOCAL_PREF in the foreign AS (eBGP Peering).
I think that is today a common way to do this. So i see the need but there exists some ways which will be more standardized within BGP!?
If i had all eBGP AS Peerings under my control, it may be usefull to do it directly with a LOCAL_PREF spreaded over the ASN, if not i think you want enable it, as the foreign AS can set it to any value it want/think. And you had to filter it again to not clash it with internal AS usage of LOCAL_PREF?!
So for general implementations i think it isn't needed/usefull, but for some special purposes it would be great to had the possibility to send LOCAL_PREF towards eBGP borders.
Thanks for your feedback!
The idea here is that all eBGP peers are under control of one organisation, but you want to speak eBGP and not iBGP between them because eBGP gives you certain benefits over iBGP, such as a more sensible loop detection algorithm. RFC7938 documents some cases where you would want to do this and our use case is roughly similar to this, and it's a fairly common design pattern in datacenter networks.
It's generally a bad idea to accept LOCAL_PREF from an eBGP peer that is not under your control, for reasons you mentioned and others. My patch doesn't accept LOCAL_PREF from an eBGP peer unless you specifically configure bird to do so (using 'ebgp localpref rx'), and if you don't enable that option, bird will do what it always did, which is to ignore the peer's value and fill in default_local_pref (which will be 100 if you didn't change it).
Cheers, Lennert
On Sat, Feb 18, 2017 at 05:20:15PM +0100, Job Snijders wrote:
Hi,
Goedemiddag!
Can you make the LOCAL_PREF something that can be matched on? Example:
if ! bgp_path.local_pref = 80 then { bgp_local_pref = 100; }
This way one can limit the influence of the adjacent neighbor to either 80 or 100 (default).
You can match against the existing variable and change it: protocol bgp peer_a { ebgp localpref rx; import filter { if bgp_local_pref = 12349 then { print "changing it"; bgp_local_pref = 54321; } accept; }; [...] } === 2017-02-18 18:28:35 <TRACE> a: Got UPDATE 2017-02-18 18:28:35 <INFO> changing it bird> show route all 0.0.0.0/0 via 172.17.76.1 on eth0 [a 18:28:35] * (100) [AS1i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 1 BGP.next_hop: 172.17.76.1 BGP.local_pref: 54321 === Are you asking for a variable that records the received LOCAL_PREF that is separate from bgp_local_pref? Cheers, Lennert
No, your example with the existing variable is perfect. Thanks! Kind regards, Job On 18 Feb 2017, 17:34 +0100, Lennert Buytenhek <buytenh@wantstofly.org>, wrote:
On Sat, Feb 18, 2017 at 05:20:15PM +0100, Job Snijders wrote:
Hi,
Goedemiddag!
Can you make the LOCAL_PREF something that can be matched on? Example:
if ! bgp_path.local_pref = 80 then { bgp_local_pref = 100; }
This way one can limit the influence of the adjacent neighbor to either 80 or 100 (default).
You can match against the existing variable and change it:
protocol bgp peer_a { ebgp localpref rx; import filter { if bgp_local_pref = 12349 then { print "changing it"; bgp_local_pref = 54321; } accept; }; [...] }
=== 2017-02-18 18:28:35 <TRACE> a: Got UPDATE 2017-02-18 18:28:35 <INFO> changing it
bird> show route all 0.0.0.0/0 via 172.17.76.1 on eth0 [a 18:28:35] * (100) [AS1i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 1 BGP.next_hop: 172.17.76.1 BGP.local_pref: 54321 ===
Are you asking for a variable that records the received LOCAL_PREF that is separate from bgp_local_pref?
Cheers, Lennert
On Sat, Feb 18, 2017 at 05:41:07AM +0200, Lennert Buytenhek wrote:
Hello!
I've attached a patch that allows (selectively) exchanging LOCAL_PREF with eBGP peers.
The BGP RFC (RFC4271) says that you shouldn't send LOCAL_PREF to eBGP peers, but most modern BGP implementations have an override to allow doing this anyway, and it is very useful in some scenarios, for example if you have a network topology a la RFC7938.
This patch enables this functionality by the 'ebgp localpref' clause in a bgp protocol statement, for example:
protocol bgp mypeer { [...]; ebgp localpref rx; }
This option works like 'add paths', in that the possible arguments are "rx" or "tx" or a bool (where "yes" means both rx and tx).
Hello I think it is a useful feature. But rx/tx values seems like a bit overengineering. If for some obscure reason someone wants it just one way, it can easily be done in filters. -- 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 Sun, Feb 19, 2017 at 12:57:29AM +0100, Ondrej Zajicek wrote:
I've attached a patch that allows (selectively) exchanging LOCAL_PREF with eBGP peers.
The BGP RFC (RFC4271) says that you shouldn't send LOCAL_PREF to eBGP peers, but most modern BGP implementations have an override to allow doing this anyway, and it is very useful in some scenarios, for example if you have a network topology a la RFC7938.
This patch enables this functionality by the 'ebgp localpref' clause in a bgp protocol statement, for example:
protocol bgp mypeer { [...]; ebgp localpref rx; }
This option works like 'add paths', in that the possible arguments are "rx" or "tx" or a bool (where "yes" means both rx and tx).
Hello
Hi!
I think it is a useful feature. But rx/tx values seems like a bit overengineering. If for some obscure reason someone wants it just one way, it can easily be done in filters.
Good point, I agree. Here's v2, also with the corresponding change to bird.sgml, against current 1.6 git HEAD. Are you happy with the name of the config option? diff --git a/doc/bird.sgml b/doc/bird.sgml index 6af0e0f..513382d 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -2043,6 +2043,14 @@ using the following configuration parameters: TX direction. When active, all available routes accepted by the export filter are advertised to the neighbor. Default: off. + <tag><label id="bgp-ebgp-localpref">ebgp localpref <m/switch/</tag> + A standard BGP implementation will not send the Local Preference + attribute to eBGP neighbors and will ignore this attribute if received + from eBGP neighbors, as per <rfc id="4271">. When this option is + enabled on an eBGP session, this attribute will be sent to and + accepted from the peer, which is useful for example if you have a + setup like in <rfc id="7938">. + <tag><label id="bgp-allow-local-as">allow local as [<m/number/]</tag> BGP prevents routing loops by rejecting received routes with the local AS number in the AS path. This option allows to loose or disable the diff --git a/proto/bgp/attrs.c b/proto/bgp/attrs.c index 9d23374..257c0ff 100644 --- a/proto/bgp/attrs.c +++ b/proto/bgp/attrs.c @@ -307,7 +307,7 @@ static struct attr_desc bgp_attr_table[] = { bgp_check_next_hop, bgp_format_next_hop }, { "med", 4, BAF_OPTIONAL, EAF_TYPE_INT, 1, /* BA_MULTI_EXIT_DISC */ NULL, NULL }, - { "local_pref", 4, BAF_TRANSITIVE, EAF_TYPE_INT, 0, /* BA_LOCAL_PREF */ + { "local_pref", 4, BAF_TRANSITIVE, EAF_TYPE_INT, 1, /* BA_LOCAL_PREF */ NULL, NULL }, { "atomic_aggr", 0, BAF_TRANSITIVE, EAF_TYPE_OPAQUE, 1, /* BA_ATOMIC_AGGR */ NULL, NULL }, @@ -822,8 +822,13 @@ bgp_get_bucket(struct bgp_proto *p, net *n, ea_list *attrs, int originate) code = EA_ID(a->id); if (ATTR_KNOWN(code)) { - if (!bgp_attr_table[code].allow_in_ebgp && !p->is_internal) - continue; + if (!p->is_internal) + { + if (!bgp_attr_table[code].allow_in_ebgp) + continue; + if (code == BA_LOCAL_PREF && !p->cf->ebgp_local_pref) + continue; + } /* The flags might have been zero if the attr was added by filters */ a->flags = (a->flags & BAF_PARTIAL) | bgp_attr_table[code].expected_flags; if (code < 32) @@ -1777,8 +1782,13 @@ bgp_decode_attrs(struct bgp_conn *conn, byte *attr, uint len, struct linpool *po { errcode = 5; goto err; } if ((desc->expected_flags ^ flags) & (BAF_OPTIONAL | BAF_TRANSITIVE)) { errcode = 4; goto err; } - if (!desc->allow_in_ebgp && !bgp->is_internal) - continue; + if (!bgp->is_internal) + { + if (!desc->allow_in_ebgp) + continue; + if (code == BA_LOCAL_PREF && !bgp->cf->ebgp_local_pref) + continue; + } if (desc->validate) { errcode = desc->validate(bgp, z, l); diff --git a/proto/bgp/bgp.c b/proto/bgp/bgp.c index 0f1c944..dee4d91 100644 --- a/proto/bgp/bgp.c +++ b/proto/bgp/bgp.c @@ -1556,7 +1556,7 @@ bgp_show_proto_info(struct proto *P) (c->peer_add_path & ADD_PATH_RX) ? " add-path-rx" : "", (c->peer_add_path & ADD_PATH_TX) ? " add-path-tx" : "", c->peer_ext_messages_support ? " ext-messages" : ""); - cli_msg(-1006, " Session: %s%s%s%s%s%s%s%s", + cli_msg(-1006, " Session: %s%s%s%s%s%s%s%s%s", p->is_internal ? "internal" : "external", p->cf->multihop ? " multihop" : "", p->rr_client ? " route-reflector" : "", @@ -1564,7 +1564,8 @@ bgp_show_proto_info(struct proto *P) p->as4_session ? " AS4" : "", p->add_path_rx ? " add-path-rx" : "", p->add_path_tx ? " add-path-tx" : "", - p->ext_messages ? " ext-messages" : ""); + p->ext_messages ? " ext-messages" : "", + p->cf->ebgp_local_pref ? " ebgp-localpref" : ""); cli_msg(-1006, " Source address: %I", p->source_addr); if (P->cf->in_limit) cli_msg(-1006, " Route limit: %d/%d", diff --git a/proto/bgp/bgp.h b/proto/bgp/bgp.h index d028bef..69c06d6 100644 --- a/proto/bgp/bgp.h +++ b/proto/bgp/bgp.h @@ -49,6 +49,7 @@ struct bgp_config { int interpret_communities; /* Hardwired handling of well-known communities */ int secondary; /* Accept also non-best routes (i.e. RA_ACCEPTED) */ int add_path; /* Use ADD-PATH extension [draft] */ + int ebgp_local_pref; /* Exchange LOCAL_PREF with eBGP peers */ int allow_local_as; /* Allow that number of local ASNs in incoming AS_PATHs */ int gr_mode; /* Graceful restart mode (BGP_GR_*) */ int setkey; /* Set MD5 password to system SA/SP database */ diff --git a/proto/bgp/config.Y b/proto/bgp/config.Y index 32ae88a..4cc1291 100644 --- a/proto/bgp/config.Y +++ b/proto/bgp/config.Y @@ -27,7 +27,8 @@ CF_KEYWORDS(BGP, LOCAL, NEIGHBOR, AS, HOLD, TIME, CONNECT, RETRY, INTERPRET, COMMUNITIES, BGP_ORIGINATOR_ID, BGP_CLUSTER_LIST, IGP, TABLE, GATEWAY, DIRECT, RECURSIVE, MED, TTL, SECURITY, DETERMINISTIC, SECONDARY, ALLOW, BFD, ADD, PATHS, RX, TX, GRACEFUL, RESTART, AWARE, - CHECK, LINK, PORT, EXTENDED, MESSAGES, SETKEY, BGP_LARGE_COMMUNITY) + CHECK, LINK, PORT, EXTENDED, MESSAGES, SETKEY, BGP_LARGE_COMMUNITY, + EBGP, LOCALPREF) CF_GRAMMAR @@ -126,6 +127,7 @@ bgp_proto: | bgp_proto ADD PATHS RX ';' { BGP_CFG->add_path = ADD_PATH_RX; } | bgp_proto ADD PATHS TX ';' { BGP_CFG->add_path = ADD_PATH_TX; } | bgp_proto ADD PATHS bool ';' { BGP_CFG->add_path = $4 ? ADD_PATH_FULL : 0; } + | bgp_proto EBGP LOCALPREF bool ';' { BGP_CFG->ebgp_local_pref = $4; } | bgp_proto ALLOW LOCAL AS ';' { BGP_CFG->allow_local_as = -1; } | bgp_proto ALLOW LOCAL AS expr ';' { BGP_CFG->allow_local_as = $5; } | bgp_proto GRACEFUL RESTART bool ';' { BGP_CFG->gr_mode = $4; }
On Mon, Feb 20, 2017 at 06:08:41AM +0200, Lennert Buytenhek wrote:
I think it is a useful feature. But rx/tx values seems like a bit overengineering. If for some obscure reason someone wants it just one way, it can easily be done in filters.
Good point, I agree. Here's v2, also with the corresponding change to bird.sgml, against current 1.6 git HEAD. Are you happy with the name of the config option?
Hi The patch is OK, i will merge it. W.r.t. config option, what about 'allow bgp_local_pref'? That would make it consistent with BIRD name of the attribute and also with other options like 'default bgp_local_pref'. -- 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 Thu, Feb 23, 2017 at 04:00:42PM +0100, Ondrej Zajicek wrote:
I think it is a useful feature. But rx/tx values seems like a bit overengineering. If for some obscure reason someone wants it just one way, it can easily be done in filters.
Good point, I agree. Here's v2, also with the corresponding change to bird.sgml, against current 1.6 git HEAD. Are you happy with the name of the config option?
Hi
Hi!
The patch is OK, i will merge it. W.r.t. config option, what about 'allow bgp_local_pref'? That would make it consistent with BIRD name of the attribute and also with other options like 'default bgp_local_pref'.
I have no objections against this. Should I send a v3?
On Thu, Feb 23, 2017 at 05:05:20PM +0200, Lennert Buytenhek wrote:
The patch is OK, i will merge it. W.r.t. config option, what about 'allow bgp_local_pref'? That would make it consistent with BIRD name of the attribute and also with other options like 'default bgp_local_pref'.
I have no objections against this. Should I send a v3?
No need, i will update that. -- 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 Thu, Feb 23, 2017 at 04:09:28PM +0100, Ondrej Zajicek wrote:
On Thu, Feb 23, 2017 at 05:05:20PM +0200, Lennert Buytenhek wrote:
The patch is OK, i will merge it. W.r.t. config option, what about 'allow bgp_local_pref'? That would make it consistent with BIRD name of the attribute and also with other options like 'default bgp_local_pref'.
I have no objections against this. Should I send a v3?
Merged. -- 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."
________________________________ De: Bird-users <bird-users-bounces@network.cz> em nome de Ondrej Zajicek <santiago@crfreenet.org> Enviado: quinta-feira, 23 de fevereiro de 2017 12:00 Para: Lennert Buytenhek Cc: bird-users@network.cz; David Barroso Assunto: Re: [PATCH,RFC] Allow exchanging LOCAL_PREF with eBGP peers. On Mon, Feb 20, 2017 at 06:08:41AM +0200, Lennert Buytenhek wrote:
I think it is a useful feature. But rx/tx values seems like a bit overengineering. If for some obscure reason someone wants it just one way, it can easily be done in filters.
Good point, I agree. Here's v2, also with the corresponding change to bird.sgml, against current 1.6 git HEAD. Are you happy with the name of the config option?
Hi The patch is OK, i will merge it. W.r.t. config option, what about 'allow bgp_local_pref'? That would make it consistent with BIRD name of the attribute and also with other options like 'default bgp_local_pref'. -- 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 (5)
-
Job Snijders -
Lennert Buytenhek -
Luciano Inacio Lima -Júpiter -
Ondrej Zajicek -
Tim Weippert