October 2020 - frog - lists.frrouting.org

Yocto Recipe for FRR
by Amol Lad 10 Aug '21

10 Aug '21

Hi, Please advise if there is any Yocto recipe for FRRouting? If not, how to go about creating one for FRR? Yocto Recipe for FRR will hugely simplify integrating FRR in Yocto based embedded linux distributions. So please advise if there are any plans to develop this recipe? Thanks Amol ________________________________ The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).

4 10

nhrpd event manager
by Joe Maimon 01 Mar '21

01 Mar '21

I have successfully gotten frr,nhrpd,strongswan,charon all running on another system for a dmvpn application. I am currently trying to do another setup, but without vpn/ipsec, just nhrp/gre. Its not working out well, debug logs show Netlink: Received msg_type 28 which if I recall correctly suggests that the neighbor entry isnt being installed correctly, trying it as root worked even less. So while poking around, I see there is an entire event manager unix sock structure. Perhaps I can parse that and do it myself? However, this is as far as I got. I am interacting with it via shell script. Mar 15 08:11:35 debian67 nhrpd[20977]: evmgr: sending event authorize-binding Mar 15 08:11:35 debian67 nhrpd[20977]: Send Registration-Reply(4) 192.168.241.129 -> 192.168.241.130 Mar 15 08:11:35 debian67 nhrpd[20977]: PACKET: Send 45.77.146.76 -> 209.51.164.27 Mar 15 08:11:35 debian67 nhrpd[20977]: evmgr: msg: eventid=214 Mar 15 08:11:35 debian67 nhrpd[20977]: evmgr: msg: result=accept Mar 15 08:11:35 debian67 nhrpd[20977]: evmgr: msg: Mar 15 08:11:35 debian67 nhrpd[20977]: evmgr: received: eventid=214 result= Mar 15 08:11:45 debian67 nhrpd[20977]: cache: t67 192.168.241.130: timeout Mar 15 08:11:46 debian67 nhrpd[20977]: Netlink: Received msg_type 28, msg_flags 0 I have looked at the source and I cant seem to convince the function to recognize that result should be "accept". Any advice appreciated. Joe For the interested, the below is the fledgling script #!/bin/bash PROGNAME=`basename $0` VERSION="0.0.1" usage() { echo "Usage: $PROGNAME -s nhrp-sock [-i interface-name] [-u user] [-g group] " echo "" echo "-s nhrp-sock file" echo "-i interface-name to execute on, may be repeated multiple times" echo "-u user to own the sock" echo "-g group to own the sock" exit 1 } SOCK="/var/run/frr/nhrp.sock" USER="frr" GROUP="frr" j=0 while getopts s:i:u:g: opt; do case "$opt" in s) SOCK="$OPTARG" ;; i) INTARR[((j++))]="$OPTARG" ;; u) USER="$OPTARG" ;; g) GROUP="$OPTARG" ;; esac; done coproc socat - UNIX-LISTEN:$SOCK,unlink-early,setuid-early=$USER || exit 1 OLDIFS="$IFS" while read -r S; do if [[ "$S" == "" ]]; then if [[ "$EVID" != "" ]]; then echo -e "eventid=$EVID\nresult=accept\n"; fi unset EVID unset EVINT continue; fi IFS="${IFS}=" SA=($S) IFS="$OLDIFS" case "${SA[0]}" in eventid) EVID="${SA[1]}" ;; interface) EVINT="${SA[1]}" esac done <&"${COPROC[0]}" >&"${COPROC[1]}" kill "$COPROC_PID"

2 3

ospfd crashes when deleting a route-map
by Amol Lad 28 Nov '20

28 Nov '20

