Arthur Jones [Mon, 12 Mar 2018 19:24:26 +0000 (12:24 -0700)]
docker build: build Alpine Linux dev packages in docker
Building alpine packages in a "standard" distro can be
complicated due to the limited scope of the distro (embedded
and small docker images). Building in a VM is one possibility,
but docker support for alpine is very good (default docker images
come in alpine due to the very small size).
Here, we want to package up the current git repo into apk packages
that can be easily installed in alpine linux using the apk tool.
This support is not intended to package released versions of
apk packages, that, if it comes to be, should be done here:
git://git.alpinelinux.org/aports
We're content here to build packages that can be used by developers
to try out frr in docker and other alpine environments.
This is a very minimal environment, we don't support importing
keys (so, installing the packages with apk requires the
--allow-untrusted option). In addition, we can't use the
git commit id in hex as version tag, as alpine doesn't support hex
digits in the version string. So, we need to convert the git hash
to decimal before tagging the package with the extra version.
This is yucky, but I can't think of another way to get a
unique version per package. The alpine way (using a numeric date),
only works for released packages, not for dev packages.
Issue: https://github.com/FRRouting/frr/issues/1859 Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
Arthur Jones [Mon, 19 Mar 2018 17:04:00 +0000 (10:04 -0700)]
redhat: enable dist tarball to build in a chroot
When building the rpms, we can use a chroot (in my case docker) to
ensure that the BuildRequires are complete. This test failed with
errors like:
checking for CARES... no
configure: error: trying to build nhrpd, but libcares not found. install c-ares and its -dev headers.
error: Bad exit status from /var/tmp/rpm-tmp.FewvLf (%build)
This is due to a couple missing BuildRequires in the spec file. Here, we
add those in for all RPM builds.
Testing done:
Ran a docker build on CentOS7 which succeeded. Loaded the modules onto
CentOS6 to make sure they were at least valid there, that succeeded.
Issue: https://github.com/FRRouting/frr/issues/1930 Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
Donald Sharp [Mon, 19 Mar 2018 01:30:27 +0000 (21:30 -0400)]
zebra: Compare to the number of elements not size of array
When figuring out whom to call and if we actually can legally
call into the handler array actually use the number of elements
in the array instead of the size of the array.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 16 Mar 2018 14:53:58 +0000 (10:53 -0400)]
lib, zebra: Signal the existence of labels on a nexthop for nht
When we are signaling to a client from zebra that a nexthop
has changed, include the labels on the nexthop as well.
Upper level protocols need to know if the labels exist
in order to make intelligent decisions about what to do.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 16 Mar 2018 04:02:56 +0000 (00:02 -0400)]
zebra: Read in on startup arbitrary tables
When we receive an arbitrary table over the netlink bus
save it for later perusal and sweep any routes that
we may have created from an earlier run.
The current redistribute code is limited to
ZEBRA_KERNEL_TABLE_MAX. I left this alone for the
moment because I believe it needs to be converted
to a RB tree instead of a flat array. Which is more
work for the future. Additionally this proposed
change might necessitate some cli changes or rethinks.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 16 Mar 2018 13:12:55 +0000 (09:12 -0400)]
bgpd: Clean up peer status checking for a received nlri
In bgp_update_receive the first thing we do is establish
that the peer->status is Established. We then do a bunch
of work and call bgp_nlri_parse where we break out for
each address family. Each AFI is then checking for
being peer->status is Established again. There is no
point in checking this again.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 15 Mar 2018 00:14:36 +0000 (20:14 -0400)]
zebra: Add some additional vrf info to debugs
There were several places where when I am attempting
to debug zebra functionality that I would really
like to have the ability to know what vrf I think
I am operating on.
Add the vrf_id to a bunch of zlog_debug messages
to help figure out issues when they happen.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Sat, 10 Mar 2018 20:12:52 +0000 (15:12 -0500)]
lib: Add nexthop-group cli
Add a nexthop-group cli:
nexthop-group NAME
nexthop A
nexthop B
nexthop C
!
This will allow interested parties to hook into the cli for
nexthops. Users can add callback functions for add/delete
of a nexthop group as well as add/delete of each individual
nexthop.
Future work( PBR and static routes ) will take advantage
of this.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Philippe Guibert [Tue, 13 Mar 2018 14:26:03 +0000 (15:26 +0100)]
lib: privileges are granted to vty netns command
Vty commands that link netns context to a vrf is requiring some
privileges. The change consists in retrieving the privileges at the
vrf_cmd_init() called by the relevant daemon. Then use it.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Quentin Young [Tue, 6 Mar 2018 23:08:37 +0000 (18:08 -0500)]
zebra: reorganize zserv, batch i/o
Group send and receive functions together, change handlers to take a
message instead of looking at ->ibuf and ->obuf, allow zebra to read
multiple packets off the wire at a time.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Tue, 6 Mar 2018 22:57:33 +0000 (17:57 -0500)]
zebra: standardize ZAPI message handler args
A lot of the handler functions that are called directly from the ZAPI
input processing code take different argument sets where they don't need
to. These functions are called from only one place and all have the same
fundamental information available to them to do their work. There is no
need to specialize what information is passed to them; it is cleaner and
easier to understand when they all accept the same base set of
information and extract what they need inline.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Quentin Young [Tue, 6 Mar 2018 22:01:42 +0000 (17:01 -0500)]
zebra: dont return a status code in zapi handlers
All of the ZAPI message handlers return an integer that means different
things to each of them, but nobody ever reads these integers, so this is
technical debt that we can just eliminate outright.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
projects / matthieu / frr.git / log