February 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

FRR on NRL CORE (fyi)
by Phil Wiggins 10 Apr '19

10 Apr '19

If anyone is interested in running FRR in the NRL CORE emulation environment, I have some build scripts for FRR on CORE that I posted at the first link below. Normally CORE runs Quagga, so this script was a hack to shoehorn FRR as a Quagga replacement. These scripts are not part of CORE yet, so are unsupported. People on this list may want to use CORE for FRR experimentation and testing, so you can customize these scripts to suit your own needs. It's best to run this stuff in a VM with no internet connection (after installation) since CORE runs lots of processes as root - a well-known security issue. https://github.com/coreemu/core/issues/170 ( install_frr_for_core.sh) FRR on NRL CORE build script - assumes Ubuntu 16.04.4 clean installation in a VM or physical host: https://gist.github.com/apwiggins/44f3592a61965783372aea5881ed9f7a (core_misc_frr.py ) used by the install script above to install at ./core/misc/frr.py https://gist.github.com/apwiggins/d610c2794c8c0a12a45bfc093fd2e949 (core_services_frr.py) used by the install script above to install at ./core/services/frr.py https://gist.github.com/apwiggins/747a9a14feff2ce3a3b8760406b825a7 https://www.nrl.navy.mil/itd/ncs/products/core The Common Open Research Emulator (CORE) is a tool for emulating networks on one or more machines. You can connect these emulated networks to live networks. CORE consists of a GUI for drawing topologies of lightweight virtual machines, and Python modules for scripting network emulation. Cheers, Phil

2 3

FRR 6.0.2 lost routes after Ubuntu 18.04.2 LTS update/upgrade
by Sim 05 Apr '19

05 Apr '19