Hi, I'm using FRR 7.4 (OpenWrt). I'm not using the integrated-config (i.e. each daemon has it's own config file). Below sequence of commands crashes ospfd. Please advise if any more useful debug information I can provide regarding this issue. === CRASH-1 [this happens after "no route-map SET_MED permit 10" command is executed] OSPF[9944]: Received signal 4 at 1772832797 (si_addr 0xffffffffb6f206d0); aborting... OSPF[9944]: in thread vtysh_read scheduled from lib/vty.c:2675 FRR(config)# log syslog FRR(config)# debug ospf zebra FRR(config)# debug ospf event FRR(config)# debug ospf ism FRR(config)# do show running-config Building configuration... Current configuration: ! frr version 7.4 frr defaults traditional log syslog hostname FRR ! line vty ! End FRR(config)# route-map SET_MED permit 10 FRR(config-route-map)# set metric 3333 FRR(config-route-map)# exit FRR(config)# no route-map SET_MED permit 10 (** console hangs here for very long time and finally shows below error **) vtysh: error reading from ospfd: No such file or directory (2)Warning: closing connection to ospfd because of an I/O error! FRR(config)# === CRASH-2 [this happens after "set metric 1234" command is executed] ripd[9945]: route_set_metric_compile: Metric specified: 1234 is greater than RIP_METRIC_INFINITY, using INFINITY instead ripngd[9948]: route_set_metric_compile: Metric specified: 1234 is being converted into METRIC_INFINITY OSPF[9952]: Received signal 11 at 1772834027 (si_addr 0x8); aborting... OSPF[9952]: in thread vtysh_read scheduled from lib/vty.c:2675 FRR(config)# log syslog FRR(config)# debug ospf ism FRR(config)# debug ospf event FRR(config)# debug ospf zebra FRR(config)# do show running-config Building configuration... Current configuration: ! frr version 7.4 frr defaults traditional log syslog hostname FRR ! line vty ! End FRR(config)# route-map SET_MED permit 10 FRR(config-route-map)# set metric 1234 (** console hangs here for very long time and finally shows below error **) vtysh: error reading from ospfd: No such file or directory (2)Warning: closing connection to ospfd because of an I/O error! AprisaLTE(config-route-map)# == root@AprisaLTE:/# cat /etc/frr/daemons # The watchfrr and zebra daemons are always started. # bgpd=yes ospfd=yes #ospfd_instances=1,20 ospf6d=yes ripd=yes ripngd=yes isisd=no pimd=no ldpd=no nhrpd=yes eigrpd=yes babeld=no sharpd=no pbrd=no bfdd=no fabricd=no vrrpd=no # # If this option is set the /etc/init.d/frr script automatically loads # the config via "vtysh -b" when the servers are started. # Check /etc/pam.d/frr if you intend to use "vtysh"! # vtysh_enable=yes zebra_options=" -A 127.0.0.1 -s 90000000 -f /opt/conf/openwrt/etc/frr/zebra.conf" bgpd_options=" -A 127.0.0.1 -f /opt/conf/openwrt/etc/frr/bgpd.conf" ospfd_options=" -A 127.0.0.1 -f /opt/conf/openwrt/etc/frr/ospfd.conf" ospf6d_options=" -A ::1 -f /opt/conf/openwrt/etc/frr/ospf6d.conf" ripd_options=" -A 127.0.0.1 -f /opt/conf/openwrt/etc/frr/ripd.conf" ripngd_options=" -A ::1 -f /opt/conf/openwrt/etc/frr/ripngd.conf" isisd_options=" -A 127.0.0.1" pimd_options=" -A 127.0.0.1" ldpd_options=" -A 127.0.0.1 -f /opt/conf/openwrt/etc/frr/ldpd.conf" nhrpd_options=" -A 127.0.0.1 -f /opt/conf/openwrt/etc/frr/nhrpd.conf" eigrpd_options=" -A 127.0.0.1 -f /opt/conf/openwrt/etc/frr/eigrpd.conf" babeld_options=" -A 127.0.0.1" sharpd_options=" -A 127.0.0.1" pbrd_options=" -A 127.0.0.1 -f /opt/conf/openwrt/etc/frr/pbrd.conf" staticd_options="-A 127.0.0.1 -f /opt/conf/openwrt/etc/frr/staticd.conf" bfdd_options=" -A 127.0.0.1 -f /opt/conf/openwrt/etc/frr/bfdd.conf" fabricd_options="-A 127.0.0.1" vrrpd_options=" -A 127.0.0.1" # The list of daemons to watch is automatically generated by the init script. #watchfrr_options="" # for debugging purposes, you can specify a "wrap" command to start instead # of starting the daemon directly, e.g. to use valgrind on ospfd: # ospfd_wrap="/usr/bin/valgrind" # or you can use "all_wrap" for all daemons, e.g. to use perf record: # all_wrap="/usr/bin/perf record --call-graph -" # the normal daemon command is added to this at the end.

2 7

OSPF and not redistributing ptp subnets
by Chriztoffer Hansen 01 Nov '20

01 Nov '20

On 31 Oct 2020 18:17, Philip Prindeville wrote: > Again, I see routing announcements for the /30 subnets in 10.0.0.0/24 going out As far as I see it, access lists are doing literal matching. docs.frrouting.org/en/stable-7.0/filter.html E.g. 10.0.0.0/30 != 10.0.0.0/24 Using access-list not-ptp deny 10.0.0.0/24 access-list not-ptp permit any Only 10.0.0.0/24 would be denied. Any prefixes larger or smaller will be permitted, matching the permit any statement coming after. > Is there a really good book (that’s recent!) about routing with Quagga/FRR, say version 7.0 or later? The current documentation is your best option. Including the examples. docs.frrouting.org (The official documentation is in no way all glorious 110 % perfect. But is your best starting point) Otherwise you are down to blog posts, mailing list threads, forum posts, GitHub issue threads, etc. (i.e. whatever else you can find) -- Best regards, Chriztoffer

2 1

OSPF and not redistributing ptp subnets
by Philip Prindeville 01 Nov '20

01 Nov '20

Hi. I’m wracking my brain trying to figure this one out. I’ve tried several examples online but none of them work. I’m using FRR 7.0 on CentOS 8 Stream. My box looks like this: hostname redfish1 GRE tunnel interface “tun-lakeland2” 10.0.0.30/30 (peer is .29, “lakeland2”) Bridge interface “br0” is 10.5.29.1/24. The subnet 10.0.0.28/30 is not meaningful to anyone other than my peer who is already directly connected to it, and hence doesn’t need to learn of it via OSPF. What I *do* want it learning is that I’m connected to 10.5.29.0/24 (and all packets sent to any 10.0.0.0/8 networks should be sourced with 10.5.29.1). This is a remote site in a spoke-and-hub topology (actually, there’s 2 hubs, but we won’t worry about that for now). My config first looks like: log file /var/log/ospfd.log debugging ! interface br0 ip ospf area 0.0.0.0 ! interface tun-lakeland2 ip ospf network point-to-point ! router ospf ospf router-id 10.5.29.1 passive-interface default no passive-interface tun-lakeland2 ! route-map set-source permit 10 set src 10.5.29.1 ! ip protocol ospf route-map set-source ! end Should be simple, but doesn’t work. Doesn’t even send announcements on tun-lakeland2. Or see its neighbor. So here’s my 2nd config: ! router ospf ospf router-id 10.5.29.1 redistribute connected redistribute kernel network 10.0.0.0/8 area 0.0.0.0 passive-interface default no passive-interface tun-lakeland2 area 0.0.0.0 range 10.0.0.0/24 not-advertise ! route-map set-source permit 10 set src 10.5.29.1 ! ip protocol ospf route-map set-source ! end Which also doesn’t work. It does peer, but it also announces the /30 networks inside of 10.0.0.0/24. Third config looks like: ! router ospf ospf router-id 10.5.29.1 network 10.0.0.0/8 area 0.0.0.0 passive-interface default no passive-interface tun-lakeland2 ! distribute-list not-ptp out connected distribute-list not-ptp out kernel ! access-list not-ptp deny 10.0.0.0/24 access-list not-ptp permit any ! end Again, I see routing announcements for the /30 subnets in 10.0.0.0/24 going out: 17:13:39.408645 IP (tos 0xc0, ttl 1, id 39681, offset 0, flags [none], proto OSPF (89), length 120) 10.0.0.30 > 224.0.0.5: OSPFv2, LS-Update, length 100 Router-ID 10.5.29.1, Backbone Area, Authentication Type: none (0), 1 LSA LSA #1 Advertising Router 10.5.29.1, seq 0x8000000d, age 1s, length 52 Router LSA (1), LSA-ID: 10.5.29.1 Options: [External] Router LSA Options: [none] Stub Network: 10.5.29.0, Mask: 255.255.255.0 topology default (0), metric 10 Stub Network: 10.0.0.24, Mask: 255.255.255.252 topology default (0), metric 10 Neighbor Router-ID: 10.5.2.1, Interface Address: 10.0.0.30 topology default (0), metric 10 Stub Network: 10.0.0.28, Mask: 255.255.255.252 topology default (0), metric 10 Which resembles what was happening with config #2 as well. Also, my peer (10.5.2.1/24 aka 10.0.0.29/30) is advertising a route that’s not in the 10.0.0.0/8 space, despite also having a similar “network” statement… How do I turn off distributing “external” routes into my area (it’s a routable address, indeed it’s to the subnet that his public interface is on, which ends up trying to draw my VPN [GRE] traffic to be routed over the 10.0.0.0/8 network with disastrous results). It’s a trivial setup, right? But I’ve been debugging it for hours. Is there a really good book (that’s recent!) about routing with Quagga/FRR, say version 7.0 or later? I’d really like to figure this out and move on to other stuff. Thanks, -Philip

1 0

Help about OSPF ECMP between quagga (CentOS7) and frr (CentOS8)
by Sun Guonian 30 Oct '20

30 Oct '20

Hello, After I upgraded one of server's OS from CentOS7 to CentOS8, the default routingsoftware changed to frr from quagga. I found that the OSPF ECMP didn't work againbetween the my two servers, one is CentOS7 with quagga, another is CentOS8 with frr. How to configure frr to make the "TOS 0 Metric" become value 10 ? Thanks in advanced ! Best Regards,SUN Guonian +-------------+ | router | +---+-----+---+192.168.8.158/28 | | 192.168.8.174/28 | |192.168.8.149/28 | | 192.168.8.166/28 +------------+--+ +---------------+ |xxx.xxx.xxx.xx1| |xxx.xxx.xxx.xx2| +---------------+ +---------------+ ===== ospfd# sh ip ospf database router adv-router 192.168.8.166 OSPF Router with ID (192.168.8.166) Router Link States (Area 0.0.0.0) LS age: 758 Options: 0x2 : *|-|-|-|-|-|E|- LS Flags: 0x3 Flags: 0x0 LS Type: router-LSA Link State ID: 192.168.8.166 Advertising Router: 192.168.8.166 LS Seq Number: 8000655c Checksum: 0xefc3 Length: 48 Number of Links: 2 Link connected to: a Transit Network (Link ID) Designated Router address: 192.168.8.174 (Link Data) Router Interface address: 192.168.8.166 Number of TOS metrics: 0 TOS 0 Metric: 100 Link connected to: Stub Network (Link ID) Net: xxx.xxx.xxx.xx1 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metric: 0 router ospf ospf router-id 192.168.8.166 network 192.168.8.160/28 area 0.0.0.0 network xxx.xxx.xxx.xx1/32 area 0.0.0.0! ===== ospfd# sh ip ospf database router adv-router 192.168.8.149 OSPF Router with ID (192.168.8.148) Router Link States (Area 0.0.0.0) LS age: 302 Options: 0x2 : *|-|-|-|-|-|E|- LS Flags: 0x6 Flags: 0x0 LS Type: router-LSA Link State ID: 192.168.8.149 Advertising Router: 192.168.8.149 LS Seq Number: 8000178d Checksum: 0x4472 Length: 96 Number of Links: 6 Link connected to: a Transit Network (Link ID) Designated Router address: 192.168.8.158 (Link Data) Router Interface address: 192.168.8.149 Number of TOS metrics: 0 TOS 0 Metric: 10 Link connected to: Stub Network (Link ID) Net: xxx.xxx.xxx.xx2 (Link Data) Network Mask: 255.255.255.255 Number of TOS metrics: 0 TOS 0 Metric: 10 router ospf ospf router-id 192.168.8.149 network 192.168.8.144/28 area 0.0.0.0 network xxx.xxx.xxx.xx2/32 area 0.0.0.0!

1 0

FRR Debian Packages
by Jafar Al-Gharaibeh 28 Oct '20

28 Oct '20

Dear All, Recently we have made changes to how we create and publish FRR deb packages. We have also moved the repository to new servers. We have had some issues with DNS and site certs during the transition in the last couple of days. We also introduced a new signing key which means you have to re-sync your keys following the instructions on [1]. Sorry for any inconvenience this may have caused. All of the issues related to this transition reported so far have been resolved. Please let me know if you still have issues. Regards, Jafar Al-Gharaibeh [1] https://deb.frrouting.org/

1 0

difference quagga/frr multiple IPv6 default routes
by Frank Kardel 22 Oct '20

22 Oct '20

I am just moving from Quagga 1.2.4 to FRR 7.4. I noticed that FRR differs in behavior in case of multiple IPv6 default routes with the interface line protocol being down. The quagga static route configuration is: ipv6 route ::/0 carp3 100 ipv6 route ::/0 <IPv6-PREFIX>::1 carp3 100 ipv6 route ::/0 <IPv6-PREFIX>:2::192 200 And with carp3 line protocol being down following route is selected and installed: S>* ::/0 [200/0] via <IPv6-PREFIX>:2::192, wm0 <=== quagga uses alternate route S ::/0 [100/0] is directly connected, carp3 inactive via <IPv6-PREFIX>::1, carp3 inactive <=== quagga detects inactive This is what I am expecting from the aboe configuration. Now FRR looks different in this regard. The FRR staticd configuration is: ip route 0.0.0.0/0 carp3 100 ip route 0.0.0.0/0 <IPv4-NET>.65 100 ip route 0.0.0.0/0 10.0.2.192 200 ipv6 route ::/0 carp3 100 ipv6 route ::/0 <IPv6-PREFIX>::1 carp3 100 ipv6 route ::/0 <IPv6-PREFIX>:2::192 200 And FRR slect following route: S ::/0 [200/0] via <IPv6-PREFIX>:2::192, wm0, weight 1, 00:01:01 <== frr does not use alternate route S>* ::/0 [100/0] is directly connected, carp3 inactive, weight 1, 00:01:01<=== here frr knows thet carp3 is inactive * via <IPv6-PREFIX>::1, carp3, weight 1, 00:01:01 <=== frr does not document/notice line protocol down. === also a route to <IPv6-PREFIX>::1 is installed === via the wm0 interface, not carp3 FRR on IPv4 the mechanism does seem to work like in quagga: S 0.0.0.0/0 [100/0] is directly connected, carp3 inactive, weight 1, 00:00:48 via <IPv4-NET>.65, carp3 inactive, weight 1, 00:00:48 <== inactive is noticed here S>* 0.0.0.0/0 [200/0] via 10.0.2.192, wm0, weight 1, 00:23:23 <== alternate route is selected This violates for me the principle of least astonishment. Multiple variants of the statics route configuration did not cause FRR to select the route with distance 200. Is this a bug or a feature? If it is a feature how would I have to configure staticd then? Best regards, Frank Kardel

1 1

Re: [FROG] Yocto Recipe for FRR
by Quang Anh Trần Đỗ 22 Oct '20

22 Oct '20

1 0

A study on community-triggered updates in BGP
by Thomas Krenc 22 Oct '20

22 Oct '20

Dear FRRouting users and developers, As a team of researchers from NPS and TU Berlin, we are investigating the impact of BGP community attributes on the update behavior between ASes. We find that when a route is associated with multiple distinct community attributes it does not only lead to multiple announcement at the tagging AS, but also at neighboring ASes, if communities are not filtered properly. This behavior is wide-spread. In order to better understand our observations, we have performed a series of laboratory experiments using Cisco IOS, Junos OS, as well as the routing daemons BIRD and FRRouting. We find that - by default - all routers generate announcements with changing community attributes, even when other attributes do not change. In addition, when communities are filtered at egress, Cisco, BIRD and FRRouting send duplicate announcements (Juniper does not). Is this side-effect known to the FRRouting community and would you consider it a bug or a feature? Since our findings are limited to observations in public data as well as few router implementations, we would like to share our research and kindly ask you to have a look at: https://www.cmand.org/communityexploration/ There, we provide some resources documenting our research, as well as open questions. We greatly appreciate any feedback and insights you can offer. Also, please don't hesitate to contact us directly: communityexploration AT cmand DOT org best regards Thomas Krenc Postdoctoral Researcher Naval Postgraduate School

2 2