- frog - lists.frrouting.org

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

Static route with BFD not supported?
by Tamás Kelemen 20 Mar '20

20 Mar '20

Hi Is it possible to disable static routes if BFD session is down to the gateway address? Thanks in advice BR, Tamas

1 0

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

18 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 0

QoS
by Emanuel - Tianguá.com 17 Mar '20

17 Mar '20

Hello! Would anyone have any tips on how to perform speed control in FRRouting? QoS shaper? -- Sua foto ou logo Emanuel Magalhães Cunha Proprietário | Adm. Rede Tianguá.com +55 88 3671 1816 | +55 88 99994-2324 Skype: tiangua.com emanuel(a)tiangua.com.br https://www.tiangua.com.br Rua Assembleia de Deus, 723, B - Centro - Tianguá/CE - CEP: 62.320-029 <https://www.facebook.com/TIG.comOficial> <https://www.instagram.com/tianguacom/> <https://www.youtube.com/channel/UCHf-k7BrXpsCau5O3xgxpDA>

2 2

static routes not working
by neeraj kharbanda 16 Mar '20

16 Mar '20

HI, I added a static route in zebra through vtysh. ip route x.x.x.x./y a.a.a.a the route is there when you do show ip route static but it doesnt work until you add with ip route command in linux shell ip route add x.x.x.x/y via a.a.a.a the interface is ppppoeXXX and the name keeps on changing. Kindly help to make static route working. -- Thanks and Regards >From Chaos to Control Neeraj Kharbanda

2 3

Link two OSPF processes in different VRFs on the same router
by Sergey Popov 11 Mar '20

11 Mar '20

Hi to all. I am trying to replicate topology from our enterprise router with FRRouting and for now i am stuck! Here is my setup: rtest1 ~ # cat /etc/frr/daemons zebra=yes ospfd=yes ospfd_instances=37,125 staticd=yes vtysh_enable=yes zebra_options="-n -s 90000000 --daemon -A 127.0.0.1" ospfd_options=" --daemon -A 127.0.0.1" staticd_options=" --daemon -A 127.0.0.1" rtest1 ~ # ip netns show TEST1 (id: 1) rtest1 ~ # ip addr show dev ve1a 14: ve1a@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 5a:01:92:9a:6a:83 brd ff:ff:ff:ff:ff:ff link-netns TEST1 inet 10.0.0.1/30 brd 10.0.0.3 scope global ve1a valid_lft forever preferred_lft forever inet6 fe80::5801:92ff:fe9a:6a83/64 scope link valid_lft forever preferred_lft forever rtest1 ~ # ip -n TEST1 addr show dev ve1b 13: ve1b@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 82:72:fd:bf:5f:4d brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.0.0.2/30 brd 10.0.0.3 scope global ve1b valid_lft forever preferred_lft forever inet6 fe80::8072:fdff:febf:5f4d/64 scope link valid_lft forever preferred_lft forever rtest1# show running-config Building configuration... Current configuration: ! frr version 7.4-dev-gentoo frr defaults traditional hostname rtest1 no ip forwarding no ipv6 forwarding service integrated-vtysh-config ! ip route 12.0.0.0/24 blackhole ! vrf TEST1 ip route 0.0.0.0/0 10.0.0.1 netns /run/netns/TEST1 exit-vrf ! interface ve1a ip address 10.0.0.1/30 ip ospf 37 area 0 ! interface ve1b vrf TEST1 ip address 10.0.0.2/30 ip ospf 125 area 0 ! router ospf ! router ospf 125 vrf TEST1 ospf router-id 10.0.0.2 ospf router-id 10.0.0.2 ospf router-id 10.0.0.2 ! router ospf 37 ospf router-id 10.0.0.1 redistribute static ! line vty ! end rtest1# show ip ospf 37 neighbor OSPF Instance: 37 Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL 10.0.0.2 1 Loading/DR 39.996s 10.0.0.2 ve1a:10.0.0.1 1 1 0 rtest1# show ip ospf 125 neighbor OSPF Instance: 125 Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL 10.0.0.1 1 ExStart/Backup 36.642s 10.0.0.1 ve1b:10.0.0.2 0 0 0 OSPF Instance: 125 Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL 10.0.0.1 1 Loading/Backup 36.637s 10.0.0.1 ve1b:10.0.0.2 1 1 0 rtest1# exit rtest1 ~ # ping 10.0.0.2 -c 1 PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.073 ms --- 10.0.0.2 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.073/0.073/0.073/0.000 ms rtest1 ~ # ip netns exec TEST1 ping 10.0.0.1 -c 1 PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data. 64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.089 ms --- 10.0.0.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.089/0.089/0.089/0.000 ms rtest1 ~ # ps aux | grep quagga quagga 3530 0.0 0.0 387400 6652 ? Ssl 11:24 0:00 /usr/sbin/zebra -d -F traditional -n -s 90000000 --daemon -A 127.0.0.1 quagga 3535 0.0 0.0 9772 6256 ? Ss 11:24 0:00 /usr/sbin/ospfd -d -F traditional --daemon -A 127.0.0.1 quagga 3539 0.1 0.0 9796 6176 ? Ss 11:24 0:00 /usr/sbin/ospfd -d -F traditional -n 37 --daemon -A 127.0.0.1 quagga 3545 0.0 0.0 9796 6192 ? Ss 11:24 0:00 /usr/sbin/ospfd -d -F traditional -n 125 --daemon -A 127.0.0.1 quagga 3553 0.0 0.0 8088 3700 ? Ss 11:24 0:00 /usr/sbin/staticd -d -F traditional --daemon -A 127.0.0.1 root 8166 0.0 0.0 7560 860 pts/0 S+ 11:31 0:00 grep --colour=auto quagga rtest1 ~ # /usr/sbin/frrinit.sh status Status of watchfrr: running Status of zebra: running Status of ospfd: running Status of ospfd-37: running Status of ospfd-125: running Status of staticd: running ----------------------------------------------------------------------------------------------- FRRouting is installed on Gentoo Linux and started via /usr/sbin/frrinit.sh. I tried 7.1-r1 from frr-gentoo overlay, 7.3 and 9999 ebuilds - no luck And it stucks in that state permanently, switching from Loading to ExStart and repeating this again. So, two thoughts: 1) Is this intended behaviour? It should be no problem to link two distinct ospf processes(like on Cisco ASR with VASI interfaces) or am i wrong? 2) Duplicating of 'ospf router-id 10.0.0.2' also bothers me. Is that a cosmetic bug or something more serious? show ip ospf <process_num> looks ok(router-id option applied successfully), but still... Output for 'show ip ospf 125 interface' is also duplicated(while output of 'show ip ospf 37 interface' is perfectly fine. -- Best regards, Sergey Popov Gentoo developer