After apt-get upgrade / upgrade FRR lost all routes. Reboot or restart the server is the solution to resolve the issue. I'm new with FRR, but this is not happened with Quagga in the last 10/15 years. Is it a "FRR issue" or about Ubuntu 18.04 LTS version? # apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: libnss-systemd libpam-systemd libpci3 libsystemd0 libudev1 pciutils systemd systemd-sysv udev 9 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 4,765 kB of archives. After this operation, 56.3 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libnss-systemd amd64 237-3ubuntu10.13 [105 kB] Get:2 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libsystemd0 amd64 237-3ubuntu10.13 [205 kB] Get:3 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libpam-systemd amd64 237-3ubuntu10.13 [108 kB] Get:4 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 systemd amd64 237-3ubuntu10.13 [2,899 kB] Get:5 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 udev amd64 237-3ubuntu10.13 [1,101 kB] Get:6 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libudev1 amd64 237-3ubuntu10.13 [54.1 kB] Get:7 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 systemd-sysv amd64 237-3ubuntu10.13 [12.0 kB] Get:8 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 pciutils amd64 1:3.5.2-1ubuntu1.1 [257 kB] Get:9 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libpci3 amd64 1:3.5.2-1ubuntu1.1 [24.1 kB] Fetched 4,765 kB in 8s (575 kB/s) (Reading database ... 67479 files and directories currently installed.) Preparing to unpack .../libnss-systemd_237-3ubuntu10.13_amd64.deb ... Unpacking libnss-systemd:amd64 (237-3ubuntu10.13) over (237-3ubuntu10.12) ... Preparing to unpack .../libsystemd0_237-3ubuntu10.13_amd64.deb ... Unpacking libsystemd0:amd64 (237-3ubuntu10.13) over (237-3ubuntu10.12) ... Setting up libsystemd0:amd64 (237-3ubuntu10.13) ... (Reading database ... 67479 files and directories currently installed.) Preparing to unpack .../libpam-systemd_237-3ubuntu10.13_amd64.deb ... Unpacking libpam-systemd:amd64 (237-3ubuntu10.13) over (237-3ubuntu10.12) ... Preparing to unpack .../systemd_237-3ubuntu10.13_amd64.deb ... Unpacking systemd (237-3ubuntu10.13) over (237-3ubuntu10.12) ... Preparing to unpack .../udev_237-3ubuntu10.13_amd64.deb ... Unpacking udev (237-3ubuntu10.13) over (237-3ubuntu10.12) ... Preparing to unpack .../libudev1_237-3ubuntu10.13_amd64.deb ... Unpacking libudev1:amd64 (237-3ubuntu10.13) over (237-3ubuntu10.12) ... Setting up libudev1:amd64 (237-3ubuntu10.13) ... Setting up systemd (237-3ubuntu10.13) ... (Reading database ... 67479 files and directories currently installed.) Preparing to unpack .../systemd-sysv_237-3ubuntu10.13_amd64.deb ... Unpacking systemd-sysv (237-3ubuntu10.13) over (237-3ubuntu10.12) ... Preparing to unpack .../pciutils_1%3a3.5.2-1ubuntu1.1_amd64.deb ... Unpacking pciutils (1:3.5.2-1ubuntu1.1) over (1:3.5.2-1ubuntu1) ... Preparing to unpack .../libpci3_1%3a3.5.2-1ubuntu1.1_amd64.deb ... Unpacking libpci3:amd64 (1:3.5.2-1ubuntu1.1) over (1:3.5.2-1ubuntu1) ... Setting up libnss-systemd:amd64 (237-3ubuntu10.13) ... Processing triggers for ureadahead (0.100.0-20) ... Setting up systemd-sysv (237-3ubuntu10.13) ... Processing triggers for libc-bin (2.27-3ubuntu1) ... Setting up udev (237-3ubuntu10.13) ... update-initramfs: deferring update (trigger activated) Processing triggers for man-db (2.8.3-2ubuntu0.1) ... Processing triggers for dbus (1.12.2-1ubuntu1) ... Setting up libpci3:amd64 (1:3.5.2-1ubuntu1.1) ... Setting up libpam-systemd:amd64 (237-3ubuntu10.13) ... Setting up pciutils (1:3.5.2-1ubuntu1.1) ... Processing triggers for initramfs-tools (0.130ubuntu3.6) ... update-initramfs: Generating /boot/initrd.img-4.15.0-45-generic Processing triggers for libc-bin (2.27-3ubuntu1) ... # apt-get upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. # ps fax PID TTY STAT TIME COMMAND 955 ? S<s 0:45 /usr/lib/frr/watchfrr -d -r /usr/lib/frr/watchfrr.sh restart %s -s /usr/lib/frr/watchfrr.sh start %s -k /usr/lib/frr/watchfrr.sh stop %s zebra bgpd staticd 1006 ? S<sl 3:59 /usr/lib/frr/zebra -d -A 127.0.0.1 -s 90000000 1009 ? S<sl 7:22 /usr/lib/frr/bgpd -d -A 127.0.0.1 1016 ? S<s 0:05 /usr/lib/frr/staticd -d -A 127.0.0.1 # vtysh Hello, this is FRRouting (version 6.0.2). Copyright 1996-2005 Kunihiro Ishiguro, et al. xxx# sh ip bgp summary IPv4 Unicast Summary: BGP router identifier x.x.32.34, local AS number xxxxxx vrf-id 0 BGP table version 6693928 RIB entries 6, using 960 bytes of memory Peers 2, using 41 KiB of memory Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd x.x.118.244 4 xxxx 915579 27779 0 0 0 00:03:45 Active x.x.32.33 4 xxxxxx 843680 352816 0 0 0 00:05:16 Active # ip add 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet x.x.32.34/32 scope global lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:50:56:ba:53:46 brd ff:ff:ff:ff:ff:ff inet x.x.32.29/28 brd x.x.32.31 scope global ens160 valid_lft forever preferred_lft forever inet6 fe80::250:56ff:feba:5346/64 scope link valid_lft forever preferred_lft forever 3: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:50:56:ba:af:9d brd ff:ff:ff:ff:ff:ff inet x.x.32.3/28 brd x.x.32.15 scope global ens192 valid_lft forever preferred_lft forever inet6 fe80::250:56ff:feba:af9d/64 scope link valid_lft forever preferred_lft forever # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface x.x.32.0 0.0.0.0 255.255.255.240 U 0 0 0 ens192 x.x.32.16 0.0.0.0 255.255.255.240 U 0 0 0 ens160 Regards Sim

4 10

frr 5.0.2, remove-private-AS and ebgp multihop
by Chris Malton 28 Feb '19

28 Feb '19

