- Bird-users - Mailing Lists

CentOS to Debian migration issue
by Pavlo Astakhov 22 Mar '21

22 Mar '21

Hello, all I got a weird question. We recently migrated two our routers from CentOS 7 to Debian 10, installed Bird, placed config files back - and since then we are observing BGP flaps. Moreover, flaps are observed on IPv6 peers only: Name Proto Table State Since Info device1 Device --- up 2021-03-18 15:42:27 direct1 Direct --- up 2021-03-18 15:42:27 kernel1 Kernel master4 up 2021-03-18 15:42:27 kernel2 Kernel master6 up 2021-03-18 15:42:27 static1 Static master4 up 2021-03-18 15:42:27 static2 Static master6 up 2021-03-18 15:42:27 UPLINK BGP --- up 2021-03-18 15:42:31 Established UPLINKv6 BGP --- up 2021-03-22 21:11:12 Established AR1 BGP --- up 2021-03-18 15:42:31 Established AR1v6 BGP --- up 2021-03-19 23:42:55 Established AR2 BGP --- up 2021-03-18 15:42:28 Established AR2v6 BGP --- up 2021-03-20 15:37:38 Established BR2 BGP --- up 2021-03-18 15:42:28 Established BR2v6 BGP --- up 2021-03-21 11:03:33 Established ospf4 OSPF master4 up 2021-03-18 15:42:27 Running ospf6 OSPF master6 up 2021-03-18 15:42:27 Running Flaps are unregular, currently we saw no coincedences with anything. The network is stable, our and peers configs were not changed, Bird version too (2.0.7 on both CentOS and Debian). The only message about this in logs is hold-related: 2021-03-22 21:01:10 <WARN> Kernel dropped some netlink messages, will resync on next scan. 2021-03-22 21:04:33 <WARN> Kernel dropped some netlink messages, will resync on next scan. 2021-03-22 21:06:10 <WARN> Kernel dropped some netlink messages, will resync on next scan. 2021-03-22 21:10:12 <RMT> UPLINKv6: Error: Hold timer expired 2021-03-22 21:10:13 <WARN> Kernel dropped some netlink messages, will resync on next scan. 2021-03-22 21:10:15 <WARN> Kernel dropped some netlink messages, will resync on next scan. 2021-03-22 21:10:16 <WARN> Kernel dropped some netlink messages, will resync on next scan. 2021-03-22 21:10:16 <WARN> Kernel dropped some netlink messages, will resync on next scan. Could you please suggest some way to go except of returning to CentOS? Thank you in advance. _--

3 3

Bird Centos 8 Replacement recommendations request
by W Templeton 18 Mar '21

18 Mar '21

Hiya Guys, Apologies if not the right approach/ protocol, do let me know what is if required. Asks: Pls provide.... 1.Details of what OS and version supported by Bird 2.Any OS preferences or best choice of useful. 3.Any views thoughts on below useful Our draft shortlist is Debian 10.7 Buster Ubuntu 20.04 LTS Leap 15.3 Note did not consider any of the BSD variants, which is an oversight so should be included Background We were close to productionising a network stack around number of sites using Bird2.07 as the Routing daemon on Centos 8. In light of the Centos changes are now looking for a replacement and would like to confirm what is supported by Bird as this is a mandatory prerequisite. Happy for call etc if easier. Thks in advance FYI -I did look at wiki FAQs and was semi generic and possibly not up to date Thks Will +44(0)7967 464459

6 9

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