summaryrefslogtreecommitdiffstats
path: root/lib/log.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* zebra,pimd,lib: Modify ZEBRA_NEXTHOP_LOOKUP_MRIBNathan Bahr2024-12-121-1/+1
| | | | | | | | | Modified ZEBRA_NEXTHOP_LOOKUP_MRIB to include the SAFI from which to do the lookup. This generalizes the API away from MRIB specifically and allows the user to decide how it should do lookups. Rename ZEBRA_NEXTHOP_LOOKUP_MRIB to ZEBRA_NEXTHOP_LOOKUP now that it is more generalized. This change is in preperation to remove multicast lookup mode completely from zebra. Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
* lib: refactor memstats logging, fix ACTIVEATEXITDavid Lamparter2024-10-171-1/+1
| | | | | | | | Move the various destinations handling into lib/memory.c, include "normal" logging as target, and make `ACTIVEATEXIT` properly non-error as it was intended to be. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* lib,zebra: remove unused ZEBRA_VRF_UNREGISTERDonna Sharp2024-10-071-1/+0
| | | | Signed-off-by: Donna Sharp <dksharp5@gmail.com>
* lib: Add ZAPI command `ZEBRA_SRV6_SID_NOTIFY`Carmine Scarpitta2024-06-131-1/+2
| | | | | | | Add a new ZAPI command `ZEBRA_SRV6_SID_NOTIFY` used by zebra to send asynchronous SRv6 SIDs notifications to zclients. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
* lib: Add ZAPI operations to get/release SRv6 SIDsCarmine Scarpitta2024-06-131-0/+2
| | | | | | | | Add two new ZAPI operations: `ZEBRA_SRV6_MANAGER_GET_SRV6_SID` and `ZEBRA_SRV6_MANAGER_RELEASE_SRV6_SID`. These APIs allow a daemon to get and release an SRv6 SID, respectively. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
* lib: Add ZAPI operation get SRv6 locatorCarmine Scarpitta2024-06-131-0/+1
| | | | | | | | Add a new ZAPI operation, ZEBRA_SRV6_MANAGER_GET_LOCATOR, which allows a daemon to request information about a specific locator from the SRv6 SID Manager. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
* *: Rename ZEBRA_NHRP_NEIGH_XXX to ZEBRA_NEIGH_XXXDonald Sharp2024-01-221-5/+5
| | | | | | This does not need to be nhrp specific. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* lib: HAVE_GLIBC_BACKTRACE does not belong in zebra.hDonald Sharp2024-01-041-0/+4
| | | | | | | | | | The backtrace functionality has been abstracted over to zlog_backtrace(). Now that every place uses this move the inclusion for HAVE_GLIBC_BACKTRACE into the appropriate files instead of having everyone pay for this costly include. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Introduce Local Host Routes to FRRDonald Sharp2023-11-011-0/+4
| | | | | | | | | | | | | | | | | | 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>
* lib: add support for new redistribute table-direct elementPhilippe Guibert2023-10-201-0/+4
| | | | | | | | | | | | | | | | Add a new kind of redistributed route that helps to import entries that are not copied in the default routing table. Contrary to the 'redistribute table' feature, the entries are directly obtained from the zebra appropriate routing table. The 'table-direct' naming expresses the direct redistribution of the routes, without having to copy the route entries in the default routing table. The distance value for this route is 14. Such route entries will be prioritary compared to 'table' and 'ebgp' route entries type. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* *: remove ZEBRA_INTERFACE_VRF_UPDATEanlan_cs2023-10-071-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | Currently when one interface changes its VRF, zebra will send these messages to all daemons in *order*: 1) `ZEBRA_INTERFACE_DELETE` ( notify them delete from old VRF ) 2) `ZEBRA_INTERFACE_VRF_UPDATE` ( notify them move from old to new VRF ) 3) `ZEBRA_INTERFACE_ADD` ( notify them added into new VRF ) When daemons deal with `VRF_UPDATE`, they use `zebra_interface_vrf_update_read()->if_lookup_by_name()` to check the interface exist or not in old VRF. This check will always return *NULL* because `DELETE` ( deleted from old VRF ) is already done, so can't find this interface in old VRF. Send `VRF_UPDATE` is redundant and unuseful. `DELETE` and `ADD` are enough, they will deal with RB tree, so don't send this `VRF_UPDATE` message when vrf changes. Since all daemons have good mechanism to deal with changing vrf, and don't use this `VRF_UPDATE` mechanism. So, it is safe to completely remove all the code with `VRF_UPDATE`. Signed-off-by: anlan_cs <anlan_cs@tom.com>
* lib: add notifications for opaque zapi messagesMark Stapp2023-06-231-1/+3
| | | | | | | | Add a new notification zapi message type. A zapi client that uses opaque messages can register to be notified when a server for an opaque type is present. Signed-off-by: Mark Stapp <mjs@labn.net>
* *: Rename `struct thread` to `struct event`Donald Sharp2023-03-241-2/+2
| | | | | | | | | 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>
* lib, bgpd: Add more debugs to GR Capability exchangeDonald Sharp2023-03-091-0/+20
| | | | | | | | | | | | | a) Make it legible what type of message is being passed back and forth instead of having to guess it from the insufficient debugs b) Make it explicit which bgp instance is sending this data c) Cleanup bgp_zebra_update to have a cleaner api Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: auto-convert to SPDX License IDsDavid Lamparter2023-02-091-16/+1
| | | | | | Done with a combination of regex'ing and banging my head against a wall. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* lib: fix zlog command types tableMark Stapp2022-12-081-7/+18
| | | | | | | Fix a number of differences between the zapi message enum and the log description table. Signed-off-by: Mark Stapp <mjs@labn.net>
* zebra, pimd: add AF param on NEXTHOP_LOOKUP_MRIBDavid Lamparter2022-04-261-1/+1
| | | | | | | | | | | By changing this API call to use a `struct ipaddr`, which encodes the type of IP address with it. (And rename/remove the `IPV4` from the command name.) Also add a comment explaining that this function call is going to be obsolete in the long run since pimd needs to move to proper MRIB NHT. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* lib: Prevent uninitialized bytesDonald Sharp2022-03-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | When using zlog_backtrace I am seeing this: ==66286== Syscall param write(buf) points to uninitialised byte(s) ==66286== at 0x4CDF48A: syscall (in /lib/libc.so.7) ==66286== by 0x4A0D409: ??? (in /usr/local/lib/libunwind.so.8.0.1) ==66286== by 0x4A0D694: ??? (in /usr/local/lib/libunwind.so.8.0.1) ==66286== by 0x4A0E2F4: _ULx86_64_step (in /usr/local/lib/libunwind.so.8.0.1) ==66286== by 0x49662DB: zlog_backtrace (log.c:250) ==66286== by 0x2AFFA6: if_get_mtu (ioctl.c:163) ==66286== by 0x2B2D9D: ifan_read (kernel_socket.c:457) ==66286== by 0x2B2D9D: kernel_read (kernel_socket.c:1406) ==66286== by 0x499F46E: thread_call (thread.c:2002) ==66286== by 0x495D2B7: frr_run (libfrr.c:1196) ==66286== by 0x2B4098: main (main.c:471) ==66286== Address 0x7fc000000 is on thread 1's stack ==66286== in frame #4, created by zlog_backtrace (log.c:239) ==66286== Let's initialize some data Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Rename quagga_timestamp with frr_timestampDonald Sharp2021-11-111-1/+1
| | | | Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* *: Remove the ZEBRA_IMPORT_ROUTE_XXX zapi messagesDonald Sharp2021-09-271-3/+0
| | | | | | | | | These are no longer really needed. The client just needs to call nexthop resolution instead. So let's remove the zapi types. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* Merge pull request #8237 from pguibert6WIND/nhrp_use_zebra_2Mark Stapp2021-05-051-1/+4
|\ | | | | Nhrp use zebra 2
| * zebra: add 3 new gre commands, and enforce synchro mecanismPhilippe Guibert2021-04-301-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 3 new gre commands are available: - GRE_GET to permit a daemon to retrieve gre information. - GRE_UPDATe is the reply message from zebra to the daemon. as it is a syncronous request, the GRE_GET expected will have to match the vrf id where the gre information is wished. this has an impact on label manager with change in APIs. - SET_GRE_SOURCE. this command will be stubbed for now, assuming that the gre interface is set accordingly by external script. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* | lib: rework how we "override" assert()David Lamparter2021-05-021-11/+0
|/ | | | | | | | | | | The previous method, using zassert.h and hoping nothing includes assert.h (which, on glibc at least, just does "#undef assert" and puts its own definition in...) was fragile - and actually broke undetected. Just provide our own assert.h and control overriding by putting it in a separate directory to add to the include path (or not.) Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* nhrp, zebra, lib: enforce usage of zapi_neigh_ip structurePhilippe Guibert2021-04-131-2/+2
| | | | | | | | | | | | | | | | zapi_nbr structure is renamed to zapi_neigh_ip. Initially used to set a neighbor ip entry for gre interfaces, this structure is used to get events from the zebra layer to nhrp layer. The ndm state has been added, as it is needed on both sides. The zebra dplane layer is slightly modified. Also, to clarify what ZEBRA_NEIGH_ADD/DEL means, a rename is done: it is called now ZEBRA_NEIGH_IP_ADD/DEL, and it signified that this zapi interface permits to set link operations by associating ip addresses to link addresses. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* lib: add api to configure neighbor table per interfacePhilippe Guibert2021-04-091-2/+2
| | | | | | | this api is needed for nhrp. the goal is to implement it in zebra, while other daemon will used it. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* nhrp, lib, zebra: add/del neighbor entry possible from nhrpPhilippe Guibert2021-04-091-1/+3
| | | | | | | | | a zebra api is extended to offer ability to add or remove neighbor entry from daemon. Also this extension makes possible to add neigh entry, not only between IPs and macs, but also between IPs and NBMA IPs. This API supports configuring ipv6/ipv4 entries with ipv4/ipv6 lladdr. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* zebra: link layer config and notification, implementation in zebraPhilippe Guibert2021-04-091-1/+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>
* lib: link layer neighbor registration and notification, define API msgsPhilippe Guibert2021-04-091-1/+5
| | | | | | | | | This patch implements new zapi api to get neighbor information that zebra knows and that other daemons may need to know. Actually, nhrp daemons is interested in getting the neighbor information on gre interfaces, and the API will be used for that. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* lib/zebra: zapi for installing EVPN nexthops from bgpAnuradha Karuppiah2021-03-261-1/+3
| | | | | | | | | | | | | | | | EVPN nexthops are installed as remote neighs by zebra. This was earlier done only via VRF IPvX uni routes imported from EVPN routes. With EVPN-MH these VRF routes now reference a L3NHG which is setup based on the EAD and doesn't include the RMAC. To workaround that BGP now consolidates and maintains EVPN nexthops which are then sent to zebra. zebra sets up these nexthops as L3-VNI nh entries using a dummy type-1 route as reference. Ticket: CM-31398 Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* Merge pull request #6766 from opensourcerouting/xrefRuss White2021-02-021-4/+6
|\ | | | | lib: xrefs - general cross-references & unique IDs
| * lib/xref: use to transport thread_* file/line/funcDavid Lamparter2021-02-011-4/+6
| | | | | | | | | | | | Just a better way of doing what was previously the "debugargdef" macro. Signed-off-by: David Lamparter <equinox@diac24.net>
* | lib: Prevent unininted usage of dataDonald Sharp2021-01-301-0/+3
|/ | | | | | | Valgrind reports that some data being used in the stack unwind of a crash is being used uninitailized. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* zebra: Adding zapi client close notificationKaren Schoener2020-12-081-1/+2
| | | | | | | When zebra detects a client close, send a zapi client close notification. Signed-off-by: Karen Schoener <karen@voltanet.io>
* bgpd: Advertise FIB installed routes to bgp peers (Part 1)Soman K S2020-11-061-1/+2
| | | | | | | | | | | | | | | | | | Issue: The bgp routes learnt from peers which are not installed in kernel are advertised to peers. This can cause routers to send traffic to these destinations only to get dropped. The fix is to provide a configurable option "bgp suppress-fib-pending". When the option is enabled, bgp will advertise routes only if it these are successfully installed in kernel. Fix (Part1) : * Added message ZEBRA_ROUTE_NOTIFY_REQUEST used by client to request FIB install status for routes * Added AFI/SAFI to ZAPI messages * Modified the functions zapi_route_notify_decode(), zsend_route_notify_owner() and route_notify_internal() to include AFI, SAFI as parameters Signed-off-by: kssoman <somanks@gmail.com>
* lib: add proto NHG Notif header to log command typesStephen Worley2020-09-281-1/+2
| | | | | | | Add the proto Nexthop Group Notify Owner header to the log command types for string conversion. Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
* lib: add logging for ZEBRA_NHG_ADD[DEL]Stephen Worley2020-09-281-1/+3
| | | | | | | | Add logging info for the new zapi ZEBRA_NHG_ADD[DEL] message types. With this patch, they are logged properly when debugs are turned on. Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
* lib, zebra: add support for sending ARP requestsJakub Urbańczyk2020-08-121-1/+2
| | | | | | | | | | We can make the Linux kernel send an ARP/NDP request by adding a neighbour with the 'NUD_INCOMPLETE' state and the 'NTF_USE' flag. This commit adds new dataplane operation as well as new zapi message to allow other daemons send ARP/NDP requests. Signed-off-by: Jakub Urbańczyk <xthaid@gmail.com>
* lib, zebra: Add SR-TE policy infrastructure to zebraSebastien Merle2020-08-071-0/+3
| | | | | | | | | | | | | | | | | | | | For the sake of Segment Routing (SR) and Traffic Engineering (TE) Policies there's a need for additional infrastructure within zebra. The infrastructure in this PR is supposed to manage such policies in terms of installing binding SIDs and LSPs. Also it is capable of managing MPLS labels using the label manager, keeping track of nexthops (for resolving labels) and notifying interested parties about changes of a policy/LSP state. Further it enables a route map mechanism for BGP and SR-TE colors such that learned BGP routes can be mapped onto SR-TE Policies. This PR does not introduce any usable features by now, it is just infrastructure for other upcoming PRs which will introduce 'pathd', a new SR-TE daemon. Co-authored-by: Renato Westphal <renato@opensourcerouting.org> Co-authored-by: GalaxyGorilla <sascha@netdef.org> 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>
* *: un-split strings across linesDavid Lamparter2020-07-141-6/+3
| | | | | | | | | | | | | | | | | Remove mid-string line breaks, cf. workflow doc: .. [#tool_style_conflicts] For example, lines over 80 characters are allowed for text strings to make it possible to search the code for them: please see `Linux kernel style (breaking long lines and strings) <https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings>`_ and `Issue #1794 <https://github.com/FRRouting/frr/issues/1794>`_. Scripted commit, idempotent to running: ``` python3 tools/stringmangle.py --unwrap `git ls-files | egrep '\.[ch]$'` ``` Signed-off-by: David Lamparter <equinox@diac24.net>
* lib: add OPAQUE zapi messageMark Stapp2020-06-021-1/+4
| | | | | | | | | 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>
* lib: rewrite zlog lock-free & TLS-bufferedDavid Lamparter2020-04-011-679/+24
| | | | | | | | | | | | | | | | | | | | | This is a full rewrite of the "back end" logging code. It now uses a lock-free list to iterate over logging targets, and the targets themselves are as lock-free as possible. (syslog() may have a hidden internal mutex in the C library; the file/fd targets use a single write() call which should ensure atomicity kernel-side.) Note that some functionality is lost in this patch: - Solaris printstack() backtraces are ditched (unlikely to come back) - the `log-filter` machinery is gone (re-added in followup commit) - `terminal monitor` is temporarily stubbed out. The old code had a race condition with VTYs going away. It'll likely come back rewritten and with vtysh support. - The `zebra_ext_log` hook is gone. Instead, it's now much easier to add a "proper" logging target. v2: TLS buffer to get some actual performance Signed-off-by: David Lamparter <equinox@diac24.net>
* lib: rewrite zlog_hexdump()David Lamparter2020-03-241-50/+38
| | | | | | | The old version was creating a multi-line log message, which we can't properly handle right now. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* *: use gmtime_r, localtime_r exclusivelyMark Stapp2020-03-051-3/+3
| | | | | | Stop using gmtime() or localtime() everywhere. Signed-off-by: Mark Stapp <mjs@voltanet.io>
* lib: add missing command DESC for MLAG messagesAnuradha Karuppiah2020-02-141-0/+5
| | | | | | | | | | | | This string is used in some logging for e.g. in zclient_read - >>>>>>>>>>>>>>>>>>>>>>>>>> if (zclient_debug) zlog_debug("zclient 0x%p command %s VRF %u", (void *)zclient, zserv_command_string(command), vrf_id); >>>>>>>>>>>>>>>>>>>>>>>>>> Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
* Merge pull request #5750 from qlyoung/fix-null-after-xfreeRenato Westphal2020-02-051-1/+0
|\ | | | | *: don't null after XFREE; XFREE does this itself
| * *: don't null after XFREE; XFREE does this itselfQuentin Young2020-02-031-1/+0
| | | | | | | | Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* | lib: Adding GR capabilites encode and decode.Santosh P K2020-01-301-1/+1
|/ | | | | | | | | | For Graceful restart clients have to send GR capabilities library functions are added to encode capabilities and also for zebra to decode client capabilities. 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>
* lib, zebra: add new MPLS zapi message with route replace semanticsRenato Westphal2019-09-101-0/+1
| | | | | | | This new message makes it possible to install/reinstall LSPs with multiple nexthops using a single ZAPI message. Signed-off-by: Renato Westphal <renato@opensourcerouting.org>