Hi all, Weird one here: In my config I have an eBGP Multihop peer, and for some reason, despite the config looking like this: router bgp 65001 neighbor w.x.y.z remote-as nnnnn neighbor w.x.y.z local-as 205804 neighbor w.x.y.z description Upstream - Peering Router - b neighbor w.x.y.z ebgp-multihop 2 neighbor w.x.y.z disable-connected-check neighbor w.x.y.z update-source 81.187.56.158 address-family ipv4 unicast neighbor w.x.y.z remove-private-AS all replace-AS nnnnn is the correct peer ASN. The resulting PCAP in wireshark shows: Path Attribute - AS_PATH: 205804 65001 Flags: 0x50, Transitive, Extended-Length, Well-known, Complete Type Code: AS_PATH (2) Length: 10 AS Path segment: 205804 65001 Segment type: AS_SEQUENCE (2) Segment length (number of ASN): 2 AS4: 205804 AS4: 65001 I am convinced I have done something wrong, as I expected FRR to strip 65001 from the sequence. I'm running frr 5.0.2 on a pfSense (so alas, upgrading to 6 isn't an option at the moment). Any hints what I've done wrong - or is this a known bug? Regards, Chris Malton -- Delta V Technologies Limited 03333 402 402 www.deltav-tech.co.uk Office: 17 Elm Close, Southampton, SO16 7DT Company No. 11006104 Registered in England and Wales

2 2

RFC 4364 configuration example
by Mark Tees 26 Feb '19

26 Feb '19

Hi there, Does anyone have a full MPLS layer 3 VPN example I can test out? Also, which version I should try with. I have tried with FRR 6.0 and can see routes under the VRF like below: ord-b457489f5df65f1f# show bgp vrf vrf2 ipv4 </snip> Network Next Hop Metric LocPrf Weight Path *> 5.5.5.1/32 0.0.0.0 0 32768 ? *> 10.13.12.0/30 0.0.0.0 0 32768 ? However I can't see them in the main vpn table or sent to vpn peers. ord-b457489f5df65f1f# show bgp ipv4 vpn No BGP prefixes displayed, 0 exist Have tried with rt/rd/label config under vrf-policy in 'router bgp xxxx' and also under 'router xxxx vrf vrf2'. redistribute connected redistribute static label vpn export 34712 rd vpn export 10.12.12.1:100 nexthop vpn export 10.12.12.1 rt vpn both 45437:100 I followed the Linux VRF instructions for setting up VRF and that appears ok. Any ideas are welcome. Cheers, Mark

2 2

BABEL Problem on DEBIAN9 FRR
by akÿfffffdn ak 25 Feb '19

25 Feb '19

In the same LAB App I applied BABEL configuration on 4 FRR Node. When I ping to other end of the network. But packets cannot sent to destination.When I delete and then add default route of DEBIAN after that ping become successful.I have to do this frequently. (When ping unsuccessful FRR learn destination address from BABEL after adding the default route ping successful) Why could it be. > I installed FRR on debian 9 on 4 VM. > I have 4 node FRR. > All of them have eigrp configuration. > When I start ping test to 2 hop away FRR Router. > Ping test successful. > But when I shutdown the interface of 2 hop away FRR Router. > Ping packets drop down. > With no shut comand in destination interface. > Ping successful again. > But sometimes eigrpd daemon kill itself on FRR and I can not pinging again. > I have to restart frr service on VM. > But normally it should not work like that. > Why this happen it in this scenario. > I have to deliver packets to destination continuously. Inan

1 0

ospf6d LSA's disappearing, probably stuck MaxAge LSA
by Leon Meßner 24 Feb '19

24 Feb '19

