March 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

Display in wrong order for prefix-list
by Sébastien 65 24 Apr '20

24 Apr '20

Hi, I note that the display of a prefix-list AND bgp as-path access-list is not in the correct order, the sequences are mixed and this is not easily readable ... ip prefix-list LIST1 seq 10 deny X ip prefix-list LIST1 seq 100 deny X ip prefix-list LIST1 seq 105 deny X ip prefix-list LIST1 seq 15 deny X ip prefix-list LIST1 seq 20 deny X ip prefix-list LIST1 seq 200 permit X ip prefix-list LIST1 seq 25 deny X ip prefix-list LIST1 seq 30 deny X ip prefix-list LIST1 seq 35 deny X ip prefix-list LIST1 seq 40 deny X ip prefix-list LIST1 seq 45 deny X ip prefix-list LIST1 seq 5 deny X How to display the sequences in the right order (10,15,20,25,...,100,105,200,...)? Thank you !

4 6

v6 Route Replace semantics
by Donald Sharp 08 Apr '20

08 Apr '20

All - We recently introduced, into master, a new cli switch for zebra on linux `--v6-rr-semantics`. This was allow zebra to take advantage of the linux kernel getting v6 route replace semantics that is coming soon in the 4.18 linux kernel. So if you are on the bleeding edge of linux kernels and FRR you can start to take advantage of this new feature. What are Route Replace semantics you ask? Suppose we have a v6 route with 2 nexthops: S>* 4:6:7::/64 [1/0] via 1:2:3::4, enp0s3, 00:00:02 via 1:2:8::8, enp0s8, 00:00:02 Now suppose we remove a nexthop: robot# conf t robot(config)# no ipv6 route 5:7:9::/78 1:2:8::9 robot(config)# end robot# show ipv6 route [snip] S>* 5:7:9::/78 [1/0] via 1:2:3::4, enp0s3, 00:01:04 Let's look at the netlink notifications for this event: [ROUTE]5:7:9::/78 proto static metric 20 <----------- From creation of the 2x ecmp for 5:7:9::/78 nexthop via 1:2:3::4 dev enp0s3 weight 1 nexthop via 1:2:8::9 dev enp0s8 weight 1 [ROUTE]Deleted 5:7:9::/78 proto static metric 20 <---- We delete the route nexthop via 1:2:3::4 dev enp0s3 weight 1 nexthop via 1:2:8::9 dev enp0s8 weight 1 [ROUTE]5:7:9::/78 via 1:2:3::4 dev enp0s3 proto static metric 20 pref medium <----- We add it back in. In order to get the routes right in the kernel we had to delete the route first and then add it back in. Exposing a small window of packets being dropped while the route is fixed in the fib. Route Replace semantics tells the linux kernel to just replace the nexthops for the route. New packets coming in would immediately start using the new ecmp nexthop group path: [ROUTE]5:7:9::/78 proto static metric 20 nexthop via 1:2:3::4 dev enp0s3 weight 1 nexthop via 1:2:8::9 dev enp0s8 weight 1 [ROUTE]5:7:9::/78 via 1:2:3::4 dev enp0s3 proto static metric 20 pref medium thanks! donald

2 1

FRR BGP Route Server Issues/Questions
by Michael Lambert 28 Mar '20

28 Mar '20

