- Bird-users - Mailing Lists

OSPFv3 auth problem
by Joakim Tjernlund 16 Mar '21

16 Mar '21

We have a ring of routers(5 of them) running unnumbered pppoe links between them. Adding OSPF authentication (auth trailer) works OK. However, removing OSPFv3 on ONE interface causes big problem in some cases, we loose auth in the whole ring and routing is then kaputt for all routers. We have noted that some PDUs(like LS update) are sent without auth trailer so the receiving nodes complains with "ospfv3_2: Authentication failed for nbr 0.0.139.1 on p1-1-3-1-4 - missing authentication trailer (0)" OSPFv3 Hello is OK though, it still has its auth trailer. Any ideas? Jocke

3 14

BIRD Journey to Threads: Chapter zero of a blogpost series
by Maria Matejka 16 Mar '21

16 Mar '21

Hello! As we're working on multithreading support in BIRD, there is a need to document this. There is a user documentation (which almost doesn't change) and a programmer's documentation composed mostly of comments spread across the source code. There is also a kind-of high-level documentation to describe how are the BIRD's internal processes changing. If you're just an ordinary user, you don't need to care much about that. We're sharing this mostly for people who know (or want to know) how BIRD works internally and how it is going to change. The zeroth chapter is here, other chapters should follow soon: https://en.blog.nic.cz/2021/03/15/bird-journey-to-threads-chapter-0-the-rea… (Content: An introduction and summary of previous major BIRD structural changes.) I deeply appreciate your feedback and questions. Maria

4 6

[PATCH] Update IPv6 neighbour authentication state from Hello pkgs
by Joakim Tjernlund 16 Mar '21

16 Mar '21

