When installing a nexthop-group the recent commit:
commit 0be6e7d75d
reversed the logic for testing if adding data to
the netlink message succeeded and we thought we did
not thus not creating the nexthop group.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* Use nl_attr_add32 instead of nl_attr_add where it is possible.
* Move common code from build_singlepath() and build_multipath()
to separate function.
Signed-off-by: Jakub Urbańczyk <xthaid@gmail.com>
* Rename netlink utility functions like addattr to be less ambiguous
* Replace rta_attr_* functions with nl_attr_* since they introduced
inconsistencies in the code
* Add helper functions for adding rtnexthop struct to the Netlink
message
Signed-off-by: Jakub Urbańczyk <xthaid@gmail.com>
We had special-cased use of atomic_add_fetch, because clang just
does not like that builtin. Just use atomic_fetch_add instead.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Distinguish between unicast and broadcast opaque messages
in zebra handler code. Add cli and internal api changes to
have sharpd send unicast opaque messages. Add opaque cli
commands to the sharp user doc.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
* Implement new dataplane operations
* Convert existing code to use dataplane context object
* Modify function preparing netlink message to use dataplane
context object
Signed-off-by: Jakub Urbańczyk <xthaid@gmail.com>
This commit is the first step to convert IP rule installation to
use dplane thread.
* Add dataplane's internal representation of a pbr rule
* Add dplane stats related to rules
* Introduce a new type of dplane operation
Signed-off-by: Jakub Urbańczyk <xthaid@gmail.com>
Start modifying the OPAQUE zapi message to include optional
unicast destination zapi client info. Add a 'decode' api and
opaque msg struct to encapsulate that optional info.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Change name of an opaque zapi api to 'decode' to align with the
other zapi message parsing apis. Missed that in the original
opaque commits.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Let's prevent nhlfe_alloc from actually returning anything that can fail:
1) nexthop_new -> never returns NULL so checking for NULL here
makes no sense, remove it.
2) lsp not being NULL is a assert condition here as that it's
a precondition for the function to work properly.
3) since nhlfe_alloc cannot return NULL now remove tests
for it in callng functions
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Every time zebra receives a ZEBRA_PW_SET, zebra should call
zebra_evaluate_rnh.
This fixes a race condition where zebra sometimes fails to install a
pseudowire that is 'up', and has a reachable next hop.
Signed-off-by: Karen Schoener <karen@voltanet.io>
Issue:
When BGP sends aggregation routes to zebra, the next hop is black hole.
Then Zebra will try to build the netlink FPM message, but there is no
next hop as it is a black hole route. Then the netlink_route_info_fill
function returns 0. In the result, zebra will crashed in
"assert(data_len)" of zfpm_build_route_updates.
This issue also happen when I create a static black hole route via
staticd.
Fix:
As the netlink message of the blackhole route is legal, it should return
success.
Signed-off-by: Richard Wu <wutong23@baidu.com>
Add initial support to maintain client daemon registrations for
OPAQUE messages. Use the registered zapi client info to forward
copies of OPAQUE messages sent to zebra.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
The zapi code processes a batch of incoming messages, using a
fifo. Hand the entire batch into the main zebra handling code,
and let it loop through the individual messages.
Divert the special OPAQUE messages from the normal processing
flow, and offer them to the new zebra_opaque module instead.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Add a mutex used to manage the list of zclients. Add a busy
counter to the zapi client session, so that we can use a
client session from another pthread.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Add the zebra_opaque module, designed to offload some opaque zapi
message processing to a new, dedicated pthread. Add to the build;
also re-sort the lists of zebra files in subdir.am.
Start, stop, and clean-up the opaque module, integrate with zebra
start and shutdown.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Move some processing of zapi label messages so they can be
handled more efficiently. Handle zapi delete and replace
messages.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Add a 'check' api to hold the code that determines whether an LSP
can be freed or not. Replace calls to the free api with check
calls.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Handle backup nhlfes in LSP zapi messages. Capture backup info
with LSPs, capture backup info in the dataplane LSP processing.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Provide a way for the data plane to indicate pseudowire
status (such as: not forwarding, AC failure).
On a data plane pseudowire install failure, data plane
sets the pseudowire status.
Zebra relays the pseudowire status to LDP.
LDP includes the pseudowire status in the LDP notification
to the LDP peer.
Signed-off-by: Karen Schoener <karen@voltanet.io>
When deleting a p2p address from an interface, include
the destination address. Without this, we don't find the
internal connected datastruct and process the delete
correctly on netlink OSes.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
The northbound configuration callbacks should now print error
messages to the provided buffer (args->errmsg) instead of logging
them directly. This will allow the northbound layer to forward the
error messages to the northbound clients in addition to logging them.
NOTE: many callbacks are returning errors without providing any
error message. This needs to be fixed long term.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
`debug zebra packet detail` dumps the full message whereas
it had been dropping exactly 10 bytes, the size of the zebra header
Signed-off-by: Wesley Coakley <wcoakley@cumulusnetworks.com>
Currently zebra when you compile without router advertisements
will just say something like `cannot handle message 42`. Which
is not terribly useful to an end user.
Add some smarts to the zapi message handling to just do nothing
and output a debug if someone has it turned on.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