We're running quagga (currently the Euro-IX fork, to be specific) as a route server. I was hoping to be able to use FRR as a more-or-less drop-in replacement. However, I've come up with some oddities which make me question whether route server functionality is still supported under FRR's bgpd. It appears that neighbor <...> route-map <...> (import | export) has disappeared from the CLI. I couldn't find anything obvious about this from either the git logs or the mailing list archive (but I have not done a bisection to figure out where they disappeared). Are import <=> in and export <=> out the new mapping? Or is it reversed? There was always something not quite intuitive about import/export. The documentation still refers to import/export, by the way. I've setup a (virtual) lab environment with FRR's bgpd running under FreeBSD 12.1 and three BGP speakers running OpenBGPd under OpenBSD 6.6. When configuring FRR's bgpd with neighbor <...> route-server-client the OpenBGPd speakers hear the expected routes from the route server, but with the route server itself as the next-hop. If I include neighbor <...> attribute-unchanged next-hop the next-hop is correctly propagated, but its presence would, on the surface, seem to make specifying "route-server-client" syntactic fluff. I also see that the show bgp [view <name>] (ipv4|ipv6) (unicast|multicast) rsclient <...> commands have disappeared, so the "obvious" way of checking route server functionality from within bgpd has, at best, changed. Assuming that the intent is to continue to support route server functionality within FRR, I have a couple of questions. Is my approach of specifying route-server-client/attribute-unchanged correct or am I missing something that makes FRR's bgpd work like quagga's bgpd? And are there plans to update the route server documentation to match the current implementation? We've been using bgpd for many years; I'd like to continue doing so with a non-orphaned version. Thanks, Michael -- Michael H Lambert, GigaPoP Manager Phone: +1 412 268-4960 Pittsburgh Supercomputing Center/3ROX FAX: +1 412 268-5832 300 S Craig St, Pittsburgh, PA 15213 USA lambert(a)psc.edu

2 3

How to import route and NOT withdraw existing route ?
by Simon Jones 24 Mar '20

24 Mar '20

Hi all, Now I need a feature, I have to import neighbor as vlink route into bgpd. So I use static route like this: > vtysh > ip route 1.1.1.1/32 Vlan100 > redistribute static route-map XXX But I encounter a problem: > before I add static route, there are B route like this: > B 2.2.2.100/32 [20/0] via 100.0.28.231, Ethernet52, src 1.1.1.230, > 3d03h18m > after I add static route, there are two route like this: > S>* 2.2.2.100/32 [1/0] is directly connected, Vlan100 > B 2.2.2.100/32 [20/0] via 100.0.28.231, Ethernet52, src 1.1.1.230, > 3d03h18m > after I redistribute, there are only one route like this: > S>* 2.2.2.100/32 [1/0] is directly connected, Vlan100 But what I need is to keep two route. Because if there is only one route, I have to relearn B route after I delete static route, which will cause package loss in long time(like 20 second). For some producer like huawei, thay have 'import route' command, which will combine redistributed route and learned route, like this: https://support.huawei.com/enterprise/en/doc/EDOC1000178171/cc777bfe/config… So will FRR support this feature ? How to import route and NOT withdraw existing route ? ---- Simon Jones

1 1

bgpd as0 rfc7607 compliance
by Joe Maimon 23 Mar '20

23 Mar '20

Seems to be finding plenty of these AGGREGATOR attribute is BGP_AS_ZERO(0) However, rfc7607 specifies error handling as per rfc7606 which suggests most frequently the withdrawn treatment bgpd appears to instead proceed for ebgp peers and notify for ibgp sessions, I am curious as to how either of these are correct and would appreciate any advice on the matter. Frustratingly, I haven't figured out any good way to log which prefix update are triggering this. Best, Joe

1 1

ospf on nhrp interface routes are inactive
by Joe Maimon 22 Mar '20

22 Mar '20

