July 2019 - 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

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

cumulusnetworks/frrouting image is missing /bin/ping
by Rafael Gozlan 30 Jul '19

30 Jul '19

Hi Frogs! I pulled the latest image from https://hub.docker.com/r/cumulusnetworks/frrouting yesterday isn't installed thus the ping command from vtysh is failing. ``` 4a5446b1d048# ping ip 172.17.0.3 Can't execute ping: No such file or directory ``` I wanted to know if https://github.com/FRRouting/frr/tree/master/docker/debian was the associated dockerfile. Thanks for any answer :) -- raf

3 3

Open source routing @ ietf meetup -- Monday Lunch
by Lou Berger 21 Jul '19

21 Jul '19

Hi, We're continuing with the informal Open Source routing @ ietf meetup. Anyone interested in joining a "bring your own lunch" gathering of folks using/building open source routing code, please drop in to "C2 (21st Floor) " on *Monday* during lunch (noon). There is no agenda or slides. Please feel free to bring a topic that you'd like to discuss or just come and listen. Cheers, Lou

1 0

Setting defaults for autodetected VRFs/VxLANx
by Eugene Crosser 15 Jul '19

15 Jul '19

Hello all, we are trying use BGP-EVPN + VRF on Linux in L3 mode. For each VPN instance, we add two snippets into the FRR configuration: Snippet 1: ==== vrf <vrf-iface-name> vni <vni> prefix-routes-only exit-vrf ==== Snippet 2: ==== router bgp 64512 vrf <vrf-iface-name> bgp router-id 169.254.0.1 ! address-family ipv4 unicast redistribute kernel exit-address-family ! address-family l2vpn evpn advertise ipv4 unicast exit-address-family ==== Our use case requires dynamic creation and removal of VRF instances on demand. I understand that FRRouting can autodetect VRF+VxLAN interface groups that are already present in the system and start serving them, but only as "classic" L2VPNs. My question is: should it be made possible (or maybe it is already possible?) to set default attributes for VRF/EVPNs that FRR autodetects? So that one could add something like this just once: ==== vrf DEFAULT vni AUTODETECT prefix-routes-only exit-vrf ==== ==== router bgp 64512 vrf DEFAULT bgp router-id 169.254.0.1 ! address-family ipv4 unicast redistribute kernel exit-address-family ! address-family l2vpn evpn advertise ipv4 unicast exit-address-family ==== and then all newly created VRF+VxLAN groups would be automatically picked up by FRR and configured as L3 EVPNs, without the need to rewrite configuration file and restart the daemon. Does this make sense or am I missing something? On a related note, I understand that currently FRR can fetch FDB only from 'bridge' interfaces, but not directly from VxLAN interfaces. So VxLAN interface cannot be directly enslaved into the VRF interface, but instead we have to add an intermediate bridge: "vrfXX---brXX---vxlanXX". (while client interfaces are directly enslaved into the VRF interface). In such setup, 'br' interface seems unnecessary. Should it be made possible to avoid this redundant 'br' interface? Thank you, and don't get too angry if I am messing things up: I am pretty new to this. Eugene

2 4

Where do those massive ARP tables come from?
by Bernd 15 Jul '19

15 Jul '19

Hi list, I have a bunch of three routers running in a project, let's call them A, B and C. They connect to multiple AS upstream and internally via OSPF and RIPng. While B is based on an (ancient) Ubuntu 12.04.5 and (also ancient) Quagga (0.99.20.1), A and C run very recent CentOS 7 and FRR 6.0.2. B performs perfectly, while A and C put massive pressure on some Cisco switches they're connected to (OSPF and RIPng): They're sending about 2k ARP requests per second each. Looking at the ARP table (``ip nei show'') of A and C, I see about 20k entries, almost all of them in nud "FAIL" (unreachable). Most of them are IPs within the customer's AS (this is VLAN310 in the graphs attached), but some are random public IPv4 addresses. I did compare all sysctl settings to no avail, they're all set in a sane and safe manner. Every daemon not needed or adding not necessary complexity (like NetworkManager) is disabled and not running on A and C. ARP flux can be ruled out, too. Any idea what is going on here? Best Bernd

2 4

Optional attribute error peering BGP with BIRD
by Derrick Lim 11 Jul '19

11 Jul '19

Hello everyone, I’m having an issue with FRR running on Cumulus (4.0+cl3u10), which is peering BGP to BIRD (2.0.2, also tried 1.6.3). When certain routes from FRR are advertised to BIRD (I configured them through vrf leaking on FRR, but not sure if that matters, or its just something with the routes), BIRD terminates the BGP session with an `Optional attribute error` (on BIRD 2.0.2, different error on 1.6.3) when receiving the BGP UPDATE message. I’m not sure if this an FRR or BIRD issue, so I'm hoping someone here could take a look if the UPDATE message from FRR could possibly be malformed, or is BIRD handling this in an odd way. I've attached the tcpdump as well as error logs from BIRD, along with the bird.conf, as well a portion of the FRR config. 100.91.38.1 is the host running BIRD. 100.91.38.61 is the host running FRR. Regards, Derrick

2 1

Certificate expired for lists.frrouting.org
by Timo Schöler 01 Jul '19

01 Jul '19

Hi, yesterday, on Sun, 30 Jun 2019 18:37:42 UTC, the SSL/TLS certificate expired on lists.frrouting.org. Seems autorenewal of that Let's Encrypt cert failed? Best Timo

2 1