April 2021 - Bird-users - Mailing Lists

IPv6 BGP & kernel 4.19
by Robert Sander 25 Aug '21

25 Aug '21

Hi, our routers run on Debian stretch with bird 1.6.4 from bird.network.cz/debian. Yesterday I tried kernel 4.19 from backports.debian.org and ran into a weird issue with IPv6 BGP sessions: All Peerings reported "Error: Hold timer expired" ca. every 40 minutes. IPv6 forwarding was flapping all the time. After rebooting into kernel 4.9 everything worked again. IPv4 BGP was not affected and also OSPF (v4 and v6). I could disable all IPv6 BGP peerings on this router and then it forwarded to another router learned via OSPF for IPv6 without issues. Has anyone seen such a behaviour? Regards -- Robert Sander Heinlein Support GmbH Schwedter Str. 8/9b, 10119 Berlin https://www.heinlein-support.de Tel: 030 / 405051-43 Fax: 030 / 405051-19 Amtsgericht Berlin-Charlottenburg - HRB 93818 B Geschäftsführer: Peer Heinlein - Sitz: Berlin

13 39

[PATCH v4 0/8] Add MAC authentication support to the Babel protocol
by Toke Høiland-Jørgensen 11 Jun '21

11 Jun '21

This series adds MAC authentication support to the Babel protocol as specified in in RFC8967: https://www.rfc-editor.org/rfc/rfc8967 I have performed basic interoperability testing between this implementation and the current babeld HMAC implementation[1]. The two implementations were able to successfully exchange authenticated messages with both HMAC-256 and Blake2s-256 keys. Given the above, and the fact that the RFC was finally published at the the IETF, I believe this series is ready for merging (subject to review, of course). For those wanting to test the code, a version of Bird with this series applied is available on Github[2] for easy consumption. [1] https://github.com/jech/babeld/pull/52 [2] https://github.com/tohojo/bird/tree/babel-mac-04 Changelog: v4: - Update RFC references to the published RFC numbers (for both MAC and Babel itself). - Rework WALK_TLVS macro to not cast initial argument, and not use goto for framing errors. - Change MAC validation logic to just let algorithms specify min/max len and enforce full key size length even for the smaller-output variants of Blake2. v3: - Add variants with smaller digest sizes for blake2s and blake2b. - Rebase on current master v2: - Don't reinvent AC_CHECK_FUNCS() for configure - Make sure random_bytes() never fails (without taking the whole daemon with it) - Use existing endianness defines in blake2s code - Just leave MAC-related code in babel.c/packets.c instead of adding a new file - Add blake2s test vectors (new patch 3) - Support supplying mac keys as raw hexadecimal bytes and allow algorithms to validate keys on configure (new patches 4-5) v1: - Add wrapper function to bird sysdep code to pick a suitable source of random bytes - Import reference Blake2 implementations into lib/ - Rename function names and data structures to use an auth_ prefix instead of hmac_ - Perform a separate authentication pass before parsing the packet, and move the authentication-related code to its own source file - Enforce key length recommendation from the specification - Add a 'permissive' configuration mode where outgoing packets are signed but incoming packets are accepted even though they fail authentication - Add user documentation for the authentication configuration, and function docstrings to the main authentication functions - Fix a bunch of nits and code style issues --- Toke Høiland-Jørgensen (8): sysdep: Add wrapper to get random bytes nest: Add Blake2s and Blake2b hash functions mac_test: Add tests for blake2s and blake2b nest: Allow specifying security keys as hex bytes as well as strings config: Allow MAC algorithms to specify a function to validate their keys babel: Refactor TLV parsing code for easier reuse babel: Add MAC authentication support babel: Update RFC references to new standards track RFC8966 conf/cf-lex.l | 31 + conf/conf.h | 5 + conf/confbase.Y | 2 + doc/bird.sgml | 49 +- lib/Makefile | 2 +- lib/blake2-impl.h | 160 ++ lib/blake2-kat.h | 4111 +++++++++++++++++++++++++++++++++++++++++ lib/blake2-ref.h | 112 ++ lib/blake2.c | 48 + lib/blake2.h | 65 + lib/blake2b-ref.c | 270 +++ lib/blake2s-ref.c | 263 +++ lib/mac.c | 35 +- lib/mac.h | 11 + lib/mac_test.c | 91 + lib/string.h | 1 + lib/strtoul.c | 27 + nest/config.Y | 54 +- nest/password.c | 6 + nest/password.h | 1 + proto/babel/Makefile | 2 +- proto/babel/babel.c | 162 +- proto/babel/babel.h | 66 +- proto/babel/config.Y | 42 +- proto/babel/packets.c | 667 ++++++- 25 files changed, 6164 insertions(+), 119 deletions(-) create mode 100644 lib/blake2-impl.h create mode 100644 lib/blake2-kat.h create mode 100644 lib/blake2-ref.h create mode 100644 lib/blake2.c create mode 100644 lib/blake2.h create mode 100644 lib/blake2b-ref.c create mode 100644 lib/blake2s-ref.c