Hey All, Thanks to the event manager working properly, NHRP spokes are up and running. kernel neighbor routes are installed and pinging is working. I have gotten ospf neighbors to come up by configuring the interface as non-broadcast, as nhrp multicast does not appear to be supported at this time. (There seems to be some difficulty there, debug shows lots of duplicates and neighbors take quite a while to transition into Full/DR-whatever state) However, all ospf routes are marked inactive. I have found that this is the case for so long as the NHRP routes (individually as /32) are installed. The workaround is to prevent those routes from being installed (I do this by returning a result=reject from the event handler), but clearly that is not right. Running 7.4 git clone local debian 10 packaged. Any assistance would be greatly appreciated. For example: O>* 10.7.255.8/32 [110/20] via 192.168.241.130, t67, 16:48:28 O>* 10.7.255.14/32 [110/20] via 192.168.241.130, t67, 16:48:28 O>* 10.10.11.32/32 [110/20] via 192.168.241.130, t67, 16:48:28 O>* 10.34.34.0/30 [110/20] via 192.168.241.130, t67, 16:48:28 O>* 10.99.255.9/32 [110/20] via 192.168.241.130, t67, 16:48:28 O>* 38.32.100.169/32 [110/20] via 192.168.241.130, t67, 16:48:28 .....more.... debian67# sh ip route nhrp debian67# Now, I send result=accept to evmgr debian67(config)# int t67 debian67(config-if)# shutdown debian67(config-if)# no shutdown debian67(config-if)# end debian67# sh ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued route, r - rejected route K>* 0.0.0.0/0 [0/0] via 45.77.146.1, ens3, 17:00:22 C>* 45.77.146.0/23 is directly connected, ens3, 17:00:22 K>* 169.254.169.254/32 [0/0] via 45.77.146.1, ens3, 17:00:22 O 192.168.241.128/27 [110/500] is directly connected, t67, 00:01:56 C>* 192.168.241.128/27 is directly connected, t67, 00:01:56 N>* 192.168.241.130/32 [10/0] is directly connected, t67, 00:00:12 N>* 192.168.241.131/32 [10/0] is directly connected, t67, 00:00:01 N>* 192.168.241.132/32 [10/0] is directly connected, t67, 00:00:01 debian67# sh ip os ne Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL 216.222.156.3 1 Full/DR 1m49s 192.168.241.130 t67:192.168.241.129 0 0 0 209.54.134.5 1 Full/DROther 1m54s 192.168.241.131 t67:192.168.241.129 0 0 0 209.54.140.100 1 Full/DROther 1m59s 192.168.241.132 t67:192.168.241.129 0 0 0 debian67# sh ip route ospf Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP, T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR, f - OpenFabric, > - selected route, * - FIB route, q - queued route, r - rejected route O 0.0.0.0/0 [110/100] via 192.168.241.130, t67 inactive, 00:00:47 O 10.7.255.8/32 [110/20] via 192.168.241.130, t67 inactive, 00:00:47 O 10.7.255.14/32 [110/20] via 192.168.241.130, t67 inactive, 00:00:47 O 10.10.11.32/32 [110/20] via 192.168.241.130, t67 inactive, 00:00:47 O 10.34.34.0/30 [110/20] via 192.168.241.130, t67 inactive, 00:00:47 O 10.99.255.9/32 [110/20] via 192.168.241.130, t67 inactive, 00:00:47 ----more----

1 1

IS-IS MTU in FRR
by Mark Tinka 21 Mar '20

21 Mar '20

Hi all. As I've been unable to find anyone in the (NOG) community who has had any experience running IS-IS on FRR, I figured I'd set it all up and see how well it works. My first major road block is the below: 2020/03/21 03:12:36 ISIS: isis_send_pdu_bcast: sock_buff size 8192 is less than output pdu size 9014 on circuit em0 2020/03/21 03:12:36 ISIS: [EC 67108865] ISIS-Adj (1): Send L2 IIH on em0 failed I've been fiddling with all manner of MTU commands/settings both in zebra.conf and isisd.conf, but they all don't seem to be supported. Does anyone know how we can fix CLNS/IS-IS MTU on FRR? I'm running FRR 7.3 on FreeBSD-12.1. All help appreciated. Mark.

2 2

IS-IS MTU in FRR
by Mark Tinka 21 Mar '20

21 Mar '20

Hi all. As I've been unable to find anyone in the (NOG) community who has had any experience running IS-IS on FRR, I figured I'd set it all up and see how well it works. My first major road block is the below: 2020/03/21 03:12:36 ISIS: isis_send_pdu_bcast: sock_buff size 8192 is less than output pdu size 9014 on circuit em0 2020/03/21 03:12:36 ISIS: [EC 67108865] ISIS-Adj (1): Send L2 IIH on em0 failed I've been fiddling with all manner of MTU commands/settings both in zebra.conf and isisd.conf, but they all don't seem to be supported. Does anyone know how we can fix CLNS/IS-IS MTU on FRR? I'm running FRR 7.3 on FreeBSD-12.1. All help appreciated. Mark.

1 0