- frog - lists.frrouting.org

Solaris and FRR
by Donald Sharp 21 Aug '19

21 Aug '19

All - During yesterday's weekly technical meeting we discussed solaris and FRR. The FRR CI system uses Omnios, and over the last year or so with the increased usage of external libraries it has started to become extremely hard to keep Omnios in a working state. With the additional major rework of the zebra data plane it is becoming apparent that not having a built up test system for that platform we are running the risk of letting Solaris compatibility become woefully out of date. One of the options discussed was dropping Solaris but before we do so we wanted to gauge community interest/usage of FRR on solaris platforms and would like to hear opinions from people on this matter. thanks! donald

1 0

DEB repo and Apt-Cacher NG
by Chriztoffer Hansen 18 Aug '19

18 Aug '19

Hello, Anyone have had success before with configuring http://deb.frrouting.org/frr/ together with Apt-Cacher NG with ForceManaged enabled? Currently trying. But ends up with the following results each time I execute 'apt-get update' on any machine connected to the proxy. ``` Err:3 http://deb.frrouting.org/frr buster InRelease 403 Forbidden file type or location [IP: 192.0.2.0 3142] ``` ``` #/etc/apt-cacher-ng/acng.conf (snip) Remap-frrouting: file:frrouting_mirrors /frr ; file:backends_frrouting ForceManaged: 1 (snip) ``` ``` #/etc/apt-cacher-ng/backends_frrouting http://deb.frrouting.org/frr/ ``` -- Chriztoffer

1 0

Why my snmptrap handle script not work?
by Simon Jones 16 Aug '19

16 Aug '19

Hi all, I'm following this to handle snmp trap: http://docs.frrouting.org/en/latest/snmp.html this is /etc/snmp/snmptrapd.conf: > traphandle .3.6.1.2.1.15 /etc/snmp/snmptrap_handle.sh this is snmptrap_handle.sh: > echo "test" > temp.txt and snmptrapd got SNMP trap like this: > root@NX-ZWYC-M1F202-A16-HW6865-A-INT-212:/# snmptrapd -f -Lo > NET-SNMP version 5.7.3 > 2019-08-14 11:53:50 172.18.8.212(via UDP: > [127.0.0.1]:34916->[127.0.0.1]:162) TRAP, SNMP v1, community public > iso.3.6.1.2.1.15 Enterprise Specific Trap (2) Uptime: 2:11:33.09 > iso.3.6.1.2.1.15.3.1.14.192.168.10.9 = Hex-STRING: 06 02 > iso.3.6.1.2.1.15.3.1.2.192.168.10.9 = INTEGER: 6 > 2019-08-14 11:54:04 172.18.8.212(via UDP: > [127.0.0.1]:34916->[127.0.0.1]:162) TRAP, SNMP v1, community public > iso.3.6.1.2.1.15 Enterprise Specific Trap (1) Uptime: 2:11:47.10 > iso.3.6.1.2.1.15.3.1.14.192.168.10.9 = Hex-STRING: 06 02 > iso.3.6.1.2.1.15.3.1.2.192.168.10.9 = INTEGER: 6 > 2019-08-14 11:57:39 172.18.8.212(via UDP: > [127.0.0.1]:34916->[127.0.0.1]:162) TRAP, SNMP v1, community public > iso.3.6.1.2.1.15 Enterprise Specific Trap (2) Uptime: 2:15:22.90 > iso.3.6.1.2.1.15.3.1.14.192.168.10.9 = Hex-STRING: 06 02 > iso.3.6.1.2.1.15.3.1.2.192.168.10.9 = INTEGER: 6 But snmptrap_handle.sh does not work, as there is no temp.txt. So why ? BTW, this is also not work /etc/snmp/snmptrapd.conf: > traphandle .1.3.6.1.4.1.3317.1.2.2 /etc/snmp/snmptrap_handle.sh > ---- Simon Jones

2 1

[BUG] [FRR-SNMP] SNMP trap message with wrong peer status
by Simon Jones 15 Aug '19

15 Aug '19

