- frog - lists.frrouting.org

BGP type 32 length 672 is too large
by Willy Manga 03 Jul '22

03 Jul '22

Hello, Can someone please tell me what "BGP type 32 length 672 is too large" stand for? I got this message from some bgp peers running ZTE ZXR10 . From my side I have FRRouting 8.2.2 on debian 11. Here is what I got in the logs Jul 03 10:51:40 bdr3 bgpd[3555975]: [HTHRX-GQYGJ][EC 33554454] bgp_process_packet: BGP UPDATE receipt failed for peer: 2001:43fd:xx:: Jul 03 10:51:44 bdr3 bgpd[3555975]: [PGS8W-47EHJ][EC 33554485] 2001:43fd:xx::: BGP type 32 length 672 is too large, attribute total length is 243. attr_endp is 0x7f746c0ee66c. endp is 0x7f746c0ee49a Any idea on what is happening? -- Willy Manga @ongolaboy https://ongola.blogspot.com/

3 2

Question: BGP Implicit Withdraw counter
by Alejandro Acosta 23 May '22

23 May '22

Hello there, good morning/afternoon/evening, This is my first message to the list :-) I'm trying to find out how to see the counters of BGP Implicit/Explicit withdraws. Is it possible? I was using FRR 7, I upgraded to FRR 8 (last night) and nothing yet :-(. I have tried several: show bgp ipv6 <many_different_commands> and nothing yet. Of course I tried show bgp ipv6 nei <ipv6_address>, statistics and more. Nothing yet about implicit/explicit withdraws. The output (or similar) I'm looking for is something like: Sent Rcvd Prefix activity: ---- ---- Prefixes Current: 2 4 Prefixes Total: 0 0 Implicit Withdraw: 1 0 Explicit Withdraw: 1 0 Thanks, Alejandro,

3 3

NHRP from FRR, cannot make it work!
by Vahid Gharaee 06 Apr '22

06 Apr '22

