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>
Add a zapi message type designed to carry opaque data. Add
'send' api, and prototype for client handler function. Also
add registration/unreg messages, so that clients can 'subscribe'
to receive these messages as they're passing through zebra.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Add utilities that init and deinit a stream_fifo - this lets us
use an on-stack fifo in some places, avoiding malloc'ing. Also
add const to some apis (no functional changes there).
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>
If present in a configured nexthop_group, include
backup nexthop/nhlfe info with LSP zapi add/update
messages.
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>
bgp_accept() gets called over and over again when a VRF device is
deleted out from under a bgp listener socket that is bound to it.
Prevent this by noting the error and cancelling ourselves, allowing the
vrf status code to clean up the mess when it receives word about the
change from Zebra.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Alpine builds have been failing for some time as a consequence of only
installing python 2 development packages when we have build scripts that
require python 3.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Try to give a bit more useful data about where we
think the connection is trying to come in from.
Hopefully this will let us debug connection issues
a bit faster in cases where there are config issues.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When received packet is processed in bgp_process_reads(), the data
is copied to static buffer and then copied to stream buffer.
The data can be copied directly to stream buffer which will avoid extra memcpy
Signed-off-by: kssoman <somanks@gmail.com>
Just add a basic test for pbr. This code
does not actually test installation in the kernel at this
point in time.
What we do do is make sure pbr is in a sane state after
some very basic configuration.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Just a simple setup for pbr to prove it starts. Once the json
code for pbr gets in we can add more.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
"set community accept-own-nexthop" returns "malformed communities"
error. This is because the token matching hits an earlier "accept-own"
and leaves "-nexthop" as a separate token to be processed.
Reorder the switch cases so that both are processed correctly.
Signed-off-by: Appu Joseph <apjo@kaloom.com>
we were not correctly checking the MPLS-TE status of the area when
adding an IP address to a circuit, and this was preventing the local
address TLV to be populated after an interfaced flap.
Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
Updated documentation for routers with a large route table, which breaks
SNMP/AgentX and in some conditions even crashes FRR. The documentation
proposal amends the SNMP configuration to exclude certain OID's that
are not needed in normal cases.
Format-fixed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Bart Vrancken <bart@abuse.io>
Description:
OSPF uses an algo to generate unique LSIDs when route updates
exists with same adrress and different masklens. It genearates
the unique LSIDs by masking its hostbits.
Ex :
Rt1 : 10.0.0.0/32 - LSID : 10.0.0.0
Rt2 : 10.0.0.0/16 - LSID : 10.0.255.255
Rt3 : 10.0.0.0/24 - LSID : 10.0.0.255
Observed an issue with external LSAs when such routes originated.
If the first route (with actual address as LSID) is got deleted,
the routes with same addresss(different msaks) are failed
to get LSA pointers from LSDB due to current fetching API design.
api : ospf_external_info_find_lsa
Here , it is allowing to look up the LSA with address specific
unique LSID (address with host bits set ex: 10.0.255.255) only
if the LSA exists where LSID as actual address of the route
(ex: 10.0.0.0 ) which is not expected and cauing for other issues.
Fix:
Corrected this logic, by looking up the LSA with unique LSID first
if it doesn’t exist then It is allowing to look up the LSDB with LSID
as address of the route.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Each northbound callback has a set of valid return values, some of
which might depend on the transaction phase. The valid return values
for each callback are documented in the northbound main header.
Add some code to detect when a callback returns an unexpected value
and log the occurrence. This should help us to identify and fix
such problems.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>