- frog - lists.frrouting.org

No NSSA areas on OSPFv3?
by Rodolfo Broco Manin 30 Jan '19

30 Jan '19

Hi there! Please excuse me if this is a silly question, but... Is it me or FRR does not support NSSA areas on OSPFv3 (via ospf6d)? Thank you! -- Rodolfo

1 0

Access to slack workspace
by Denys Myrhorodskyi 29 Jan '19

29 Jan '19

Hello, can you provide access to FRR workspace?

1 0

New Releases of FRR
by Donald Sharp 24 Jan '19

24 Jan '19

All - On Monday a research group installed into the global BGP routing table a prefix with a attribute type of 0xFF, which is designated as experimental by BGP RFC's. FRR had a developmental escape that read this attribute incorrectly and caused the bgp peering session to flap. If you have compiled FRR with the `--enable-bgp-vnc` option and run BGP as a peer on the global routing table you are vulnerable to this issue. This issue has been fixed in FRR with this commit: https://github.com/FRRouting/frr/commit/943d595a018e69b550db08cccba1d0778a8… We have applied this fix to the stable/3.0(3.0.4), stable/4.0(4.0.1), stable/5.0(5.0.2) and stable/6.0(6.0.2) branches. New releases can be found here: https://github.com/FRRouting/frr/releases/tag/frr-3.0.4 https://github.com/FRRouting/frr/releases/tag/frr-4.0.1 https://github.com/FRRouting/frr/releases/tag/frr-5.0.2 https://github.com/FRRouting/frr/releases/tag/frr-6.0.2 Snap packaging and the FreeBSD ports have been updated as well. We recommend you update your installation of FRR immediately. At this point we are applying for a CVE and will announce that information when we have it. In the near future we plan to implement RFC-7606 to handle this situation better in BGP, if you have any questions please feel free to email me, or to open up discussions on the frog alias. thanks! donald

6 11

[LDP] status Bad PDU Length (fatal error)
by Alessio Leonarduzzi 23 Jan '19

23 Jan '19