Hi all, I'm working on sonic-frr, which is just frr. I enable frr-snmp, and follow this (http://docs.frrouting.org/en/latest/snmp.html) to get trap, this is my configuration: > root@NX-ZWYC-M1F202-A16-HW6865-A-INT-212:/# cat /etc/snmp/snmptrapd.conf > # > # EXAMPLE-trap.conf: > # An example configuration file for configuring the Net-SNMP snmptrapd > agent. > # > > ############################################################################### > # > # This file is intended to only be an example. > # When the snmptrapd agent starts up, this is where it will look for it. > # > # All lines beginning with a '#' are comments and are intended for you > # to read. All other lines are configuration commands for the agent. > disableAuthorization yes > # > # PLEASE: read the snmptrapd.conf(5) manual page as well! > # > #authCommunity log,execute,net private > #authCommunity log,execute,net public > #authCommunity log,execute,net snmp@sankuai > # > traphandle .1.3.6.1.2.1.15.0.1 ./bgp-peer-status > traphandle .1.3.6.1.2.1.15.0.2 ./bgp-peer-status > root@NX-ZWYC-M1F202-A16-HW6865-A-INT-212:/# cat ./bgp-peer-status > #!/bin/bash > echo `cat -` Then I up/down bgp peer use these command: > NX-ZWYC-M1F202-A16-HW6865-A-INT-212(config-router)# router bgp 65003 > NX-ZWYC-M1F202-A16-HW6865-A-INT-212(config-router)# neighbor 192.168.10.9 > shutdown > NX-ZWYC-M1F202-A16-HW6865-A-INT-212(config-router)# no neighbor > 192.168.10.9 shutdown This is trap message I got, I got 2 messages, you could see, the 2 message is the same, especially in bgp peer status, I guess this is a BUG ? > root@NX-ZWYC-M1F202-A16-HW6865-A-INT-212:/etc/snmp# /usr/sbin/snmptrapd > -f -Lo4d > NET-SNMP version 5.7.3 > 2019-08-15 09:42:15 172.18.8.212(via UDP: > [127.0.0.1]:34916->[127.0.0.1]:162) TRAP, SNMP v1, community public > iso.3.6.1.2.1.15 Enterprise Specific Trap (1) Uptime: 23:59:58.54 > iso.3.6.1.2.1.15.3.1.14.192.168.10.9 = Hex-STRING: 06 02 > iso.3.6.1.2.1.15.3.1.2.192.168.10.9 = INTEGER: 6 # This is first BGP peer > status, which is Establish > localhost > UDP: [127.0.0.1]:34916->[127.0.0.1]:162 > iso.3.6.1.2.1.1.3.0 0:23:59:58.54 > iso.3.6.1.6.3.1.1.4.1.0 iso.3.6.1.2.1.15.0.1 > iso.3.6.1.2.1.15.3.1.14.192.168.10.9 "06 02 " > iso.3.6.1.2.1.15.3.1.2.192.168.10.9 6 > iso.3.6.1.6.3.18.1.3.0 172.18.8.212 > iso.3.6.1.6.3.18.1.4.0 "public" > iso.3.6.1.6.3.1.1.4.3.0 iso.3.6.1.2.1.15 > > 2019-08-15 09:42:22 172.18.8.212(via UDP: > [127.0.0.1]:34916->[127.0.0.1]:162) TRAP, SNMP v1, community public > iso.3.6.1.2.1.15 Enterprise Specific Trap (2) Uptime: 1 day, 0:00:05.65 > iso.3.6.1.2.1.15.3.1.14.192.168.10.9 = Hex-STRING: 06 02 > iso.3.6.1.2.1.15.3.1.2.192.168.10.9 = INTEGER: 6 # This is second BGP peer > status, which is also Establish > localhost > UDP: [127.0.0.1]:34916->[127.0.0.1]:162 > iso.3.6.1.2.1.1.3.0 1:0:00:05.65 > iso.3.6.1.6.3.1.1.4.1.0 iso.3.6.1.2.1.15.0.2 > iso.3.6.1.2.1.15.3.1.14.192.168.10.9 "06 02 " > iso.3.6.1.2.1.15.3.1.2.192.168.10.9 6 > iso.3.6.1.6.3.18.1.3.0 172.18.8.212 > iso.3.6.1.6.3.18.1.4.0 "public" > iso.3.6.1.6.3.1.1.4.3.0 iso.3.6.1.2.1.15 ---- Simon Jones

1 0

What's this 'interface' mean in 'neighbor' configure node ?
by Simon Jones 09 Aug '19

09 Aug '19

Hi all, I found this is new in FRR compared to QUAGGA, what's this used for ? Why I should config interface first ? Is there some DOC about this ? # neighbor 1.1.1.1/24 > ... > interface Enable BGP on interface # neighbor 1.1.1.1/24 remote-as 5001 > % Create the peer-group or interface first or specify "interface" keyword > % if using an unnumbered interface neighbor ---- Simon Jones

3 2

terminal paginate
by mike tancsa 07 Aug '19

07 Aug '19

After years of not using vtysh (habit), we are switching to use it for frr6. However, one thing I cant seem to figure out is how to make terminal paginate the default ? On FreeBSD, I have the environment var set setenv VTYSH_PAGER '/usr/bin/less -EFX' but when I connect, I always have to issue terminal paginate and then it works from there. Is there a way to make this the default ? ---Mike

2 6

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