Hello everyone, would someone please help me with this: I want to use nhrpd from FRR, to connect to a Cisco network. I have an IPv4 network and want to use IPv6 with gre tunnels over IPv4. the structure is as below: **Spoke1** ----- **Switch** ------**Spoke2** (gentoo PC with Frr running) | **HUB** *Spoke1* : Cisco router configured with GRE and NHRP *HUB*: Cisco router: IP: 10.179.240.169 IPV6: 2a02:d20:e8:503::1 *Spoke2* : FRR with below config: interface gre1 description DSL-Payload-v6 ipv6 address 2a02:d20:e8:503::c/128 ipv6 nhrp holdtime 60 ipv6 nhrp map 2a02:d20:e8:503::1 10.179.240.169 ipv6 nhrp map multicast 10.179.240.169 ipv6 nhrp network-id 99 ipv6 nhrp nhs 2a02:d20:e8:503::1 nbma 10.179.240.169 ipv6 nhrp registration no-unique ipv6 nhrp shortcut no link-detect tunnel source enp3s0 exit also the interfaces on OS: enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.201.202 netmask 255.255.252.0 broadcast 192.168.203.255 inet6 fe80::e8f6:102d:1d27:d0ce prefixlen 64 scopeid 0x20<link> ether 40:8d:5c:dd:09:cb txqueuelen 1000 (Ethernet) RX packets 31262 bytes 23696880 (22.5 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 22327 bytes 3724978 (3.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 the tunnel: gre1: flags=81<UP,POINTOPOINT,RUNNING> mtu 1472 inet6 2a02:d20:e8:503::c prefixlen 128 scopeid 0x0<global> unspec 64-40-3C-67-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 1000 (UNSPEC) RX packets 2949 bytes 566208 (552.9 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2949 bytes 377472 (368.6 KiB) TX errors 62 dropped 0 overruns 0 carrier 62 collisions 0 gre1: gre/ip remote 10.179.240.169 local 100.64.60.103 ttl 64 key 503 logs: 2022/04/05 11:14:09 NHRP: [KHACV-6YE92] Send Registration-Request(3) 2a02:d20:e8:503::c -> 2a02:d20:e8:503::1 2022/04/05 11:14:09 NHRP: [WSA6E-5GM0H] PACKET: Send 100.64.60.103 -> 10.179.240.169 Wireshark says: Linux cooked capture v1 Next Hop Resolution Protocol (NHRP Registration Reply) 0000 00 01 86 dd 00 00 00 00 00 ff 00 c0 b0 3f 00 6c 0010 01 04 04 00 10 10 80 02 00 00 00 01 64 40 3c 67 0020 2a 02 0d 20 00 e8 05 03 00 00 00 00 00 00 00 0c 0030 2a 02 0d 20 00 e8 05 03 00 00 00 00 00 00 00 01 0040 00 00 00 00 00 00 00 3c 00 00 00 00 00 00 00 00 0050 26 f4 00 3c 00 00 10 00 fe 80 00 00 00 00 00 00 0060 be e7 12 ff fe 41 53 80 0a b3 f0 a9 80 04 00 00 0070 80 05 00 00 80 03 00 20 00 00 00 00 26 f4 00 3c 0080 04 00 10 ff 0a b3 f0 a9 2a 02 0d 20 00 e8 05 03 0090 00 00 00 00 00 00 00 01 00 09 00 20 00 80 00 00 00a0 00 00 00 00 04 00 10 00 0a b3 f0 a9 2a 02 0d 20 00b0 00 e8 05 03 00 00 00 00 00 00 00 01 80 00 00 00 on the HUB we can see both request and reply. and IPv4 networks also works. *The Problem:* the spoke1 can ping HUB through the tunnel, but on the Frr we cannot! is this structure correct? should it work or we need different configuration? *Some more info*: I looked into the code and it fails in function: os_recvmsg(uint8_t *buf, size_t *len, int *ifindex, uint8_t *addr, size_t *addrlen) the addrlen should be 4 and it is 0 instead!! the value of sockaddr_ll : lladdr.sll_addr[] -> all zero ------------> this leads to addrlen be 0 later lladdr.sll_family -> 0x11 lladdr.sll_protocol -> 0x120 lladdr.sll_ifindex -> 0x1a lladdr.sll_hatype -> 0x30a lladdr.sll_pkttype -> 0 lladdr.sll_halen -> 0 *addrlen -> 40

1 0

Re: frog Digest, Vol 61, Issue 2
by xiaoyu.net 03 Apr '22

03 Apr '22

Reported here: https://github.com/FRRouting/frr/issues/10826 [https://github.com/FRRouting/frr/issues/10826] From: frog-request(a)lists.frrouting.org To: frog(a)lists.frrouting.org Date: Sun, 03 Apr 2022 12:00:02 +0000 Subject: frog Digest, Vol 61, Issue 2 Send frog mailing list submissions to frog(a)lists.frrouting.org [mailto:frog%40lists.frrouting.org] To subscribe or unsubscribe via the World Wide Web, visit https://lists.frrouting.org/listinfo/frog [https://lists.frrouting.org/listinfo/frog] or, via email, send a message with subject or body 'help' to frog-request(a)lists.frrouting.org [mailto:frog-request%40lists.frrouting.org] You can reach the person managing the list at frog-owner(a)lists.frrouting.org [mailto:frog-owner%40lists.frrouting.org] When replying, please edit your Subject line so it is more specific than "Re: Contents of frog digest..." Today's Topics: 1. BGPD hanging in FRR 8.2.2 (Philip Smith) ---------------------------------------------------------------------- Message: 1 Date: Sat, 2 Apr 2022 20:47:42 +0100 From: Philip Smith <philip(a)nsrc.org [mailto:philip%40nsrc.org]> To:frog@lists.frrouting.org [mailto:frog%40lists.frrouting.org] Subject: [FROG] BGPD hanging in FRR 8.2.2 Message-ID: <54869a9a-07db-2033-cc16-c0b8a6612060(a)nsrc.org [mailto:54869a9a-07db-2033-cc16-c0b8a6612060%40nsrc.org]> Content-Type: text/plain; charset=UTF-8; format=flowed Hi everyone, Just following up on my previous note about BGPD hanging in FRR 8.2.2. I now have more info to share. As background, I've got around 60 BGP feeds total in 30 different "views", to form a route collector for analysis work I'm doing of the global R&E routing table. This hang seems to have a period of 5-7 days. Using FRR 8.2.2 on Ubuntu 20.04. Not had any issue with FRR 8.1.0; this only started with FRR 8.2.2. The latest hang earlier today allowed a colleague to grab debug info which I hope will help. /var/log/frr/frr.log shows entries like this: Apr 2 11:46:42 frr watchfrr[52904]: [T58XM-TP956][EC 268435457] bgpd state -> unresponsive : no response yet to ping sent 90 seconds ago Apr 2 11:46:42 frr watchfrr[52904]: [YFT0P-5Q5YX] Forked background command [pid 1674696]: /usr/lib/frr/watchfrr.sh restart bgpd Apr 2 11:47:02 frr watchfrr[52904]: [ZE9RA-19PS5] restart bgpd child process 1674696 still running after 20 seconds, sending signal 15 Apr 2 11:47:02 frr watchfrr[52904]: [SK7QP-A2GT9] restart bgpd process 1674696 terminated due to signal 15 <snip> Apr 2 14:18:03 frr watchfrr[52904]: [YFT0P-5Q5YX] Forked background command [pid 1697956]: /usr/lib/frr/watchfrr.sh restart bgpd Apr 2 14:18:23 frr watchfrr[52904]: [ZE9RA-19PS5] restart bgpd child process 1697956 still running after 20 seconds, sending signal 15 Apr 2 14:18:23 frr watchfrr[52904]: [SK7QP-A2GT9] restart bgpd process 1697956 terminated due to signal 15 which just repeat every 10 minutes or so. A few hours earlier I was getting: Apr 1 22:53:19 frr bgpd[52925]: [YZRX4-ZXG0C][EC 100663315] Thread Starvation: {(thread *)0x5566a35c01a0 arg=0x556682b31da0 timer r=-5.940 bgp_announce_route_timer_expired() &paf->t_announce_route from bgpd/bgp_route.c:4763} was scheduled to pop greater than 4s ago Apr 1 23:24:34 frr bgpd[52925]: [YZRX4-ZXG0C][EC 100663315] Thread Starvation: {(thread *)0x5567954b16c0 arg=0x556682f14870 timer r=-5.224 bgp_announce_route_timer_expired() &paf->t_announce_route from bgpd/bgp_route.c:4763} was scheduled to pop greater than 4s ago Trying to connect by vtysh prints message of day, but never a command prompt. Same if trying to connect via telnet. The only way out is a kill -9 of the BGPD process, followed by a "systemctl restart frr". The process stack for bgpd shows: root@frr:~# cat /proc/52925/stack [<0>] futex_wait_queue_me+0xbb/0x120 [<0>] futex_wait+0x105/0x290 [<0>] do_futex+0x157/0x4d0 [<0>] __x64_sys_futex+0x13f/0x170 [<0>] do_syscall_64+0x57/0x190 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Thread debugging shows: [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". __pthread_clockjoin_ex (threadid=139670697043712, thread_return=0x0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145 145 pthread_join_common.c: No such file or directory. (gdb) bt #0 __pthread_clockjoin_ex (threadid=139670697043712, thread_return=0x0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145 #1 0x00007f07b1f3d985 in ?? () from /lib/x86_64-linux-gnu/librtr.so.0 #2 0x00007f07b1f38dc1 in rtr_mgr_stop () from /lib/x86_64-linux-gnu/librtr.so.0 #3 0x00007f07b1f53ef0 in ?? () from /usr/lib/x86_64-linux-gnu/frr/modules/bgpd_rpki.so #4 0x00007f07b1f53f7d in ?? () from /usr/lib/x86_64-linux-gnu/frr/modules/bgpd_rpki.so #5 0x00007f07b1f543ca in ?? () from /usr/lib/x86_64-linux-gnu/frr/modules/bgpd_rpki.so #6 0x00007f07b2586621 in thread_call () from /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0 #7 0x00007f07b2540198 in frr_run () from /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0 #8 0x00005566800b6678 in main () I've got about 2.5Mbytes of strace which I'll happily unicast to whoever would like to have a look at it. It looks very repetitive/boring to my non-developer eye, like something's got stuck waiting for something else. BTW, this is what's running (after I killed and restarted), including command line options: 1707406 ? S<s 0:02 /usr/lib/frr/watchfrr -d -F traditional zebra bgpd staticd 1707423 ? S<sl 0:01 /usr/lib/frr/zebra -d -F traditional -A 127.0.0.1 -s 90000000 1707428 ? S<sl 17:03 /usr/lib/frr/bgpd -d -F traditional -Z -M rpki 1707435 ? S<s 0:00 /usr/lib/frr/staticd -d -F traditional -A 127.0.0.1 Any ideas? I'd hate to revert to 8.1 but... philip -- ------------------------------ Subject: Digest Footer _______________________________________________ frog mailing list frog(a)lists.frrouting.org [mailto:frog%40lists.frrouting.org] https://lists.frrouting.org/listinfo/frog [https://lists.frrouting.org/listinfo/frog] ------------------------------ End of frog Digest, Vol 61, Issue 2 *********************************** ***************************************************** Best Service and Trustworthy From Us Our Mail Server Support IPv6 & IPv4 Mail ======================================================

1 0

BGPD hanging in FRR 8.2.2
by Philip Smith 02 Apr '22

02 Apr '22

Hi everyone, Just following up on my previous note about BGPD hanging in FRR 8.2.2. I now have more info to share. As background, I've got around 60 BGP feeds total in 30 different "views", to form a route collector for analysis work I'm doing of the global R&E routing table. This hang seems to have a period of 5-7 days. Using FRR 8.2.2 on Ubuntu 20.04. Not had any issue with FRR 8.1.0; this only started with FRR 8.2.2. The latest hang earlier today allowed a colleague to grab debug info which I hope will help. /var/log/frr/frr.log shows entries like this: Apr 2 11:46:42 frr watchfrr[52904]: [T58XM-TP956][EC 268435457] bgpd state -> unresponsive : no response yet to ping sent 90 seconds ago Apr 2 11:46:42 frr watchfrr[52904]: [YFT0P-5Q5YX] Forked background command [pid 1674696]: /usr/lib/frr/watchfrr.sh restart bgpd Apr 2 11:47:02 frr watchfrr[52904]: [ZE9RA-19PS5] restart bgpd child process 1674696 still running after 20 seconds, sending signal 15 Apr 2 11:47:02 frr watchfrr[52904]: [SK7QP-A2GT9] restart bgpd process 1674696 terminated due to signal 15 <snip> Apr 2 14:18:03 frr watchfrr[52904]: [YFT0P-5Q5YX] Forked background command [pid 1697956]: /usr/lib/frr/watchfrr.sh restart bgpd Apr 2 14:18:23 frr watchfrr[52904]: [ZE9RA-19PS5] restart bgpd child process 1697956 still running after 20 seconds, sending signal 15 Apr 2 14:18:23 frr watchfrr[52904]: [SK7QP-A2GT9] restart bgpd process 1697956 terminated due to signal 15 which just repeat every 10 minutes or so. A few hours earlier I was getting: Apr 1 22:53:19 frr bgpd[52925]: [YZRX4-ZXG0C][EC 100663315] Thread Starvation: {(thread *)0x5566a35c01a0 arg=0x556682b31da0 timer r=-5.940 bgp_announce_route_timer_expired() &paf->t_announce_route from bgpd/bgp_route.c:4763} was scheduled to pop greater than 4s ago Apr 1 23:24:34 frr bgpd[52925]: [YZRX4-ZXG0C][EC 100663315] Thread Starvation: {(thread *)0x5567954b16c0 arg=0x556682f14870 timer r=-5.224 bgp_announce_route_timer_expired() &paf->t_announce_route from bgpd/bgp_route.c:4763} was scheduled to pop greater than 4s ago Trying to connect by vtysh prints message of day, but never a command prompt. Same if trying to connect via telnet. The only way out is a kill -9 of the BGPD process, followed by a "systemctl restart frr". The process stack for bgpd shows: root@frr:~# cat /proc/52925/stack [<0>] futex_wait_queue_me+0xbb/0x120 [<0>] futex_wait+0x105/0x290 [<0>] do_futex+0x157/0x4d0 [<0>] __x64_sys_futex+0x13f/0x170 [<0>] do_syscall_64+0x57/0x190 [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Thread debugging shows: [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". __pthread_clockjoin_ex (threadid=139670697043712, thread_return=0x0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145 145 pthread_join_common.c: No such file or directory. (gdb) bt #0 __pthread_clockjoin_ex (threadid=139670697043712, thread_return=0x0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145 #1 0x00007f07b1f3d985 in ?? () from /lib/x86_64-linux-gnu/librtr.so.0 #2 0x00007f07b1f38dc1 in rtr_mgr_stop () from /lib/x86_64-linux-gnu/librtr.so.0 #3 0x00007f07b1f53ef0 in ?? () from /usr/lib/x86_64-linux-gnu/frr/modules/bgpd_rpki.so #4 0x00007f07b1f53f7d in ?? () from /usr/lib/x86_64-linux-gnu/frr/modules/bgpd_rpki.so #5 0x00007f07b1f543ca in ?? () from /usr/lib/x86_64-linux-gnu/frr/modules/bgpd_rpki.so #6 0x00007f07b2586621 in thread_call () from /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0 #7 0x00007f07b2540198 in frr_run () from /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0 #8 0x00005566800b6678 in main () I've got about 2.5Mbytes of strace which I'll happily unicast to whoever would like to have a look at it. It looks very repetitive/boring to my non-developer eye, like something's got stuck waiting for something else. BTW, this is what's running (after I killed and restarted), including command line options: 1707406 ? S<s 0:02 /usr/lib/frr/watchfrr -d -F traditional zebra bgpd staticd 1707423 ? S<sl 0:01 /usr/lib/frr/zebra -d -F traditional -A 127.0.0.1 -s 90000000 1707428 ? S<sl 17:03 /usr/lib/frr/bgpd -d -F traditional -Z -M rpki 1707435 ? S<s 0:00 /usr/lib/frr/staticd -d -F traditional -A 127.0.0.1 Any ideas? I'd hate to revert to 8.1 but... philip --

1 0

Announcing the GRRouting fork
by David Lamparter 01 Apr '22

01 Apr '22

Dear all, it is with a heavy heart that I have to announce that due to the way the FRR project has been developing, another fork has become inevitable. I expect that a majority of you are already aware of the ongoing issues we've been having with the community. There simply is no opportunity for any real expression of anger and disdain at the project maintenance. This is very concerning and alienates a large portion of amoeba from participating and contributing constructively. As such, I have been left with no other choice than to create the GRRouting fork. GRRouting's goals and objectives are summarized handily by our new slogan: "putting the GRR back in routing." Of course this applies to development and community standards as well. Our goals will be to deliver software capable of evoking high-quality cursing at your routers. The very first feature will be to implement IP GRR, also known as anGry ReRoute. The plan for this feature is to incorporate a VoIP client and speech synthesis software to expedite waking up network administrators at 3 AM to have them drive to a datacenter to plug some cable. I am confident everyone sees the absolute necessity of this fork. You can find further information at https://grrouting.org/ Saddened but relieved by this finally being out in public, equi

1 0

What could cause 0.0.0.0 (inaccessible) from 0.0.0.0 (<my loopback IP>) in FRR bgpd
by Peter Olsson 28 Mar '22

28 Mar '22

Hello! I run FRR 7.5.1-1.1 in Debian 11.3. I am trying to convert a quagga router to a frr router. I have come to the point that all BGP peers are up, and ospfd/ospf6d seem fine. But I can't advertise my own networks in BGP, because of this: Local 0.0.0.0 (inaccessible) from 0.0.0.0 (<my loopback IP>) Origin IGP, metric 0, weight 32768, invalid, sourced, local This problem applies to both connected interfaces and static routes. I can't see the problem in my configuration and there are too many BGP peers and interfaces to anonymize all of it to be able to upload it. There are no confederations or reflectors, just a lot of ebgp peers and some ibgp peers in a full mesh. The frr logs don't seem to contain anything useful, and google just gives me years old entries for that message or similar. Where should I start looking for the problem? bgpd> sh ip bg x.y.z.46 BGP routing table entry for x.y.z.0/23 Paths: (2 available, best #1, table default) Advertised to non peer-group peers: xxx Local <ibgp peer> (metric 40) from <ibgp peer> (<ibgp peer>) Origin IGP, metric 0, localpref 100, valid, internal, best (First path received) Last update: Mon Mar 28 03:48:31 2022 Local 0.0.0.0 (inaccessible) from 0.0.0.0 (<my loopback IP>) Origin IGP, metric 0, weight 32768, invalid, sourced, local Last update: Mon Mar 28 03:47:50 2022 zebra> sh ip route x.y.z.46 Routing entry for x.y.z.32/27 Known via "ospf", distance 110, metric 40 Last update 01:09:24 ago <ospf neighbor, same as ibgp peer>, via enp196p0.107, weight 1 Routing entry for x.y.z.32/27 Known via "connected", distance 0, metric 0, best Last update 01:09:41 ago * directly connected, enp196p0.519 zebra> sh ip route <my loopback IP> Routing entry for <my loopback IP>/32 Known via "connected", distance 0, metric 0, best Last update 00:57:29 ago * directly connected, lo htgr01-zebra> sh ip route 0.0.0.0 Routing entry for 0.0.0.0/0 Known via "ospf", distance 110, metric 40 Last update 00:58:54 ago <ibgp peer>, via enp196p0.107, weight 1 Routing entry for 0.0.0.0/0 Known via "static", distance 1, metric 0, best Last update 00:59:11 ago * x2.y2.z2.78, via veth-S, weight 1 Thanks! Peter Olsson

1 1

FRR "overlooks" creation of kernel routes (on linux) - how to debug?
by Eugene Crosser 25 Mar '22

25 Mar '22

Hello, I am trying to investigate a situation when after a flurry of activity when a whole bunch of veth, vrf interfaces are created, with a bunch of addresses and routes added to them, not all of such routes appear in the FRR's view ("show ip route"), and consequently not redistributed. (If I later delete and re-add the route in the kernel, FRR notices it and redistributes it.) I am trying to understand the workflow that "notices" newly added routes and adds them into zebra's state, and I have no success so far. It looks like netlink messages NEWROUTE and DELROUTE are never seen by zebra process, neither asynchronous announcements, nor resulted from a "dump" request, even when the routes are successfully noticed! To troubleshoot, I need to understand how this _should_ work. Documentation contains some vague references to multiple ways of reading the kernel route table, but it's not easy to find it in zebra code. Can someone explain how zebra process gets informed about an added or removed kernel route, and what mechanism is used to get it from the kernel? Then I may be able to track down the part that does not work reliably. I am running on relatively recent Linux (kernel 5.10.x). Thanks, Eugene

2 3

ospf6d doesn't work since upgrading to 8.2.2
by Nicolas Desseauve 22 Mar '22

22 Mar '22

Hello, Since upgrading to 8.2.2 we have a problem with ospf6d (https://github.com/FRRouting/frr/issues/10823) Is there a way to have access to the 8.1 debian package in the repository ? Regards, -- *Nicolas Desseauve* /Responsable de la Sécurité des Systèmes d'Information/ http://www.xsalto.com/ Tél : 04 92 36 60 06 Support : 04 92 36 60 07 Fax : 04 92 36 19 75

2 1

Announcing FRR Release 8.2.2
by Jafar Al-Gharaibeh 15 Mar '22

15 Mar '22

Hi all, We are pleased to announce FRR 8.2.2 release. This release brings a long list of enhancements and fixes with more than 800 commits from 58 developers. Packages: Debian Packages - https://deb.frrouting.org/ <https://deb.frrouting.org/> RPM Packages - https://rpm.frrouting.org/ <https://rpm.frrouting.org/> Snaps - https://snapcraft.io/frr <https://snapcraft.io/frr> Docker - frrouting/frr:v8.2.2 https://hub.docker.com/layers/frrouting/frr/v8.2.2/images/sha256-b236f9d9d6… Some major highlights: - BGP Long-lived graceful restart capability (http://docs.frrouting.org/en/stable-8.2/bgp.html#long-lived-graceful-restart) - BGP Extended Optional Parameters Length for BGP OPEN Message (http://docs.frrouting.org/en/stable-8.2/bgp.html#clicmd-neighbor-PEER-exten…) - BGP Extended BGP Administrative Shutdown Communication - IS-IS Link State Traffic Engineering support (http://docs.frrouting.org/en/stable-8.2/isisd.html#traffic-engineering) - OSPFv3 Support for NSSA Type-7 address ranges (http://docs.frrouting.org/en/stable-8.2/ospf6d.html#ospf6-area) - PBR VLAN actions support (http://docs.frrouting.org/en/stable-8.2/pbr.html#pbr-maps) Please see the release notes for the detailed changelog: * Github release: https://github.com/FRRouting/frr/releases/tag/frr-8.2.2 * FRRouting website: https://frrouting.org/release/8.2.2/ Thanks to all contributors! Cheers, The FRR Development Team!

1 0