2 15

Exact Definition of numbers-match bitmask-match and fragmentation-type
by Matt Corallo 18 May '21

18 May '21

The match classifiers for flowspec (numbers-match bitmask-match and fragmentation-type) don't appear to be exactly specified in the documentation anywhere. eg 1) Based on the grouping in the examples, I'd think && and || are parsed first, followed by , and .. ie 1 && 2,3 means 1 AND (two OR three) not (1 AND 2) or 3. Same would apply for fragmentation-type, which makes the spacing in the flow4 example somewhat confusing, though obviously it doesn't change the logic given its all ORs. 2) What are the full list of possible operators? From the examples there is at least <, <=, >, >=, &&, ||, ",", .., and !. 3) I can make a pretty good guess as to what each operator means, but it doesn't seem to be written down anywhere. Separately, the documentation seems to indicate dscp applies for both IPv4 flowspec as well as IPv6 flowspec as-is, however this is somewhat confusing - is DSCP intended to match on v4 ECN bits as well, or is the expected length of DSCP simply 8 bits instead for v6 and matched against the traffic class? Finally, and I suppose this is an RFC question not a BIRD question, how does the fragment field interact with the next header field in v6 - I assume a router is expected to parse a fragment header before checking next header, irrespective of the fragment bits (unless they require all bits unset)? Thanks, Matt

4 19

BIRD 2.0.8 packaging update
by Jakub Ružička 10 May '21

10 May '21

Hello BIRD Community! Latest bird-2.0.8 is available from most current downstream distro repos including: * Arch * EPEL/CentOS * Fedora * Gentoo * Manjaro * NixOS * OpenBSD You can use repology to get an overview: https://repology.org/project/bird/versions # Debian Debian is currently in Hard Freeze before 11/Bullseye release and thus updating bird2 package to 2.0.8 is problematic (it lacks autopkgtests): https://release.debian.org/bullseye/freeze_policy.html#hard Current Maintainer of Debian bird2 package Ondřej Surý has agreed to pass the maintenance to me but I don't have access yet. Once I gain it I'll release bird2-2.0.8 in experimental and eventually keep debian/master up-to-date after the freeze ends. The Community is also working on providing Debian backports for Debian stable. Until proper downstream packages are ready, I've prepared upstream packages for Debian 9, 10 and 11 in new bird-latest OBS repos: https://download.opensuse.org/repositories/home:/CZ-NIC:/bird-latest/ However, OBS "Download Package" link is currently missing instructions for Debian for some reason: https://software.opensuse.org//download.html?project=home%3ACZ-NIC%3Abird-l… It's either a bug in OBS or a slow propagation of new repo. I'm trying to resolve this on #opensuse-buildservice but for now you're left to your Debian-fu in enabling these repos. # Ubuntu I've updated BIRD launchpad PPA with upstream bird2-2.0.8 packages for all current Ubuntu releases: https://launchpad.net/~cz.nic-labs/+archive/ubuntu/bird I've tested all of these packages lightly on respective Ubuntu VMs. They installed successfully and bird service started. Ubuntu uses Debian bird packages so once they're updated in Debian, Ubuntu downstream should pick them up. # openSUSE bird-2.0.8 is available from openSUSE Tumbleweed. I've prepared new bird-latest OBS to cover remaining SUSE platforms: https://build.opensuse.org/package/show/home:CZ-NIC:bird-latest/bird Please use "Download Package" link (top right) to enable: https://software.opensuse.org//download.html?project=home%3ACZ-NIC%3Abird-l… # upstream packaging All the upstream packages were created from official 2.0.8 archive using modified downstream sources from Debian and Fedora. Please note that I had to disable -docs subpackages to get working builds on older systems as well as other tweaks like relaxing deps. I've prepared an upstream MR adding packaging in apkg format directly to upstream repo: https://gitlab.nic.cz/labs/bird/-/merge_requests/25 In short it allows building upstream packages directly from upstream sources or from upstream archives(tarballs) or combination of both, see more info in the MR. More work is required for building from sources, but I was able to use apkg to create packages for different .deb/.rpm distros from official upstream archives. Best Regards, Jakub Ružička CZ.NIC packager 📦

