January 2019 - frog - lists.frrouting.org

Difference between releases
by Antoine Joubert 19 Jan '19

19 Jan '19

Hi, Sorry if this has been asked before, but I was wondering, what is the difference between the https://github.com/FRRouting/frr/releases/tag/frr-6.0.2 <https://github.com/FRRouting/frr/releases/tag/frr-6.0.2> release and the https://github.com/FRRouting/frr/releases/tag/debian%2Ffrr-6.0.2-1 <https://github.com/FRRouting/frr/releases/tag/debian/frr-6.0.2-1> release ? The debian package provided for the first one seems to be the 6.0.2-0 version. Is the second one newer ? If so, why are there no package download available ? Thanks ! Antoine Joubert

1 0

LDP Cannot assign request address
by Alessio Leonarduzzi 18 Jan '19

18 Jan '19

Hi all, If I set loopback interface IP as discovery transport-address in MPLS configuration the DEBUG output is: [CUT] 2019/01/17 12:05:19 LDP: nbr_establish_connection: error while binding socket to 1.1.1.1: Cannot assign requested address 2019/01/17 12:05:23 LDP: nbr_establish_connection: error while binding socket to 1.1.1.1: Cannot assign requested address 2019/01/17 12:05:27 LDP: nbr_establish_connection: error while binding socket to 1.1.1.1: Cannot assign requested address 2019/01/17 12:05:32 LDP: nbr_establish_connection: error while binding socket to 1.1.1.1: Cannot assign requested address 2019/01/17 12:05:36 LDP: nbr_establish_connection: error while binding socket to 1.1.1.1: Cannot assign requested address 2019/01/17 12:05:40 LDP: nbr_establish_connection: error while binding socket to 1.1.1.1: Cannot assign requested address [/CUT] but if I use the physical interface all works good. This is the configuration: vrf VRF-PUBLIC ! interface dummy0 vrf VRF-PUBLIC description Loopback0 ip address 1.1.1.1/32 ! interface enp2s0f0 vrf VRF-PUBLIC description P2P01 ip address 2.2.2.2/30 ip ospf network point-to-point ! interface enp2s0f2 vrf VRF-PUBLIC description P2P02 ip address 3.3.3.3/30 ip ospf network point-to-point ! mpls ldp router-id 1.1.1.1 dual-stack cisco-interop ! address-family ipv4 discovery transport-address 1.1.1.1 label local advertise explicit-null ! interface enp2s0f0 interface enp2s0f1 ! exit-address-family ! ! The FRR version is 6.0.2 and I need to use MPLS on two interfaces (enp2s0f0 and enp2s0f1). thank you for your help regards Alessio

3 4

Kernel Bug with address retrieval
by Donald Sharp 18 Jan '19

18 Jan '19

All - The 4.20 linux kernel has a bug with sending link addresses to user-space causing some of them not to be read. The tl;dr; is that after one skb of data sent up, the data is stopped from being sent. If you have a small number of addresses assigned to a box, then you will probably not notice a problem. At this time I would not recommend using linux kernel 4.20 for production network uses. The commit that fixes this is this: commit 7c1e8a3817c55d73b27cc29b84075999c8894179 Author: Arthur Gautier <baloo(a)gandi.net> Date: Mon Dec 31 02:10:58 2018 +0000 netlink: fixup regression in RTM_GETADDR It is my understanding that this was introduced in 4.19-next. This fix should be available in one of the upcoming 4.20.X releases as I understand it. thanks! donald

1 0

Version Tagged Docker Images?
by Kingsley Jarrett 18 Jan '19

18 Jan '19

Hi all, I'm looking at running FRR across a small Kubernetes cluster to assist with a few simple routing operations. In order to do so however, I would need to deploy a Docker-based image of FRR. I've found the official build of FRR on Docker Hub<https://hub.docker.com/r/frrouting/frr>, however it appears to only be a continuous release of the master branch of the repository. Although great for testing, it's a little impractical to run this for 'production' purposes since I'd just be running the latest commit rather than a specific stable version. Would it be possible for the FRR Docker image to have version tags applied (e.g. frrouting/frr:6.0.2)? Just as there are versioned builds for each platform on the GitHub releases page, and indeed the snap, it would be very useful if the same was available for FRR's Docker image. Many thanks, K Jarrett

2 1

Re: [FROG] Advisory - FRR BGP peer flaps @ 2019-01-07
by Töma Gavrichenkov 09 Jan '19

09 Jan '19

Hi, On 1/7/2019 1:31 PM, Quentin Young wrote: > This morning some users running FRR BGP noticed that their sessions were > flapping. [..] > We have a patch in testing now and expect to have new build artifacts published > shortly. Additionally, we have contacted the experiment operators and requested > a pause in the experiment while we handle this issue. A flapping BGP session may possibly affect availability of an autonomous system, and, as long as CIA triad is concerned, availability is a part of security. Has this been assigned a CVE number so that OS distributions as well as information security departments of possibly affected network entities would be aware of this properly and would act accordingly? | Töma Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera(a)gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58

2 1

Advisory - FRR BGP peer flaps @ 2019-01-07
by Quentin Young 09 Jan '19

09 Jan '19