Signed-off-by: Joakim Tjernlund <joakim.tjernlund(a)infinera.com> --- proto/ospf/hello.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proto/ospf/hello.c b/proto/ospf/hello.c index d094f934..51f685e5 100644 --- a/proto/ospf/hello.c +++ b/proto/ospf/hello.c @@ -341,6 +341,8 @@ ospf_receive_hello(struct ospf_packet *pkt, struct ospf_iface *ifa, n->bdr = rcv_bdr; n->priority = rcv_priority; n->iface_id = rcv_iface_id; + if (ospf_is_v3(p)) + n->options = (n->options & ~OPT_AT) | (rcv_options & OPT_AT); /* Update inactivity timer */ ospf_neigh_sm(n, INM_HELLOREC); -- 2.26.2

1 0

Routing decision based on carp status under freebsd
by Manon Goo 15 Mar '21

15 Mar '21

Hello, I would like announce routes differently via bgp (longer AS-Path) depending on, if carp(4) status is "master" or "backup". If the carp status is „Master“ Status the shows up as a kernel route to the carp(4) address. If carp is in "Backup“ status the route is removed. **Master Status for carp IP 10.8.15.254** bird> show route 10.8.15.254/32 all 10.8.15.254/32 dev lo0 [kernel1 00:06:42] * (10) Type: inherit unicast univ Kernel.source: 1 Kernel.metric: 0 bird> **Backup Status for carp IP 10.8.15.254** bird> show route 10.8.15.254/32 all Network not in table bird> If possible I would like to check in my bgp export filter if I have a kernel route to my carp address (10.8.15.254) and if possible if this route is via the loopback dev lo0 Is there any function to lookup a route in bird that could be used in the following scenario? filter bgp_export { if ( [ check_if_10.8.15.254/32 is via lo0] ) { bgp_local_pref = 120; accept; } else { bgp_path.prepend(65534); accept; } } Kind regards, Manon

1 0

Weird behavior of link local gateway assignments
by Marcel Krüger 15 Mar '21

15 Mar '21

Hi, I encountered some issues when trying to set the gateway to a link-local IPv6 address in a filter and am wondering if there is a trick I am missing: When assigning a link-local address (say fe80::4242%eno1) to `gw` in a filter using e.g. gw = fe80::4242%eno1; the config file parser complains about a unexpected "%". Of course, it doesn't work without the `%eno1` either ("Invalid gw address"), so is there other way to pass the intended interface? It seems that the interface doesn't get passed even if assigning from an existing address with correctly set interface, since invoking in a filter gw = gw; fails with "Invalid gw address" too if `gw` has a link local value. Is this intended? Is there some other way to set the gw in a filter to a link local value? Best regards, Marcel

2 2

[PATCH] Client: add "show hostname" command, and add client prompt hostname display
by Molly Miller 05 Mar '21

05 Mar '21

Hi all, The recent patch on the list from Vincent Bernat which added support for the draft BGP hostname capability [1] reminded me of a thread from last year, in which there was a feature request for the ability to display the system hostname in the Bird client prompt [2]. This feature doesn't appear to have been implemented since then, and now that a hostname is tracked internally by Bird, I've written a proof-of-concept patch (appended inline) which displays the daemon hostname in the client prompt. This patch adds a "show hostname" command to the daemon for convenience, and modifies the client to automatically issue this command when starting in interactive mode. The client then intercepts the response (which will either contain the daemon hostname, or be a syntax error if the daemon does not understand the command), and then sets the received hostname in the prompt if the response is a success code. (The rationale for not simply calling uname(2) in the client is that the resulting nodename may not match the hostname configured in the daemon, in the case where the daemon configuration contains a hostname "<foo>" directive. It's also possible to connect to the daemon over a Unix socket forwarded over SSH, in which case the client would be running on a separate system with a different hostname regardless of the daemon configuration -- thanks to Tim Stallard for pointing this out.) I don't know how willing the Bird maintainers would be to commit this patch, however I thought I'd post it to the list in case anyone else is interested. Cheers, --mm. [1]: https://bird.network.cz/pipermail/bird-users/2021-February/015187.html, merged as 71423871 [2]: https://bird.network.cz/pipermail/bird-users/2020-July/014678.html -- >8 -- Subject: [PATCH] Client: add "show hostname" command, and client prompt hostname display. This patch adds a "show hostname" command to the daemon, which returns the server's currently configured hostname, and extends the command line client to issue this command upon connecting to the daemon, in order to retrieve a hostname to display in the client's prompt. A '-p' option has also been added to suppress this behaviour. molly on flywheel ~> birdc BIRD v2.0.7 ready. bird (flywheel)> show hostname Hostname: flywheel bird (flywheel)> exit molly on flywheel ~> birdc -p BIRD v2.0.7 ready. bird> show hostname Hostname: flywheel bird> quit Additionally, the error message generated by older versions of the daemon when running the "show hostname" command is caught, in order to remain interoperable with versions which do not have this patch. The client program does not, however, have any means of detecting whether the hostname changes as part of an online configuration update, so changes in the daemon's hostname will not be propagated to a client which is persistent across the configuration change. --- client/birdc.c | 11 +++++++++-- client/birdcl.c | 8 +++++++- client/client.c | 48 ++++++++++++++++++++++++++++++++++++++++++------ client/client.h | 2 ++ doc/reply_codes | 1 + nest/cmds.c | 7 +++++++ nest/cmds.h | 1 + nest/config.Y | 3 +++ 8 files changed, 72 insertions(+), 9 deletions(-) diff --git a/client/birdc.c b/client/birdc.c index f1aea2fe..b1b9b218 100644 --- a/client/birdc.c +++ b/client/birdc.c @@ -162,7 +162,7 @@ input_init(void) rl_readline_name = "birdc"; rl_add_defun("bird-complete", input_complete, '\t'); rl_add_defun("bird-help", input_help, '?'); - rl_callback_handler_install("bird> ", input_got_line); + rl_callback_handler_install(prompt_string, input_got_line); // rl_get_screen_size(); term_lns = LINES; @@ -184,7 +184,7 @@ input_reveal(void) tcdrain(STDOUT_FILENO); rl_end = input_hidden_end; - rl_expand_prompt("bird> "); + rl_expand_prompt(prompt_string); rl_forced_update_display(); prompt_active = 1; @@ -201,6 +201,13 @@ input_hide(void) prompt_active = 0; } +void +input_reload(void) +{ + input_hide(); + input_reveal(); +} + void input_notify(int prompt) { diff --git a/client/birdcl.c b/client/birdcl.c index 4508185c..d36914c9 100644 --- a/client/birdcl.c +++ b/client/birdcl.c @@ -38,6 +38,12 @@ input_stop_list(void) /* Empty in non-ncurses version. */ } +void +input_reload(void) +{ + /* Empty in non-ncurses version. */ +} + void input_notify(int prompt) { @@ -45,7 +51,7 @@ input_notify(int prompt) if (!prompt) return; - printf("bird> "); + printf(prompt_string); fflush(stdout); } diff --git a/client/client.c b/client/client.c index 97cf6639..0de7aaaf 100644 --- a/client/client.c +++ b/client/client.c @@ -37,8 +37,11 @@ #include "sysdep/unix/unix.h" #define SERVER_READ_BUF_LEN 4096 +#define SERVER_PROMPT_LEN 64 +#define SERVER_PROMPT_DEFAULT "bird> " +#define SERVER_HOSTNAME_PREFIX "Hostname: " -static char *opt_list = "s:vrl"; +static char *opt_list = "s:vrlp"; static int verbose, restricted, once; static char *init_cmd; @@ -47,12 +50,15 @@ static int server_fd; static byte server_read_buf[SERVER_READ_BUF_LEN]; static byte *server_read_pos = server_read_buf; -int init = 1; /* During intial sequence */ -int busy = 1; /* Executing BIRD command */ -int interactive; /* Whether stdin is terminal */ +int init = 1; /* During intial sequence */ +int busy = 1; /* Executing BIRD command */ +int hostprompt = 1; /* Whether to show hostname in prompt */ +int interactive; /* Whether stdin is terminal */ +char prompt_string[SERVER_PROMPT_LEN]; /* Prompt string */ static int num_lines, skip_input; int term_lns, term_cls; +static int hostname_read = 0; /*** Parsing of arguments ***/ @@ -60,7 +66,7 @@ int term_lns, term_cls; static void usage(char *name) { - fprintf(stderr, "Usage: %s [-s <control-socket>] [-v] [-r] [-l]\n", name); + fprintf(stderr, "Usage: %s [-s <control-socket>] [-v] [-r] [-l] [-p]\n", name); exit(1); } @@ -87,6 +93,9 @@ parse_args(int argc, char **argv) if (!server_changed) server_path = xbasename(server_path); break; + case 'p': + hostprompt = 0; + break; default: usage(argv[0]); } @@ -199,6 +208,12 @@ init_commands(void) exit(0); } + /* Set up local prompt, and attempt to retrieve daemon hostname */ + memset(prompt_string, 0, sizeof(prompt_string)); + strcpy(prompt_string, SERVER_PROMPT_DEFAULT); + if (hostprompt) + submit_server_command("show hostname"); + input_init(); term_lns = (term_lns > 0) ? term_lns : 25; @@ -239,6 +254,16 @@ more(void) more_end(); } +static void +update_prompt(char *x) +{ + if (strncmp(x, SERVER_HOSTNAME_PREFIX, sizeof(SERVER_HOSTNAME_PREFIX)-1) != 0) + return; + + memset(prompt_string, 0, sizeof(prompt_string)); + snprintf(prompt_string, sizeof(prompt_string), "bird (%s)> ", x+sizeof(SERVER_HOSTNAME_PREFIX)-1); +} + /*** Communication with server ***/ @@ -281,7 +306,18 @@ server_got_reply(char *x) (x[4] == ' ' || x[4] == '-')) { if (code) - PRINTF(len, "%s\n", verbose ? x : x+5); + { + if ((code == 1026 || code == 9001) && !hostname_read && hostprompt) + { + hostname_read = 1; + if (code == 1026) { + update_prompt(x+5); + input_reload(); + } + } + else + PRINTF(len, "%s\n", verbose ? x : x+5); + } if (x[4] == ' ') { diff --git a/client/client.h b/client/client.h index f9693def..8de7b38c 100644 --- a/client/client.h +++ b/client/client.h @@ -9,6 +9,7 @@ extern int init, busy, interactive; extern int term_lns, term_cls; +extern char prompt_string[]; /* birdc.c / birdcl.c */ @@ -16,6 +17,7 @@ void input_start_list(void); void input_stop_list(void); void input_init(void); +void input_reload(void); void input_notify(int prompt); void input_read(void); diff --git a/doc/reply_codes b/doc/reply_codes index 02f4e656..47f9d3e8 100644 --- a/doc/reply_codes +++ b/doc/reply_codes @@ -61,6 +61,7 @@ Reply codes of BIRD command-line interface 1023 Show Babel interfaces 1024 Show Babel neighbors 1025 Show Babel entries +1026 Show hostname 8000 Reply too long 8001 Route not found diff --git a/nest/cmds.c b/nest/cmds.c index 18f39eb5..a412faf3 100644 --- a/nest/cmds.c +++ b/nest/cmds.c @@ -95,6 +95,13 @@ cmd_show_memory(void) cli_msg(0, ""); } +void +cmd_show_hostname(void) +{ + cli_msg(-1026, "Hostname: %s", config->hostname); + cli_msg(0, ""); +} + void cmd_eval(const struct f_line *expr) { diff --git a/nest/cmds.h b/nest/cmds.h index 194a9d7f..14c7293d 100644 --- a/nest/cmds.h +++ b/nest/cmds.h @@ -16,6 +16,7 @@ struct f_inst; void cmd_show_status(void); void cmd_show_symbols(struct sym_show_data *sym); void cmd_show_memory(void); +void cmd_show_hostname(void); struct f_line; void cmd_eval(const struct f_line *expr); diff --git a/nest/config.Y b/nest/config.Y index 39bf6149..72ea0726 100644 --- a/nest/config.Y +++ b/nest/config.Y @@ -564,6 +564,9 @@ CF_CLI(SHOW STATUS,,, [[Show router status]]) CF_CLI(SHOW MEMORY,,, [[Show memory usage]]) { cmd_show_memory(); } ; +CF_CLI(SHOW HOSTNAME,,, [[Show current hostname]]) +{ cmd_show_hostname(); } ; + CF_CLI(SHOW PROTOCOLS, proto_patt2, [<protocol> | \"<pattern>\"], [[Show routing protocols]]) { proto_apply_cmd($3, proto_cmd_show, 0, 0); } ; -- 2.20.1

1 1

shutdown BGP sessions without administrative shutdown?
by Tim Meusel 05 Mar '21

05 Mar '21

Hi! I'm running many boxes with Bird 2.x. They all peer with virtual JunOS routers via BGP. Each Bird instance announces routes for IP addresses from local virtual machines. In case bird dies or gets stopped for upgrades, I want that the JunOS route reflectors keep the routes for a certain amount of time. My config currently looks like this: template bgp VMX { local $ip as $as; multihop; # we don't have a layer 2 connection to the routers bfd graceful; hold time 240; startup hold time 240; connect retry time 120; graceful restart yes; graceful restart time 0; long lived graceful restart yes; long lived stale time 90; ipv4 { export filter virtual_machines_v4; import none; next hop self; }; ipv6 { export filter virtual_machines_v6; import none; next hop self; }; } protocol bgp $peer from VMX { description $desc; neighbor $ip> as $as; } this works fine if I do: * birdc reconfigure * kill -HUP on the bird pid * killall -9 bird however if I do a `systemctl stop bird`, it does an administrative shutdown and the virtual MX drops the routes. As far as I understand the RFC for LLGR this is the correct behavior. Can one of you tell me if there is an option on JunOS to keep the routes, even after a ` administrative shutdown`, or if I can advice Bird to not cleanly shutdown sessions? Cheers, Tim

2 2

Static protocol reconfiguration results in sub-optimal route updates
by Damian Zaremba 05 Mar '21

05 Mar '21

Hi, I recently observed a case where bird 2.0.7 emits sub-optimal route updates during a reconfiguration. Using the sample configuration of e.g. ipv4 table seed; ipv4 table announce; protocol static { route 203.0.113.0/24 unreachable; ipv4 { table seed; }; } protocol pipe { table announce; peer table seed; import filter { bgp_large_community.add((65000, 1, 1)); accept; }; } protocol bgp { debug all; ipv4 { table announce; export all; }; local 10.240.0.226 as 65000; neighbor 10.240.1.59 as 65000; } When the pipe configuration is updated to e.g. import filter { bgp_large_community.add((65000, 1, 2)); accept; }; Bird replaces the route into the BGP protocol; 2021-03-05 11:57:36.168 <INFO> Reconfiguring 2021-03-05 11:57:36.168 <INFO> Reloading channel pipe1.sec 2021-03-05 11:57:36.168 <TRACE> bgp1: Reconfigured 2021-03-05 11:57:36.168 <INFO> Reconfigured 2021-03-05 11:57:36.168 <TRACE> bgp1.ipv4 < replaced 203.0.113.0/24 unreachable 2021-03-05 11:57:36.168 <TRACE> bgp1: Sending UPDATE And emits a single update as expected; $ cat bgp.pcap | pbgpp --filter-message-type=UPDATE - [BGPMessage UPDATE] - 63 Bytes |- MAC: 42:01:0a:f0:00:01 -> 42:01:0a:f0:01:3b |- IP: 10.240.0.226:32871 -> 10.240.1.59:179 |- Timestamp: 2021-03-05 12:04:50.255913 (1614945890.255913) | |- Update Message Sub-Type: ANNOUNCE |- Withdrawn Routes Length: 0 Bytes |- Total Path Attribute Length: 36 Bytes |- Prefix (NLRI): |--- 203.0.113.0/24 |- Path Attributes: |--- ORIGIN: IGP |- Path Attributes: |--- AS_PATH: |- Path Attributes: |--- NEXT_HOP: 10.240.0.226 |- Path Attributes: |--- LOCAL_PREF: |- Path Attributes: |--- LARGE_COMMUNITIES: 65000:1:2 However if we directly feed the table from a static protocol e.g. ipv4 table announce; protocol static { route 203.0.113.0/24 unreachable; ipv4 { table announce; import filter { bgp_large_community.add((65000, 1, 1)); accept; }; }; } protocol bgp { debug all; ipv4 { table announce; export all; }; local 10.240.0.226 as 65000; neighbor 10.240.1.59 as 65000; } The same filter update results in a protocol restart e.g. 2021-03-05 12:10:39.042 <INFO> Reconfiguring 2021-03-05 12:10:39.042 <INFO> Cannot reconfigure channel static1.ipv4 2021-03-05 12:10:39.042 <INFO> Restarting protocol static1 2021-03-05 12:10:39.042 <TRACE> bgp1: Reconfigured 2021-03-05 12:10:39.042 <TRACE> bgp1.ipv4 < removed 203.0.113.0/24 unreachable 2021-03-05 12:10:39.042 <TRACE> bgp1: Sending UPDATE 2021-03-05 12:10:39.042 <TRACE> bgp1.ipv4 < added 203.0.113.0/24 unreachable 2021-03-05 12:10:39.042 <INFO> Reconfigured 2021-03-05 12:10:39.042 <TRACE> bgp1: Sending UPDATE And our client receives 2 distinct UPDATE packets, the first being an explicit withdrawal, followed by an announcement; [BGPMessage UPDATE] - 27 Bytes |- MAC: 42:01:0a:f0:00:01 -> 42:01:0a:f0:01:3b |- IP: 10.240.0.226:48185 -> 10.240.1.59:179 |- Timestamp: 2021-03-05 12:10:39.43871 (1614946239.43871) | |- Update Message Sub-Type: WITHDRAWAL |- Withdrawn Routes Length: 4 Bytes |- Total Path Attribute Length: 0 Bytes |- Withdrawn Routes: |--- 203.0.113.0/24 [BGPMessage UPDATE] - 63 Bytes |- MAC: 42:01:0a:f0:00:01 -> 42:01:0a:f0:01:3b |- IP: 10.240.0.226:48185 -> 10.240.1.59:179 |- Timestamp: 2021-03-05 12:10:39.44893 (1614946239.44893) | |- Update Message Sub-Type: ANNOUNCE |- Withdrawn Routes Length: 0 Bytes |- Total Path Attribute Length: 36 Bytes |- Prefix (NLRI): |--- 203.0.113.0/24 |- Path Attributes: |--- ORIGIN: IGP |- Path Attributes: |--- AS_PATH: |- Path Attributes: |--- NEXT_HOP: 10.240.0.226 |- Path Attributes: |--- LOCAL_PREF: |- Path Attributes: |--- LARGE_COMMUNITIES: 65000:1:2 When this happens during a long converge, the clients can experience a significant gap between the withdrawal and announcement causing sub-optimal state on the clients; we have observed this to be more than 10min in edge cases. Under Bird 1.6.5 we see the same restart & route remove/add in the log however we see only 1 UPDATE emitted reflecting the attribute change e.g. 2021-03-05 12:34:40 <INFO> Reconfiguring 2021-03-05 12:34:40 <INFO> Reloading protocol static1 2021-03-05 12:34:40 <INFO> Restarting protocol static1 2021-03-05 12:34:40 <TRACE> bgp1: Reconfigured 2021-03-05 12:34:40 <INFO> Reconfigured 2021-03-05 12:34:40 <TRACE> bgp1 < removed 203.0.113.0/24 unreachable 2021-03-05 12:34:40 <TRACE> bgp1 < added 203.0.113.0/24 unreachable 2021-03-05 12:34:40 <TRACE> bgp1: Sending UPDATE $ cat bgp.pcap | pbgpp --filter-message-type=UPDATE - [BGPMessage UPDATE] - 63 Bytes |- MAC: 42:01:0a:f0:00:01 -> 42:01:0a:f0:01:3b |- IP: 10.240.0.226:52101 -> 10.240.1.59:179 |- Timestamp: 2021-03-05 12:34:41.414028 (1614947681.414028) | |- Update Message Sub-Type: ANNOUNCE |- Withdrawn Routes Length: 0 Bytes |- Total Path Attribute Length: 36 Bytes |- Prefix (NLRI): |--- 203.0.113.0/24 |- Path Attributes: |--- ORIGIN: IGP |- Path Attributes: |--- AS_PATH: |- Path Attributes: |--- NEXT_HOP: 10.240.0.226 |- Path Attributes: |--- LOCAL_PREF: |- Path Attributes: |--- LARGE_COMMUNITIES: 65000:1:2 - Damian

2 1

BGP keepalive packets delayed during reconfigure
by Damian Zaremba 05 Mar '21

05 Mar '21

Hi, I recently observed a case where bird 2.0.7 stopped emitting keepalive packets to configured neighbors during a protocol reconfigure. To replicate this condition I have constructed a single BGP session that is fed a large number of filtered routes, the configuration structure resembles; protocol static -> table source -> protocol pipe [import filters] -> table neighbor -> protocol bgp Changing a route attribute in the source table and calling `reconfigure` results in the following observations; 1. Bird logs on the sender side show a slow reconfigure; 2021-03-05 10:28:19.872 <TRACE> bgp1: Sending KEEPALIVE 2021-03-05 10:28:34.886 <TRACE> bgp1: Sending KEEPALIVE 2021-03-05 10:28:53.772 <TRACE> bgp1: Sending KEEPALIVE 2021-03-05 10:28:56.259 <INFO> Reconfiguring 2021-03-05 10:45:13.606 <TRACE> bgp1: Sending KEEPALIVE 2021-03-05 10:45:13.611 <WARN> I/O loop cycle took 966448 ms for 1016 events 2021-03-05 10:45:13.612 <INFO> Reconfigured 2021-03-05 10:45:13.612 <TRACE> bgp1: Got KEEPALIVE 2021-03-05 10:45:13.612 <TRACE> bgp1: Got KEEPALIVE 2021-03-05 10:45:13.612 <TRACE> bgp1: Got KEEPALIVE 2021-03-05 10:45:13.612 <RMT> bgp1: Received: Hold timer expired 2021-03-05 10:46:06.106 <TRACE> bgp1: Sending KEEPALIVE 2021-03-05 10:46:24.541 <TRACE> bgp1: Sending KEEPALIVE 2021-03-05 10:46:42.282 <TRACE> bgp1: Sending KEEPALIVE 2. Packet capture shows the client receiving no keepalives and then multiple close together; $ cat bgp.pcap | pbgpp --filter-message-type=KEEPALIVE --formatter=LINE - 1614940133.773725 KEEPALIVE None None None 1614940138.282074 KEEPALIVE None None None 1614940154.308565 KEEPALIVE None None None 1614940174.343514 KEEPALIVE None None None 1614940190.374193 KEEPALIVE None None None 1614941113.607580 KEEPALIVE None None None 1614941166.106192 KEEPALIVE None None None 1614941166.106316 KEEPALIVE None None None 1614941183.134392 KEEPALIVE None None None 1614941184.541810 KEEPALIVE None None None 1614941200.157543 KEEPALIVE None None None 1614941202.282814 KEEPALIVE None None None 1614941214.180433 KEEPALIVE None None None 1614941217.732128 KEEPALIVE None None None 1614941234.209164 KEEPALIVE None None None 1614941236.416377 KEEPALIVE None None None 1614941250.233110 KEEPALIVE None None None 1614941253.668823 KEEPALIVE None None None 1614941268.260864 KEEPALIVE None None None 1614941269.668392 KEEPALIVE None None None 1614941285.289222 KEEPALIVE None None None 1614941287.120920 KEEPALIVE None None None 1614941301.314094 KEEPALIVE None None None 1614941302.270840 KEEPALIVE None None None 1614941319.342323 KEEPALIVE None None None 1614941321.92028 KEEPALIVE None None None 1614941335.366858 KEEPALIVE None None None 1614941337.417243 KEEPALIVE None None None 1614941352.392059 KEEPALIVE None None None 1614941356.43815 KEEPALIVE None None None 1614941369.420711 KEEPALIVE None None None 1614941373.705122 KEEPALIVE None None None 1614941386.445406 KEEPALIVE None None None 1614941391.885447 KEEPALIVE None None None 1614941403.473187 KEEPALIVE None None None 1614941407.172799 KEEPALIVE None None None 1614941419.498776 KEEPALIVE None None None The 6th packet is 15min after the 5th packet then they spread back out to the intervals seen in the steady state. 3. Client trips off on timers until we get to a converged state on the sender; 2021-03-05 10:29:53 <RMT> bgp1: Error: Hold timer expired 2021-03-05 10:34:05 <RMT> bgp1: Error: Hold timer expired 2021-03-05 10:39:38 <RMT> bgp1: Error: Hold timer expired 2021-03-05 10:43:48 <RMT> bgp1: Error: Hold timer expired I suspect this is down to the scheduling of BGP packets more generally as we also observed the case where a route addition into a bgp protocol (as reported by trace) was not seen as an UPDATE by the client for multiple minutes during a reconfigure. - Damian

2 1

[PATCH] Add 'preferred' route attribute for selective add-path
by Trisha Biswas 04 Mar '21

04 Mar '21

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>

3 5