Hi, we recently moved two OSPFv3 routers from quagga 0.99.23 to frr-6.0.2 and are now having two (perhaps unrelated) issues. Issue one is that link-states from one FRR (R1) do only appear very briefly in the databases of other routers. This issue is the pressing one. The other issue is that E1 routes from some routers stay in the ospf6d route table although they have been flushed from the area already. What i observe about issue one: Every LSRefreshTime, when restarting R1 or when "clear ipv6 ospf6 interface INTERFACE" is run, i see R1's LSA's appear very briefly in neighbors databases. I also see routes related to R1 appear in the ospf6d table. After a few seconds these disappear again. Looking at R1's "show ipv6 ospf6 database self-originated" everything is there all the time. What i see in debugging on some other Router (R2): OSPF6: LSUpdate received on bond0.84 OSPF6: src: fe80::3efd:feff:fea2:145a <-R1 OSPF6: dst: ff02::5 OSPF6: OSPFv3 Type:4 Len:108 Router-ID:192.109.82.2 <-R1 OSPF6: Area-ID:0.0.0.0 Cksum:452b Instance-ID:0 OSPF6: Number of LSA: 1 OSPF6: [Router Id:0.0.0.0 Adv:192.109.82.2] OSPF6: Age: 1 SeqNum: 0x800002b4 Cksum: 2e43 Len: 88 OSPF6: ospf6_install_lsa Install LSA: [Router Id:0.0.0.0 Adv:192.109.82.2] age 1 seqnum 800002b4 in LSDB. ... flooding of that LSA ... OSPF6: LSUpdate received on tun0 OSPF6: src: fe80::f101:2 OSPF6: dst: fe80::f101:1 OSPF6: OSPFv3 Type:4 Len:108 Router-ID:192.109.82.24 OSPF6: Area-ID:0.0.0.0 Cksum:7bab Instance-ID:0 OSPF6: Number of LSA: 1 OSPF6: [Router Id:0.0.0.0 Adv:192.109.82.2] OSPF6: Age: 3600 SeqNum: 0x8000040c Cksum: 580c Len: 88 OSPF6: ospf6_install_lsa Install LSA: [Router Id:0.0.0.0 Adv:192.109.82.2] age 268139 3600 seqnum 8000040c in LSDB. OSPF6: LSA disappearing: [Router Id:0.0.0.0 Adv:192.109.82.2] OSPF6: Schedule SPF Calculation for 0.0.0.0 OSPF6: SPF: Scheduled in 0 msec OSPF6: LSA disappearing: [Router Id:0.0.0.0 Adv:192.109.82.2] ... flooding of that LSA ... So there is a MaxAge LSA that has a "higher" SequenceNumber. Probably from a prior boot. Should FRR on R1 raise its SequenceNumber for this LSA to 0x8000040d? Is this likely a problem on R1? I also noticed, that LSAcks for MaxAge LSAs are multicast to either ff02::6 or ff02::5 depending on DR status. Is this correct bahavior, or should they be unicast? I tried to reproduce issue one via FRRouting/topotests, but haven't succeeded until now. Probably because i didn't manage to get a stuck MaxAge LSA in my test instance. Any help would be really appreciated. If more information is needed, i'm happy to supply more logging and help with debugging. Regards, Leon

1 1

Frr init script 'reload' option
by Ron Hermsen 24 Feb '19

24 Feb '19

I'm using FRR 5.0.2 with Tinycorelinux (TCL-10.0) with the frr init script [1]. I have a question regarding the the 'reload' option. The usage message give its use as "reload applies only modifications from the running config to all daemons." not sure what to expect from this option. >From its behaviour I get it is a rollback from running config to startup config without a restart of the daemons. Is my understanding correct? [1] https://raw.githubusercontent.com/FRRouting/frr/frr-5.0.2/tools/frr

2 1

Hardware Requirements
by Steuer Heribert 23 Feb '19

23 Feb '19

Hello, for using FRR with VPP & underlying DPDK, is there any “working hardware” list which goes beyond “use Intel NICs”? I am aware of some white box lists provided by NOS vendors but was not able to find anything about native FRR. I´ve found some posts of cloudscale.ch where they mentioned appliances from a vendor named Lanner (which I never heard of before). Its not about advertising vendors but more kind of a “known-to-work-well” list. In addition it would be nice to chat on Slack, please invite 😊 Thanks, Heri

5 8

Re: [FROG] FRR eigrp daemon kill
by Donald Sharp 23 Feb '19

23 Feb '19