Hi all, I have a problem with MPLS and LDP neighbor between FRR 6.0.2. and Cisco IOS 12.2 advk9. the log FRR side is: [CUT] 2019/01/22 01:03:12 LDP: discovery[recv]: iface enp2s0f0 lsr-id 2.2.2.2 transport-address 2.2.2.2 holdtime 15 2019/01/22 01:03:12 LDP: discovery[send]: iface enp2s0f0 (ipv4) holdtime 180 2019/01/22 01:03:12 LDP: nbr_fsm: event CONNECTION UP resulted in action SETUP NEIGHBOR CONNECTION and changing state for lsr-id 2.2.2.2 from PRESENT to INITIALIZED 2019/01/22 01:03:12 LDP: msg[out]: initialization: lsr-id 2.2.2.2 2019/01/22 01:03:12 LDP: nbr_fsm: event INIT SENT resulted in action NOTHING and changing state for lsr-id 2.2.2.2 from INITIALIZED to OPENSENT 2019/01/22 01:03:12 LDP: discovery[recv]: iface enp2s0f0 lsr-id 2.2.2.2 transport-address 2.2.2.2 holdtime 15 2019/01/22 01:03:12 LDP: msg[in]: initialization: lsr-id 2.2.2.2 2019/01/22 01:03:12 LDP: recv_init: lsr-id 2.2.2.2 announced the Dynamic Capability Announcement capability 2019/01/22 01:03:12 LDP: recv_init: lsr-id 2.2.2.2 announced the Typed Wildcard FEC capability 2019/01/22 01:03:12 LDP: nbr_fsm: event INIT RECEIVED resulted in action SEND KEEPALIVE and changing state for lsr-id 2.2.2.2 from OPENSENT to OPENREC 2019/01/22 01:03:12 LDP: nbr_fsm: event KEEPALIVE RECEIVED resulted in action START NEIGHBOR SESSION and changing state for lsr-id 2.2.2.2 from OPENREC to OPERATIONAL ... 2019/01/22 01:03:12 LDP: msg[in]: label mapping: lsr-id 2.2.2.2, fec 1.1.1.1/32, label 250 2019/01/22 01:03:12 LDP: msg[in]: notification: lsr-id 2.2.2.2, status Bad PDU Length (fatal error) 2019/01/22 01:03:12 LDP: nbr_fsm: event SESSION CLOSE resulted in action CLOSE SESSION and changing state for lsr-id 2.2.2.2 from OPERATIONAL to PRESENT 2019/01/22 01:03:12 LDP: session_close: closing session with lsr-id 2.2.2.2 2019/01/22 01:03:12 LDP: zebra[out]: prefix 10.226.135.0/30 nexthop 10.224.1.21 ifindex 2 labels 497/166 (add) [/CUT] Cisco side: [CUT] Jan 22 00:51:51.049 CET: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (2) is UP Jan 22 00:51:51.053 CET: %LDP-4-PTCL: peer 1.1.1.1:0, bad PDU hdr Jan 22 00:51:51.053 CET: PDU HDR: Jan 22 00:51:51.053 CET: 0x00 0x01 0x0F 0xFE 0x5D 0xBD 0xBF 0xFC 0x00 0x00 0x00 0x00 Jan 22 00:51:51.053 CET: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (2) is DOWN (Received bad message) Jan 22 00:51:53.241 CET: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.12:0 (7) is UP Jan 22 00:51:53.245 CET: %LDP-4-PTCL: peer 1.1.1.1:0, bad PDU hdr Jan 22 00:51:53.245 CET: PDU HDR: Jan 22 00:51:53.245 CET: 0x00 0x01 0x0F 0xFE 0x5D 0xBD 0xBF 0xFC 0x00 0x00 0x00 0x00 Jan 22 00:51:53.245 CET: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (7) is DOWN (Received bad message) Jan 22 00:52:13.065 CET: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (2) is UP Jan 22 00:52:13.069 CET: %LDP-4-PTCL: peer 1.1.1.1:0, bad PDU hdr Jan 22 00:52:13.069 CET: PDU HDR: Jan 22 00:52:13.069 CET: 0x00 0x01 0x0F 0xFE 0x5D 0xBD 0xBF 0xFC 0x00 0x00 0x00 0x00 Jan 22 00:52:13.069 CET: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (2) is DOWN (Received bad message) Jan 22 00:52:15.953 CET: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (7) is UP Jan 22 00:52:15.957 CET: %LDP-4-PTCL: peer 1.1.1.1:0, bad PDU hdr Jan 22 00:52:15.957 CET: PDU HDR: Jan 22 00:52:15.957 CET: 0x00 0x01 0x0F 0xFE 0x5D 0xBD 0xBF 0xFC 0x00 0x00 0x00 0x00 Jan 22 00:52:15.957 CET: %LDP-5-NBRCHG: LDP Neighbor 1.1.1.1:0 (7) is DOWN (Received bad message) [/CUT] FRR configuration: interface dummy0 ip address 1.1.1.1/32 ! interface enp2s0f0 description CORE-1 ip address 10.224.1.22/30 ip ospf network point-to-point ! interface enp2s0f1 description CORE-2 ip address 10.224.1.26/30 ip ospf network point-to-point ! mpls ldp router-id 1.1.1.1 dual-stack cisco-interop ! address-family ipv4 discovery hello holdtime 180 discovery hello interval 15 discovery transport-address 1.1.1.1 label local advertise explicit-null ! interface enp2s0f0 ! interface enp2s0f1 ! exit-address-family ! ! Cisco configuration: mpls traffic-eng tunnels mpls ip default-route mpls label protocol ldp interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface TenGigabitEthernet1/1 description ASBR-FRR-TEST mtu 1600 ip address 10.224.1.21 255.255.255.252 ip ospf network point-to-point mpls traffic-eng tunnels mpls ip ! The OSPF is up and Loopback are in both routing tables. I try with/with-out "mpls traffic-eng tunnels" with same result. Timers/MTU are corrects. The result is that the devices don't share the labels becouse neighbors are down This is a bug? or wrong configuration? regards Alessio

3 7

Re: [FROG] Difference between releases
by Martin Winter 21 Jan '19

21 Jan '19

On 19 Jan 2019, at 8:50, Antoine Joubert via frog wrote: > 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 release and > the https://github.com/FRRouting/frr/releases/tag/debian%2Ffrr-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 ? In general, approximately no difference. The frr-6.0.2 is the current latest official FRR release. The Debian one is part of the work to get FRR into the debian distribution and should follow the official release. In practice however, debian maintainers and debian packages are frequently with some changes/patches in comparison to official releases on any package. In the case of FRR, we try to avoid any changes as far as possible, but as part of the testing and getting FRR into debian, there is a good chance for a few changes in the near term (which would then be integrated into further FRR releases whenever possible). Not sure if this explains it, but in general: - Use our official releases (which has packages on GitHub) until the FRR release is part of the debian packages. - Once we have them in there (you’ll hear an announcement), then we may stop providing debian packages ourself and you would get packages from the debian package archives. - Ignore the differences. If there would be anything important, then we would make a new version anyway. Hope this explains it somehow Regards, Martin Winter

2 1

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 10 Jan '19

10 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