Add setting the onlink flag to the zapi_nh conversion
helper function so that we can set the onlink flag with
it when passing down NHGs from upper level protos.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Fix check in zread where we determine validity of a route
based on reading in nexthops/checking ID is present.
We had a bad conditional that was determining a route
is bad if its not NHG ID based.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
We were hard coding proto bgp for use with the NHG creation.
Use the actual passed one from zapi now that it exists.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Make NHG ID allocation smarter so it wraps once it hits
the lower bound for protos and performs a lookup to make
sure we don't already have that ID in use.
Its pretty unlikely we would wrap since the ID space is somewhere
around 24million for Zebra at this point in time.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
We were incrementing in the output the ID value when we
shouldnt be. The value the NHG is assigned is before its
incremented.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Determine the NHG ID spacing and lower bound with ZEBRA_ROUTE_MAX
in macros.
Directly set the upperbound to be the lower 28bits of the uint32_t ID
space (the top 4 are reserved for l2-NHGs). Round that number down
a bit to make it more even.
Convert all former lower_bound calls to just use the macro.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
When we receive a NHG from the kernel, we set the ID counter
to that to avoid using IDs owned from the kernel.
If we get one outside of zebra's range, lets not update it
since its probably one we created and never deleted anyway.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
For now let's assume proto-NHG-based routes are good to go
(we assume they are onlink/interface based anyway) and bypass
route resolution altogether.
Once we determine how to handle recursive nexthop-resolution for
proto-NHGs we will revisit this.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add code to properly handle routes sent with NHG ID rather
than a nexthop_group.
For now, we separate this from backup nexthop handling since that
should probably be added to the nhg_proto_add calls.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Implement the ability to replace an NHG sent down
from an upper level proto. With proto-owned NHGs, we make the
assumption they are ecmp and always treat them as a group
to make the replace from 1 -> 2 and 2 -> 1 quite a bit
easier.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
To prevent duplication of singleton NHGs, lets hash
any zebra-ID spaced NHGs sent from an upper level proto.
These would be singleton NHGs anyway and should prevent duplication
of dataplane installs.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Add a command/functionality to only install proto-based nexthops.
That is nexthops owned/created by upper level protocols, not ones
implicitly created by zebra.
There are some scenarios where you would not want zebra to be
arbitrarily installing nexthop groups and but you still want
to use ones you have control over via lib/nexthop_group config
and an upper level protocol.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Implement the underlying zebra functionality to Add/Del an
internal zebra and kernel NHG.
These NHGs are managed by the upperlevel protocols that send them
down via zapi messaging.
They are not put into the overall zebra NHG hash table and only
put into to the ID table. Therefore, different protos cannot
and will not share NHGs.
The proto is also set appropriately when sent to the kernel.
Expand the separation of Zebra hashed/shared/created NHGs and
proto created and mangaged NHGs.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Remove the code for setting a NHG as unhashable. Originally
this was to prevent us from attempting to put duplicates from
the kernel in our hashtable.
Now I think its better to not use them in the hashtable at all
and only track them in the ID table. Routes will still be able
to use them if they specify the ID explicitly when sending Zebra
the route, but 'normal' routes we hash the nexthop group on
will not.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Modify the sharpd program to have the ability to pass down
a NHG and then operate on it for route installation.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Modify the send down of a route to use the nexthop group id
if we have one associated with the route.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add the ability to send a NHG from an upper level protocol down to
zebra. ZAPI_NHG_ADD encompasses both the addition and replace
semantics ( If the id passed down does not exist yet, it's Add,
else it's a replace ).
Effectively zebra will take this nhg passed down save the nhg
in the id hash for nhg's and then create the appropriate nhg's
and finally install them into the linux kernel. Notification
will be the ZAPI_NHG_NOTIFY_OWNER zapi message for normal
success/failure messaging to the installing protocol.
This work is being done to allow us to work with EVPN MH
which needs the ability to modify NHG's that BGP will own
and operate on.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Take the zebra code that reads nexthops and combine it
into one function so that when we add zapi messages
to send/receive nexthops we can take advantage of this function.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Add new function zclient_get_nhg_start that will allow an
upper level protocol to get a starting point for it's own
nhg space. Give each protocol a space of 50 million.
zebra will own the space from 0 - 199999999 because
of SYSTEM, KERNEL and CONNECT route types.
This is the start of some work that will allow upper
level protocols to install and maintain their own NHG's.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
dh-systemd was merged into debhelper in version 9.20160709 [1] and since
stretch, dh-systemd is an empty transitional package.
For bullseye there's an intend to drop this empty transitional package.
This commit drops the "| dh-systemd" alternative Build-Depends as it is no
longer required (not even for backports) and is only confusing.
For Debian Jessie, it's easier to add backported debhelper >= 10 to the
repository.
The sphinx-build (since version 2.0.0) doesn't install the images into the
texinfo build directory. Workaround the issue, by copying the required
images from the source directory.
While it's ok to use individual wrapping/sorting in the debian/ source files,
it's often simpler to just go with the formatting supported by tools. One such
tool is wrap-and-sort, so this commit re-wraps and re-sorts the debian/ files to
be unified and (-a) always wrapped.
There are couple of related changes:
* Bump the debhelper dependency to the version at least in Debian Jessie
* Drop the dh-autoreconf, autotools-dev dependency, this is automatically
included.
* Drop the --parallel, --with=systemd and --with=autoreconf, this is
automatically enabled in dh compat level 10, add a --without=systemd
when requested via build profile.
The pkg.frr.snmp build profile is no longer present in the Debian build scripts,
so this just cleans up the old documentation that mentions it.
Signed-off-by: Ondřej Surý <ondrej@sury.org>
The debian/frr.conf was manually installed as systemd-tmpfiles configuration,
but the dh_installinit now has capability to install it automatically if named
debian/frr.tmpfile.
Signed-off-by: Ondřej Surý <ondrej@sury.org>
