David Lamparter [Fri, 14 Dec 2018 15:08:25 +0000 (16:08 +0100)]
debian: cleanly split off from dist tarball
The debian/ directory is distributed separately for tarballs in 3.0
(quilt) format. Including it in the dist tarball causes problems with
automake when the separately distributed debian directory is unpacked on
top of the dist tarball; the clean and correct thing to do here is to
not include the debian/ directory in dist tarballs.
Users have two choices for building FRR Debian packages:
- build straight off git
- build from a "frr.tar" + "frr-debian.tar"
The tarsource.sh tool does the right thing when invoked with the -D
("Debian") option.
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Mon, 10 Dec 2018 21:46:55 +0000 (22:46 +0100)]
debian: clean up debian/ directory for git build
Running `dpkg-buildpackage` with source-format "git" complains about
newly created files under debian/. Remove the build-created frr.init &
frr.service to avoid the build erroring out due to this.
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Sun, 28 Oct 2018 17:54:14 +0000 (18:54 +0100)]
debianpkg: install libraries to /usr/lib64/frr
This makes them "private libraries" (which they are, since we don't
maintain a proper versioned ABI on libfrr.) This also properly fixes
another few lintian warnings.
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Tue, 23 Oct 2018 11:55:36 +0000 (13:55 +0200)]
debianpkg: add -0 to version
We need a -something suffix since otherwise part of our version number
(e.g. -dev or -DATE) will get taken as Debian sub-version. (Everything
after the last -)
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Thu, 25 Oct 2018 13:37:28 +0000 (15:37 +0200)]
debianpkg: always install /etc/init.d/frr
There is no point in making this conditional, systemd correctly prefers
the service file over the init script when it is present. Also, people
can install an init system that doesn't match their distribution and
even change init systems on an installation.
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Thu, 25 Oct 2018 13:00:55 +0000 (15:00 +0200)]
debianpkg: ditch development-only files
It is currently impossible to build external stuff that links against
installed FRR headers or libraries. Such projects need to directly
reference an FRR source tree until we revamp the library installation
semantics.
In any case these files would then be in a frr-dev Debian package.
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Wed, 24 Oct 2018 18:57:32 +0000 (20:57 +0200)]
debianpkg: raise debhelper compat level to 9
Compat level 7 has long been deprecated. 9 works fine for us, though it
does change the library installation directories to multi-arch. (Which
is not a problem.)
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Wed, 24 Oct 2018 15:20:29 +0000 (17:20 +0200)]
debianpkg: make frr-pythontools a "Recommends:"
From the Debian policy:
Recommends:
This declares a strong, but not absolute, dependency.
The Recommends field should list packages that would be found
together with this one in all but unusual installations.
I'd say, yes, we do want the python-based reload functionality in all
but unusual installations.
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Wed, 3 Oct 2018 17:14:27 +0000 (19:14 +0200)]
debianpkg: create frr-snmp and frr-rpki-rtrlib
This splits off SNMP and RPKI support so that users can install these
packages (with the appropriate dependencies) independently of main FRR.
It also obsoletes out the weird multi-variant package distribution we've
been doing for RPKI support.
The snmpd dependency is also changed to Recommends: on frr-snmp since
the frr-snmp package is essentially useless without snmpd.
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Tue, 23 Oct 2018 11:54:07 +0000 (13:54 +0200)]
debianpkg: use better dependency for pythontools
As described in https://wiki.debian.org/binNMU, arch-indep packages
should have an "almost identical" dependency so "+..." changes can be
made to arch-dep packages without breaking the arch-indep pkgs.
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Wed, 24 Oct 2018 15:01:11 +0000 (17:01 +0200)]
tools: add new tarsource.sh helper
It cleans your house and cooks dinner. Or maybe it creates a clean dist
tarball for you, plus a Debian .dsc if you have dpkg installed - and
GPG-signs the result appropriately if requested.
In any case the resulting tarball should be distributed for our
releases.
Signed-off-by: David Lamparter <equinox@diac24.net>
David Lamparter [Mon, 22 Oct 2018 11:37:53 +0000 (13:37 +0200)]
debianpkg: kill backports
The debianpkg/backports system is rather complicated and actually slows
down Debian package building quite a lot since the backports/rules file
is evaluated a zillion times during a normal build.
This just folds up everything into a single Debian package build that
works on all OSes. The only real difference that the backports stuff
was used for is switching between systemd and init.d, the latter for
Ubuntu 12.04 and 14.04.
With this, that switch is controlled by the pkg.frr.nosystemd
Build-Profile instead. Package builds for Ubuntu 14.04 need to supply
the -Ppkg.frr.nosystemd option to dpkg-buildpackage. (12.04 isn't
supported anymore anyway.)
Note that the update-rc.d step that was previously coded into
postinst/postrm is now handled by the dh_installinit magic.
Other than this, there were some minor build dependency differences, all
of which are now just handled as | in the central deps.
Signed-off-by: David Lamparter <equinox@diac24.net>
bgpd: flowspec redirect IP info is retrieved into nh tracking
redirect IP nh of flowspec entry is retrieved so that the nexthop
IP information is injected into the nexthop tracking, and is associated
to the bgp_path structure. This permits validating or unvalidating the
bgp_path for injection in zebra or not.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Philippe Guibert [Tue, 18 Dec 2018 17:00:31 +0000 (18:00 +0100)]
zebra: handle multiple events for netns deletion event
When handling events from /var/run/netns folder, if several netns are
removed at the same time, only the first one is deleted in the frr. Fix
this behaviour by applying continue in the loop.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Donald Sharp [Wed, 9 Jan 2019 17:18:21 +0000 (12:18 -0500)]
lib: Convert RUSAGE_SELF to RUSAGE_THREAD where we can
When using getrusage, we have multiple choices about what
to call for data gathering about this particular thread of execution.
RUSAGE_SELF -> This means gather all cpu run time for all pthreads associated
with this process.
RUSAGE_THREAD -> This means gather all cpu run time for this particular
pthread.
Clearly with data gathering for slow thread as well as `show thread cpu`
it would be preferable to gather only data about the current running
pthread. This probably was the original behavior of using RUSAGE_SELF
when we didn't have multiple pthreads. So it didn't matter so much.
Prior to this change, 10 iterations of 1 million routes install/remove
from zebra would give us this cpu time for the dataplane pthread:
Showing statistics for pthread Zebra dplane thread
--------------------------------------------------
CPU (user+system): Real (wall-clock):
Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread
0 280902.149 326541 860 2609982 550 2468910 E dplane_thread_loop
After this change we are seeing this:
Showing statistics for pthread Zebra dplane thread
--------------------------------------------------
CPU (user+system): Real (wall-clock):
Active Runtime(ms) Invoked Avg uSec Max uSecs Avg uSec Max uSecs Type Thread
0 58045.560 334944 173 277226 539 2502268 E dplane_thread_loop
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Wed, 9 Jan 2019 19:59:22 +0000 (14:59 -0500)]
lib, bgpd: Convert frr_pthread_set_name to only cause it to set os name of the thread
The current invocation of frr_pthread_set_name was causing it reset the os_name.
There is no need for this, we now always create the pthread appropriately
to have both name and os_name. So convert this function to a simple
call through of the pthread call now.
Before(any of these changes):
sharpd@robot ~/frr1> ps -L -p 16895
PID LWP TTY TIME CMD
16895 16895 ? 00:01:39 bgpd
16895 16896 ? 00:00:54
16895 16897 ? 00:00:07 bgpd_ka
Donald Sharp [Wed, 9 Jan 2019 19:32:44 +0000 (14:32 -0500)]
lib: Cleanup thread name setting to happen at start
When we start a thread we always call fpt_run and since
the last commit we know os_name is filled with something,
therefore we can just set the name on startup.
I removed the abstraction to frr_pthread_set_name because
it was snprintf'ing into the same buffer which was the
real bug here( the first character of os_name became null).
In the next commit I'll remove that api because
it is unneeded and was a horrible hack to get
this to work for the one place it was wanted.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Wed, 9 Jan 2019 18:41:46 +0000 (13:41 -0500)]
lib: On frr_pthread_new save a os_name
On call of frr_pthread_new, save the os_name if given,
if not given use the name passed in( shortening to fit
in available space ) and finally if the name was not
passed in use the default value.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Wed, 9 Jan 2019 13:48:37 +0000 (08:48 -0500)]
bgpd: Do not send a label to zebra that it doesn't understand
When using an `import vrf` mechanism we are marking
the vrf label as BGP_PREVENT_VRF_2_VRF_LEAK, and then sending
this down to zebra. Since zebra knows nothing about this special
value, convert it to a value that it does know MPLS_LABEL_NONE.
And zebra kept the label as:
donna.cumulusnetworks.com# show mpls table
Inbound Outbound
Label Type Nexthop Label
-------- ------- --------------- --------
-2 BGP GREEN
-2 BGP BLUE
After this fix, neither the labels are stored in zebra nor do we see
the log error message.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Rafael Zalamena [Tue, 8 Jan 2019 12:32:28 +0000 (10:32 -0200)]
zebra: fix FreeBSD warning on fresh OS boot
Handle corner case where a warning log message is issued on interface
address netmask handling with sockaddr type AF_LINK: it may come empty
or with match all (all 0xFF).
In the first case all lengths are zero and we only need to copy the
first bytes, second case it comes with a zero index and all 0xFF bytes.
In any case we only need to figure out a few of the first bytes instead
of all data.
Rafael Zalamena [Tue, 8 Jan 2019 10:14:28 +0000 (08:14 -0200)]
zebra: implement FreeBSD route attr handling
When porting routing socket macro data handling to functions, the
attribute function was forgotten. The only difference between the
attribute and address handler is the family type check.
`isis network point-to-point` was being rejected from the configuration
file as it was being processed before the reception of the UP zebra
notification for the interface. This meant that the `circ_type` was set
at CIRCUIT_T_UNKNOWN, which led the northbound callback to fail. This
check was removed as it was not really necessary; when the zebra
notification is received, the correct circuit type will be enforced,
but now the point-to-point config will be saved and correctly applied
when zebra recognizes the interface as a broadcast one.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
Renato Westphal [Wed, 2 Jan 2019 18:47:51 +0000 (16:47 -0200)]
zebra: silence harmless ioctl warning when retrieving interface speed
zebra uses the SIOCETHTOOL ioctl with the ETHTOOL_GSET command to
fetch the speed of interfaces from the kernel. The only problem is
that ETHTOOL_GSET returns EOPNOTSUPP when the given interface is a
virtual interface. This leads to zebra emitting warnings like this
at startup:
ZEBRA: IOCTL failure to read interface lo speed: 95 Operation not supported
ZEBRA: IOCTL failure to read interface dummy0 speed: 95 Operation not supported
ZEBRA: IOCTL failure to read interface ovs-system speed: 95 Operation not supported
Silence these warnings by ignoring EOPNOTSUPP errors, since we know
they are harmless. This is similar to how we handle EINVAL errors
from the BSD SIOCGIFMEDIA ioctl (commit c69f2c1ff).
Renato Westphal [Wed, 2 Jan 2019 15:05:53 +0000 (13:05 -0200)]
zebra, lib: fix the ZEBRA_INTERFACE_VRF_UPDATE zapi message
Unlike the other interface zapi messages, ZEBRA_INTERFACE_VRF_UPDATE
identifies interfaces using ifindexes and not interface names. This
is a problem because zebra always sends ZEBRA_INTERFACE_DOWN
and ZEBRA_INTERFACE_DELETE messages before sending
ZEBRA_INTERFACE_VRF_UPDATE, and the ZEBRA_INTERFACE_DELETE callback
from all daemons set the interface index to IFINDEX_INTERNAL. Hence,
when decoding a ZEBRA_INTERFACE_VRF_UPDATE message, the interface
lookup would always fail since the corresponding interface lost
its ifindex. Example (ospfd):
OSPF: Zebra: Interface[rt1-eth2] state change to down.
OSPF: Zebra: interface delete rt1-eth2 vrf default[0] index 8 flags 11143 metric 0 mtu 1500
OSPF: [EC 100663301] INTERFACE_VRF_UPDATE: Cannot find IF 8 in VRF 0
To fix this problem, use interface names instead of ifindexes to
indentify interfaces like the other interface zapi messages do.
Donald Sharp [Mon, 31 Dec 2018 22:49:47 +0000 (17:49 -0500)]
sharpd: Allow sharpd to accept nexthop group as part of route install
When installing routes via sharpd 'sharp install route... ' command
add the ability to specify a nexthop-group to use. This will
allow sharpd to create ECMP routes into zebra.
donna.cumulusnetworks.com# sharp install routes 10.0.50.0 nexthop-group JANELLE 10
donna.cumulusnetworks.com# end
donna.cumulusnetworks.com# show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
F - PBR, f - OpenFabric,
> - selected route, * - FIB route
K>* 0.0.0.0/0 [0/106] via 10.0.2.2, enp0s3, 00:20:38
C>* 10.0.2.0/24 is directly connected, enp0s3, 00:20:38
D>* 10.0.50.0/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.1/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.2/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.3/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.4/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.5/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.6/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.7/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.8/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
D>* 10.0.50.9/32 [150/0] via 192.168.209.1, enp0s8, 00:00:02
* via 192.168.210.1, enp0s9, 00:00:02
C>* 192.168.209.0/24 is directly connected, enp0s8, 00:20:38
C>* 192.168.210.0/24 is directly connected, enp0s9, 00:20:38
donna.cumulusnetworks.com#
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Renato Westphal [Mon, 31 Dec 2018 13:11:15 +0000 (11:11 -0200)]
ospfd: convert a couple of "show" commands to DEFPY
DEFPY commands are easier to maintain and less susceptible to
bugs. In the long term we should try to merge the plethora of
"show ip ospf neighbor" commands (total of 14) into a single DEFPY.
Donald Sharp [Mon, 31 Dec 2018 00:59:52 +0000 (19:59 -0500)]
eigrpd: Allow eigrp to set/unset the router-id as a value.
This code addition allows eigrp to set/unset the router-id
value. At this point I am not 100% sure that we do all the necessary
rework when a router-id changes. But on startup if read in before
a network statement we should be ok.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Mon, 31 Dec 2018 00:54:25 +0000 (19:54 -0500)]
eigrpd: eigrp usage of uint32_t to struct in_addr for router_id data
In eigrp we were using a uint32_t to hold the `struct in_addr` data
for the router id values. This caused us to do unnecessary conversions
pre and post for in/out. Let's just use the standard `struct in_addr`
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>