summaryrefslogtreecommitdiffstats
path: root/zebra/zserv.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* zebra: Cleanup leaked memory on shutdown from GR codeDonald Sharp2024-03-131-0/+1
| | | | | | | | | | | | Recent commit: 6b2554b94a Exposed, via Address Sanitation, that memory was being leaked. Unfortunately the CI system did not catch this. Two pieces of memory were being lost: The zserv client data structure as well as anything on the client->gr_info_queue. Clean these up. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: create a single registry of daemons' default port valuesMark Stapp2024-02-011-3/+0
| | | | | | | | Create a single registry of default port values that daemons are using. Most of these are vty ports, but there are some others for features like ospfapi and zebra FPM. Signed-off-by: Mark Stapp <mjs@labn.net>
* *: Rename ZEBRA_NHRP_NEIGH_XXX to ZEBRA_NEIGH_XXXDonald Sharp2024-01-221-1/+1
| | | | | | This does not need to be nhrp specific. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* Merge pull request #12600 from donaldsharp/local_routesRuss White2023-12-051-2/+1
|\ | | | | *: Introduce Local Host Routes to FRR
| * *: Introduce Local Host Routes to FRRDonald Sharp2023-11-011-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Create Local routes in FRR: S 0.0.0.0/0 [1/0] via 192.168.119.1, enp39s0, weight 1, 00:03:46 K>* 0.0.0.0/0 [0/100] via 192.168.119.1, enp39s0, 00:03:51 O 192.168.119.0/24 [110/100] is directly connected, enp39s0, weight 1, 00:03:46 C>* 192.168.119.0/24 is directly connected, enp39s0, 00:03:51 L>* 192.168.119.224/32 is directly connected, enp39s0, 00:03:51 O 192.168.119.229/32 [110/100] via 0.0.0.0, enp39s0 inactive, weight 1, 00:03:46 C>* 192.168.119.229/32 is directly connected, enp39s0, 00:03:46 Create ability to redistribute local routes. Modify tests to support this change. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | zebra: add client counter for nhg operationsPhilippe Guibert2023-11-301-0/+3
|/ | | | | | | | | | | | | | | | | | | | Add three counters that account for the nhg operations that are using the zebra API with the NHG_ADD and NHG_DEL commands. > # show zebra client > [..] > Type Add Update Del > ================================================== > IPv4 100 0 0 > IPv6 0 0 0 > Redist:v4 0 0 0 > Redist:v6 0 0 0 > NHG 1 1 1 > VRF 3 0 0 > [..] Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* zebra: remove current_afi as that it is no longer usedDonald Sharp2023-03-291-3/+0
| | | | | | | After the restructure of the gr code to allow zebra_gr to have individual cleanups of afi, this is no longer necessary. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: zebra GR only works with AFI's limit itDonald Sharp2023-03-291-2/+2
| | | | | | | | | | | | | | | | We have code that tracks both afi and safi's, but we only ever operate on the afi's. So lets limit our work being done to something more sensible. I'm leaving the safi being broadcast through the zapi message, as that I am not sure what else should be ripped out at this point in time. Finally re-arrange the zread_client_capabilites function to stop the multiple levels of function calling that really serve no purpose. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: GR code could potentially stop runningDonald Sharp2023-03-291-1/+0
| | | | | | | | | | | | | | | | | | | When GR is running and attempting to clear up a node if the node that is currently saved and we are coming back to happens to be deleted during the time zebra suspends the GR code due to hitting the node limit then zebra GR code will just completely stop processing and potentially leave stale nodes around forever. Let's just remove this hole and process what we can. Can you imagine trying to debug this after the fact? If we remove a node then that counts toward the maximum to process of ZEBRA_MAX_STALE_ROUTE_COUNT. This should prevent any non-processing with a slightly larger cost of having to look at a few nodes repeatedly Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Convert event.h to frrevent.hDonald Sharp2023-03-241-1/+1
| | | | | | | We should probably prevent any type of namespace collision with something else. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Rename `struct thread` to `struct event`Donald Sharp2023-03-241-6/+6
| | | | | | | | | Effectively a massive search and replace of `struct thread` to `struct event`. Using the term `thread` gives people the thought that this event system is a pthread when it is not Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Rename thread.[ch] to event.[ch]Donald Sharp2023-03-241-1/+1
| | | | | | | | | | | This is a first in a series of commits, whose goal is to rename the thread system in FRR to an event system. There is a continual problem where people are confusing `struct thread` with a true pthread. In reality, our entire thread.c is an event system. In this commit rename the thread.[ch] files to event.[ch]. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: auto-convert to SPDX License IDsDavid Lamparter2023-02-091-14/+1
| | | | | | Done with a combination of regex'ing and banging my head against a wall. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* zebra: do not load/store wider-than-ptr atomicsDavid Lamparter2023-01-061-5/+10
| | | | | | | | | | | | | | | | Most 32-bit architectures cannot do atomic loads and stores of data wider than their pointer size, i.e. 32 bit. Funnily enough they generally *can* do a CAS2, i.e., 64-bit compare-and-swap, but while a CAS can emulate atomic add/bitops, loads and stores aren't available. Replace with a mutex; since this is 99% used from the zserv thread, the mutex should take the local-to-thread fast path anyway. And while one atomic might be faster than a mutex lock/unlock, we're doing several here, and at some point a mutex wins on speed anyway. This fixes build on armel, mipsel, m68k, powerpc, and sh4. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* zebra: use real MTYPEs for various objectsMark Stapp2022-12-051-0/+7
| | | | | | | Don't use MTYPE_TMP for many things in zebra: add specific mem types. Signed-off-by: Mark Stapp <mjs@labn.net>
* zebra: Convert time to uint64_t for zclient data structuresDonald Sharp2022-08-241-5/+5
| | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: clean up rtadv integrationDavid Lamparter2022-05-211-2/+2
| | | | | | | | | | | | Move a few things into places they actually belong, and reduce the number of places we have `#ifdev HAVE_RTADV`. Just overall code prettification. ... I had actually done this quite a while ago while doing some other random hacking and thought it more useful to not be sitting on it on my disk... Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* *: Change thread->func to return void instead of intDonald Sharp2022-02-241-1/+1
| | | | | | | The int return value is never used. Modify the code base to just return a void instead. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: link layer config and notification, implementation in zebraPhilippe Guibert2021-04-091-0/+3
| | | | | | | | | | | | | zebra implements zebra api for configuring link layer information. that can be an arp entry (for ipv4) or ipv6 neighbor discovery entry. This can also be an ipv4/ipv6 entry associated to an underlay ipv4 address, as it is used in gre point to multipoint interfaces. this api will also be used as monitoring. an hash list is instantiated into zebra (this is the vrf bitmap). each client interested in those entries in a specific vrf, will listen for following messages: entries added, removed, or who-has messages. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* zebra: remove fuzzing stuffJakub Urbańczyk2020-08-251-4/+0
| | | | | | | | | The fuzzing code that is in the master branch is outdated and unused, so it is worth to remove it to improve readablity of the code. All the code related to the fuzzing is in the `fuzz` branch. Signed-off-by: Jakub Urbańczyk <xthaid@gmail.com>
* Merge pull request #6483 from sylane/router-id-v6Donald Sharp2020-08-101-1/+1
|\ | | | | zebra: add IPv6 router-id
| * zebra: add IPv6 router-idSebastien Merle2020-07-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * add a vrf sub-command `[no] ipv6 router-id X:X::X:X`. * add command `[no] ipv6 router-id X:X::X:X [vrf NAME]` for backward compatibility. * add a vrf sub-command `[no] ip router-id A.B.C.D` and make the old one without `ip` an alias for it. * add a command `[no] ip router-id A.B.C.D [vrf NAME]` for backward comptibility and make the old one without `ip` an alias for it. * add command `show ip router-id [vrf NAME]` and make the old one without `ip` an alias for it. * add command `show ipv6 router-id [vrf NAME]`. * add ZAPI commands `ZEBRA_ROUTER_ID_V6_ADD`, `ZEBRA_ROUTER_ID_V6_DELETE` and `ZEBRA_ROUTER_ID_V6_UPDATE` for deamons to get notified of the IPv6 router-id. * update zebra documentation. Signed-off-by: Sebastien Merle <sebastien@netdef.org>
* | zebra: Ethernet segment management and support for MAC-ECMPAnuradha Karuppiah2020-08-051-0/+4
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Local ethernet segments are configured in zebra by attaching a local-es-id and sys-mac to a access interface - >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ! interface hostbond1 evpn mh es-id 1 evpn mh es-sys-mac 00:00:00:00:01:11 ! >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This info is then sent to BGP and used for the generation of EAD-per-ES routes. 2. Access VLANs associated with an (ES) access port are translated into ES-EVI objects and sent to BGP. This is used by BGP for the generation of EAD-EVI routes. 3. Remote ESs are imported by BGP and sent to zebra. A list of VTEPs is maintained per-remote ES in zebra. This list is used for the creation of the L2-NHG that is used for forwarding traffic. 4. MAC entries with a non-zero ESI destination use the L2-NHG associated with the ESI for forwarding traffic over the VxLAN overlay. Please see zebra_evpn_mh.h for the datastruct organization details. Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* zebra: add zserv_send_batch apiMark Stapp2020-06-021-0/+11
| | | | | | | Add a zserv api to send a batch (a fifo) of messages to a zapi client. Signed-off-by: Mark Stapp <mjs@voltanet.io>
* zebra: add lock and busy counter for zclientsMark Stapp2020-06-021-1/+30
| | | | | | | | 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>
* zebra: avoid using c++ keywords in headersEmanuele Di Pascale2020-05-141-1/+1
| | | | | | | to make sure that c++ code can include them, avoid using reserved keywords like 'delete' or 'new'. Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
* lib,zebra: add a session id for zapi sessionsMark Stapp2020-04-161-1/+20
| | | | | | | | | | Distinguish zapi sessions, for daemons who use more than one, by adding a session id. The tuple of proto + instance is not adequate to support clients who use multiple zapi sessions. Include the id in the client show output if it's present. Add a bit of info about this to the developer doc. Signed-off-by: Mark Stapp <mjs@voltanet.io>
* Merge pull request #5925 from volta-networks/synchronous_clientRenato Westphal2020-03-261-0/+3
|\ | | | | zebra: synchronous client queues accumulate messages from zebra
| * zebra: Synchronous client queues accumulate messages from zebra.Karen Schoener2020-03-231-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Zebra is currently sending messages on interface add/delete/update, VRF add/delete, and interface address change - regardless of whether its clients had requested them. This is problematic for lde and isis, which only listens to label chunk messages, and only when it is waiting for one (synchronous client). The effect is the that messages accumulate on the lde synchronous message queue. With this change: - Zebra does not send unsolicited messages to synchronous clients. - Synchronous clients send a ZEBRA_HELLO to zebra. The ZEBRA_HELLO contains a new boolean field: sychronous. - LDP and PIM have been updated to send a ZEBRA_HELLO for their synchronous clients. Signed-off-by: Karen Schoener <karen@voltanet.io>
* | treewide: add attribute to functions that do not returnRuben Kerkhof2020-03-191-1/+1
|/ | | | Signed-off-by: Ruben Kerkhof <ruben@rubenkerkhof.com>
* Zebra: Zebra gr dynamic client handling.Santosh P K2020-02-211-0/+4
| | | | | | | | | | | When a client connects to zebra with GR capabilities and then restarts, it might disconnect again even before hello is sent leading zebra cores. GR should be supported only for dynamic neighbor who are capable of restarting. Signed-off-by: Santosh P K <sapk@vmware.com>
* zebra: Capabality and stale route handling for GR client.Santosh P K2020-01-311-0/+4
| | | | | | | | | Handling capability received from client. It may contain GR enable/disable, Stale time changes, RIB update complete for given AFi, ASAFI and instance. It also has changes for stale route handling. Signed-off-by: Santosh P K <sapk@vmware.com>
* zebra: Handling of connection disconnect and connect with GR.Santosh P K2020-01-301-0/+6
| | | | | | | | | | | Zebra will have special handling for clients with GR enabled. When client disconnects with GR enabled, then a stale client will be created and its RIB will be retained till stale timer or client comes up and updated its RIB. Co-authored-by: Santosh P K <sapk@vmware.com> Co-authored-by: Soman K S <somanks@vmware.com> Signed-off-by: Santosh P K <sapk@vmware.com>
* zebra: Header file changes and show commands.Santosh P K2020-01-301-2/+49
| | | | | | | | | | | Adding header files changes where structure to hold received graceful restart info from client is defined. Also there are changes for show commands where exisiting commands are extended. Co-authored-by: Santosh P K <sapk@vmware.com> Co-authored-by: Soman K S <somanks@vmware.com> Signed-off-by: Santosh P K <sapk@vmware.com>
* lib,zebra: add zapi msg top level error handlingStephen Worley2020-01-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add error handling for top level failures (not able to execute command, unable to find vrf for command, etc.) With this error handling we add a new zapi message type of ZEBRA_ERROR used when we are unable to properly handle a zapi command and pass it down into the lower level code. In the event of this, we reply with a message of type enum zebra_error_types containing the error type. The sent packet will look like so: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Marker | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VRF ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ERROR TYPE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Also add appropriate hooks for clients to subscribe to for handling these types of errors. Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
* Zebra: adding support for Zebra MLAG FunctionalitySatheesh Kumar K2019-11-141-0/+7
| | | | | | | | | | | | | This includes: 1. Processing client Registrations for MLAG 2. storing client Interests for MLAG updates 3. Opening communication channel to MLAG with First client reg 4. Closing Communication channel with last client De-reg 5. Spawning a new thread for handling MLAG updates peocessing 6. adding Test code 7. advertising MLAG Updates to clients based on their interests Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
* Revert "Merge pull request #4885 from satheeshkarra/pim_mlag"Quentin Young2019-10-141-7/+0
| | | | | This reverts commit d563896dada99f3474d428f928786cbfde936fee, reversing changes made to 09ea1a40386f02a13cdb0462cc55af0d03f0c277.
* Zebra: adding support for Zebra MLAG FunctionalitySatheesh Kumar K2019-09-241-0/+7
| | | | | | | | | | | | | This includes: 1. Processing client Registrations for MLAG 2. storing client Interests for MLAG updates 3. Opening communication channel to MLAG with First client reg 4. Closing Communication channel with last client De-reg 5. Spawning a new thread for handling MLAG updates peocessing 6. adding Test code 7. advertising MLAG Updates to clients based on their interests Signed-off-by: Satheesh Kumar K <sathk@cumulusnetworks.com>
* zebra: label manager refactorEmanuele Di Pascale2019-07-101-1/+0
| | | | | | | | | | | | | | | | | | in order to both streamline the code and allow users to define their own specialized versions of the LM api handlers, define hooks for the 4 main primitives offered by the label manager (i.e. connect, disconnect, get_chunk and release_chunk), and have the existing code be run in response to a hook_call. Additionally, have the responses to the requesting daemon be callable from an external API. Note that the proxy version of the label manager was a source of issues and hardly used in practice. With the new hooks, users with more complex requirements can simply plug in their own code to handle label distribution remotely, so there is no longer a reason to maintain this code. Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
* zebra: Move multipath_num into zrouterDonald Sharp2019-05-141-2/+0
| | | | | | | The multipath_num variable is a property of zebra_router, so move it there. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* doc, zebra: Remove "table X" commandDonald Sharp2019-05-061-3/+0
| | | | | | | | | This command is broken and has been broken since the introduction of vrf's. Since no-one has complained it is safe to assume that there is no call for this specialized linux command. Remove from the system with extreme prejudice. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* zebra: fix zapi msg debugging dumpsQuentin Young2019-05-031-0/+16
| | | | | | | | | | When we switched to a pthread per client, we lost the ability to correlate zapi message debugs with their handlers in zlog, because the message was logged when it was read off the zapi socket and not right before it was processed. Move the zapi msg hexdump to happen right before we call the message handler. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* lib, zebra: changes to propagate vxlan mcast SG entries to pimdAnuradha Karuppiah2019-04-201-0/+2
| | | | | | | | These updates act as triggers to pimd to - 1. join the MDT for rxing VxLAN encapsulated BUM traffic 2. register the local-vtep-ip as a source for the MDT Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* zebra: When shutting down actually close the socketDonald Sharp2019-03-271-0/+7
| | | | | | | | When shutting down and we have a very large table to shutdown and after we've intentionally closed all the client connections close the zebra zserv client socket. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* add cplusplus guards to all zebra headersEmanuele Di Pascale2019-03-251-0/+8
| | | | Signed-off-by: Emanuele Di Pascale <emanuele@voltanet.io>
* zebra: Remove zclient->idinfo restrictionsDonald Sharp2019-02-051-3/+0
| | | | | | | | | | | | | | | | | | | | | The restricting of data about interfaces was both inconsistent in application and allowed protocol developers to get into states where they did not have the expected data about an interface that they thought that they would. These restrictions and inconsistencies keep causing bugs that have to be sorted through. The latest iteration of this bug was that commit: f20b478ef3d25e153939516a473bb2e80603cbd5 Has caused pim to not receive interface up notifications( but it knows the interface is back in the vrf and it knows the relevant ip addresses on the interface as they were changed as part of an ifdown/ifup cycle ). Remove this restriction and allow the interface events to be propagated to all clients. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* zebra: Remove `struct zebra_t`Donald Sharp2019-01-311-4/+0
| | | | | | This structure is unused anymore and does not belong in zserv.h Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* zebra: Move packets_to_process to zrouterDonald Sharp2019-01-311-2/+0
| | | | Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* zebra: Move lsp_process_q to zrouterDonald Sharp2019-01-311-3/+0
| | | | Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* zebra: Move the mq data structure to zrouterDonald Sharp2019-01-311-2/+0
| | | | Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 22:18:31 +0100