So EIGRP still needs some work to bring it up to a more acceptable level of performance. Having said that, I did fix a few EIGRP crashes on master a couple of weeks back that were directly related to interfaces going up/down. Please try latest master and see if this fixes the issues you are seeing. donald On Fri, Feb 22, 2019 at 3:17 AM akÿfffffdn ak via frog <frog(a)lists.frrouting.org> wrote: > > > > > ---------- Forwarded message ---------- > From: "akÿfffffdn ak" <akinengineer(a)yahoo.com> > To: "frog(a)lists.frrouting.org" <frog(a)lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 22 Feb 2019 08:16:07 +0000 (UTC) > Subject: FRR eigrp daemon kill > I installed FRR on debian 9 on 4 VM. > I have 4 node FRR. > All of them have eigrp configuration. > When I start ping test to 2 hop away FRR Router. > Ping test successful. > But when I shutdown the interface of 2 hop away FRR Router. > Ping packets drop down. > With no shut comand in destination interface. > Ping successful again. > But sometimes eigrpd daemon kill itself on FRR and I can not pinging again. > I have to restart frr service on VM. > But normally it should not work like that. > Why this happen it in this scenario. > I have to deliver packets to destination continuously. > Please help! > > > > ---------- Forwarded message ---------- > From: "akÿfffffdn ak via frog" <frog(a)lists.frrouting.org> > To: "frog(a)lists.frrouting.org" <frog(a)lists.frrouting.org> > Cc: > Bcc: > Date: Fri, 22 Feb 2019 00:17:16 -0800 (PST) > Subject: [FROG] FRR eigrp daemon kill > _______________________________________________ > frog mailing list > frog(a)lists.frrouting.org > https://lists.frrouting.org/listinfo/frog

1 0

Using FRR in a product.
by Amod Mishra 22 Feb '19

22 Feb '19

Hello, I am evaluating if i would be able to productize FRR on a clusters of VM. Appreciate if can be provided with some pointers on how to complile FRR libs and make use of these libs. Regards Amod.

3 4

FRR eigrp daemon kill
by akÿfffffdn ak 22 Feb '19

22 Feb '19

I installed FRR on debian 9 on 4 VM. I have 4 node FRR. All of them have eigrp configuration.When I start ping test to 2 hop away FRR Router. Ping test successful.But when I shutdown the interface of 2 hop away FRR Router.Ping packets drop down.With no shut comand in destination interface.Ping successful again. But sometimes eigrpd daemon kill itself on FRR and I can not pinging again. I have to restart frr service on VM. But normally it should not work like that. Why this happen it in this scenario.I have to deliver packets to destination continuously.Please help!

1 0

Re: [FROG] FRR Installation on Debian9
by Tim Bray 21 Feb '19

21 Feb '19

On 21/02/2019 12:33, akÿfffffdn ak via frog wrote: > I have a problem for instaling FRR on Debian 9 that installed on VM. I > need to install FRR installation steps on Debian9 What are you doing at the moment? https://github.com/FRRouting/frr/releases/download/frr-6.0.2/frr_6.0.2-0.de… download and dpkg -i should work **** Your other option is to install or upgrde to debian 10 (buster), because this includes an frr package. Either re-install. Or add buster lines in /etc/apt/sources.list Then: # apt install frr Info here, https://packages.debian.org/buster/frr I'm not sure using debian 10 would be great for production, no security support. But would be an easy way to test. -- Tim Bray Technology Director, ProVu Communications Ltd, Huddersfield, UK. http://www.provu.co.uk/ Phone: +44 1484 840048 IP Telephones, Drop shipping, pre-configuration, XML orders ***** If it is important, just phone *****

1 0

FRR Installation on Debian9
by akÿfffffdn ak 21 Feb '19

21 Feb '19

I have a problem for instaling FRR on Debian 9 that installed on VM. I need to install FRR installation steps on Debian9.

1 0

interface shutdown question
by Oguzhan Kayhan 18 Feb '19

18 Feb '19

Hello I created two virtual servers with FRR 6.0.2 installed on it.. Both has 3 interfaces 1st interafce is wan interafce 2nd and third interfaces are for test of eigrp.. 1st server has this config interface eth1 ip address 192.168.100.1/24 ! router eigrp 100 network 192.168.100.0/24 network 192.168.200.0/24 redistribute kernel redistribute connected 2nd server has; interface eth1 ip address 192.168.100.2/24 ! interface eth3 ip address 192.168.200.2/24 shutdown ! router eigrp 100 network 192.168.100.0/24 network 192.168.200.0/24 redistribute kernel redistribute connected ! I can see the 192.168.200.0/24 routing on server1 via eigrp.. which is nice.. The problem is, if i shutdown the interface 2 on server2.. nothing happens.. centos1# conf t centos1(config)# interface eth3 centos1(config-if)# shutdown centos1(config-if)# end and on sh run i have; interface eth3 ip address 192.168.200.2/24 shutdown but i can still ping this intrface from server1. and on server2 ip addr output as follows; 6: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether 62:9c:df:28:36:4a brd ff:ff:ff:ff:ff:ff inet 192.168.200.2/24 brd 192.168.200.255 scope global eth3 valid_lft forever preferred_lft forever It is really strange. It seems shutdown command does not work.