1 0

7.3 Belated Release
by Donald Sharp 10 Mar '20

10 Mar '20

All - I'd like to announce the 7.3 release of FRRouting: bgpd - EVPN PIP Support Route Aggregation code speed ups BGP Vector I/O speed ups New CLI: `set distance XXX` New CLI: `aggregate-address A.B.C.D/M route-map WORD` New CLI: `bgp reject-as-sets` New CLI: `advertise pip ...` New CLI: `match evpn rd ASN:NN_OR_IP-ADDRESS:NN` New CLI: `show bgp l2vpn evpn community|large-community X` New CLI: `show bgp l2vpn evpn A.B.C.D` Auto-completion for clear bgp command Add ability to set tcp socket buffer size pbrd - New CLI: `set vrf unchanged|NAME` pimd - Significant Speedups in accessing Internal Data for higher scale Support for joining any-source Multicast Updated CLI: 'show ip pim upstream-join-desired' New CLI: 'show ip pim channel' Debug Cleanup MLAG experimental support bfdd - VRF Support New CLI: 'show bfd peers brief' New CLI: 'clear bfd peer ...' ospfd - Partial MPLS TE support vrrpd - VRF Support Northbound Conversion vtysh - New CLI: `banner motd line LINE...` watchfrr - Additional status messages of system state to systemd New CLI: `watchfrr ignore DAEMON` yang - New CLI: `show yang operational-data XPATH` New CLI: `debug northbound` zebra - Nexthop Group support New CLI: 'show nexthop-group rib [singleton]' New CLI: 'debug zebra nexthop [detail]' New CLI: 'show router-id' MLAG experimental support Change in Behavior: isisd - All areas created default automatically to level-1-2 zebra - Nexthop Group Installation in Kernel is turned on by default if the kernel supports. Man Pages Renamed to frr-* to remove collision with other packages As always all daemons have received too many bug fixes to fully list Test Additions There has been a significant focus on increasing test coverage Snapcraft vrrpd support added Finally I'd like to thank each individual contributor, all 63 of them this time with over 900 commits As usual the release can be found on https://deb.frrouting.org thanks! donald

1 0