2 4

[PATCH] babel: Log the reason when refusing to run on an interface
by Toke Høiland-Jørgensen 10 May '21

10 May '21

The babel protocol code checks various properties of an interface before starting it: whether the interface is up, whether it supports multicast, and whether it has a link-local address assigned. However, it doesn't give any feedback if any of those checks fail, it just silently ignores the interface. Fix this by explicitly logging errors when any of the checks fail; to avoid spamming the logs for all interfaces on the system, move the checks so they are only performed after it was determined that an interface is actually configured by an interface pattern. Reported-by: Stefan Haller <stefan.haller(a)stha.de> Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- proto/babel/babel.c | 50 ++++++++++++++++++++++++--------------------- 1 file changed, 27 insertions(+), 23 deletions(-) diff --git a/proto/babel/babel.c b/proto/babel/babel.c index 4b6b9d7f9f6f..6ac3bb6a7fec 100644 --- a/proto/babel/babel.c +++ b/proto/babel/babel.c @@ -1639,6 +1639,29 @@ babel_remove_iface(struct babel_proto *p, struct babel_iface *ifa) rfree(ifa->pool); /* contains ifa itself, locks, socket, etc */ } +static int iface_is_valid(struct babel_proto *p, struct iface *iface) +{ + if (!(iface->flags & IF_UP)) { + log(L_ERR "%s: Interface '%s' is down", p->p.name, iface->name); + return 0; + } + + if (!(iface->flags & IF_MULTICAST)) { + log(L_ERR "%s: Interface '%s' does not support multicast", + p->p.name, iface->name); + return 0; + } + + /* We need a link-local address to communicate */ + if (!iface->llv6) { + log(L_ERR "%s: Interface '%s' has no link-local address assigned", + p->p.name, iface->name); + return 0; + } + + return 1; +} + static void babel_if_notify(struct proto *P, unsigned flags, struct iface *iface) { @@ -1655,19 +1678,8 @@ babel_if_notify(struct proto *P, unsigned flags, struct iface *iface) if (ifa) babel_remove_iface(p, ifa); - if (!(iface->flags & IF_UP)) - return; - - /* We only speak multicast */ - if (!(iface->flags & IF_MULTICAST)) - return; - - /* Ignore ifaces without link-local address */ - if (!iface->llv6) - return; - struct babel_iface_config *ic = (void *) iface_patt_find(&cf->iface_list, iface, NULL); - if (ic) + if (ic && iface_is_valid(p, iface)) babel_add_iface(p, iface, ic); return; @@ -1733,20 +1745,12 @@ babel_reconfigure_ifaces(struct babel_proto *p, struct babel_config *cf) WALK_LIST(iface, iface_list) { - if (!(iface->flags & IF_UP)) - continue; - - /* Ignore non-multicast ifaces */ - if (!(iface->flags & IF_MULTICAST)) - continue; - - /* Ignore ifaces without link-local address */ - if (!iface->llv6) - continue; - struct babel_iface *ifa = babel_find_iface(p, iface); struct babel_iface_config *ic = (void *) iface_patt_find(&cf->iface_list, iface, NULL); + if (ic && !iface_is_valid(p, iface)) + continue; + if (ifa && ic) { if (babel_reconfigure_iface(p, ifa, ic)) -- 2.31.1

2 1

[PATCH] sysdep/bsd: propagate OS-level IFF_MULTICAST to internal IF_MULTICAST flag
by Toke Høiland-Jørgensen 10 May '21

10 May '21

The BSD code did not propagate the OS-level IFF_MULTICAST flag to the Bird-internal IF_MULTICAST flag, which causes problems with Wireguard interfaces on FreeBSD. The Linux sysdep code does propagate the flag already, so just copy over the same check and flag update. Tested-by: Stefan Haller <stefan.haller(a)stha.de> Signed-off-by: Toke Høiland-Jørgensen <toke(a)toke.dk> --- sysdep/bsd/krt-sock.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sysdep/bsd/krt-sock.c b/sysdep/bsd/krt-sock.c index c2faa23dd44f..cd89544063c7 100644 --- a/sysdep/bsd/krt-sock.c +++ b/sysdep/bsd/krt-sock.c @@ -665,6 +665,9 @@ krt_read_ifinfo(struct ks_msg *msg, int scan) else f.flags |= IF_MULTIACCESS; /* NBMA */ + if (fl & IFF_MULTICAST) + f.flags |= IF_MULTICAST; + iface = if_update(&f); if (!scan) -- 2.31.1

