April 2022 - frog - lists.frrouting.org

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