March 2022 - frog - lists.frrouting.org

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

27 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 21 Mar '22

21 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 14 Mar '22

14 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

OSPF over GRE over IPSec
by Volodymyr Litovka 11 Mar '22

11 Mar '22

Hi colleagues, can anybody help me with an issue in the following configuration. There is GRE over IPSec in transport mode between Linux (Ubuntu 20.04) and two other boxes - Cisco (virtual XE v17.07.01) and Mikrotik (CHR v6). Pings are there, so IPSec policies, addresses, connectivity is ok, but OSPF (I'm using FRR 8.1) do not work. On the linux side, tcpdump shows that it sends hellos in this interface, but both Cisco and CHR see nothing: # tcpdump -i gre1 -v [ ... ] 15:34:49.132222 IP (tos 0xc0, ttl 1, id 15017, offset 0, flags [none], proto OSPF (89), length 68) my_linux > ospf-all.mcast.net: OSPFv2, Hello, length 48 Router-ID x.x.x.x, Backbone Area, Authentication Type: none (0) Options [External] Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.252, Priority 1 Neighbor List: 100.100.8.1 Cisco: Mar 11 15:31:33.522: OSPF-1 HELLO Tu8: Send hello to 224.0.0.5 area 0 from 100.99.0.65 Mar 11 15:31:42.586: OSPF-1 HELLO Tu8: Send hello to 224.0.0.5 area 0 from 100.99.0.65 Mar 11 15:31:51.641: OSPF-1 HELLO Tu8: Send hello to 224.0.0.5 area 0 from 100.99.0.65 Mikrotik (using packet sniffer) also see nothing on input. Definitely, the issue is on Linux side but I can't realize, where exactly. Linux side (mtu is same, multicast switched on): 6: gre1@NONE: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc noqueue state UNKNOWN group default qlen 1000 link/gre x.x.x.x peer x.x.x.y inet 100.99.0.66/30 brd 100.99.0.67 scope global gre1 valid_lft forever preferred_lft forever vtysh#sh run [ ... ] interface gre1 ip ospf cost 5 ip ospf mtu-ignore vtysh#sh ip ospf interface gre1 gre1 is up ifindex 6, MTU 1400 bytes, BW 0 Mbit <UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> Internet Address 100.99.0.66/30, Broadcast 100.99.0.67, Area 0.0.0.0 MTU mismatch detection: disabled Router ID x.x.x.x, Network Type POINTOPOINT, Cost: 5 Transmit Delay is 1 sec, State Point-To-Point, Priority 1 No backup designated router on this network Multicast group memberships: OSPFAllRouters Timer intervals configured, Hello 10s, Dead 40s, Wait 40s, Retransmit 5 Hello due in 8.701s Neighbor Count is 1, Adjacent neighbor count is 0 vtysh#sh ip ospf neigh Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL 100.100.8.1 1 Init/DROther 37.960s 100.99.0.65 gre1:100.99.0.66 0 0 0 host# ip maddress [ ... ] 6: gre1 inet 224.0.0.5 inet 224.0.0.1 What I miss in the Linux configuration? Cisco configuration is for reference: interface Tunnel8 description HZF ip address 100.99.0.65 255.255.255.252 ip mtu 1400 ip ospf network point-to-point ip ospf cost 5 tunnel source GigabitEthernet1 tunnel destination x.x.x.x Tunnel8 is up, line protocol is up Internet Address 100.99.0.65/30, Interface ID 20, Area 0 Attached via Network Statement Process ID 1, Router ID 100.100.8.1, Network Type POINT_TO_POINT, Cost: 5 Topology-MTID Cost Disabled Shutdown Topology Name 0 5 no no Base Transmit Delay is 1 sec, State POINT_TO_POINT Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 oob-resync timeout 40 Hello due in 00:00:04 Supports Link-local Signaling (LLS) Cisco NSF helper support enabled IETF NSF helper support enabled Can not be protected by per-prefix Loop-Free FastReroute Can be used for per-prefix Loop-Free FastReroute repair paths Not Protected by per-prefix TI-LFA Index 1/8/8, flood queue length 0 Next 0x0(0)/0x0(0)/0x0(0) Last flood scan length is 1, maximum is 38 Last flood scan time is 0 msec, maximum is 1 msec Neighbor Count is 0, Adjacent neighbor count is 0 Suppress hello for 0 neighbor(s) Thank you for any recommendations. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

2 2