summaryrefslogtreecommitdiff
path: root/pathd/path_zebra.c
AgeCommit message (Collapse)Author
2025-04-08pathd: clean up variable-shadow warningsMark Stapp
Clean up various variable-shadow warnings from -Wshadow Signed-off-by: Mark Stapp <mjs@cisco.com>
2024-04-30pathd: retry synchronous label-manager zapi connectionMark Stapp
Be prepared to retry setting up pathd's synchronous zapi session that's used for label-manager. Signed-off-by: Mark Stapp <mjs@cisco.com>
2023-11-23*: add `zclient_options_sync`David Lamparter
... and use it instead of fiddling with the `.synchronous` field. (Make it const while at it.) Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2023-06-26pathd: Stop and free synchronous Zebra client on pathd terminationDonatas Abraitis
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2023-03-24*: Convert event.h to frrevent.hDonald Sharp
We should probably prevent any type of namespace collision with something else. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-24*: Convert `struct event_master` to `struct event_loop`Donald Sharp
Let's find a better name for it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-24*: Convert struct thread_master to struct event_master and it's ilkDonald Sharp
Convert the `struct thread_master` to `struct event_master` across the code base. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2023-03-24*: Rename thread.[ch] to event.[ch]Donald Sharp
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>
2023-02-09*: auto-convert to SPDX License IDsDavid Lamparter
Done with a combination of regex'ing and banging my head against a wall. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2022-07-22pathd: add a zebra stop handlerPhilippe Guibert
This handler code is used to stop zebra related contexts. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2021-10-20*: convert zclient callbacks to tableDavid Lamparter
This removes a giant `switch { }` block from lib/zclient.c and harmonizes all zclient callback function types to be the same (some had a subset of the args, some had a void return, now they all have ZAPI_CALLBACK_ARGS and int return.) Apart from getting rid of the giant switch, this is a minor security benefit since the function pointers are now in a `const` array, so they can't be overwritten by e.g. heap overflows for code execution anymore. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2021-05-10pathd. TED support . Client to link State - [part 1/4]Javier Garcia
- pathd will act as a client to for the configured igp. - pathd must be configured to activate and receive data from igp. !pathd config snippet segment-routing traffic-eng mpls-te on mpls-te import ospfv2 Signed-off-by: Javier Garcia <javier.garcia@voltanet.io>
2021-04-23*: make sure `config.h` or `zebra.h` is firstDavid Lamparter
`config.h` has all the defines from autoconf, which may include things that switch behavior of other included headers (e.g. _GNU_SOURCE enabling prototypes for additional functions.) So, the first include in any `.c` file must be either `config.h` (with the appropriate guard) or `zebra.h` (which includes `config.h` first thing.) Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
2021-01-04pathd: Fix unlock of non-locked mutexDonald Sharp
We have several instances of a non-locked mutex being unlocked in path_zebra_router_id_update. Clean this up. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2020-12-18pathd: New SR-TE policy management daemonSebastien Merle
This new daemon manages Segment-Routing Traffic-Engineering (SR-TE) Policies and installs them into zebra. It provides the usual yang support and vtysh commands to define or change SR-TE Policies. In a nutshell SR-TE Policies provide the possibility to steer traffic through a (possibly dynamic) list of Segment Routing segments to the endpoint of the policy. This list of segments is part of a Candidate Path which again belongs to the SR-TE Policy. SR-TE Policies are uniquely identified by their color and endpoint. The color can be used to e.g. match BGP communities on incoming traffic. There can be multiple Candidate Paths for a single policy, the active Candidate Path is chosen according to certain conditions of which the most important is its preference. Candidate Paths can be explicit (fixed list of segments) or dynamic (list of segment comes from e.g. PCEP, see below). Configuration example: segment-routing traffic-eng segment-list SL index 10 mpls label 1111 index 20 mpls label 2222 ! policy color 4 endpoint 10.10.10.4 name POL4 binding-sid 104 candidate-path preference 100 name exp explicit segment-list SL candidate-path preference 200 name dyn dynamic ! ! ! There is an important connection between dynamic Candidate Paths and the overall topic of Path Computation. Later on for pathd a dynamic module will be introduced that is capable of communicating via the PCEP protocol with a PCE (Path Computation Element) which again is capable of calculating paths according to its local TED (Traffic Engineering Database). This dynamic module will be able to inject the mentioned dynamic Candidate Paths into pathd based on calculated paths from a PCE. https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-06 Co-authored-by: Sebastien Merle <sebastien@netdef.org> Co-authored-by: Renato Westphal <renato@opensourcerouting.org> Co-authored-by: GalaxyGorilla <sascha@netdef.org> Co-authored-by: Emanuele Di Pascale <emanuele@voltanet.io> Signed-off-by: Sebastien Merle <sebastien@netdef.org>