2 1

Missing bable routes after configure - bug in bird 2.0.8?
by Nico Schottelius 30 Apr '21

30 Apr '21

Hello, we are using direct + babel as an IGP and today something "funky" happened: the routes of one router disappeared and on other routers the babel entries contained empty router IDs in babel: bird> show babel entries babel1: Prefix Router ID Metric Seqno Routes Sources 185.203.114.0/23 00:00:00:00:93:4e:c3:fb 0 2204 4 0 195.141.230.102/31 <none> - - 1 0 185.203.112.0/24 <none> - - 2 0 147.78.195.224/27 00:00:00:00:93:4e:c3:fb 0 2204 7 0 193.192.225.72/31 <none> - - 1 0 94.78.2.168/29 00:00:00:00:93:4e:c3:fb 0 2204 4 0 147.78.195.0/29 <none> - - 1 0 185.155.31.0/24 00:00:00:00:93:4e:c3:fb 0 2204 4 0 45.134.132.0/29 00:00:00:00:93:4e:c3:fb 0 2204 4 0 185.155.31.0/26 00:00:00:00:93:4e:c3:fb 0 2204 4 0 2a0a:e5c0:1:f::/64 <none> - - 1 0 2a0a:e5c0:1:e::/64 <none> - - 1 0 2a0a:e5c0:1:d::/64 00:00:00:00:93:4e:c3:fb 0 2204 5 0 2a0a:e5c0:0:9::/64 00:00:00:00:00:00:00:2f 96 1 1 0 2a0a:e5c0:1:8::/64 00:00:00:00:93:4e:c3:fb 0 2204 10 0 2a0a:e5c0:0:6::/64 00:00:00:00:00:00:00:2e 96 2 1 0 2a0a:e5c0:0:5::/64 <none> - - 2 0 2a0a:e5c0:0:4::/64 00:00:00:00:00:00:00:2f 96 1 1 0 2a0a:e5c0:1:4::/64 00:00:00:00:93:4e:c3:fb 0 2204 5 0 2a0a:e5c0:0:3::/64 00:00:00:00:00:00:00:2e 96 2 1 0 2a0a:e5c0:0:2::/64 <none> - - 2 0 2a0a:e5c0:2:2::/64 00:00:00:00:93:4e:c3:fb 0 2204 5 0 2a0a:e5c0:10:1::/64 <none> - - 1 0 After restarting the router, the entries are correct now (router id 00:00:00:00:93:4e:c3:e3): bird> show babel entries babel1: Prefix Router ID Metric Seqno Routes Sources 185.203.114.0/23 00:00:00:00:93:4e:c3:fb 0 2204 4 0 195.141.230.102/31 <none> - - 1 0 185.203.112.0/24 <none> - - 2 0 147.78.195.224/27 00:00:00:00:93:4e:c3:fb 0 2204 7 0 193.192.225.72/31 <none> - - 1 0 94.78.2.168/29 00:00:00:00:93:4e:c3:fb 0 2204 4 0 147.78.195.0/29 00:00:00:00:93:4e:c3:e3 96 1 1 0 185.155.31.0/24 00:00:00:00:93:4e:c3:fb 0 2204 4 0 45.134.132.0/29 00:00:00:00:93:4e:c3:fb 0 2204 4 0 185.155.31.0/26 00:00:00:00:93:4e:c3:fb 0 2204 4 0 2a0a:e5c0:1:f::/64 00:00:00:00:93:4e:c3:e3 96 1 1 0 2a0a:e5c0:1:e::/64 00:00:00:00:93:4e:c3:e3 96 1 1 0 2a0a:e5c0:1:d::/64 00:00:00:00:93:4e:c3:fb 0 2204 5 0 2a0a:e5c0:0:9::/64 00:00:00:00:00:00:00:2f 96 1 1 0 2a0a:e5c0:1:8::/64 00:00:00:00:93:4e:c3:fb 0 2204 10 0 2a0a:e5c0:0:6::/64 00:00:00:00:00:00:00:2e 96 2 1 0 2a0a:e5c0:0:5::/64 <none> - - 2 0 The "funny" part is that bird 2.0.8 on that router was up and running, it did see babel neighbors, it did BGP, however only after restarting bird, the routes were correctly received be neighboring routers. As you can see in above table there is at least another router that is affected. I tried `disable babel1` and `enable babel1` on it, however that did not fix the problem. We did some amount of `configure` commands on the bird process, but my understanding was that it should be very similar to restarting it, without the loss of sessions. The babel protocol *did* previously export the routes correctly to other routers, but I am 99% sure that it did stop doing it, until we hard restarted bird. The babel configuration we use on most of our routers looks like this: protocol direct { ipv4; ipv6; interface "bond0.*"; } protocol babel { interface "bond0.*" { type wired; }; ipv4 { export where (source = RTS_DEVICE); }; ipv6 { export where (source = RTS_DEVICE); }; } So we are not re-babling like babeld, but only inject local device routes, as we have 2 redundant routers per network. Is there a conceptual problem or is this a bug in bird 2.0.8 and in either way, is there anything we can do to fix it besides restarting bird on router propagation error? Best regards, Nico p.s.: In case it matters, we are running bird on alpine/musl. -- Sustainable and modern Infrastructures by ungleich.ch