Hello operators, This morning some users running FRR BGP noticed that their sessions were flapping. Investigation revealed that this was caused by an experiment being run by SwiNOG [0] which was triggering an undesired code path in FRR. Specifically, FRR uses attribute type 0xFF as the attribute code for VNC [1]. This code was intended to be turned off by default, but our current published builds [2] have it turned on. Consequently, bgpd attempts to parse the received attribute as a VNC attribute and fails, triggering a session reset. We have a patch in testing now and expect to have new build artifacts published shortly. Additionally, we have contacted the experiment operators and requested a pause in the experiment while we handle this issue. Thank you to the operators that notified us this morning! - FRR maintainer team [0] http://lists.swinog.ch/public/swinog/2018-December/007110.html [1] http://docs.frrouting.org/en/latest/vnc.html [2] https://github.com/FRRouting/frr/releases

5 6

vty[??]@> echo PING
by Alessio Leonarduzzi 08 Jan '19

08 Jan '19

Hi all, in a new installation of frr 6 on ubuntu 18.04 I have in /var/log/frr/frr.log a lot of "vty[??]@> echo PING" (every second....) how can I disable this log? [CUT] Jan 4 16:38:54 FRR zebra[1258]: vty[??]@> echo PING Jan 4 16:38:56 FRR ldpd[1312]: vty[??]@> echo PING Jan 4 16:38:58 FRR bgpd[1271]: vty[??]@> echo PING Jan 4 16:38:58 FRR ospfd[1297]: vty[??]@> echo PING Jan 4 16:38:59 FRR zebra[1258]: vty[??]@> echo PING Jan 4 16:39:01 FRR ldpd[1312]: vty[??]@> echo PING Jan 4 16:39:03 FFR bgpd[1271]: vty[??]@> echo PING Jan 4 16:39:03 FRR ospfd[1297]: vty[??]@> echo PING Jan 4 16:39:04 FRR zebra[1258]: vty[??]@> echo PING Jan 4 16:39:06 FRR ldpd[1312]: vty[??]@> echo PING Jan 4 16:39:08 FRR bgpd[1271]: vty[??]@> echo PING Jan 4 16:39:08 FRR ospfd[1297]: vty[??]@> echo PING Jan 4 16:39:09 FRR zebra[1258]: vty[??]@> echo PING [/CUT] thank you Alessio

3 3

Tunnel Encap attribute sub-tlv length 48582, exceeds remaining length 28
by Mike Tancsa 07 Jan '19

07 Jan '19

A couple of my peers started flapping for some reason this morning with the error messages Jan 7 09:48:39 bgpd[19828]: Tunnel Encap attribute sub-tlv length 48582 exceeds remaining length 28 Jan 7 09:48:39 bgpd[19828]: %NOTIFICATION: sent to neighbor xx.yy.zz.205 3/9 (UPDATE Message Error/Optional Attribute Error) 35 bytes e0 ff 20 ac d9 bd c6 ec 73 13 8f f0 6d ed c7 52 11 5a 91 3c 0e 8b 8c 1e be aa f2 72 d5 83 92 83 5e 5b 57 Jan 7 09:48:39 bgpd[19828]: xx.yy.zz.205: Attribute VNC, parse error Jan 7 09:48:39 bgpd[19828]: %ADJCHANGE: neighbor xx.yy.zz.205(Unknown) in vrf Default Down BGP Notification send I was running frr 3.0.3 on FreeBSD RELENG11. Any idea what this bug is or problematic advertisement ? I started a pcap of the bgp sessions, but havent found anything obvious yet -- ------------------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, mike(a)sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada

3 2

Question regarding IETF draft "Well-Known Community Policy Behavior"
by Christoffer Hansen 07 Jan '19

07 Jan '19

@FROG, <<Disclaimer: maybe this question if best answered by the devs...(?)>> Was reading the IETF draft "Well-Known Community Policy Behavior" [0]. And was wondering if FRR does any special treatment for well-known communities?* Maybe the behaviour of FRR could be included in future revisions of the draft[0] ? *) thinking if FRR does similair behaviour to ios-xr (partial special treament), or junos (no special treatment). (refer to section 4 [0]) [0]: https://datatracker.ietf.org/doc/draft-ietf-grow-wkc-behavior/ -- Cheers Christoffer

1 0

Tunnel Encap attribute sub-tlv length 48582 exceeds remaining length 28
by Mike Tancsa 07 Jan '19

07 Jan '19

A couple of my peers started flapping for some reason this morning with the error messages Jan 7 09:48:39 bgpd[19828]: Tunnel Encap attribute sub-tlv length 48582 exceeds remaining length 28 Jan 7 09:48:39 bgpd[19828]: %NOTIFICATION: sent to neighbor xx.yy.zz.205 3/9 (UPDATE Message Error/Optional Attribute Error) 35 bytes e0 ff 20 ac d9 bd c6 ec 73 13 8f f0 6d ed c7 52 11 5a 91 3c 0e 8b 8c 1e be aa f2 72 d5 83 92 83 5e 5b 57 Jan 7 09:48:39 bgpd[19828]: xx.yy.zz.205: Attribute VNC, parse error Jan 7 09:48:39 bgpd[19828]: %ADJCHANGE: neighbor xx.yy.zz.205(Unknown) in vrf Default Down BGP Notification send I was running frr 3.0.3 on FreeBSD RELENG11. Any idea what this bug is or problematic advertisement ? I started a pcap of the bgp sessions, but havent found anything obvious yet -- ------------------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, mike(a)sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada

1 0