1 0

OSPF Interface Poll Interval
by Amol Lad 12 Feb '19

12 Feb '19

Hi, RFC4750 defines "ospfIfPollInterval" as "The larger time interval, in seconds, between the Hello packets sent to an inactive non-broadcast multi-access neighbor." Does FRR supports this? If yes, then please advise how to configure it? 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).

1 0

FRRouting (6.0.2) now available in Debian buster/testing
by David Lamparter 11 Feb '19

11 Feb '19

Hi all, I'm pleased to announce FRRouting 6.0.2(-2) is now available in Debian testing (buster)! Please note that if you have an earlier version installed (e.g. from CI auto-packages), you will be auto-updated to 6.0.2 unless you mark the package for hold. It may be necessary to do this as the official Debian packages have been considerably cleaned up and reworked compared to 6.0 and older; there are some visible changes particularly in init scripts and startup behaviour. (These changes were merged in 6.0.1. If you already are at that or newer, the update should be smooth sailing.) Ubuntu has also auto-copied the package to their 19.04 / disco branch. This means that unless something unexpected happens, FRRouting will be available in the following upcoming distribution releases: - Debian 10 / buster (expected to become "stable" in 2~3 months) - Ubuntu 19.04 (expected to release end of April) If you have installed pre-release versions of either of these distributions, installing FRRouting is now a matter of doing a plain "apt install frr". FRRouting will very likely remain at the 6.0.x release train for both of these distributions. If you want to receive updates to newer major versions, manual intervention will still be needed (there might be a PPA/repo at some point.) Cheers, -David

3 3

Need help with bootstrap.sh
by muhammed ibrahim 03 Feb '19

03 Feb '19

Hello I am trying to configure FRR on CentOS 7 and I cloned the source code from github. The next step was to run ./bootstrap.sh but I can't seem to run the script. Whenever I run the script an error listed below shows up. ./bootstrap.sh: line 7: autoreconf: command not found What do I need to do? Here is the instruction below http://docs.frrouting.org/en/latest/installation.html#configuration FRR has an excellent configure script which automatically detects most host configurations. There are several additional configure options to customize the build to include or exclude specific features and dependencies. First, update the build system. Change into your FRR source directory and issue: ./bootstap.sh This will install any missing build scripts and update the Autotools configuration. Once this is done you can move on to choosing your configuration options from the list below. PS: I have also posted this on stackover flow but I haven't gotten a response yet. Sincerely, *Muhammed Ibrahim * *muhe31(a)gmail.com* <muhe31(a)gmail.com>

3 2

Daemons start error
by Amol Lad 01 Feb '19

01 Feb '19

Hi, First thanks to Tobias Jungel. With his help in providing Yocto recipe for FRR, I'm now running FRR on Solidrun's Clearfog platform. I'm running release 5.0.1 and get below error at startup. However, daemons do run even after the error. It seems I need to enable some more kernel config options. Please advise. root@clearfog:~# /usr/lib/frr/frr start Loading capability module if not yet done. Starting Frr daemons (prio:10):.1024 zebra2019/01/19 07:09:55 errors: ZEBRA: NS initialization failure 2(No such file or directory) 2019/01/19 07:09:56 warnings: ZEBRA: Disabling MPLS support (no kernel support) .1024 ospfd2019/01/19 07:09:56 errors: OSPF: NS initialization failure 2(No such file or directory) . Starting Frr monitor daemon:1024 watchfrr. Exiting from the script root@clearfog:~# ps 1410 frr 8308 S /usr/lib/frr/zebra --daemon -A 127.0.0.1 1417 frr 8916 S /usr/lib/frr/ospfd --daemon -A 127.0.0.1 1423 root 5628 S /usr/lib/frr/watchfrr -d -r /usr/sbin/servicebBfrrbBrestartbB%s -s /usr/sbin/servicebBfrrbBstartbB%s -k /usr/sbin/servicebBfrrbBstopbB%s -b bB zebra ospfd root@clearfog:~# ls -l /proc/self/ns/ lrwxrwxrwx 1 root root 0 Jan 19 07:11 cgroup -> cgroup:[4026531835] lrwxrwxrwx 1 root root 0 Jan 19 07:11 mnt -> mnt:[4026531840] root@clearfog:~# 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).

2 1