2 3

I admit I am rookie to IP routing. Looking for a little bet of simple help configuring BIRD for simple routing.
by Myron 29 Apr '21

29 Apr '21

I am trying to learn how to set-up a router and maintain a configuration and I'm hoping someone can help me. I'm that sort of person who learns by example. The configuration is a bit nn standard and will be only used on a local area network. Essentially, how would I configure BIRD to route everything except DHCP traffic between networks 192.168.0.0/16, 192.168.30.0/16, 192.168.31.0/16 and packets for any other network get sent to 192.168.0.1? So, as an example, a device on 192.168.31.4 can talk to 192.168.0.33? All using a subnet mask of 255.255.255.0. I will try and read through the user guide, but at this moment I'm not sure what I need to do to get it to work.

3 3

Configure igmp/pim using BIRD
by Dhruv Bhagadia 26 Apr '21

26 Apr '21

Hi all, Thanks Ondrej for giving insights to my previous query. Your guess as to the neighbor AS having low hold time was correct and when I reduced keep-alive time on my end, I could bypass the Hold timer expired issue. I write this mail to address another query of mine. Is it possible to configure multicast routing protocols like igmp/pim through BIRD. I saw on the future work page that support for multicasting protocol is yet to be added to BIRD, also couldn't find the protocol implementation in the source code still wanted to confirm. If the support is not added can I make use of some other already supported routing protocol to address the issue? I want the server on which BIRD is configured to listen to mcast data. Also, on researching I could find out this thesis <https://is.cuni.cz/webapps/zzp/download/130183774> Do we plan to in-coporate these changes into BIRD anytime soon? Thanking you, Dhruv Bhagadia.

1 0

Not able to configure bgp with BIRD
by Dhruv Bhagadia 23 Apr '21

23 Apr '21

Hi all, I was trying to configure bgp using BIRD on a server running rhel 7.6. The issue I am facing is that the neighbor AS seems to be rejecting the routes sent by my local AS. However, my server seems to be learning routes sent by the neighbor AS router. Have provided some details from the logs below. I wanted to ask what could be the probable reason that the remote is rejecting the packets? 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.1.192/28 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.1.192/28 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.1.200/30 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.1.200/30 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.1.200/29 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.1.200/29 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.1.201/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.1.201/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.42.0/24 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.42.0/24 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.43.0/24 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.43.0/24 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.44.0/24 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.44.0/24 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.48.0/24 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.48.0/24 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.42.101/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.42.101/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.42.102/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.42.102/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.42.103/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.42.103/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.42.104/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.42.104/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.42.105/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 < rejected by protocol 172.19.42.105/32 via 10.33.5.33 on enp26s0d1 2021-04-22 17:48:56 <TRACE> bgp1 > added [best] 172.19.43.101/32 via 10.33.5.33 on enp26s0d1 In consequence to this, BIRD throws an error after sometime saying `*bgp1: Error: Hold timer expired *` and `bgp1: Received: Hold timer expired` However from the logs I figured out that the difference between most latest KEEPALIVE message and the error being thrown is 2 secs. Since I have set HOLD time to 180 sec in config shouldn't this error be never thrown since the KEEPALIVE message will reset it? Sharing that logs too below 2021-04-22 20:12:44 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:45 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:46 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:47 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:48 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:49 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:50 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:51 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:53 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:53 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:55 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:56 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:57 <TRACE> bgp1: Got KEEPALIVE 2021-04-22 20:12:59 <RMT> bgp1: Error: Hold timer expired I am new to configuring routing and hence my understanding can be wrong somewhere. Please feel free to correct me and ask for more details if required. Thanks in advance. Thanking you, Dhruv Bhagadia.

2 2